Bug 1598900

Summary:	tmpfiles snippet tries to create folder owned by nonexistent user
Product:	[Community] GlusterFS	Reporter:	Eli Schwartz <eschwartz93>
Component:	build	Assignee:	Kaleb KEITHLEY <kkeithle>
Status:	CLOSED UPSTREAM	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.1	CC:	bugs, kkeithle, ndevos, rkothiya
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-03-12 13:03:05 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:

Description Eli Schwartz 2018-07-06 19:30:50 UTC

When installing glusterfs using --with-tmpfilesdir=/usr/lib/tmpfiles.d a tmpfiles snippet is installed that creates /run/gluster owned by the "gluster" user, but the user itself is never created and won't exist without user intervention.

Initially introduced in https://github.com/gluster/glusterfs/commit/0e50c4b3ea734456c14e2d7a578463999bd332c3 which is the commit which introduced the snippet itself.

Looks like the sysusers.d snippet was instead inlined as part of the redhat-specific build scripts in a post-install statement, which is quite odd.

Rather than requiring distros to reimplement this on their own, it should be moved to a sysusers.d snippet.

Aside: why is this disabled by default, and why does it use a --with-*=$path argument then heuristically check if it is nonexistent instead of an --enable-* argument which uses the default path?

Comment 1 Eli Schwartz 2018-07-06 19:33:14 UTC

I'm blind, that commit just migrated it from root => gluster, and added the post-install routine.

Comment 2 Amar Tumballi 2019-06-14 10:16:54 UTC

Kaleb, Niels, would like to hear your opinions here.

Comment 3 Niels de Vos 2019-06-14 12:53:56 UTC

For the Fedora (and CentOS) packaging we follow the Fedora Guidelines. https://fedoraproject.org/wiki/Packaging:UsersAndGroups does not recommend to use sysusers.d (https://www.freedesktop.org/software/systemd/man/sysusers.d.html) but the 'manual' getent/groupadd procedure.

We could include a sysusers.d snippet and install it. But it would need to be removed (or not installed) by the included glusterfs.spec.in file.

Comment 4 Kaleb KEITHLEY 2019-06-20 11:54:06 UTC

Since Eli has an archlinux email address I'd venture this is a Debian/Ubuntu/Arch issue and the Debian packaging bits need something similar to the 'gluster' user and group creation in the %pre section of the glusterfs.spec(.in)

The GlusterFS packaging files for Debian are at https://github.com/gluster/glusterfs-debian if someone would like to send a PR for such a change.

Comment 5 Eli Schwartz 2019-06-20 14:24:44 UTC

Yeah, I added those bits right after submitting this ticket: https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/glusterfs&id=89503fa1665343a1724e7dc0dc3733b57f4e92c9

I still figure it probably makes sense to ship the paired files. e.g. what happens if you use sudo make install, that does not run fedora %pre either. If nothing else, a sysusers.d file serves as documentation for what to do, and for distros that do expect to use them, it's always best to have a canonical one.

Comment 6 Eli Schwartz 2019-06-20 14:33:28 UTC

BTW: Arch Linux decided to take advantage of sysusers.d for account creation, because it is more convenient than running lots of post-install shellscript fragments and because it can recover from a wiped passwd db in time to make the corresponding tmpfiles.d succeed.

I am curious why Fedora guidelines say not to use them. It looks like that page is very, very old, its current form dates to 2013-04-17, and systemd added the sysusers.d file format and systemd-sysusers tool with systemd 215, released 2014-07-03. Perhaps it has simply never been updated since then?

I know systemd ships with its own sysusers.d snippets internally, and according to https://rpmfind.net/linux/RPM/fedora/devel/rawhide/x86_64/s/systemd-242-3.git7a6d834.fc31.x86_64.html it also packages them.
The specfile at https://src.fedoraproject.org/rpms/systemd/blob/master/f/systemd.spec does not seem to delete the sysusers.d files, but it does *additionally* include %pre macros which execute useradd/groupadd.

This would indicate, perhaps, that glusterfs should both (optionally) install a sysusers.d file, and (mandatory) run useradd in %pre.

Comment 7 Niels de Vos 2019-10-22 08:02:03 UTC

Wow, sorry that this took so long to reply. I only received an email from Bugzilla with list of NEEDINFOs on me today!?

From /usr/lib/rpm/macros.d/macros.systemd:
# This should be used by package installation scripts which require users or
# groups to be present before the files installed by the package are present on
# disk (for example because some files are owned by those users or groups).
#
# Example:
#   Source1: %{name}-sysusers.conf
#   ...
#   %install
#   install -D %SOURCE1 %{buildroot}%{_sysusersdir}/%{name}.conf
#   %pre
#   %sysusers_create_package %{name} %SOURCE1
#   %files
#   %{_sysusersdir}/%{name}.conf

Together with sysusers.d(5) this is pretty well explained.
There are a few packages in Fedora that place files under /usr/lib/sysusers.d, so that is not prohibited and glusterfs could use that as well. It does not seem to be part of CentOS-7 though, so the older method of creating the user/group is still needed.

I do not have any objection to adding a sysusers.d snippet :)

Comment 8 Worker Ant 2020-03-12 13:03:05 UTC

This bug is moved to https://github.com/gluster/glusterfs/issues/992, and will be tracked there from now on. Visit GitHub issues URL for further details