Install Packages with "useradd" Commands in RPM's

[MaxHerrmannSVA]

Hi,

I am currently working on a Image that i want to pitch to my coworkers/company that is based on plain Silverblue.

While installing some Agents I saw, that a the user that should be created within the Image is just not there...

So I created a small RPM File, that just creates a user and installs a small "hello-world" bash script, to test this.

The Image with the Package gets build successfully but the user is also not installed.
When installing the same package with "rpm-ostree install" the user gets created...

See the RPM SPEC File here:

RPM SPEC File

Name:           hello-world
Version:        1.0
Release:        1%{?dist}
Summary:        Simple Hello World shell script

License:        MIT
BuildArch:      noarch

Source0:        hello-world.sh

%description
A simple RPM package that installs a Hello World shell script
and creates a dedicated system user.

%prep
# Nothing to prepare

%build
# Nothing to build

%install
mkdir -p %{buildroot}%{_bindir}

install -m 0755 %{SOURCE0} %{buildroot}%{_bindir}/hello-world

%pre
# Create the system user before files are installed.
if ! getent passwd helloworld >/dev/null; then
    useradd \
        --system \
        --no-create-home \
        --shell /sbin/nologin \
        helloworld
fi

%post
echo "hello-world installed successfully."
echo "The 'helloworld' system user is available."

%preun
# $1 == 0 means the package is being completely uninstalled.
if [ "$1" -eq 0 ]; then
    if getent passwd helloworld >/dev/null; then
        userdel helloworld
    fi
fi

%files
%{_bindir}/hello-world

%changelog
* Wed Sep 30 2026 Package Maintainer <maintainer@example.com> - 1.0-1
- Initial package

Has anybody experienced the same issue when installing something that should have created some users?
I dont want to open an issue (yet), because I want to dive deeper ;)

[Arthur031221]

Put the account definition in the image as a sysusers.d file. Your RPM's %pre runs useradd during installation, but it does not leave a declarative account definition for the booted image. This also explains why a later rpm-ostree install can behave differently: rpm-ostree has special handling that synthesizes sysusers definitions for useradd during client-side layering.

Create files/system/usr/lib/sysusers.d/helloworld.conf in your BlueBuild repository with this line:

u helloworld - "Hello World Service" /nonexistent /usr/sbin/nologin

Copy it with the BlueBuild files module:

modules:
  - type: files
    files:
      - source: system
        destination: /

I exercised that exact sysusers line against an isolated filesystem root with systemd 255:

$ systemd-sysusers --root="$PWD/.tmp/galaxy-bluebuild/root"
Creating group 'helloworld' with GID 999.
Creating user 'helloworld' (Hello World Service) with UID 999 and GID 999.
$ rg '^helloworld:' .tmp/galaxy-bluebuild/root/etc/passwd
helloworld:x:999:999:Hello World Service:/nonexistent:/usr/sbin/nologin

After building and booting the new image, check getent passwd helloworld on the target. You can also ship the same file inside the RPM under /usr/lib/sysusers.d/ instead of copying it separately. Avoid deleting a persistent system account in %preun; removal of an image package does not imply that its service data or files have gone away.

[MaxHerrmannSVA]

Thanks for the quick and helpful reply @Arthur031221 !

But does this behavior breaks a lot of compatibility with RPM's that create some user or group?

First you always have to check first if a user/group is installed with a RPM and second if you create some files with a user in the install container, how can you garantee that the files got the same uid/gid than the user systemd is creating for you?

[Arthur031221]

Yes, packages that rely on account-creating RPM scriptlets need checking when moved into an image build. My earlier sysusers example establishes the account at boot, but it does not preserve the numeric UID/GID of files owned by that account during the build. rpm-ostree documents that client-side layering synthesizes sysusers definitions and allocates IDs per machine.

With u helloworld - ..., there is no numeric match to guarantee. I ran systemd-sysusers --root=<test-root> twice against the same definition: with UID 999 free it created helloworld as 999:999; with UID 999 occupied it created 998:998. For a package you plan to include, inspect rpm -q --scripts PACKAGE for account creation and rpm -qlv PACKAGE for account-owned payload files. Your example spec lists only /usr/bin/hello-world, so the account definition is enough for that specific RPM.

For writable service data, let the target system create and own it after the account exists, for example with /usr/lib/tmpfiles.d/helloworld.conf containing d /var/lib/helloworld 0750 helloworld helloworld -. For files that must already be owned by that user in the image, coordinate a fixed UID/GID in the package and sysusers definition across the target machines, and check for collisions. After boot, compare getent passwd helloworld with stat -c '%u:%g %n' /var/lib/helloworld or the affected file.