linux – IBeBlog

GitLab “STDERR: chgrp: invalid group: ‘git’” 🤔

July 22, 2019 Frédéric Hannes

Today I ran into a bit of a pickle 🥒. I was upgrading GitLab on an Ubuntu server machine using Aptitude. I’ve done this hundreds of times and GitLab has never had the slightest issues updating for me in the past. Today was time for a new experience.

There was an error running gitlab-ctl reconfigure:

storage_directory[/var/opt/gitlab/.ssh] (gitlab::gitlab-shell line 38) had an error: Mixlib::ShellOut::ShellCommandFailed: ruby_block[directory resource: /var/opt/gitlab/.ssh] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/package/resources/storage_directory.rb line 33) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of chgrp git /var/opt/gitlab/.ssh ----
STDOUT:
STDERR: chgrp: invalid group: ‘git’
---- End output of chgrp git /var/opt/gitlab/.ssh ----
Ran chgrp git /var/opt/gitlab/.ssh returned 1

There was an error running gitlab-ctl reconfigure:

storage_directory[/var/opt/gitlab/.ssh] (gitlab::gitlab-shell line 38) had an error: Mixlib::ShellOut::ShellCommandFailed: ruby_block[directory resource: /var/opt/gitlab/.ssh] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/package/resources/storage_directory.rb line 33) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'

---- Begin output of chgrp git /var/opt/gitlab/.ssh ----

STDOUT:

STDERR: chgrp: invalid group: ‘git’

---- End output of chgrp git /var/opt/gitlab/.ssh ----

Ran chgrp git /var/opt/gitlab/.ssh returned 1

So to make a long story short… When GitLab is updated, it runs the command gitlab-ctl reconfigure. This command essentially performs some checks, makes sure that everything is upgraded and set up correctly. One of its internal features ensures that a folder exists and that it has the correct permissions.

      # In /opt/gitlab/embedded/cookbooks/cache/cookbooks/package/resources/storage_directory.rb

       33:   ruby_block "directory resource: #{new_resource.path}" do
       34:     block do
       35:       # Ensure the directory exists
       36:       storage_helper.ensure_directory_exists(new_resource.path)
       37:
       38:       # Ensure the permissions are set
       39:       storage_helper.ensure_permissions_set(new_resource.path)
       40:
       41:       # Error out if we have not achieved the target permissions
       42:       storage_helper.validate!(new_resource.path)
       43:     end
       44:     not_if { storage_helper.validate(new_resource.path) }
       45:   end
       46: end

# In /opt/gitlab/embedded/cookbooks/cache/cookbooks/package/resources/storage_directory.rb

33: ruby_block "directory resource: #{new_resource.path}" do

34: block do

35: # Ensure the directory exists

36: storage_helper.ensure_directory_exists(new_resource.path)

37:

38: # Ensure the permissions are set

39: storage_helper.ensure_permissions_set(new_resource.path)

40:

41: # Error out if we have not achieved the target permissions

42: storage_helper.validate!(new_resource.path)

43: end

44: not_if { storage_helper.validate(new_resource.path) }

45: end

46: end

This code failed to set the user group for the folder /var/opt/gitlab/.ssh because the required user group does not exist. Though this error seems fairly obvious, the problem I faced is that the user group actually does exist.

Luckily I remembered that after setting up this server, I also did some server hardening. One step in that process was to restrict access permissions to specific system files. So I went and checked which files I modified and one of the files happened to be /etc/group.

What I had done was take away privileges for those system files so they could only be accessed by their owner, the root user. This is typically not an issue, but it turns out that even though Aptitude was being ran by the root user, the gitlab-ctl process must have been trying to set the permissions of that folder using a different user account, which had no permission to access /etc/group.

The solution: “sudo chmod og+r /etc/group” to permit other users to read the file. After having Aptitude retry the upgrade process, everything worked great!

After you have finished the upgrade, you can go ahead and revert the permission changes (sudo chmod og-r /etc/group). But keep in mind that it will probably happen again the next time you are upgrading GitLab.

