Update docs re superuser often needed for shared library installation

[javabrett]

Update docs to explain that some superuser access is likely to be required in most installation scenarios, as highlighted by https://github.com/mobile-shell/mosh/issues/188 . This is due to the dependency of binaries on dynamically-linked shared libraries, which are unlikely to be all pre-installed on most platforms, and will require superuser access to be installed. That is until/unless there is a statically-linked option for most server/client on some platforms.

[eminence]

I'm not sure this is the right clarification to make. While you need root to install system-wide binaries, you don't need root to install them into your home directory (or any other directory you have write-access to). This is true for both mosh, and the libraries that mosh depends on.

[javabrett]

Perhaps the wording is unclear - I was trying to make the addition succinct in this particular location.

Or perhaps I misunderstand all of the installation options. Do you say that it is possible to install a standard mosh-client and mosh-server into your home-directories, and have their less-commonly-installed dynamically-linked shared-library dependencies (e.g. protobuf) resolved by copies of libraries located in such a way that they don't require root access (i.e. also in home directory)? Is there a recipe for that somewhere? Do you just need to copy them to the same directory?

[eminence]

Yep. Here's a simple recipe that will build mosh and tmux and all of their dependencies. Then they will be installed into a directory of your choice (see INSTALL_DIR on line 13ish).

https://gist.github.com/eminence/85961d47244a140fde89314837d0db0a

If you didn't care about tmux, you can remove the build for libevent (but I find that mosh+tmux is a powerful combination, so I use this script whenever I have access to machines with build tools, but I'm without root access)

[cgull]

I think the point of this paragraph is that Mosh doesn't require any privileges or system installation to run successfully on most systems-- unlike sshd, it doesn't need reserved ports (≤1024) or access to the system's password hashes (/etc/shadow, /etc/master.passwd). So I think it should stand as is.

There's several ways for a user to get Mosh working on a system without all the required dependencies: build scripts, building Mosh as a static executable, or using library paths to access non-system shared libraries. Perhaps we could comment on that a bit in the "Building from source" section of the page?

[keithw]

I'm closing this, as shared libraries do not require superuser access to install. Happy to take a pointer to more complete installation instructions though, especially if they're already on the Wiki first (https://github.com/mobile-shell/mosh/wiki).

[javabrett]

@eminence the script in that gist is very helpful - thank you so much for it.

I'm currently making progress towards a self-contained build. A couple of early points of note:

• mosh-server wants to load libtinfo.so.6 (based on how I built):

bin/mosh-server: error while loading shared libraries: libtinfo.so.6: cannot open shared object file: No such file or directory

I read that ncurses actually includes this library and that creating a symlink can fix this, but the ncurses build command will need to be modified as it's not currently even creating shared objects.

• mosh (client, if you need that too) requires:

bin/mosh error: requires Perl 5.14 or Socket::GetAddrInfo.

... so a Perl kit is needed somewhere if looking for a portable client.

[andersk]

@javabrett You are probably picking up the libtinfo.so.6 dependency from your system ncurses? Note that @eminence’s gist fails to build ncurses and also fails to detect this failure (see comments there).