Lennart Poettering <[email protected]> writes: > On Thu, 07.03.13 16:41, Gergely Nagy ([email protected]) wrote: > >> While a separate group to own the journal files is desirable, which >> group it is should be tweakable (to the point where it can be set to >> an existing group, like adm, for systems where that makes sense). >> >> To this end, this patch introduces a --with-journal-group=GROUP option >> to configure, and uses the supplied value (or systemd-journal, if none >> specified) as the dedicated group. > > I don't think this is really desirable. This group is something external > packages should be able to make use of and rely on, and it would be > suboptimal if you'd have to configure this group everywhere manually.
The main reason behind the patch is that I already have systems installed where logfiles belong to a dedicated group, and when I'll be migrating those to systemd & journal, I'd like to keep the groups and not introduce yet another one that does the same thing. There's already more groups on my systems than I need, I'd like to trim them down, not introduce new ones. It *can* be considered a corner case, as I also have very few, and only trusted users, so the adm group was a perfect fit for my use case. > Note that your patch already ran into one instance of the problem of > making this configureable: systemd-journal-gatewayd.service refers to > this group in SupplementaryGroups= in order to get access to the journal > files, which your patch didn't update. So, you see, it already made > BOOM! once to have this configurable, because it was too hard to keep > things in sync. Yeah, my bad. Caught that a few moments after sending the patch, and started to investigate if I missed anything else too. :( That's what I get for "submit first, test later". > So, I am very conservative on making this configurable, but hey, I can > be convinced, so can you make a really good case for this? Apart from the case I outlined above, all other reasons I'd have boil down to convenience. Similarly how the 'tty' group's ID is configurable, the journal group being similarly configurable would make it much easier downstream to adapt the journal to an existing environment. Sure, I could patch it, but... I don't like patching, it makes it harder to follow upstream in the long run. With a configure flag, I can just update my sources and rebuild. If I have to patch, I need to fix any conflicts, or even at best, refresh patches so they apply without fuzz. Will even need to pay attention to any new places the hard-coded group gets introduced aswell, and update the patch. That's a tedious job, one I'd rather avoid. Making it configurable would allow me to follow systemd more closely. Perhaps a warning can be added to the configure switch that changing it from the default may very well break external tools, or even hide the option (if that is possible with autoconf). I do understand your concern, and wholeheartedly agree that it does bear some risk, but with clear documentation or with a hidden configure flag, I think those risks are negligible, while the benefits are great for those of us who can upgrade software, but not change policy. I mean, if I have to add the users I have in the adm group to systemd-journal aswell, that means adding the group to LDAP, then updating the users too... ick. Too much work for no real gain for me. -- |8] _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
