Rispetto alla versione 11 Bullseye è stata aggiunta la nuova componente non-free-firmware, per distribuire solo i firmware non-free, che prima erano nella più generica non-free:

deb     http://deb.debian.org/debian bookworm         main contrib non-free non-free-firmware
deb-src http://deb.debian.org/debian bookworm         main contrib non-free non-free-firmware
deb     http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
deb-src http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
deb     http://security.debian.org/debian-security/  bookworm-security main contrib non-free non-free-firmware
deb-src http://security.debian.org/debian-security/  bookworm-security main contrib non-free non-free-firmware

L'opzione cipher viene usata quando si usa una configurazione con l'opzione secret e pre-shared-key, una situazione che in generale dovrebbe essere rimpiazzata dalle configurazioni TLS (es. EasyRSA).

L'impostazione predefinita per cipher è BF-CBC, che però non è più presente in OpenVPN 2.6.3 (controllare con openvpn --show-ciphers); si deve quindi necessariamente indicare un protocollo diverso, ad esempio:

cipher AES-256-CBC

In generale dovrebbe funzionare la procedura pg_upgradecluster. Vedere una descrizione dettagliata in PostgreSQL/PostGIS Upgrade from 9.6 to 11 soprattutto se si hanno database con estensioni PostGIS. In estrema sintesi:

su -
su - postgres
# Siamo utente postgres
pg_lsclusters
# Verificare che la nuova istanza 15 sia sulla porta alternativa 5433.
psql --cluster 13/main
# Verificare con \l che i database esistenti siano in questa istanza.
psql --cluster 15/main
# Verificare che questa istanza sia in effetti vuota
pg_dropcluster --stop 15 main
pg_upgradecluster 13 main
pg_lsclusters
# Verificare che la nuova istanza 15 sia sulla porta predefinita 5432.
pg_dropcluster 13 main
pg_ctlcluster 15 main stop
exit
# Siamo di nuovo utente root
systemctl daemon-reload
systemctl stop postgresql@13-main
systemctl disable postgresql@13-main
systemctl stop postgresql@15-main
systemctl start postgresql@15-main
systemctl enable postgresql@15-main

Dopo l'aggiornamento di versione Debian, aprendo l'URL del sistema Cacti si viene accolti da una procedura di aggiornamento (wizard) dalla versione 1.2.16 di Cacti alla 1.2.24. Il sistema effettua una serie di controlli e suggerisce le modifiche da effettuare. In particolare si è dovuto:

Anzitutto si verifica che le tabelle timezone non sono state popolate: si esegue il client mysql e quindi:

CONNECT mysql
SELECT * FROM time_zone_name;

Si esegue quindi lo script per la popolazione delle tabelle:

mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql

Collegarsi al database Cacti e eseguire:

CONNECT cacti
ALTER DATABASE cacti CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Per consentire alla procedura PHP di aggiungere e/o modificare template ecc., si devono dare (temporaneamente) i seguenti permessi:

chown -R www-data:www-data /usr/share/cacti/site/resource/snmp_queries/
chown -R www-data:www-data /usr/share/cacti/site/resource/script_server/
chown -R www-data:www-data /usr/share/cacti/site/resource/script_queries/
chown -R www-data:www-data /usr/share/cacti/site/scripts/

Al termine della procedura eseguire di nuovo lo script assegnando proprietario e gruppo a root:root.

Il wizard segnala come anomalia che l'impostazione innodb di MySQL sarebbe UNSET. In effetti sembra che già tutte le tabelle della nostra installazione siano gestite dal motore InnoDB (è l'impostazione predefinita del server MariaDB 10.11.3).

Per verificare l'impostazione predefinita collegarsi al database mysql ed eseguire SHOW ENGINES. Per verificare le tabelle del database cacti collegarsi a quel database ed eseguire SHOW TABLE STATUS e controllare per ogni riga il valore del campo Engine. Eventualmente convertire le tabelle che fossero ancora MyISAM.

