Sudo apt update not possible, likely related to wrong key of Influxdb

[matapalo775]

Hello there,

on my raspberry pi 4 the command sudo apt update is not successful any more (see response below).

I guess it is related to the change of the key for Influxdb (https://www.influxdata.com/blog/linux-package-signing-key-rotation/). I am running Influxdb via Docker Container.

Any idea how I can update the key?
The way that is described on influx-site is not working (no failure message, but 'sudo apt update' still not successful)

English code below

pi@raspberrypi:~ $ sudo apt update
OK:1 http://archive.raspberrypi.org/debian buster InRelease
OK:2 http://raspbian.raspberrypi.org/raspbian buster InRelease
OK:3 https://download.docker.com/linux/raspbian buster InRelease
Holen:4 https://repos.influxdata.com/debian stable InRelease [6.892 B]
Holen:5 https://repos.influxdata.com/debian buster InRelease [7.038 B]
Fehl:3 https://download.docker.com/linux/raspbian buster InRelease
Splitting up /var/lib/apt/lists/download.docker.com_linux_raspbian_dists_buster_InRelease into data and signature failed
Fehl:4 https://repos.influxdata.com/debian stable InRelease
Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY D8FF8E1F7DF8B07E
Fehl:5 https://repos.influxdata.com/debian buster InRelease
Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY D8FF8E1F7DF8B07E
Fehler beim Verbinden: Verbindung ist gescheitert: Verbindungsaufbau abgelehnt
Paketlisten werden gelesen... Fehler!

automatically translated:
pi@raspberrypi:~ $ sudo apt update
OK:1 http://archive.raspberrypi.org/debian buster InRelease
OK:2 http://raspbian.raspberrypi.org/raspbian buster InRelease
OK:3 https://download.docker.com/linux/raspbian buster InRelease
Get:4 https://repos.influxdata.com/debian stable InRelease [6.892 B]
Get:5 https://repos.influxdata.com/debian buster InRelease [7.038 B]
Miss:3 https://download.docker.com/linux/raspbian buster InRelease
Splitting up /var/lib/apt/lists/download.docker.com_linux_raspbian_dists_buster_InRelease into data and signature failed
Error:4 https://repos.influxdata.com/debian stable InRelease
The following signatures could not be verified because their public key is not available: NO_PUBKEY D8FF8E1F7DF8B07E
Miss:5 https://repos.influxdata.com/debian buster InRelease
The following signatures could not be verified because their public key is not available: NO_PUBKEY D8FF8E1F7DF8B07E
Error connecting: Connection failed: connection establishment rejected
Packet lists are being read... Error!

[Paraphraser]

I have several comments which may or may not help.

First, problems with GnuPG keys often turn out to be transient. I have a small script which I use to confirm whether key IDs are available or not. The script is named fetch_gpg_public_keys. I've listed it below and you are welcome to add it to your ~/.local/bin directory.

#!/usr/bin/env bash

# the name of the script is...
SCRIPT=$(basename "$0")

# at least one argument expected
[ $# -eq 0 ] && echo "Usage: $SCRIPT keyid {keyid...}" && exit 1

# construct a temporary directory to hold downloaded keys
KEYDIR=$(mktemp -d)
chmod 700 "$KEYDIR"

# borrow config file (if it exists)
CONFIG="$HOME/.gnupg/gpg.conf"
[ -f "$CONFIG" ] && cp "$CONFIG" "$KEYDIR"/

# iterate argument(s) as keyIDs
while (( "$#" )); do

	# try to fetch the indicated key
	gpg --homedir "$KEYDIR" \
	    --keyserver hkps://keyserver.ubuntu.com:443 \
	    --recv-keys "$1"

	# did that succeed?
	if [ $? -eq 0 ] ; then

		# yes! export the key
		gpg --homedir "$KEYDIR" \
		    --armor \
		    --export "$1" > "./gpg-public-key-$1.asc"

	fi

	# move to the next argument
	shift

done

# list whatever keys are now in the temporary keychain
gpg --homedir "$KEYDIR" --list-keys --with-sig-check

# clean up
rm -rf "$KEYDIR"

The script takes one or more KEYIDs as arguments. It attempts to fetch each key using its ID. If it is successful, it also exports the ASCII armored form of the key into the working directory. It finishes off listing whatever has turned up in the temporary keychain and then cleans up. All the work is done in a temporary directory so it won't interfere with any existing keychains.

Here's the script running on my Raspberry Pi 4 (64-bit Bullseye) fetching the KEYID from your error message:

$ fetch_gpg_public_keys D8FF8E1F7DF8B07E
gpg: keybox '/tmp/tmp.X7JQICBn7o/pubring.kbx' created
gpg: /tmp/tmp.X7JQICBn7o/trustdb.gpg: trustdb created
gpg: key D8FF8E1F7DF8B07E: public key "InfluxData Package Signing Key <[email protected]>" imported
gpg: Total number processed: 1
gpg:               imported: 1
/tmp/tmp.X7JQICBn7o/pubring.kbx
-------------------------------
pub   rsa4096 2023-01-18 [SC] [expires: 2026-01-17]
      9D539D90D3328DC7D6C8D3B9D8FF8E1F7DF8B07E
uid           [ unknown] InfluxData Package Signing Key <[email protected]>
sig!3        D8FF8E1F7DF8B07E 2023-01-18  InfluxData Package Signing Key <[email protected]>

gpg: 1 good signature

$ 

Conclusion: the key definitely exists. It doesn't expire until January 2026 so it's still valid.

Second point. I don't understand why apt even knows about this key. On my Pi:

$ grep -i influx /etc/apt/sources.list /etc/apt/sources.list.d/*
$ apt list 2>/dev/null | grep influx | grep installed
$ apt-key list 2>/dev/null | grep "^pub" | wc -l
11
$ apt-key list apt-key list 2>/dev/null | grep InfluxData
$ 

In words:

1. Does apt have anything in its repository lists that smells of Influx? Silence means "no".
2. Is anything to do with Influx installed anywhere on this Pi? Silence means "no".
3. How many keys does apt know about? There are 11 in the keychain. You can just run apt-key list to see them all.
4. Does any key even mention Influx? Nope.

Is my machine running InfluxDB? You betcha:

$ docker exec -it influxdb influx -precision=rfc3339
Connected to http://localhost:8086 version 1.8.10
InfluxDB shell version: 1.8.10
> show databases
name: databases
name
----
power
weather
computer
battery
mailbox
trigboard
airquality
> exit
$

Now let's repeat the keys check but, this time, inside the InfluxDB container:

$ docker exec -it influxdb bash
# apt update
Get:1 http://deb.debian.org/debian bullseye InRelease [116 kB]
Get:2 http://deb.debian.org/debian-security bullseye-security InRelease [48.4 kB]
Get:3 http://deb.debian.org/debian bullseye-updates InRelease [44.1 kB]
Get:4 http://deb.debian.org/debian bullseye/main arm64 Packages [8071 kB]
Get:5 http://deb.debian.org/debian-security bullseye-security/main arm64 Packages [242 kB]
Get:6 http://deb.debian.org/debian bullseye-updates/main arm64 Packages [12.1 kB]
Fetched 8533 kB in 4s (2199 kB/s)                         
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.

# grep -i influx /etc/apt/sources.list /etc/apt/sources.list.d/*
grep: /etc/apt/sources.list.d/*: No such file or directory
# apt list 2>/dev/null | grep influx | grep installed
influxdb/now 1.8.10-1 arm64 [installed,local]
# apt-key list 2>/dev/null | grep "^pub" | wc -l
9
# apt-key list apt-key list 2>/dev/null | grep InfluxData
# exit
$ 

Although the container doesn't have a separate sources list mentioning Influx, it's plain that influxdb was installed by apt when the container was built.

Yet, just like the Pi that is hosting the InfluxDB container, the container knows nothing about any Influx GnuPG keys.

What I think might be going on on your system is that, at some point in the past, you installed InfluxDB "natively". You probably also have it running as a container (else you wouldn't be asking this question on the IOTstack repo).

I'm no expert on apt so please take this with a few grains of salt and proceed at your own risk. If it were me, providing I could answer "yes" to the two-part question, "am I running InfluxDB in a Docker container and am I sure that the container version is where I'm storing all my databases?", I would:

1. Take down my IOTstack so InfluxDB running in a container didn't confuse the issue.

2. Check to see if InfluxDB was running outside of any container (eg ps ax | grep -i influx). If it is, it'll probably show up as influxd.

3. See if I could figure out how it was being started. One possibility is systemctl so something like:

   $ sudo systemctl status influxd
   

   then, if it shows up in that list, clobber it with:

   $ sudo systemctl stop influxd
   $ sudo systemctl disable influxd
   

   If it isn't being managed by systemctl then that's something you need to hunt down.

4. Poke around in /etc/apt/sources.list and the contents of /etc/apt/sources.list.d and clobber anything that mentions Influx.

5. Run an apt list | grep influx | grep installed and purge each component that emerges (eg sudo apt purge -y influxdb).

6. If the purge chucks up warnings about files/folders it can't remove then track those down and clobber them by hand (assuming none of the paths was inside ``/IOTstack`).

7. Bring up the stack again.

Last point. It looks like you're running Buster. The current Raspberry Pi OS is based on Bullseye. Debian Bookworm is all the rage and, at some point, the Raspberry Pi Foundation is going to upgrade to that as its base. It might be time to start thinking about a rebuild with Bullseye. I've emphasised rebuild (as opposed to some form of migration) because, if this were my machine and my guess about an unnecessary native install of InfluxDB had just proven correct, I'd be wondering how many other gremlins were hiding in the cracks. A rebuild gives you a nice clean slate.

Hope this helps.