Non-interactive ssh sessions don't have necessary environment variables

[maquak]

When using ssh for non-interactive session, environment variables used by runtime_loader are not set, PATH is set, but LIBRARY_PATH and ADDON_PATH are not.

This causes for example jam builds to fail when executed via non-interactive ssh:

runtime_loader: Cannot open file libroot.so(needed by /boot/system/bin/cat): No such file or directory

To reproduce:

> ssh user@192.168.0.100 env                                                                     
SHELL=/bin/bash
PWD=/boot/home
LOGNAME=user
HOME=/boot/home
SSH_CONNECTION=192.168.0.200 53891 192.168.0.100 22
USER=user
SHLVL=0
SSH_CLIENT=192.168.0.200 53891 22
PATH=.:/boot/home/config/non-packaged/bin:/boot/home/config/bin:/boot/system/non-packaged/bin:/boot/system/bin:/bin:/boot/system/apps:/boot/system/preferences
MAIL=/var/mail/user
_=/boot/system/bin/env

Expected: PATH, LIBRARY_PATH and ADDON_PATH set in environment.

[waddlesplash]

I just opened #17360 which is the "meta" ticket about this exact problem.

[maquak]

#17360 is only partially related, I already did some investigation and:

• sshd does not propagate it's own environment onto created sessions, instead it creates new environment from scratch with some variables that are used across all systems (implemented in ​do_setup_env fn). Even if I start sshd from my interactive shell, then ssh sessions do not inherit any of my shell's variables.
• we could fix this for Haiku:

a) by patching do_setup_env to also set Haiku-specific variables, but it's another patch to maintain and it also requires that sshd itself is started with LIBRARY_PATH and ADDON_PATH set and most likely it's not (#17360)

b) by adding SetEnv to default sshd_config

I'll go with option b)

[waddlesplash]

I note sshd does not have LD_LIBRARY_PATH in do_setup_env, but it does have PATH. That seems odd, how does that work on Linux then?

Option b) may be OK, but let's look at the other options first.

[maquak]

Replying to waddlesplash:

I note sshd does not have LD_LIBRARY_PATH in do_setup_env, but it does have PATH. That seems odd, how does that work on Linux then?

I have only one Linux host to test and I don't have LD_LIBRARY_PATH set at all there. According to man for ld.so it just uses default directories if LD_LIBRARY_PATH is not set. I would kinda expect Haiku's loader to work similar, so your question got me thinking that maybe the problem I have with my build is not that LIBRARY_PATH is not set, but it's actually set during build to something weird (I think I've seen line like export LIBRARY_PATH="something:$LIBRARY_PATH"). I'll check this...

[waddlesplash]

Yes, indeed, the problem is that Jam modifies LIBRARY_PATH in various places, so runtime_loader does not use its default directories.

[maquak]

I tried to modify BuildSetup file to enforce that LIBRARY_PATH is set before overwriting it with broken value, but I failed with Jam. I give up, I'll just use source /system/boot/SetupEnvironment before running jam.