Le tabelle che usan l'engine Memory dovrebbero servire per le installazioni con migliaia di data source e i Remote Data Collectors; in tal caso è necessario abilitare l'opzione On-demand RRD Updating in Console ⇒ Configuration ⇒ Settings ⇒ Performance.

Debian 12 aderisce al Python Enhancement Proposal 668, cioè l'ambiente Python viene gestito esclusivamente dal sistema di pacchetti Debian (system-wide); per impostazione predefinita non è possibile installare moduli aggiuntivi in user space con il comando pip3 install ... o similari.

La strada suggerita è quella di creare, quando necessario, dei venv in user-space; all'interno di ciascnun venv è possibile installare con pip tutti i moduli aggiuntivi necessari. Vedere in proposito il paragrafo Solving the pip3 install problem.

Si modifica il file /etc/apt/sources.list sostituendo buster con bullseye:

deb     http://deb.debian.org/debian/               bullseye           main contrib non-free
deb-src http://deb.debian.org/debian/               bullseye           main contrib non-free
deb     http://deb.debian.org/debian/               bullseye-updates   main contrib non-free
deb-src http://deb.debian.org/debian/               bullseye-updates   main contrib non-free
deb     http://security.debian.org/debian-security  bullseye-security  main contrib non-free
deb-src http://security.debian.org/debian-security  bullseye-security  main contrib non-free

Ricordiamo che la distribuzione codename-updates serve a contenere gli aggiornamenti che è opportuno integrare anche prima dei successivi rilasci minori; ad esempio gli aggiornamenti degli antivirus oppure delle timezone forniti con i pacchetti clamav-base e tzdata.

La distribuzione codename-security contiene gli aggiornamenti urgenti relativi a problemi di sicurezza.

È possibile quindi aggiornare la lista dei pacchetti disponibili e fare un aggiornamento intelligente, cioè vengono eventualmente rimossi dei pacchetti se è necessario per completare l'aggiornamento:

apt update
apt full-upgrade

Si possono fare le stesse operazioni anche con il front-end apt-get:

apt-get update
apt-get dist-upgrade

Pare che i due comandi siano equivalenti, almeno stando a quanto riportato da questo post.

Terminato l'upgrade dovrebbe essere possibile fare un reboot e quindi un normale upgrade:

apt update
apt upgrade

Alcuni pacchetti installati in precedenza potrebbero risultare marcati per deinstall, è necessario esaminare la lista ed eventualmente procedere alla loro reinstallazione:

dpkg --get-selections | egrep -v '\binstall\b'
apt install <package1> <package2> ...

Con Debian 11 si cerca di forzare il passaggio dall'obsoleto Python 2 al Python 3. L'eseguibile python non esiste, si deve esplicitamente lanciare python2 oppure python3. In alternativa si pò installare il pacchetto python-is-python2 oppure python-is-python3 per definire qual è l'ambiente predefinito.

Alcune librerie non sono più disponibili:

• python-gtk2
• …

Dopo un aggiornamento da Buster a Bullseye (cioè da Debian 10 a Debian 11) risulta un problema nell'esecuzione di Unison fra host con le due versioni: 2.48.4 per Buster e 2.51.3, che ovviamente risultano incompatibili. In teoria in Bullseye il programma Unison è pacchettizzato includendo il numero di versione, cioè il pacchetto si chiama unison-2.51+4.11.1 e contiene l'eseguibile unison-2.51+4.11.1, questo consentirebbe la coesistenza di versioni differenti; tuttavia pare che non esista un pacchetto Unison 2.48 per Bullseye.

Per il momento la soluzione sembra che sia quella di installare il pacchetto per Buster sulla nuova Bullseye, non ci sono problemi di dipendenza.

Con pg_lsclusters si vede che risultano installati i due cluster, ver. 11 e ver. 13:

pg_lsclusters 
Ver Cluster Port Status Owner    Data directory              Log file
11  main    5432 online postgres /var/lib/postgresql/11/main /var/log/postgresql/postgresql-11-main.log
13  main    5433 online postgres /var/lib/postgresql/13/main /var/log/postgresql/postgresql-13-main.log

