Archivi tag: debian

Debian – Invalid Signatures

Questa mattina avrei voluto aggiornare uno dei miei sistemi basati su Debian Stretch ma, all’esecuzione di apt-get update ho ottenuto il seguente errore:
root@intranet:~# apt-get update
(...)
Err:5 https://packages.sury.org/php stretch InRelease
The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org
Fetched 1457 kB in 1s (1150 kB/s)
Reading package lists… Done
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.sury.org/php stretch InRelease: The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org
W: Failed to fetch https://packages.sury.org/php/dists/stretch/InRelease The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org
W: Some index files failed to download. They have been ignored, or old ones used instead.

Il problema sembra causato dalla coesistenza di chiavi valide e scadute, come ampiamente riportato qui.

Dal post precedente ho tratto ispirazione per una serie di comandi che hanno risolto il prolema:
root@intranet:~# apt-key list
/etc/apt/trusted.gpg
pub rsa4096 2014-09-09 [SC]
DF3D 585D B8F0 EB65 8690 A554 AC0E 4758 4A7A 714D
uid [ unknown] CZ.NIC Labs Archive Automatic Signing Key ftpmaster@labs.nic.cz
pub rsa3072 2019-03-18 [SC] [expired: 2021-03-17]
1505 8500 A023 5D97 F5D1 0063 B188 E2B6 95BD 4743
uid [ expired] DEB.SURY.ORG Automatic Signing Key deb@sury.org
sub rsa4096 2014-09-09 [E]

Il problema è quindi nel file /etc/apt/trusted.gpg, che deve essere cancellato e la chiave corrispondente deve essere rimossa:
root@intranet:~# rm /etc/apt/trusted.gpg

Per rimuovere la chiava è sufficiente prendere nota della parte finale della sua signature: 95BD 4743
root@intranet:~# apt-key del 95BD4743
OK

UNa volta completata questa operazione è necessario scaricare la nuova chiave:

root@intranet:~# wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg
--2021-03-22 09:01:41-- https://packages.sury.org/php/apt.gpg
Resolving packages.sury.org (packages.sury.org)… 172.67.182.150, 104.21.18.148, 2606:4700:3030::ac43:b696, …
Connecting to packages.sury.org (packages.sury.org)|172.67.182.150|:443… connected.
HTTP request sent, awaiting response… 200 OK
Length: 1769 (1.7K) [application/octet-stream]
Saving to: '/etc/apt/trusted.gpg.d/php.gpg'
/etc/apt/trusted.gpg.d/php.gpg 100%[=================================================>] 1.73K --.-KB/s in 0s
2021-03-22 09:01:41 (12.4 MB/s) - '/etc/apt/trusted.gpg.d/php.gpg' saved [1769/1769]

Verifica delle chiavi:
root@intranet:~# apt-key list
(…)
/etc/apt/trusted.gpg.d/php.gpg
pub rsa3072 2019-03-18 [SC] [expires: 2024-02-16]
1505 8500 A023 5D97 F5D1 0063 B188 E2B6 95BD 4743
uid [ unknown] DEB.SURY.ORG Automatic Signing Key deb@sury.org
sub rsa3072 2019-03-18 [E] [expires: 2024-02-16]
root@intranet:~#

A questo punto il processo di update può essere completato senza errori.

Impazzire con la mail

Ho diversi sistemi linux-based sparsi in giro per la provincia. In tutti ho uniformato la configurazione del sistema di gestione della posta elettronica, impostando un funzionamento come “satellite” ed usando gmail per il lavoro “sporco”.

Uno dei miei sistemi, con sistema operativo Debian 9.4 si è sempre rifiutato di inviare la mail a “se stesso”. L’errore che ho sempre ottenuto è:

DNS Error: 21091730 DNS type ‘mx’ lookup of linuxade responded with code NXDOMAIN Domain name not found: linuxade

Ho controllato l’output del comando:
root@linuxade:/etc# exim4 -bP primary_hostname
primary_hostname = localhost

Ho provato un sacco di strade diverse. L’unica azione che ha risolto il problema è stata la riconfigurazione di /etc/hosts nella sezione ipv6 passando dalla prima alla seconda versione. La prima scrittura penso sia stata una configurazione temporanea per fare qualche prova.

# The following lines are desirable for IPv6 capable hosts
::1  localhost ip6-localhost ip6-loopback linuxade

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback

Cambiato il contenuto del file, riavviato exim4, adesso il comando viene eseguito correttamente:
root@linuxade:/etc# exim4 -bP primary_hostname
primary_hostname = linuxade

Finalmente mi arrivano le email con gli errori dovuti all’esecuzione degli script!

tempus fugit!

Il tempo corre, vola e qualche volta regala qualche sorpresa. Come quella di fare giungere uno dei miei server “storici” a quota 2000 giorni di UPTIME. L’ultimo reboot del server risale al 30 Aprile 2011. Dal punto di vista “sistemistico” è una boiata clamorosa. Dal punto di vista “elettronico” è un buon record, soprattutto se si pensa che la macchina è del 2004 ed è completamente originale.

Si tratta di un DELL PowerEdge SC1600, con sistema operativo Debian. Lunga vita al server e (almeno) altri 2000 giorni di uptime!