Use systemd-environmentd or pam to override xdg-paths about localdir HOT 7 CLOSED

Oh I see you are already using, is there a reason that editing the service is still needed?

from localdir.

I noticed that in some places you set vars manually or parse environment.d you can just call:
export $(run-parts /usr/lib/systemd/user-environment-generators | xargs)

Instead.

from localdir.

Hi, thanks for your interest in this repo! :-)

The PAM approach no longer works due to pam_env.so having deprecated the user_readenv option (discussions in linux-pam#7), hence my switch to something that does not involve PAM in cea0a05.

However, in that commit I also noticed that merely using environment.d does not work entirely as intended, because the systemd user instance itself does not adopt the variables. So while all user units adopt the new envvars, systemd itself reads its units from ~/.config/systemd, replaces %E in unit files by ~/.config, etc.

The way I see it, there is currently no way of solving the bootstrapping issue purely on a user level, hence my workaround solution of extending my user's [email protected] where possible, or simply give up and let systemd create a mess in my homedir.

On using the provided environment generators rather than parsing the variable files manually, that does seem more elegant indeed, thanks for the suggestion! :-)
I'll see if I can implement this sometime soon.

from localdir.

from localdir.

Improved environment generation in 5460772 (no more manual parsing). Not doing it with run-parts, because I cannot assume that to be universally available.

If you set the variables early enough than it picks them up.

Unfortunately, the "early enough" is "before the user unit starts", so it's either extending the user unit itself or setting the variables at PAM level (e.g. /etc/environment, which is ugly).

Ideally, [email protected] would allow the user to provide an environment file somewhere in it's home (I'd probably go with ~/.environment) that it sources with EnvironmentFile=-…, but I could not find a way to determine the user name from within the unit file. 🙁

from localdir.

Improved environment generation in 5460772 (no more manual parsing). Not doing it with run-parts, because I cannot assume that to be universally available.

I used xargs -0, didn't use eval but that seems to work too.

If you set the variables early enough than it picks them up.

Unfortunately, the "early enough" is "before the user unit starts", so it's either extending the user unit itself or setting the variables at PAM level (e.g. /etc/environment, which is ugly).

Ideally, [email protected] would allow the user to provide an environment file somewhere in it's home (I'd probably go with ~/.environment) that it sources with EnvironmentFile=-…, but I could not find a way to determine the user name from within the unit file. slightly_frowning_face

Yeah that is what I couldn't avoid too. But anything outside of /etc is chicken and e.g. issue.

from localdir.

Turned out my solution was a bit bugged (only found out later upon restarting my session), so had to adapt the variable exporting a little more with 1e25dd7, but it now works for me.

Going to close this for now, thanks for your input!

from localdir.