image: add /etc/environment

[MilhouseVH]

Executables (scripts, binaries) installed via add-ons are not accessible to sshd unless the full add-on path is specified because profiles are not sourced unless the user actually logs in to an interactive session.

This is a particular issue with rsync:

hias@lenny:~$ mkdir /tmp/videos
hias@lenny:~$ rsync -avn root@xbmc:~/videos/ /tmp/videos/
sh: rsync: not found
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(235) [Receiver=3.1.3]
hias@lenny:~$ rsync -avn --rsync-path=/storage/.kodi/addons/virtual.network-tools/bin/rsync root@xbmc:~/videos/ /tmp/videos/
receiving incremental file list

In the case of rsync, the current workaround is to specify the full path of the remote LibreELEC rsync binary to the rsync client (with --rsync-path=/storage/.kodi/addons/virtual.network-tools/bin/rsync) but this is far from ideal.

Installing rsync into the image would also work, but this is wasteful and doesn't solve the problem for other add-on installed executables, and we can't install them all in to the image...

This PR provides a general solution by adding the system-wide /etc/environment file which is sourced by sshd when a session is connected allowing add-on executables to be successfully located on the PATH.

I've added /bin and /sbin to the base PATH set by 98-busybox.conf as although /bin is a symbolic link to /usr/bin, sshd doesn't seem to follow symbolic links. eg:

rpi4:~ # which date
/usr/bin/date
rpi4:~ # exit
Connection to rpi4 closed.

with /bin in /etc/environment

neil@nm-linux:~/projects$ ssh root@rpi4 -C date
Mon Dec 16 22:39:10 GMT 2019

without /bin in /etc/environment

neil@nm-linux:~/projects$ ssh root@rpi4 -C date
sh: date: not found

[lrusak]

Really not a fan of this. It adds patches and a bunch of custom stuff to make it work.

is it really so bad to use the full path?

rsync -avn --rsync-path=/storage/.kodi/addons/virtual.network-tools/bin/rsync root@xbmc:~/videos/ /tmp/videos/

[MilhouseVH]

It was more for the convenience, and because this is a general issue. I didn't think the patches were too intrusive. The alternative would be to install rsync into the image, but of course that only solves the issue for rsync. Fortunately rsync assumes that the remote binary may not be in the standard location or on the default PATH and provides the --rsync-path workaround, but not all client tools may be so accommodating.

[HiassofT]

As commented in Slack: with /etc/environment directly processed by sshd we're basically mimicing what normal Linux distros with PAM enabled do as well.

Having to specify the rsync path on the host is a really awful thing - same goes for tvheadend which can't find ffmpeg on it's path and probably lots of other cases.

Installing binaries to non-standard locations that are not on PATH is biting us now. We need to fix that.

[MilhouseVH]

Created separate envconfig.service to generate/regenerate /etc/environment.

[MilhouseVH]

I've added /bin and /sbin to the base PATH set by 98-busybox.conf as although /bin is a symbolic link to /usr/bin, sshd doesn't seem to follow symbolic links. eg:

I've reverted the 98-busybox.conf commit (and will squash it later) as I think the problems as mentioned in the first post with /bin were due to my mount -bind testing setup (which thinking about it probably broke the /bin to /usr/bin sym link). When testing a build that includes this PR (ie. without mount --bind) I don't have any issue with /bin (in fact which date now returns /usr/bin/date as expected).

[vpeter4]

For rsync and ffmpeg just make symbolic link in image to addon's location and problem will go away?

[MilhouseVH]

@vpeter4 Yes it would, but that's fixing the issue for those two examples only, and we'd be littering the image with (for most users) broken links (and if we ever decided to reorganise add-ons and move the location of an executable, how would that work with links in some versions of LE pointing to the wrong location?)

This is a general solution that works for everything, without any unnecessary hacks (apart from re-using some AIX functionality). The /etc/environment file is a standard Linux facility these days.