Linux – gitlab-ctl reconfigure error when creating user/group on initial install

gitgitlablinuxredhatrhel7

I'm trying to run Gitlab CE on RHEL 7.2 (Maipo). I've completed the Gitlab install. However I'm unable to run sudo gitlab-ctl reconfigure. The error, environment details and what I've tried is outlined below. Does anyone know what I'm missing or doing wrong?

Error

================================================================================
Error executing action `create` on resource 'user[Webserver user and group]'
================================================================================

Mixlib::ShellOut::ShellCommandFailed
------------------------------------
Expected process to exit with [0], but received '6'
---- Begin output of ["usermod", "-s", "/bin/false", "-d", "/var/opt/gitlab/nginx", "gitlab-www"] ----
STDOUT:
STDERR: usermod: user 'gitlab-www' does not exist in /etc/passwd
---- End output of ["usermod", "-s", "/bin/false", "-d", "/var/opt/gitlab/nginx", "gitlab-www"] ----
Ran ["usermod", "-s", "/bin/false", "-d", "/var/opt/gitlab/nginx", "gitlab-www"] returned 6

Environment

RHEL 7.2 (Maipo), Chef Client, version 12.12.15 (taken for the gitlab-ctl reconfigure output)

What I've tried

Followed install steps here for RHEL 7.
Manually add the gitlab-www user: When executing this sudo useradd -s /bin/false -d /var/opt/gitlab/nginx gitlab-www I get the error useradd: user 'gitlab-www' already exists. However I verified a record for gitlab-www doesn't exist in /etc/passwd.
Renamed users in gitlab.rb: I renamed the following users in /etc/gitlab/gitlab.rb [git, gitlab-www, git-redis, and gitlab-psql]. That does allow me to run gitlab-ctl reconfigure successfully but this seems like a super hack and I don't know what the impact is to the Gitlab installation. I had to rename all those users because after renaming gitlab-www I would get the same error with the user git, then git-redis and so on.

Best Answer

When a user is created properly, it gets added to two files - /etc/passwd and /etc/shadow. The former contains info about the home directory, login shell etc; the latter contains the encrypted password for the user.

From your description, I should guess that the user exists in /etc/shadow but not in /etc/passwd.

The simplest solution is to either edit /etc/shadow (using sudo) and remove the line that looks something like

gitlab-www:!!:12345::::::

Another possibility is to manually add the user to /etc/passwd. First, find the UID in the shadow file:

[jenny@finch ~]$ sudo grep gitlab-www /etc/shadow | cut -d: -f3
12345
[jenny@finch ~]$ sudo vi + /etc/passwd

Then add the following line:

 gitlab-www:x:12345:12345:Gitlab WWW user:/var/opt/gitlab/nginx:/bin/false

Related Solutions

Linux – Yum error when updating / install

The error is exactly what it says: it can't connect to the RHN server. If you paste the contents of /etc/sysconfig/rhn/up2date (as @packs suggested in his comment), you can use the URL to verify whether or not its up. For example, if you were using a mirror, that mirror is--perchance--shutdown.

Also verify that your server has internet connectivity, and try running a traceroute to the server (and other URLs) to make sure its not a local problem.

What “access rights” could be blocking access to a gitlab repository

I'm pretty sure you have a configuration problem between SSH and the system because of this SSH debug message :

client_input_channel_req: channel 0 rtype eow@openssh.com reply 0

You receive this message immediately after a successful authentication and no message from bash which means no program was launched after login.

Watch in your passwd file if you have the right settings for the gitlab user :

gitlab:x:1011:1012:GitLab,,,:/path/to/gitlab:/bin/bash

Verify bash has no weird thing in configurations files such as

bash.bashrc
.profile
.bashrc

Then go up to the uper level : Gitlab-shell Verify the /path/to/gitlab/.ssh/authorized_keys has the configuration below :

command="/path/to/gitlab/gitlab-shell/bin/gitlab-shell key-2",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa A...

with /path/to/gitlab/gitlab-shell/bin/gitlab-shell owned by the gitlab user and executable.

You can be sure gitlab-shell is fully operational by launching the command :

# /path/to/gitlab-shell/bin/gitlab-shell
Welcome to GitLab, Anonymous!

If the remote login is actually working and properly connected to the gitlab-shell, you should get the same welcome message (but matched to the user whose ssh key you used to login) before it dumps you out if you try to login remotely.

$ ssh gitlab@server
Welcome to GitLab, <your user's full name>!
Connection to <server> closed.

No message here probably indicates ssh isn't connecting you to gitlab at all.

Finally, checkout your gitlab-shell configuration (config.yml) and verify if :

http_settings:
    # trailing slash is important
    gitlab_url: "https://remote_server/"
    ca_file: /path/to/webserver/certificate.crt

and eventually :

    self_signed_cert: false