Bug 1118907

Summary: [PATCH] 90-default.preset: Don't use systemd-sysusers yet
Product: [Fedora] Fedora Reporter: Colin Walters <walters>
Component: systemdAssignee: systemd-maint
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: gholms, johannbg, lnykryn, mattdm, msekleta, s, systemd-maint, tomek, vpavlin, zbyszek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-11-07 02:21:41 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
[PATCH] 90-default.preset: Don't use systemd-sysusers yet
none
Don't use systemd-sysusers yet none

Description Colin Walters 2014-07-11 21:34:25 UTC
Created attachment 917437 [details]
[PATCH] 90-default.preset: Don't use systemd-sysusers yet

This already caused SELinux issues, which I fixed, but let's just do this all at once for F22 instead of having a halfway state for F21 where only systemd itself does it.

Comment 1 Lennart Poettering 2014-07-23 19:25:23 UTC
Hmm? sysusers is statically enabled, the preset stuff doesn't work for it...

Also, it is a noop unless people flush /etc out, or touch /usr manually...

it's designed to not break anything unless explicitly used...

Comment 2 Colin Walters 2014-07-23 19:33:18 UTC
I think sysusers was run because systemd 215 added new users/groups, but didn't update the spec file for them.  For example, the systemd-journal-remote group.

Comment 3 Colin Walters 2014-07-24 15:38:08 UTC
Created attachment 920596 [details]
Don't use systemd-sysusers yet

New patch which uses the proper configure flag, and updates the spec files for new users.

Comment 4 Colin Walters 2014-07-30 11:54:02 UTC
What we have to decide here is whether it's worth having sysusers run for just systemd in F21 or not.  I think it just makes things more confusing, and we should look at doing it for more RPMs for F22.

Comment 5 Matthew Miller 2014-07-30 12:55:31 UTC
Is there a downside to delaying this until F22?

Comment 6 Zbigniew Jędrzejewski-Szmek 2014-07-31 03:47:59 UTC
I applied a patch similar to attachment #920596 [details], to create the new users in the journal-remote-gateway package.

(In reply to Matthew Miller from comment #5)
> Is there a downside to delaying this until F22?
Why would we do that? Unless explicitly used (by adding a sysusers file without creating users in a packaging scriptlet), sysusers should almost have no effect (the only one I see is having /etc/.updated and /var/.updated files around). At this point, it is likely that we discovered (and fixed) bugs in the implementation, so keeping it around should be safe. Nobody is proposing to do a mass conversion to sysusers, but early adopters can play around with it.
I don't see how it differs from any other new technology which is opt-in.

So, are there any concrete concerns preventing leaving systemd-sysusers in F21?

Comment 7 Colin Walters 2014-07-31 14:26:54 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #6)

> So, are there any concrete concerns preventing leaving systemd-sysusers in
> F21?

It creates a halfway state where sysusers is only kind of used.  If systemd is later rebased and you forget to add the users to the spec file, then it'll come into play.

We can leave it on in rawhide, right?

Comment 8 Zbigniew Jędrzejewski-Szmek 2014-11-07 02:21:41 UTC
So, sysusers is enabled in F21, but not used. Systemd package is now stabilizing, errors with sysusers seems to have been ironed out. We shouldn't be adding new functionality, which means we should not be adding new users too... It is fine to leave it on imho.