Pacchetti di sistema

Sirio elenca gli aggiornamenti disponibili sull’host e li applica: tutti insieme, solo quelli selezionati, oppure le due operazioni di pulizia (autoremove e svuotamento della cache). Sono le stesse cose che faresti con apt da riga di comando, con il vantaggio di vedere in una tabella cosa è arretrato e quanto di quell’arretrato è di sicurezza.

Gestori supportati

Il riconoscimento guarda quale binario è presente, non /etc/os-release: vale quindi anche sulle derivate. L’ordine di ricerca è apt-get, dnf, yum, apk — dnf prima di yum perché su RHEL 8+ yum è ormai un collegamento a dnf.

Gestore	Distribuzioni	Note
apt	Debian, Ubuntu, Mint, Raspberry Pi OS, Devuan, Proxmox	supporto completo
dnf	Fedora, RHEL 8+, Rocky, Alma, CentOS Stream	completo; la versione installata arriva da rpm -qa
yum	CentOS 7, RHEL 7	come dnf, con update al posto di upgrade
apk	Alpine	solo elenco e aggiornamento: vedi sotto

Su tutto il resto (pacman, zypper, portage) la sezione si mostra vuota e lo dice.

Cosa cambia fra un gestore e l’altro

L’elenco si legge sempre senza privilegi, ma non tutti dicono le stesse cose.

• Versione installata. apt e apk la mettono accanto a quella disponibile. dnf check-update no, quindi la ricaviamo da una singola chiamata a rpm -qa; se rpm manca, la colonna resta vuota e il resto dell’elenco regge lo stesso.
• Aggiornamenti di sicurezza. apt li deduce dall’archivio di origine, dnf e yum da check-update --security (su yum molto vecchi serve il plugin: se non c’è, nessuno viene marcato). Alpine non ha il concetto: non esiste un archivio separato da cui dedurlo, quindi il contatore di sicurezza resta a zero.
• Operazioni disponibili. apk non ha un autoremove e tiene la cache spenta di default, quindi dichiara solo aggiorna elenco e aggiorna. La pagina non mostra pulsanti che fallirebbero: legge le azioni possibili da GET /api/packages (campo status.actions).

Alpine e gli host senza systemd

L’innesco è una unit .path di systemd, che su Alpine non esiste. Là l’elenco funziona lo stesso — non richiede privilegi — ma per applicare gli aggiornamenti serve qualcosa che esegua l’helper quando compare la richiesta. La riga di crontab equivalente è:

* * * * * [ -f /var/lib/sirio/packages/richiesta ] && /usr/local/lib/sirio/sirio-pkg

Il protocollo è lo stesso: l’helper consuma la richiesta e scrive log ed esito. Vale per qualunque init diverso da systemd, non solo per Alpine.

Perché serve una unit separata

È la parte che vale la pena capire, perché spiega i tre file che install.sh mette sulla macchina.

sirio-sysadmin.service gira come utente sirio, non root, con NoNewPrivileges=true e ProtectSystem=strict. In quel namespace /usr, /etc e /var/lib/dpkg sono in sola lettura: apt non funzionerebbe nemmeno se Sirio fosse root, e sudo è bloccato in partenza da NoNewPrivileges. L’unica directory scrivibile è SIRIO_DATA_DIR.

Invece di allentare l’irrigidimento dell’intero servizio, l’operazione privilegiata vive fuori:

pannello  →  /var/lib/sirio/packages/richiesta      (unico canale, scritto da Sirio)
                     ↓  sirio-pkg.path
             sirio-pkg.service   (root, oneshot, senza sandbox)
                     ↓
             /usr/local/lib/sirio/sirio-pkg  →  apt-get
                     ↓
             job/<id>.log   +   job/<id>.esito       (Sirio li legge e li mostra)

Sirio non esegue mai l’helper: scrive un file e legge due file. Il log viene inoltrato riga per riga alla pagina via WebSocket mentre apt lavora.

È lo stesso ragionamento con cui il reverse proxy gira come container invece che come servizio dell’host: l’irrigidimento resta, e ciò che ha bisogno di più permessi si sposta fuori.

Cosa può essere eseguito

L’insieme è chiuso e viene controllato due volte: da Sirio prima di scrivere la richiesta, e dall’helper — che gira come root — prima di eseguirla. Il file di richiesta è scritto da un processo meno fidato di chi lo legge, quindi il suo contenuto non è mai dato per buono.

