ceph-common postinst does not check for ceph user existing externally

Bug #1858692 reported by Mark Cunningham on 2020-01-07
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Landscape Server
Eric Desrochers
ceph (Ubuntu)

Bug Description

If the $SERVER_USER name exists in LDAP outside the server the user will not exist in /etc/passwd. This will cause the postinst script to attempt to create the user, which will fail. This user creation/modification failure then causes the configuration operation to be marked as failed and prevent the package from completing installation.

Current workaround is to define $SERVER_USER in /etc/default/ceph or otherwise export a custom value for this into the environment, so that the postinst script uses a username that does not exist in LDAP, and can be created within the local system. Ideally there would be a more robust check for the existence of the $SERVER_USER perhaps using the 'id' command.

Snippets from /var/lib/dpkg/info/ceph-common.postinst

[ -f "/etc/default/ceph" ] && . /etc/default/ceph

[ -z "$SERVER_HOME" ] && SERVER_HOME=/var/lib/ceph
[ -z "$SERVER_USER" ] && SERVER_USER=ceph
[ -z "$SERVER_NAME" ] && SERVER_NAME="Ceph storage service"
[ -z "$SERVER_UID" ] && SERVER_UID=64045 # alloc by Debian base-passwd maintainer

case "$1" in
       # create user to avoid running server as root
       # 1. create group if not existing
       if ! getent group | grep -q "^$SERVER_GROUP:" ; then
          addgroup --quiet --system --gid $SERVER_GID \
              $SERVER_GROUP 2>/dev/null ||true
       # 2. create user if not existing
       if ! getent passwd | grep -q "^$SERVER_USER:"; then
         adduser --quiet \
                 --system \
                 --no-create-home \
                 --disabled-password \
                 --uid $SERVER_UID \
                 --gid $SERVER_GID \
                 $SERVER_USER 2>/dev/null || true
       # 3. adjust passwd entry
       usermod -c "$SERVER_NAME" \
               -d $SERVER_HOME \
               -g $SERVER_GROUP \
               $SERVER_USER 2>/dev/null

[Observe impacted scenario]

* lanscape-server installation may fail when the ceph user/group already exists on the system with non-default UID/GID particularly when the user exists in LDAP outside the local system.

Tags: sts Edit Tag help
Eric Desrochers (slashd) wrote :

While this installation problem occurs .... what your "/etc/nsswitch.conf" looks like ?

Eric Desrochers (slashd) wrote :

IMHO, getent should be ables to get information from sources such as LDAP.

so maybe the problem is just on how nsswitch.conf is configured ?

Changed in ceph (Ubuntu):
status: New → Incomplete
Eric Desrochers (slashd) wrote :

or also how the client is configured ? (e.g sssd)

did you try to run the command manually by hand ?

Eric Desrochers (slashd) on 2020-01-09
tags: added: sts
Eric Desrochers (slashd) on 2020-01-09
Changed in landscape:
status: New → Confirmed
assignee: nobody → Eric Desrochers (slashd)
status: Confirmed → In Progress
Eric Desrochers (slashd) on 2020-01-09
description: updated
description: updated
description: updated
Eric Desrochers (slashd) wrote :

Additional note:

landscape-server installation as we speak "Depends" on ceph-common.
ceph-common is no longer needed/used in the landscape context since autopilot code got removed.

I'll propose a MP to Simon to remove the Depend from Landscape server.

Nevertheless, I think the situation observe while intalling ceph-common should be debug a little more and look for system configurations (e.g nsswitch.conf, sssd, ...) to figure out why "getent" can't get information from external users when it should.

Until I'm proven wrong, I think it's too early to pretend that getent is "buggy" or the maintainer script doing the wrong thing. I doubt it is the case.

I'm more incline to pretend that the behaviour is cause by a system configuration than anything else (until I'm provent wrong with solid data)

Eric Desrochers (slashd) on 2020-01-09
Changed in landscape:
status: In Progress → Fix Released
Simon Poirier (simpoir) on 2020-01-09
Changed in landscape:
status: Fix Released → Fix Committed
Changed in landscape:
milestone: none → 19.11
Simon Poirier (simpoir) on 2020-01-10
Changed in landscape:
milestone: 19.11 → 19.10.1
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers