Hai un server Linux in produzione, provi a installare un pacchetto e ti ritrovi con dipendenze rotte, versione sbagliata, o peggio: un repo che non esiste più. Oppure hai bisogno di un software che nei repository ufficiali non c'è, e non sai da dove cominciare per compilarlo da sorgente. Succede a tutti, anche a noi dopo anni di lavoro su server Debian, CentOS e Arch. La buona notizia: una volta capito come funzionano i gestori di pacchetti e la compilazione, hai il controllo totale del sistema. In questa guida ti portiamo dritto al punto, con esempi reali e nessuna teoria astratta.
Gestori di pacchetti: perché ne hai bisogno
Su Linux ogni software è un insieme di file binari, librerie, configurazioni e dipendenze. Installare a mano significa rischiare conflitti, versioni sbagliate e un incubo di manutenzione. I package manager risolvono tutto: scaricano da repository verificati, gestiscono le dipendenze (quelle librerie che servono al software per funzionare), permettono aggiornamenti semplici e rimozioni pulite.
Noi, di Meteora Web, abbiamo decenni di esperienza con server Linux. L'errore più comune che vediamo: usare apt su una CentOS, o forzare un pacchetto RPM su Debian. Ogni gestore ha il suo formato: .deb per Debian/Ubuntu, .rpm per Fedora/RHEL/CentOS, .pkg.tar.zst per Arch Linux. Mescolarli è il modo più veloce per rompere il sistema.
APT su Debian e Ubuntu
APT (Advanced Package Tool) è il gestore delle distribuzioni Debian-based. Lavora sopra dpkg, che installa fisicamente i pacchetti .deb. I comandi essenziali:
# Aggiornare la lista dei pacchetti disponibili
sudo apt update
# Installare un pacchetto
sudo apt install nginx
# Rimuovere ma tenere le configurazioni
sudo apt remove nginx
# Rimuovere anche le configurazioni e dipendenze non più necessarie
sudo apt purge nginx
sudo apt autoremove
# Cercare un pacchetto
apt search "web server"
# Mostrare dettagli e dipendenze
apt show nginxErrore comune: dimenticare sudo apt update prima di installare. Se il repository locale non è sincronizzato, installi una versione vecchia o non trovi il pacchetto. Noi lo vediamo spesso in ambienti di produzione: si spende un minuto in più per aggiornare, si risparmiano ore di debug.
Sponsored Protocol
Per aggiungere repository esterni (es. PHP più recente di quello ufficiale Debian):
# Aggiungere la chiave GPG e il repository
sudo apt -y install lsb-release ca-certificates curl
sudo curl -fsSL https://packages.sury.org/php/apt.gpg | sudo gpg --dearmor -o /usr/share/keyrings/php.gpg
echo "deb [signed-by=/usr/share/keyrings/php.gpg] https://packages.sury.org/php/ $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/php.list
sudo apt update
sudo apt install php8.3DNF su Fedora e RHEL/CentOS 8+
DNF è il successore di YUM, usato nelle distribuzioni Red Hat-based. Stesso concetto di repository, ma con sintassi diversa. Comandi essenziali:
# Aggiornare e installare
sudo dnf update
sudo dnf install nginx
# Rimuovere
sudo dnf remove nginx
# Cercare
sudo dnf search "web server"
# Informazioni
sudo dnf info nginxUna differenza importante: DNF gestisce meglio i conflitti di dipendenze rispetto a YUM, ma è più lento nel refresh dei repository. Per aggiungere repository extra, ad esempio EPEL (Extra Packages for Enterprise Linux):
Sponsored Protocol
sudo dnf install epel-release
sudo dnf update
sudo dnf install htopAttenzione: su CentOS 7 (vecchio) non usare dnf, ma yum. Noi abbiamo già fatto il salto a Rocky Linux 9 su tutti i server, molto più moderno e con supporto attivo.
Pacman su Arch Linux
Arch Linux usa pacman, semplice e veloce. Ma attenzione: rolling release, gli aggiornamenti sono continui. Comodi, ma ogni tanto possono rompere qualcosa. Comandi:
# Sincronizzare e installare
sudo pacman -Syu
sudo pacman -S nginx
# Rimuovere
sudo pacman -R nginx
# Rimuovere con dipendenze non necessarie
sudo pacman -Rs nginx
# Cercare
pacman -Ss "web server"
# Informazioni
pacman -Qi nginxUn trucco che usiamo spesso: pacman -Qdt elenca i pacchetti orfani (non più dipendenti da nessuno). Pulirli fa bene al sistema.
Compilazione da sorgente: quando serve e come farla
Ci sono casi in cui il pacchetto nei repository non esiste, è troppo vecchio, o hai bisogno di opzioni di compilazione specifiche. Allora si compila dal sorgente. Non serve essere un ingegnere del kernel: il processo è standard e, se fatto bene, ti dà il massimo controllo.
Scenario reale: un cliente ci chiede di installare una versione personalizzata di Nginx con il modulo ngx_pagespeed per ottimizzare le performance. Nei repository ufficiali non c'è. Soluzione: compilare.
Il flusso base: configure, make, make install
Tutti i progetti seri (C, C++) usano lo stesso pattern:
Sponsored Protocol
# 1. Scaricare il sorgente
wget https://nginx.org/download/nginx-1.26.2.tar.gz
tar -xzf nginx-1.26.2.tar.gz
cd nginx-1.26.2
# 2. Configurare con opzioni
./configure --prefix=/usr/local/nginx --with-http_ssl_module --add-module=../ngx_pagespeed-latest
# 3. Compilare (con make -jN sfrutta tutti i core CPU)
make -j$(nproc)
# 4. Installare
sudo make installErrori tipici: mancano le dipendenze di sviluppo. Il configure fallisce con messaggi tipo "checking for OpenSSL... no". Soluzione: installare i pacchetti -dev o -devel.
# Su Debian/Ubuntu
sudo apt install build-essential libssl-dev libpcre3-dev zlib1g-dev
# Su Fedora/RHEL
sudo dnf groupinstall "Development Tools"
sudo dnf install openssl-devel pcre-devel zlib-develStrumenti moderni: checkinstall per pacchettizzare
Compilare con make install sporca il sistema perché non tiene traccia di ciò che installi. Per avere un vero pacchetto e poterlo disinstallare pulitamente, usa checkinstall o crea un pacchetto .deb/.rpm manualmente.
# Installa checkinstall
sudo apt install checkinstall # su Debian
sudo dnf install checkinstall # su Fedora (se disponibile)
# Dopo configure & make, invece di make install
sudo checkinstall
# Ti chiederà descrizione, versione, e creerà un pacchetto .deb che puoi installare e disinstallare come un software normaleGestione avanzata: dipendenze e repository
Spesso il problema non è installare, ma capire cosa serve e da dove viene. Ecco tre situazioni che affrontiamo ogni giorno:
1. Risolvere dipendenze mancanti
Il classico: provi a installare qualcosa e ti dice "depends on libfoo >= 2.0 but 1.0 is installed". Su Debian:
Sponsored Protocol
# Vedere le dipendenze di un pacchetto
apt depends nginx
# Tentare di risolvere automaticamente (ma attento a non rompere il sistema)
sudo apt --fix-broken installSu Fedora:
dnf repoquery --requires nginx
sudo dnf distro-sync # risincronizza pacchetti per risolvere conflitti2. Aggiungere repository di terze parti
Noi usiamo spesso repository non ufficiali per software più recenti (es. Docker, Node.js, MariaDB). La regola d'oro: fidarsi solo di repository con chiave GPG verificata e manutenzione attiva.
# Esempio per Docker su Debian
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
# Su Arch, usa AUR (Arch User Repository): attento alla sicurezza perché i pacchetti non sono ufficiali3. Compilazione con patch locali
A volte devi applicare una modifica al codice sorgente. Scarichi il sorgente, applichi la patch, poi compile.
wget https://example.com/software-1.0.tar.gz
tar -xzf software-1.0.tar.gz
cd software-1.0
wget https://example.com/fix-security.patch
patch -p1 < fix-security.patch
./configure && make && sudo make installConsiglio pratico: tieni sempre un backup del sorgente originale e documenta le patch applicate. Noi usiamo un file README nel progetto del server per tracciare ogni modifica.
Sponsored Protocol
Errori comuni e come evitarli
- Usare sudo su comandi errati:
sudo apt upgradeè giusto,sudo dnf upgradepure, masudo pacman -Syuva fatto con attenzione (aggiorna tutto il sistema). - Non leggere output di errore: se configure fallisce, l'ultima riga spesso dice cosa manca. Imparare a leggerlo ti fa risparmiare ore.
- Installare da sorgente senza pacchettizzare: dopo un anno, dimentichi cosa hai compilato e non riesci a rimuoverlo pulitamente. Usa checkinstall o crea un pacchetto fittizio.
- Mescolare repository: aggiungere repo di Ubuntu su Debian o viceversa porta a conflitti di librerie. Mai farlo.
- Dimenticare l'aggiornamento di sicurezza: i repository ufficiali rilasciano patch critiche. Su sorgente compilato devi starci dietro da solo.
In sintesi — cosa fare adesso
Non serve diventare un esperto overnight. Bastano tre mosse per mettersi al sicuro:
- Impara i tre comandi base di apt, dnf e pacman: install, remove, update. Se gestisci server, sappi qual è il tuo gestore e usa solo quello.
- Prima di compilare da sorgente, verifica se esiste un repository PPA, COPR o AUR ufficiale. Molto più semplice e sicuro.
- Quando compili, usa checkinstall per creare un pacchetto nativo. Il tuo te del futuro ti ringrazierà.
Se vuoi approfondire la gestione del server Linux partendo da zero, la nostra guida pillar Linux per Sviluppatori e Sysadmin ti porta dalla shell alla produzione. E se hai bisogno di un aiuto concreto sul tuo progetto, contattaci.
