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).