Please don’t hard-code assumptions

>That is my major issue with systemd: That it postulates that everybody else shall adapt to its conventions, w/o configurability, even if there other conventions exist for a very long time.

This is also pretty difficult here. In our case, Central LDAP is used by groups throughout the University, and getting a complete list of people who use the UIDs is difficult, because the UID attribute is one that is available without needing to authenticate.

So, if we wanted to change someone's UID, we would have to perform a large outreach campaign, which still wouldn't catch everyone. Then, on the day of the change, everyone involved would trigger a big series of `find -user … -exec chown new_uid {} \;` commands, across all of their file storage. Oh, and you'd have to ensure that the user isn't logged in _anywhere_ while the change is done.

Now, in a normal organization, there would be a manager somewhere up the hierarchy who is in charge, and who would tell people "you have to do this, on this schedule". Or, you will have a corporate IT department who sets the policies. Here, the common manager is the University President. Forcing a move like this would burn a fair amount of 'political capital'.

Plus, and this may sound petty, but we were there first. What I mean is, we allocated those UIDs before systemd picked that range to use.

So I hope you can understand now why "adapt[ing] your own UID allocation" is pretty difficult to do here.

Not sure what you mean? There are multiple ways to expose environment variables to services. The most straightforward one being

https://coreos.com/os/docs/latest/using-environment-varia...

What more is required here?