I've found a few solutions for GDM on Ubuntu, but they're no good to me - I log in to the CLI on Arch and then launch my DE with startx, if I need a gui session.
I can doubtless kludge it by abusing SystemD services: I already provision my system by running a systemD service that runs a script to mount the data partition on the system drive to /srv/sys, remount it to /srv/sys/0, test for the presence of external drives and mount them over the corresponding default locations (/srv/sys/1../srv/sys/3), if found — that way, if any of the external drives isn’t present, it defaults to the location on the data partition and rsyncs the next time the external drive is found to keep the two locations up-to-date with each other.
So it shouldn't be impossible to set some environment variables in the same script.
Or I could possibly risk a cron job as root on reboot.
But I'd rather do it cleanly (and without the security hole of the cron job) and am hoping that there's a default location/entry that (unlike /etc/profile or /etc/environment) will initialise them up before login.
My last hope before resorting to a kludge is that the DefaultEnvironment= entry in /etc/systemd/system.conf is the place for it (or rather an /etc/systemd/system/*.conf.d dropin file).
But the man page is typically curt and it's really not clear if it is or not.
Nor have I found anything online that makes it any more so; the closest I've found is one discussion mentioning how to form the entries (but not why) - everything else revolves around kludges with service files (and is, moreover, not even clearly applicable to pre-login).
I'm just gonna have to suck it and see, I guess - either system.conf dropins work or they don't.
But I need to get it sorted out one way or the other, so I can move on to the next stage: autologging the user into a default account and then immediately presenting the login for a systemd-nspawn container (that will hold the working version of the GNU suite, user config, etc.) … which is (unsurprisingly) also proving quite tricky to provision in the manner I'd like — sad to say, there hasn’t been an OS yet that wasn’t entirely inadequately conceived, let alone implemented *sigh*.
So, I need to get the base system properly architecturally provisioned before I can then try to use a container that doesn’t bootstrap itself from /home/<user> or /var/lib/machines/<container>, but simply presents the whole FSH directly from its actual location (/srv/sys//${SYSVAR_ORG}/${SYSVAR_DOMAIN}/${SYSVAR_SAN}/${SYSVAR_SITE}/${SYSVAR_DEVICE}/${SYSVAR_VOLUME}/is/profiles/systems/local/${SYSVAR_HOST} — meaning that all that need be done on any given host is initialise the appropriate values prior to login for the correct target host to be provisioned to the user
… from amongst
7,500 users per host
32,768 hosts per volume
32,768 volumes per device
25,000 devices (RAID, JBOD, single disk) per SAN
3 SANs per domain (mirrored across 2+ sites per domain)
1,000 domains per organisational unit (business/governmental/other enterprise/individual subscriber)
1,0000 organisational units per instance
So, flexibility is the watchword … and requires simplicity as a result (common config with just localised environment variables to maintain per host) — so, I’d rather avoid kludges, if possible, and make use of standard config options, for the sake of ease of maintenance by way of automation.
