provide distribution packages

[hex-m]

To make Sandstorm easier to install and update it should ideally be available via distribution package managers. The most important targets would be Debian and Fedora as many (popular) distributions use those repositories as a base. https://github.com/sandstorm-io/sandstorm/issues/1603 is about getting Sandstorm into Linux Mint but this issue is more general.

[Michael-S]

This was discussed on the mailing list a few times. I think this post explains why Sandstorm does not yet have packages for major distributions yet: https://groups.google.com/d/msg/sandstorm-dev/9BeBsiM6Cpw/e9WNZJR2BgAJ

Short summary (and someone who knows the project better can correct me): the project's rate of change is quick enough that it doesn't make sense to have packages in the official Debian or Ubuntu repositories. The sandstorm packages would be obsolete long before the release reached end-of-support.

[kentonv]

So, I have a controversial opinion here, and I apologize in advance since I know many people very much disagree with me here.

I'm not sure that distro packages would make Sandstorm easier to install or upgrade. Sandstorm's installer and self-containerization strategy make it pretty easy to install across all Linux distros today, and updates are entirely automatic. Automatic updates are a big deal not just for ease of administration and security, but also because we can more-or-less guarantee to Sandstorm developers that they do not need to support non-current versions of Sandstorm. It would be pretty unfortunate if developers start having to worry about backwards-compatibility and probing for features.

Distro packages would also be a fair amount of work for us to maintain and test. Since presumably Sandstorm would use the distro's dependency mechanism rather than ship its own dependencies with a self-container, it would be necessary to test every target distro before every release. The current self-containerization strategy, on the other hand, avoids dependency skew entirely and makes us pretty confident that the same release will work regardless of host distro. I feel that the extra cost to ship distro packages would not be the best use of our resources, especially as they become more constrained.

So, my preference is not to ship distro packages, or, perhaps, to ship distro packages that deliver only the installer, which in turn installs Sandstorm using the current mechanism. (The latter would allow bootstrapping cryptographic trust, since the installer in turn verifies the PGP signature on the package it downloads.)

But as always I am interested in hearing other people's thoughts.

[kpreid]

While I don't hold the opinion that substantial effort should be spent on this, some arguments for it:

• Being in your distro's package manager is a signal of respectability.
• …and of having a sane effects-of-installation and _un_installer. (Packages or the software they install can do whatever, of course, but there's generally rules about what a package should do.)

• It allows comparatively convenient software installation on machines that cannot access the Internet, since a collection of packages can be put on disks/LAN servers, and the folks who run such machines might also be interested in Sandstorm as replacement for cloud (that is, you-must-have-internet-access) services.

  (Note that this in particular is not satisfied by the “package the installer” strategy.)

[kentonv]

Yeah, I feel like the best argument for distro packages comes down to expectations and assurances... Even though packages can do whatever they want, you can usually expect that a distro package installs cleanly, uninstalls cleanly, doesn't break other parts of your system, etc.

Sandstorm's installer, I believe, satisfies all these desires as well, in some cases better than the distro package managers do -- but new users don't know that upfront.

[Michael-S]

I do have one suggestion to mull over: what about making official software packages for some of the rolling release distributions? Arch Linux, Gentoo, OpenSuse Tumbleweed, Void Linux. (I have a soft spot for Void, but it's undoubtedly the least popular of the four so probably not a good way to invest your time if you want to invest your time efficiently to grow the community.) Then you have something available in official package repositories but expected to be updated as often as necessary.

I think it makes sense to pursue your current course. I just wanted to toss that idea out.

[NickeZ]

There are also other standardized ways to install software on modern distros like snaps and flatpak. I would be really hesitant to simply run a script from a website..

[sghosh151]

I think there is a balance between being a distro package and leveraging the distro packaging formats and mechanism. With the current sandstorm packaging mechanism - there is very little community knowledge about the format for packages, how to verify that the intended services are running, etc. The distro packaging mechanism on the other hand are pretty well understood - rpm and deb packages can be listed, inspected, files verified, etc.

It is possible to package using distro formats, limit yourself to the FHS hierarchy and not depend on anything in the distro except for sysvinit|systemd and glibc

I was just trying a sandstorm install today - and the install just is not working. I have no installer version number to be able to report against. It would be good if the install.sh reported a version number.

---

su -c "sandstorm admin-token" - sandstorm

su: warning: cannot change directory to /home/sandstorm: No such file or directory Generated new admin token. Please proceed to:

http://sandstorm.dlab.example.org:6080/setup/token/a49ba84cb5fcb0ddb1c3b7722ee9be98e3954604

Here you can access the admin settings page and configure your login system. You must visit the link within 15 minutes, after which you will have 24 hours to complete the setup process. If you need more time, you can always generate a new token with sandstorm admin-token.

ss -t

State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 127.0.0.1:6081 127.0.0.1:45580
ESTAB 0 0 127.0.0.1:6081 127.0.0.1:45576
ESTAB 0 0 127.0.0.1:45576 127.0.0.1:6081
ESTAB 0 0 192.168.122.17:ssh 192.168.122.1:55024
ESTAB 0 0 127.0.0.1:6081 127.0.0.1:45578
ESTAB 0 0 127.0.0.1:45578 127.0.0.1:6081
ESTAB 0 0 127.0.0.1:45580 127.0.0.1:6081

No processes running at port 6080

[necrose99]

Gentoo (Sabayon Funtoo other Gentoo based) https://github.com/sandstorm-io/ < sandstorm-overlay.. 9999 packages ... get sandstorm scripts , add docker etc from dependencies. in gentoo 9999 denotes LIVE git clone , make etc with emerge. but install other dependencies first. sandstorm---name?-2.0.1.3.ebuild , simple bash with API's... and a sandbox emake =make econf ./configure .. https://github.com/tianon/docker-overlay will need a gentoo chroot for repoman/ ebuild/emerge for manifest sig... and testing. , however on packaging > sandstorm.io script , run setup script for users, mainly the package will yank in all depends... and install script/s run script for (LAZY) users.

for RPM or Debian OBS can create in a repo https://github.com/sandstorm-io/deb/debian , ubuntu , RPM RH,CENT,SUSE etc. alpha,Beta ,Live , Kill old packages , own the repo and can force it to update to current. OWN your bin repo , then if thier using dated , can just have them re-install /upgrade... on install it will just run the script for your (LAZY) users.