When installating GitLab on a clean machine, it creates five unix users:
gitlab-www
git
gitlab-redis
gitlab-psql
registry
In some test (and production) environments here, we try to control which unix users exists, so we made sure these five names were known there - except a typo was made so while there are no problems with 4 of these, the fifth one gets created as gitlab-pgsql (with an extra g - pgsql is a more common abbreviation of PostgreSQL), but that still stops GitLab from creating a gitlab-psql user on those systems (it still tries to use it, so things doesn’t work optimally).
I would like to understand why this is (it will make it easier to fix the results of that typo). GitLab is installed from Debian packages on those systems, and I guessed that would mean it was done in either the package’s preinst or it’s postinst script. That doesn’t seem to be the case, so I’m a little lost on where that might happen, can anybody enlighten me?
seems to show some files, specifically the chef cookbooks which are used during installation, configuration as well as when upgrades are taking place. The cookbooks will be what creates the users, etc. However, it won’t be so simple as editing these to fit your requirements, mostly since they will get replaced when new upgrades are installed and so would revert to gitlab-psql again. Other than the chef cookbooks, there are service files that rely on the users that are being created.
Even though I think gitlab-pgsql is a better name than gitlab-psql, I wasn’t planning on changing what GitLab uses, but rather (as said) on fixing that typo, i.e. making everything use the names without the g.
My question was just fuelled by:
A desire to understand why we had ended up where we did
A wish to know if there were parts that have picked up the bad username to clean up
I can just (and I probably will) just redeploy those testsystems, then every trace of the typo will be gone, but I won’t have learned much.
We use chef quite a bit here, so I hope I can find my way through that.
To be honest, I just use Gitlab and so it creates the users for me whenever I do an install. Since I’ve been using it since 12.x and my system has gitlab-psql, it must have been some process outside of gitlab that created your users with gitlab-pgsql. Maybe someone created them manually, or with something like ansible, chef when preparing those systems so that they already existed before you installed Gitlab.
You could easily rename the users in question to the correct format on the systems that have them incorrectly created. But if Gitlab already is installed, then you will have gitlab-pgsql and gitlab-psql, in that instance, just delete the incorrect one. Gitlab doesn’t use gitlab-pgsql as a user and as far as I know never has. It doesn’t exist on any of my systems, which is most likely that this was created outside of Gitlab.
I agree that pgsql is the most common abbreviation for it, I expect they more named it after the binary psql which exists in /opt/gitlab/embedded/bin/
If you look throught the chef cookbooks under the path /opt/gitlab/embedded/cookbooks that should at least help you clarify the situation that you are in now and should back up what I’ve mentioned so far.
It was chef (directed by me) who created the gitlab-pgsql user, and along with the other mentioned users, it did so before GitLab was installed on that host, that was the whole point. So I know that.
The problem is that GitLab says it’s installed correctly, but while the gitlab-pgsql user that chef made is there, there is no gitlab-psql. I’d like to understand how GitLab can be/look satisfied with that situation, but as things have worked in that setup I guess it has been?
I’ve already changed gitlab-pgsql to gitlab-psql in our chef setup, so this will be correct if I redeploy the server(s).
Our future GitLabs still don’t work, but this is quite unrelated.
The database is elsewhere, so no user for that is needed, which explains why it didn’t create gitlab-psql on those servers (on another test server - with a local postgresql - I ended up with both gitlab-pgsql and gitlab-psql users) - but when I tried to use the command gitlab-psql it did try to do something with that user - and when fixed said something about nothing listening on some socket.
This all turned out to be a red herring in the search for why those new servers (mis)behave like they do.