Chris SiebenmannI am sure I will not regret upgrading my eccentric office desktop from Fedora 42 to Fedora 43 through a live dnf upgrade the day before a long weekend.
(Well, I have to do it sometime, I've sat on this far too long.)
This is my unsurprised face that I am now gluing one local program back together because the old version broke in the upgrade. I hope that this is not an omen that the old old version of this program that I run at home will also break in the upgrade, because that would annoy me deeply. (I like the old old version better than the old version.)
On the negative side, gluing the local program back together took a lot more work than I expected at the start. On the slightly more positive side, apparently the old version was quietly broken too and I just didn't notice. Yay for actually testing things.
(In theory I could have done some of my stuff with local CSS hacks but in practice I'm building from source anyway so I already have a chainsaw running.)
I impulsively updated my home Fedora desktop to Fedora 43 this evening and the old old version of the program (Liferea) broke, which makes me unhappy because I liked the old UI better than the current one. On the other hand the old (old) version was very old in the tooth by now and being up to date is probably good for me.
I am going to be hacking the new UI, though (which, as usual, is HTML + CSS under the hood).
WHAT THE HELL. My home Fedora desktop (now Fedora 43) is refusing to start a 'systemd --user' daemon/session/etc when I log in on the tty/vty console. SSH in and the 'systemd --user' stuff starts (and then the console session can find it). This breaks sound, among other unpleasant things. At work this works, and I can't see any obvious /etc/pam.d differences.
This is apparently happening because direct console tty logins are now 'user-light' sessions which don't trigger things. On my work desktop, I run something from cron as an @ reboot thing that triggers user service manager startup but at home I don't so I get screwed.
Ah. I believe this is ancient sins coming back to haunt me. Many decades ago my UID was set to '19', a decision that has in no way haunted my Unix machines ever since. Low UIDs are by default system users and in systemd v258+, system users deliberately get a 'user-light' session.
Well. System users in systemd v258+ get a 'user-light' session if and only if they log in on a tty, if they log in via SSH they apparently get a 'user' session. I in no way understand this or how to manipulate this.
It turns out that I'm wrong about one detail of my work Fedora machine. It does open some sort of early session for me when it boots, but it's not from a crontab at-reboot entry and not from any 'User=' .service setting I can see. Loginctl says it's a 'manager-early' class with no seat associated.
All of this is rather charmingly opaque, and some of our users at work have low UIDs too (although none as low as 19, that was a Special Choice).
So pam_systemd's idea of who is a system user can in theory be influenced by userdb data (the 'disposition' field). However, I don't see a way of putting just some data about a user in userdb; all of the stuff seems to be all or nothing, and I need /etc/passwd et al to keep working.
So, #systemd people, am I missing something here, some way to set just the 'disposition' for a particular existing user without swallowing 100% of their user record into userdb?
Lennart Poettering@cks no, sorry, there is currently no way to merge NSS and userdb records...
a UID of 19 for a human, non-system user is highly problematic, and that not since systemd exists...
@cks what's your gid? on fedora gid 19 is assigned statically to the "floppy" group...
all of this is kinda fucked...
@pid_eins I have GID 200 (or 500 on the other desktop) because my login was indeed created that long ago even on Linux. So even without being UID 19 I'd have fallen into this trap. My natural UID would match the GID (UID 200 or 500), and it'd still be considered a system login (and a system GID).
grawity@cks That's the PAM session for systemd --user *itself* (its [email protected] has a PAMName=), which is why it has no seat.
Systemd by default honors SYS_UID_MAX in login.defs for the system/non-system UID boundary, unless Fedora disables that feature at build time...
@grawity Something is starting the session, though, which turns out to be that at some point loginctl's 'linger' was turned on for me at work¹, so a session starts during boot and sticks around perpetually. Unfortunately, I don't think login.defs can help me because of how it works. (I can't set the maximum system UID to 18, things would explode.)
stephen@cks maybe linger mode is enabled for your user on your work system?
see man loginctl section: enable-linger
@dmaonR Wow, you're right. For some reason, the work machine has linger mode turned on for me, while the home one doesn't. Based on timestamps in /var/lib/systemd/linger, that was set in 2021, but where and why is a good question.
I learn something new every day.
mirabilos
adb@cks I’ve only been doing Unix since 1987, and even then there was the convention mortal user accounts started at 100. There was the expectation a vendor service could have a hardcoded UID and installables owned by that, including setuid binaries, perhaps coming along in an upgrade after you had started using the system. And always the chance of software giving different treatment based on a numerical comparison of UID values. So congratulations on getting away with it for so long!
@adb Questionable decisions were made at the time, and not by me exactly¹.
¹ It was tradition in the group I joined that all system staff got extremely low UIDs, for reasons I don't know. I believe I got an unusually low UID even at the time, but possibly that was because it was a free UID. Then inertia carried it forward even when I had a couple of natural chances to change it (first due to NFS and later due to 'I'm going to dump|restore this filesystem and it has my old UID...').