Azione	apt	dnf / yum	apk
Aggiorna elenco	apt-get update	makecache	apk update
Aggiorna tutti	apt-get upgrade	upgrade (yum: update)	apk upgrade
Aggiorna selezionati	install --only-upgrade -- <nomi>	upgrade <nomi>	apk upgrade -- <nomi>
Rimuovi inutilizzati	apt-get autoremove	autoremove	—
Svuota cache	apt-get clean	clean all	—

Nessuna delle varianti di aggiorna selezionati installa un pacchetto che non è già presente: --only-upgrade per apt, e per dnf/yum/apk il verbo di aggiornamento su un pacchetto non installato non fa nulla.

Tutto il resto è rifiutato. In particolare:

• niente dist-upgrade/full-upgrade: rimuovono pacchetti, e non è ciò che ci si aspetta da un pulsante “aggiorna”;
• niente installazione o rimozione di pacchetti arbitrari: --only-upgrade non installa nulla di nuovo, e i nomi accettati sono solo quelli già presenti nell’elenco degli aggiornabili;
• i nomi devono rispettare ^[A-Za-z0-9][A-Za-z0-9+._-]*(:arch)?$ — l’unione delle policy di Debian, RPM e Alpine. Non è la regola di un gestore specifico ed è voluto: quel che deve essere impossibile è passare qualcosa che una shell o un parser di opzioni interpreti, e che il nome esista davvero lo stabiliscono il controllo di appartenenza all’elenco e il gestore stesso;
• per apt e apk un -- chiude le opzioni, così un nome non può diventare un flag nemmeno se la validazione fallisse; dnf5 (Fedora 41+) rifiuta -- dopo upgrade, quindi per dnf/yum è la regola sui nomi qui sopra — prima una lettera o una cifra, mai - — a impedire che un nome sia letto come opzione. Nulla viene mai concatenato in una stringa di shell: il gestore riceve una lista di argomenti;
• anche il gestore da usare passa dalla richiesta, ma l’helper lo riconvalida contro il suo insieme chiuso e verifica che il binario esista.

Le operazioni girano una alla volta: apt prende comunque il lock di dpkg, e due in parallelo darebbero solo un errore illeggibile.

Sola lettura

Se l’helper non è installato — install.sh lo salta quando apt-get non c’è — la sezione funziona lo stesso, ma solo in lettura: l’elenco degli aggiornamenti si ottiene senza privilegi (apt-get -s upgrade), applicarli no. La pagina lo dice e disabilita i pulsanti.

Per installare l’helper a posteriori:

sudo install -d -m 0755 /usr/local/lib/sirio
sudo install -m 0755 deploy/sirio-pkg /usr/local/lib/sirio/sirio-pkg
sudo install -m 0644 deploy/sirio-pkg.service deploy/sirio-pkg.path /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable --now sirio-pkg.path

Per toglierlo, basta il contrario: systemctl disable --now sirio-pkg.path e via i tre file. La sezione torna in sola lettura senza altre modifiche.

Riavvio richiesto

Alcuni aggiornamenti (kernel, libc) chiedono un riavvio per avere effetto. Sirio mostra l’avviso leggendo /var/run/reboot-required e i pacchetti che l’hanno creato. Il riavvio non lo fa il pannello: è un’operazione che interrompe i siti ospitati, e va decisa da chi sa quando può permetterselo.

Se qualcosa non torna

Sintomo	Causa probabile
«nessuna risposta da sirio-pkg»	l’unit non è attiva: systemctl status sirio-pkg.path
«apt è uscito con codice 100»	lock di dpkg occupato, spesso da unattended-upgrades. L’output completo è nel log dell’operazione
Elenco fermo a una data vecchia	manca un apt-get update: è il pulsante Aggiorna elenco
La sezione è vuota su Debian	SIRIO_PACKAGES_ENABLED=false, oppure apt-get non è nel PATH del servizio

Il registro attività annota chi ha chiesto cosa; lo storico delle operazioni conserva log ed esito delle ultime SIRIO_PACKAGES_RETENTION esecuzioni.

Convivenza con unattended-upgrades

Non si escludono: unattended-upgrades continua a fare il suo lavoro, e Sirio vede il risultato al giro di elenco successivo. L’unico attrito è il lock di dpkg quando le due cose capitano insieme — in quel caso l’operazione del pannello fallisce con un errore esplicito e si può ripetere.