Cannot open your terminal ‘/dev/pts/0’

February 1, 2016 Frédéric Hannes

I ran into the error Cannot open your terminal '/dev/pts/0'. Though I had not seen this before, it seems to occur when you use the “switch user (su)” command to access a user account and then try to open a screen.

The issue can be resolved by either logging in directly with the user account you want to use, or by running the command “script /dev/null” as demonstrated here on StackOverflow.

Tar (+GZip) individual (sql) files in a folder

May 12, 2014 Frédéric Hannes

I had been backing up a MySQL database with a simple shell script for a while now. What I somehow forgot to add to the script was a command to compress the SQL dumps before uploading them to my backup server. The script had been running for a few months, so manually compressing each file wasn’t much of an option. So I wrote this little shell script do the work for me.

#!/bin/sh

cd /some/directory/with/sql/files
for file in *.sql; do
    tar cvzf "${file}".tar.gz "${file}"
    rm "${file}"
done

#!/bin/sh

cd /some/directory/with/sql/files

for file in *.sql; do

tar cvzf "${file}".tar.gz "${file}"

rm "${file}"

done

The script places all of the sql files individually into a tar archive with GZip compression. The new file uses the old file’s name with “.tar.gz” appended at the end. The old file is deleted after the compressed archive has been created.

You can of course do this for other files, just change the *.sql mask to work with different files. If for some reason you just want TAR files without the GZip compression, replace the tar line in the script with “tar cvf "${file}".tar "${file}"“.

Check available diskspace on Ubuntu (CLI)

May 12, 2014 Frédéric Hannes

If you are running an Ubuntu (or other linux) commandline interface, you might have to check how much diskspace is available on the system. You can easily have the system output a list of the disk space usage on all mounted filesystems with the command df -h.

The output depends completely on how your system is set up, but it will look something like:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       110G   33G   72G  32% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            7.7G  4.0K  7.7G   1% /dev
tmpfs           1.6G  328K  1.6G   1% /run
none            5.0M     0  5.0M   0% /run/lock
none            7.8G  4.0K  7.8G   1% /run/shm

Filesystem Size Used Avail Use% Mounted on

/dev/sda1 110G 33G 72G 32% /

none 4.0K 0 4.0K 0% /sys/fs/cgroup

udev 7.7G 4.0K 7.7G 1% /dev

tmpfs 1.6G 328K 1.6G 1% /run

none 5.0M 0 5.0M 0% /run/lock

none 7.8G 4.0K 7.8G 1% /run/shm

Elementary OS 0.2 Jupiter

April 13, 2011 Frédéric Hannes

Elementary OS 0.2 Jupiter is the first stable release of Elementary OS and was release just over 10 days ago. I’ve been using the OS on one of my production machines for a week now and I’d like to share some of my thought about the OS.

Elementary OS is an Ubuntu remix, though things aren’t all that different. The only real difference between Ubuntu and Elementary OS is the interface. Elementary OS uses a custom built shell that runs on top of Gnome. The shell is clearly designed to resemble Mac OSX. The interface looks very sleek and tidy, is very responsive and overall I must say that it works really well.

As for functionality, the interface unfortunately doesn’t really add any, at the bottom of your desktop you will see a dock such as in Max OSX, opened programs will show up on the dock and you can easily stick them to do the dock to quick launch them. Aside from the dock, the interface seems to actually reduce the functionality of the Ubuntu desktop environment. The Desktop itself is completely gone, you can no longer put any files or folders onto the desktop and aside from this you no longer have multiple desktop support.

The OS still has a couple of bugs to iron out, often folders like Documents won’t launch and there’s a few other minor bugs.

Overall even though there’s some reduced functionality and small bugs, I must say I’m very satisfied with this new distro, the new interface looks very clean and is fun to use, it reduces that basic feel to Gnome while retaining the performance.

Note that you can use Ubuntu Tweak to bring back a lot of the functionality that was removed.