Lennart Poettering wrote on 24/07/14 11:59: > ... > snip > ... > I am pretty sure you will find people who will defend some of this > non-sense, but honestly, this is all is stuff that shouldn't exist.
OK, that was a fairly convincing message! Many thanks for taking the time and being so explicit. I now appreciate why the journal/coredump splitting is desirable and why it can/should be different from the sysusers range (and from each other too). That said, I'm still not convinced that it should be a simple setting in journald.conf only. If a package wants to install a service with it's own user and explicitly wants it to have it's own journal (is apache httpd a good example of this? Dunno, but it's conceivable either way!), then they would need the appropriate sysusers.d snippet but then they'd also have to either manipulate the journald.conf file's SplitUserRange line or use a dropin file that some generator uses to manipulate and configure the line accordingly. This just feels a bit too clunky. Would there be a a way to somehow keep SplitUserRange for basic (administrator) overrides, but also parse e.g. a column in the sysusers file to specify whether or not that user wants it's own journal [and another column for coredump]? The SplitUserRange setting could have syntax that allowed the admin to either extend the info found in sysusers (which would be the default), or explicitly override some setting. e.g. Say I wanted a split journal for UID 99 (a manually created system user), I could just say: SplitUserRange=99 and all the packaged preferences in sysusers files would still be honoured in addition to UID 99. If the sysusers file for apache's httpd had: u httpd 440 "HTTP User" y where "y" is the new "split journal" column, but I, as an admin, wanted to override that, I could just specify: SplitUserRange=99,-440 The leading "-" means "remove range". Of course an alternative would be to just override the sysusers file in /etc and put an "n" instead of the "y" (or leave it out), but there may be a desire for the admin to override all the journal splitting easily by doing something like: SplitUserRange=-1-65535 or SplitUserRange=-* It's maybe crossing a boundary (i.e. journald should maybe not be parsing sysuser's config files?), but it would certainly simplify packaging and avoid the need for the "config patching generator thingy". Iff it's OK to parse sysusers config from journal [and coredump] stuff, then perhaps it's also OK to parse it from shadow-utils? If so, then this is one step closer to your goal of killing login.defs. If direct parsing is NAKed perhaps it could just shell out to a systemd-sysusers-getnewuserdetails command which spat out a uid:gid pair (and took an optional --system argument), that way the parsing logic only needs to live in one place. This is obviously pretty racey, but I guess shadow-utils should really do some kind of locking on the files anyway. I've no idea if/how all of this would work when hooking things up to e.g. LDAP (I'm not even sure adduser+friends can do that?) I guess my main concern still remains that uid range settings for system users would now be in two places - one used by sysusers and another by adduser (I now accept your argument that the other two places are different configuration data even if it's conceptually similar). I want to be able to tell a user that the configuration is in one place not explain that package "system users ranges" are in one place and adduser's "system user range" is in another. Of course I'm assuming here that shadow-utils and it's adduser commands are still expected to be around for a while... perhaps this is considered legacy too these days (not sure what the replacement would be tho'!)? Sorry if this thread is getting a bit annoying, but I am convinced by most of the arguments now! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel