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?
I'm blind, that commit just migrated it from root => gluster, and added the post-install routine.
Kaleb, Niels, would like to hear your opinions here.
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.
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.
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.
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.
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 :)
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