| > Virtually every Linux distribution anyone would use to host a service such as Sandstorm will include a package manager. Yes, but: * Most of them ship on a 6-month or even 2-year release cycle whereas Sandstorm updates every week. * Most of them will not accept a package that wants to self-containerize with its own dependencies, which means Sandstorm would instead have to test against every different distro's dependency packages every week, whereas with self-containerization we only depend on the Linux kernel API -- which is insanely stable. * If we publish the packages from our own repo, we're back to square one: how does the user get the signing key, if not from HTTPS download? * Sandstorm actually has a PGP-verified install option: https://docs.sandstorm.io/en/latest/install/#option-3-pgp-ve... * You should probably be installing Sandstorm in its own VM anyway. I'm certainly not saying curl|bash is perfect. There are trade-offs. For now this is the trade-off that makes the most sense for us. Later on, maybe something else will make sense. > If they think that will ever be acceptable in an enterprise environment where change management is important, they're delusional. We've never had an enterprise customer comment on this (other than requesting the PGP-verified option, which we implemented). The vast majority of complaints come from HN, Twitter, and Reddit. ::shrug:: |
That's fine. Run your own repo where you control the release cycle. Puppet does this. GitLab does this. PostgreSQL does this. Sandstorm does not do this.
> Most of them will not accept a package that wants to self-containerize with its own dependencies, which means Sandstorm would instead have to test against every different distro's dependency packages every week, whereas with self-containerization we only depend on the Linux kernel API -- which is insanely stable.
GitLab ships an omnibus installer with their CE/EE product, and it works great. I don't see why Sandstorm couldn't also publish an omnibus installer which contains all the dependencies, in essence creating your own container in somewhere neutral like /opt
This way, you have atomic releases you can install. How do I select the version to install with 'curl | bash' without user interaction?
> If we publish the packages from our own repo, we're back to square one: how does the user get the signing key, if not from HTTPS download?
Publish your signing key as a distribution package. This is what most organizations do (e.g. EPEL, PostgreSQL, Puppet).
Then the user does 'apt-get install sandstorm-release', 'apt-get update', 'apt-get install sandstorm' and you have an authenticated release.
Your signing infrastructure should be secure enough that you don't have to change the signing key within the major release cycle of a Linux distribution anyway.
> You should probably be installing Sandstorm in its own VM anyway.
This isn't an excuse for 'curl | bash' installs. If they want to recommend that their customers run the product in a VM or container, they should provide appliance/container images, as well as packages.
> We've never had an enterprise customer comment on this
I am in enterprise, although I'm not a sandstorm customer. I will tell you that one of the first considerations when deciding on a product is how well it fits into our existing infrastructure. If I can't push a repo and install a specific version of the software, tested and known working, using puppet, it's not getting deployed in our org.
Perhaps the reason none of Sandstorm's enterprise customers are asking for packaged installers is because every enterprise customer who expects a packaged installer sees Sandstorm's installation method and decides not to use it.