Nel cluster nuovo non dovrebbero esserci database in esecuzione (a parte ovviamente postgres, template0 e template1):

su - postgres
psql --cluster 13/main
postgres=# \l

Per tentare l'aggiornamento autmatico la procedura da utente root è la seguente (verificare dopo ogni operazione che i cluster attivi siano quelli attesi, sulla porta TCP attesa):

pg_dropcluster --stop 13 main
pg_upgradecluster 11 main
pg_dropcluster 11 main

In Debian 11 Bullseye esite il pacchetto icinga2 versione 2.12.3-1 che dipende da libreadline7, ma quest'ultimo non è disponibile. Durante l'aggiornamento verrà mantenuto il pacchetto libreadline7 7.0-5 dalla vecchia distribuzione Buster, che pare funzionare.

Controllare inoltre che venga installato il pacchetto php-pgsql e la sua dipendenza dalla nuova versione PHP 7.4.

In Debian 11 Bullseye non esiste il pacchetto python-mysqldb per Python 2.

Anzitutto è opportuno allineare l'installazione all'ultima versione rilasciata di Buster. Poiché è installata la versione 10.9 ma è disponibile la 10.10 e la suite Buster è passata dalla condizione di stable o oldstable, il gestore di pacchetti segnala il seguente warning, impedendo l'aggiornamento:

N: Repository 'http://ftp.debian.org/debian buster InRelease'
   changed its 'Version' value from '10.9' to '10.10'
E: Repository 'http://ftp.debian.org/debian buster InRelease'
   changed its 'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this repository
   can be applied. See apt-secure(8) manpage for details.

Una soluzione da riga di comando, da eseguire una tantum è la seguente:

apt-get update --allow-releaseinfo-change

Con questa forzatura è possibile procedere all'update e upgrade con il client preferito, ad esempio dselect oppure apt-get come in questo esempio:

apt-get update
apt-get upgrade

Può capitare di voler aggiungere un repository alternativo, ad esempio il famoso Deb Multimedia. Tale repository viene aggiunto nel file /etc/apt/sources.list, l'ordine in cui compare non fa differenza perché la priorità di installazione viene dal numero di versione.

deb   https://www.deb-multimedia.org   bullseye             main non-free
deb   https://www.deb-multimedia.org   bullseye-backports   main

In particolari circostanze si potrebbe però preferire la versione fornita ufficialmente da Debian, per ottenere questo risultato si elencano le versioni disponibili nei vari repository:

apt-cache showpkg <package>

e poi si forza l'installazione della versione esatta:

apt-get install --reinstall <package>=4.0.0-1

Per forzare invece la scelta di un pacchetto dai packports, bisogna specificare l'opzione -t:

apt-get -t bullseye-backports install <package>

In generale l'ordine in cui le source vengono elencate in /etc/apt/sources.list non è importante. Quello che conta è la priorità assegnata ad ognuna di esse. In generale le priorità delle sorgenti codename, codename-updates, codename-backports e codename sono predefinite in modo opportuno (vedi avanti).

• Nel file /etc/apt/sources.list viene indicato una source (repository) per ogni riga; ogni source ha una priorità predefinita.
• I pacchetti presenti in security e in updates vengono installati automaticamente perché hanno una versione superiore a quelli forniti dalla distribuzione standard (hanno la stessa priorità, ma versione superiore).
• I pacchetti presenti in backports non vengono installati automaticamente perché hanno una priorità più bassa. È possibile installare un singolo pacchetto dai backports con apt -t bullseye-backports install nomepacchetto. L'impostazione rimane memorizzata ed ogni aggiornamento successivo agirà di conseguenza. Come vedere i pinning attivi e come disattivarli?
• A parità di versione e di priorità viene installato il pacchetto dal repository elencato per primo. È l'unico caso in cui l'ordine conta, ma in generale non dovrebbe mai accadere.
• In generale anche i repository alternativi hanno la stessa priorità della distribuzione ufficiale e vengono preferiti tramite numero di versione superiore o pinning esplicito.

