Installer: Handle non-writable /usr/local

[ndarilek]

Trying to come up with the ultimate, hands-off, don't-have-to-touch-it Sandstorm installation for organizations with no or little tech competency. I think CoreOS and its automatic security updates might make a great choice since both the OS and Sandstorm could upgrade themselves without interaction.

Only, unfortunately /usr/local/bin isn't writable under CoreOS--or, at least, the installer fails trying to write the /usr/local/bin symlink. Would it be possible for the installer to either a) skip creating the /usr/local/bin symlink if writing fails, or b) put it in /opt/sandstorm/bin? I don't know if the systemd unit file accesses the binary directly, but I'm pretty sure /etc/systemd/system is writable so that much should work, and the unit could be updated to always access it directly rather than via the symlink.

Thanks.

[paulproteus]

Tentatively, I'm on board with this. I have two questions about this. First, what is the specific nature of writing to /usr/local/bin not working. Is it mounted read-only? If so, I guess that does make sense. Second, is there somewhere else we can put things that causes them to appear on the user's $PATH? Maybe we should offer to use $HOME/.local/bin if /usr/local/bin doesn't work. I'm also OK with skipping it, I guess. I'm also A-OK with adding an install.sh environment variable that causes it to not even try to set up the /usr/local/bin symlink. To answer your question - I'm pretty sure the systemd unit doesn't need this. The sysvinit unit might, but I think CoreOS is 100% systemd, so that should be fine.

[ndarilek]

1. Yes, it is read-only. I think everything outside of /opt and /etc is
   mounted RO.
2. CoreOS has /opt/bin in the user's $PATH by default, though in my
   fresh VM /opt doesn't exist. It can be created just fine though.

CoreOS is indeed 100% systemd.

Thanks.