Bug 1598900 - tmpfiles snippet tries to create folder owned by nonexistent user
Summary: tmpfiles snippet tries to create folder owned by nonexistent user
Keywords:
Status: ASSIGNED
Alias: None
Product: GlusterFS
Classification: Community
Component: build
Version: 4.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Kaleb KEITHLEY
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-06 19:30 UTC by Eli Schwartz
Modified: 2019-10-22 08:02 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.