Bug #41909
“ceph-deploy install” in mimic seems to require impossible action from usermod
0%
Description
In the “Storage Cluster Quick Start” section of the documentation, after creating users and ssh keys then running ceph-deploy on the admin host, we’re instructed to run “ceph-deploy install” on each node. This fails with the error “RuntimeError: Failed to execute command: env DEBIAN_FRONTEND=noninteractive DEBIAN_PRIORITY=critical apt-get --assume-yes -q --no-install-recommends install ca-certificates apt-transport-https”.
Looking up through the log, this is preceded by several issues wherein dependency problems prevent dpkg from configuring packages. This appears to start at “Setting up ceph-common”, where it reports “Setting system <username> ceph properties..usermod: user <username> is currently used by process <process_id>”.
No user is logged in via any other means, but apparently “ceph-deploy” is logging in through ssh then running “sudo usermod...”, which is then failing because the user is trying to modify itself while running processes. So “ceph-deploy install” seems to be asking the system to do something that the system considers impossible.
This looks like the same issue as described in bugs #15726 and #23710, albeit on different versions of ceph. The former gives a potential workaround, though it’s messy (run “ceph-deploy install”, manually run failed command as root, run “ceph-deploy install” again).
Note: The attached log is a retry, so it notes on the first line that .cephdeploy.conf already exists. The error was the same on the first go as well; thought I'd mention in case that might matter.
$ ceph-deploy --version
2.0.1
$ ceph --version
ceph version 13.2.6 (7b695f835b03642f85998b2ae7b6dd093d9fbce4) mimic (stable)
$ python3 --version
Python 3.6.8
$ dpkg -S /usr/sbin/usermod
passwd: /usr/sbin/usermod
$ apt list passwd
Listing... Done
passwd/bionic-updates,now 1:4.5-1ubuntu2 amd64 [installed]
History
#1 Updated by Alfredo Deza over 4 years ago
- Status changed from New to 4
I wonder what exactly is required to replicate this problem because I can't using a vanilla instance of Bionic. Looking at the other bugs linked, it seems like this might be one of the problems:
The documentation recommends adding a ceph user, and preparing password-less login.
I've never created a ceph user at all, and the Ceph packages themselves create a ceph user that is in turn used to control the various different daemons and files.
Is it possible that you've created a ceph user and that is causing your issues here? Can you try to not use a ceph user and see if that fixes your problem?
#2 Updated by John Cholewa over 4 years ago
Alfredo Deza wrote:
I wonder what exactly is required to replicate this problem because I can't using a vanilla instance of Bionic. Looking at the other bugs linked, it seems like this might be one of the problems:
The documentation recommends adding a ceph user, and preparing password-less login.
I've never created a ceph user at all, and the Ceph packages themselves create a ceph user that is in turn used to control the various different daemons and files.
Is it possible that you've created a ceph user and that is causing your issues here? Can you try to not use a ceph user and see if that fixes your problem?
Aha, it certainly does look like I completely glossed over the warning stating that the "ceph" user is reserved when I went through the creating a user part of the documentation. Looks like it might be a human bug after all, but I'll nuke and retry everything as suggested to be sure.
#3 Updated by John Cholewa over 4 years ago
John Cholewa wrote:
Alfredo Deza wrote:
I wonder what exactly is required to replicate this problem because I can't using a vanilla instance of Bionic. Looking at the other bugs linked, it seems like this might be one of the problems:
The documentation recommends adding a ceph user, and preparing password-less login.
I've never created a ceph user at all, and the Ceph packages themselves create a ceph user that is in turn used to control the various different daemons and files.
Is it possible that you've created a ceph user and that is causing your issues here? Can you try to not use a ceph user and see if that fixes your problem?
Aha, it certainly does look like I completely glossed over the warning stating that the "ceph" user is reserved when I went through the creating a user part of the documentation. Looks like it might be a human bug after all, but I'll nuke and retry everything as suggested to be sure.
I have confirmed that doing things correctly results in correct installation. This is indeed not a bug.
#4 Updated by Patrick Donnelly over 4 years ago
- Status changed from 4 to New