Per vedere la policy con cui viene scelta la source da cui installare un pacchetto si usa il comando:

apt-cache policy

Per ogni source si hanno più sezioni relative alle varie componenti elencate (main, non-free, contrib, …); inoltre se è attivo il multiarch si hanno altre sezioni relative alle architetture attivate (i386, amd64, …). Ecco un estratto dell'output:

 500 http://deb.debian.org/debian-security bullseye-security/main amd64 Packages
     release v=11,o=Debian,a=stable-security,n=bullseye-security,l=Debian-Security,c=main,b=amd64
     origin deb.debian.org
 500 http://deb.debian.org/debian bullseye-updates/main amd64 Packages
     release v=11-updates,o=Debian,a=stable-updates,n=bullseye-updates,l=Debian,c=main,b=amd64
     origin deb.debian.org
 500 http://deb.debian.org/debian bullseye/main amd64 Packages
     release v=11.0,o=Debian,a=stable,n=bullseye,l=Debian,c=main,b=amd64
     origin deb.debian.org
 100 https://www.deb-multimedia.org bullseye-backports/main amd64 Packages
     release v=11,o=Unofficial Multimedia Packages,a=stable-backports,n=bullseye-backports,l=Unofficial Multimedia Packages,c=main,b=amd64
     origin www.deb-multimedia.org
 500 https://www.deb-multimedia.org bullseye/main amd64 Packages
     release v=11,o=Unofficial Multimedia Packages,a=stable,n=bullseye,l=Unofficial Multimedia Packages,c=main,b=amd64
     origin www.deb-multimedia.org

Nella prima colonna viene mostrata la priorità di ciascuna source: numeri più grandi corrispondono ad una maggiore priorità; la priorità predefinita è 500.

Come si vede i pacchetti bullseye-security hanno la stessa priorità di quelli nella distribuzione ufficiale bullseye, quindi vengono installati perché hanno una versione maggiore. Stesso discorso vale per i bullseye-updates: hanno la stessa priorità e quindi dovranno avere una versione maggiore. Invece i backports hanno una priorità più bassa (100) e quindi non verranno mai installati automaticamente, sarà necessario fare un pinning manuale.

A parità di priorità della source verrà selezionato il pacchetto con numero di versione superiore, questo ad esempio è il modo in cui viene preferito un pacchetto da Deb Multimedia piuttosto che da Debian ufficiale.

• SourcesList
• AptConfiguration
• Repository & pinning

Può accadere che alcuni pacchetti installati dai backports, dagli updates oppure dai security della vecchia distribuzione, non vengano aggiornati automaticamente alla nuova stabile. Con questo comando si dovrebbe poter scoprire ciò che è stato installato dalla Debian 10 Backports:

dpkg --list | grep '~deb10u'

In generale dovrebbe essere sufficiente elencare in sources.list tutte le distribuzioni aggiuntive (updates, security, ecc.) ed effettuare l'aggiornamento. È possibile chiedere quali saranno i pacchetti aggiornati con:

apt update
apt list --upgradable

Raramente si dovrà ricorrere all'aggiornamento manuale come indicato al paragrafo precedente.

Al termine dell'aggiornamento conviene verificare ad esempio con dselect quali sono i pacchetti considerati obsoleti, e quindi disinstallarli.

Inoltre dovrebbe essere possibile eliminare tutti i pacchetti installati per dipendenze precedenti, che non sono più necessari:

apt autoremove

Infine si possono cercare pacchetti marcati per essere disinstallati, per rimuovere anche loro:

dpkg --get-selections | egrep -v '\binstall\b'

Per il Python è possibile installare python-is-python2 oppure python-is-python3, a seconda di quale interprete predefinito si voglia usare. Non è più prevista la dipendenza generica da python, ma un pacchetto dovrà indicare esplicitamente python2 oppure python3.