Nfo's picture

Helo!!

i have problems whit updates.... in var\logs\messages i can see this:

May 18 06:46:51 gitlab cron-apt: W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://packages.gitlab.com/gitlab/gitlab-ce/debian stretch InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 3F01618A51312F3F
May 18 06:46:51 gitlab cron-apt: W: Failed to fetch https://packages.gitlab.com/gitlab/gitlab-ce/debian/dists/stretch/InRele... The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 3F01618A51312F3F
May 18 06:46:51 gitlab cron-apt: W: Some index files failed to download. They have been ignored, or old ones used instead.

 

Any solution? Thanx

Forum: 
Jeremy Davis's picture

GitLab have rotated their keys. So you'll need to update the GitLab package signing key. Exactly how you do that depends on how you have the GitLab omnibus repo configured. To find out, run this:

grep -r "^deb .*gitlab" /etc/apt/sources.list*

If you get a line like this (i.e. our "best practice" config which includes the specific keyring file in a '[signed-by=...]' bit):

deb [signed-by=/usr/share/keyrings/gitlab-ce.gpg] https://packages.gitlab.com/gitlab/gitlab-ce/debian/ stretch main

Then update the key like this:

curl https://packages.gitlab.com/gpg.key -o /tmp/omnibus_gitlab_gpg.key
apt-key --keyring /usr/share/keyrings/gitlab-ce.gpg add /tmp/omnibus_gitlab_gpg.key

Alternatively, if you get a shorter line (without the '[signed-by=...]' bit) like this:

deb https://packages.gitlab.com/gitlab/gitlab-ce/debian/ stretch main

Then update the key like this (i.e. without specifying a specific keyring file, as per what GitLab notes):

curl https://packages.gitlab.com/gpg.key -o /tmp/omnibus_gitlab_gpg.key
apt-key add /tmp/omnibus_gitlab_gpg.key

Regardless which way you need to do it, you can check that it worked by running this:

apt update

If you still see the error message, please post the full output of that, as well as the relevant line that the grep command at the top of this post gives.

Nfo's picture

Perfect Jeremy. The first thing was to make a backup to tinker with. Although the first command did not work for me "grep -r" ^ deb. * Gitlab "/etc/apt/sources.list*" since it did not show me anything, I kept trying with the ones you have given me and I have managed to solve the problem. My gitlab is already updating smoothly again. I have updated it to version 12.10.6.

Now a question has arisen, but I don't know how to look at it.

When downloading the latest version, I have seen that the file occupied 800 Mgs .... I imagine that every time I update, files that occupy my hard disk will be downloaded .... where they are stored and in which way I can clean those temporary files so that the server does not increase in size disproportionately?

Thank you very much for your help...

Jeremy Davis's picture

Re the grep command not returning anything, that seems strange?! Although the command that you posted would almost certainly not work:

grep -r" ^ deb. * Gitlab "/etc/apt/sources.list*

The exact command I posted previously should have worked though (although it's possible if there was a leading space before the 'deb' it might not have; see the explanation on this command at the end if you're interested). Note the exact position of spaces and quotes, and no capital letters, etc). I.e.:

grep -r "^deb .*gitlab" /etc/apt/sources.list*

Regardless, I'm glad that you managed to work it out and that it's working fine again now.


Re your question on the downloaded deb files, by default, those files are cached within /var/cache/apt/archives/. You can have a look at them like this:

 ls -l /var/cache/apt/archives/

If you wish to clean them up, you could manually clean up the deb files and it's unlikely tht ti will cause any issue. However, it's probably better to use apt as it knows exactly what to clean and what to leave. There are 2 possibilities that do slightly different things.

The first is 'autoclean", which clears old packages only (i.e. it will keep the deb files which relate to the currently installed versions). This means that if you wanted to reinstall that particular version, you could do that without having to download them again. It works like this:

apt autoclean

FWIW, in v16.0 (and perhaps v15.x too?) that's what it will do by default everytime you install apps (including the auto security update installs).

The other option is 'clean'. That will remove all cached deb packages. Do that like this:

apt clean

As something of an aside, as I mentioned above, I'll give you a little more info about the grep command that I provided. I.e. this one:

grep -r "^deb .*gitlab" /etc/apt/sources.list*

You can view the general explanation of the command on explainshell.

The part in quotes is regex (in this case "simplified grep regex"). The regex can be explained like this:

^ - means start of the line
deb - the exact characters 'deb' (in that exact order)
 (space) - the exact ' ' character (i.e. a single space)
. - any character
* - repeat previous character 0 or more times
gitlab - the exact characters 'gitlab'  (in that exact order)

In other words, return all lines that start with "deb " and include "gitlab".

The path with the asterisk ('*') at the end (i.e. '/etc/apt/sources.list*') is known as a globbing expression (sort of like a super simple regex provided by the shell). In this case, the asterisk is expanded by the shell to match any character. So it would expand to match any file or folder that starts with '/etc/apt/sources.list' (e.g. will match '/etc/apt/sources.list' and '/etc/apt/sources.list.d' and all the files inside '/etc/apt/sources.list.d/').

Add new comment