1 30/10/2026 9 min

Su AlmaLinux 9 Jenkins gira bene, ma conviene impostarlo con criterio fin dall’inizio: Java corretta, servizio stabile, accesso protetto e, se serve, pubblicazione dietro reverse proxy. L’errore più comune è trattarlo come un’applicazione qualsiasi e lasciarlo esposto sulla porta 8080 senza limiti: funziona subito, poi diventa un problema di sicurezza e manutenzione.

Qui trovi una procedura completa per installarlo, avviarlo, aprirlo in rete in modo ordinato e fare i controlli minimi prima di usarlo in produzione o in un ambiente condiviso.

Prerequisiti e obiettivo operativo

Assumo un server AlmaLinux 9 aggiornato, accesso root o sudo, con connettività verso i repository ufficiali e una porta libera per Jenkins. Jenkins richiede Java; su AlmaLinux 9 la scelta più lineare è OpenJDK 17, che è la linea supportata e coerente con l’ecosistema attuale.

Obiettivo pratico: installare Jenkins come servizio systemd, verificarne l’avvio, accedere all’interfaccia web, aprire il firewall solo dove serve e, se necessario, metterlo dietro un reverse proxy con TLS. Se stai lavorando in un nodo di produzione, considera l’impatto come potenzialmente alto: il servizio tocca rete, autenticazione e spesso credenziali di deploy.

Aggiungere il repository Jenkins su AlmaLinux 9

Jenkins non è normalmente disponibile nei repository base di AlmaLinux. La via più pulita è aggiungere il repository ufficiale, importare la chiave GPG e installare il pacchetto da lì. Così eviti build manuali o pacchetti di terze parti non allineati agli aggiornamenti del progetto.

Prima di tutto aggiorna il sistema e installa i pacchetti necessari per la gestione del repository:

sudo dnf update -y
sudo dnf install -y curl fontconfig java-17-openjdk java-17-openjdk-devel

Il pacchetto fontconfig non è un vezzo: Jenkins e alcune sue dipendenze possono averne bisogno in fase di rendering o per componenti che generano output grafico. La parte Java è obbligatoria: senza JDK/JRE non parte proprio.

Ora aggiungi il repository ufficiale Jenkins. Il file può variare nel tempo, quindi la logica è semplice: scaricare la sorgente del repo, registrarla in /etc/yum.repos.d/ e poi importare la chiave se richiesto dal pacchetto o dal repository stesso.

sudo curl -fsSL \ https://pkg.jenkins.io/redhat-stable/jenkins.repo \ -o /etc/yum.repos.d/jenkins.repo sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io-2023.key

Se il nome della chiave dovesse cambiare nel tempo, lo verifichi direttamente sulla documentazione ufficiale del progetto. Il punto importante è non installare Jenkins da sorgenti non verificate o da repository casuali.

Installazione del pacchetto Jenkins

A questo punto l’installazione è lineare. Il pacchetto crea utente di servizio, unità systemd e configurazione iniziale in /etc/sysconfig/jenkins e /var/lib/jenkins.

sudo dnf install -y jenkins

Dopo l’installazione, il servizio non sempre parte automaticamente. Conviene verificare subito lo stato e abilitare l’avvio all’accensione solo quando sei sicuro che la configurazione sia coerente.

sudo systemctl enable --now jenkins
sudo systemctl status jenkins --no-pager

Output atteso: stato active (running), nessun errore di Java o di binding sulla porta. Se il servizio fallisce, il primo posto da guardare è il journal:

sudo journalctl -u jenkins -b --no-pager

Verifica della porta e primo accesso

Per default Jenkins ascolta sulla porta 8080. Verifica che il processo sia in ascolto prima di aprire il firewall o di esporlo pubblicamente.

sudo ss -lntp | grep 8080

Se la porta risulta in ascolto, puoi raggiungere Jenkins da browser usando http://IP_DEL_SERVER:8080. Al primo avvio ti verrà chiesta la password iniziale, che si trova nel file indicato dal pacchetto:

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

Questa password serve solo per la procedura iniziale. Dopo il primo accesso va superata con la configurazione degli utenti e dei permessi, non riutilizzata o condivisa in chiaro.

Configurazione del firewall su AlmaLinux 9

Se il server usa firewalld, devi aprire almeno la porta 8080 in ingresso. In un ambiente serio, però, è preferibile esporre Jenkins solo dietro reverse proxy e limitare l’accesso diretto alla porta applicativa a rete interna o localhost.

Per un accesso diretto temporaneo, apri la porta così:

sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reload
sudo firewall-cmd --list-ports

Condizione OK: 8080/tcp compare nell’elenco. Condizione KO: il browser non raggiunge il servizio pur con Jenkins in ascolto. In quel caso verifica anche eventuali ACL di rete, security group cloud o filtri upstream.

Rendere Jenkins meno esposto: reverse proxy con Nginx

Esporre Jenkins direttamente su 8080 è accettabile solo per test rapidi o reti molto controllate. La configurazione più sana è: Jenkins in ascolto locale o su porta interna, Nginx davanti, TLS attivo e accesso pubblico solo su 443. Questo ti semplifica certificati, header, HSTS e logging.

Per prima cosa, limita Jenkins ad ascoltare solo su localhost o su una rete interna. Il file da toccare è /etc/sysconfig/jenkins. Qui trovi il parametro della porta; in molte installazioni puoi gestirlo anche dall’interfaccia o dalla variabile di servizio, ma il file resta il punto più immediato da controllare.

Apri il file e imposta, per esempio, una porta locale diversa o mantieni 8080 ma accessibile solo internamente se il server è protetto da firewall:

sudo grep '^JENKINS_PORT=' /etc/sysconfig/jenkins

Se vuoi farlo ascoltare solo in locale, l’approccio dipende dalla versione e dal packaging, ma il principio è sempre lo stesso: l’edge pubblico non deve parlare direttamente con la porta applicativa. Dopo ogni modifica riavvia il servizio e verifica il binding con ss.

Un esempio minimo di virtual host Nginx per inoltrare verso Jenkins:

server { listen 80; server_name jenkins.example.com; location / { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; }
}

Questo snippet è la base. In produzione serve quasi sempre anche TLS, quindi il blocco va portato su 443 con certificato valido, redirezione da HTTP a HTTPS e, se necessario, header di sicurezza coerenti con il resto dell’infrastruttura.

Ricorda di configurare in Jenkins il valore del proxy se l’URL pubblico non coincide con la porta interna. La voce si trova in Manage Jenkins > System > Jenkins Location e, nelle installazioni dietro proxy, va impostato correttamente il Jenkins URL.

TLS e URL pubblica corretta

Jenkins dietro proxy funziona male se l’URL pubblico non è coerente con quello configurato internamente. Il sintomo tipico è login che rimbalza, link errati nelle email, webhook che falliscono o asset caricati con schema sbagliato. Il controllo da fare è semplice: l’URL impostato in Jenkins deve corrispondere al dominio con cui gli utenti accedono davvero.

Se usi Nginx con certificato Let’s Encrypt, la sequenza tipica è installare il supporto ACME, ottenere il certificato e poi attivare il redirect 80→443. I dettagli dipendono dal tuo stack web, ma la logica non cambia: TLS termina sull’edge, Jenkins resta dietro.

Verifica pratica: nel browser il lucchetto deve risultare valido, e un accesso a http://jenkins.example.com deve essere rediretto a https://jenkins.example.com. Se non succede, guarda la configurazione del virtual host e i log di Nginx.

Hardening minimo dell’istanza Jenkins

Una Jenkins appena installata non è un ambiente sicuro per default. Va trattata come un servizio amministrativo sensibile: autenticazione, autorizzazioni, plugin e accesso di rete devono essere ridotti al minimo utile.

  1. Disabilita l’accesso anonimo se non serve. In Manage Jenkins > Security, imposta un modello di autorizzazione chiaro e assegna i permessi per ruolo o gruppo.
  2. Usa account nominativi, non condivisi. Gli account di servizio per pipeline vanno separati dagli account umani.
  3. Installa solo i plugin necessari. Ogni plugin aggiunge superficie d’attacco e complessità di upgrade.
  4. Mantieni Jenkins aggiornato insieme a Java e al sistema operativo. Controlla compatibilità prima di aggiornare in massa i plugin.
  5. Se Jenkins è accessibile da Internet, valuta restrizioni IP, MFA tramite integrazione con IdP e logging centralizzato.

Un punto spesso trascurato è il file system. La directory /var/lib/jenkins contiene job, configurazioni, credenziali e dati operativi. Va protetta con backup regolari e permessi coerenti. Se fai snapshot o backup a livello host, verifica che la finestra di backup non corrompa job in scrittura o archivi in fase di rotazione.

Backup e ripristino di base

Per un’istanza piccola, il backup minimo utile include almeno /var/lib/jenkins e, se hai personalizzato il servizio, anche /etc/sysconfig/jenkins e la configurazione del reverse proxy. Senza questi elementi il ripristino è incompleto.

Controlla anche dove tieni i job esterni, gli script di pipeline e le credenziali gestite fuori da Jenkins. Il rischio classico è ripristinare l’applicazione ma perdere il contesto operativo attorno ad essa.

Se vuoi verificare rapidamente che il backup sia sensato, confronta dimensione e contenuto con una copia di test:

sudo du -sh /var/lib/jenkins
sudo ls -la /var/lib/jenkins

Rollback tipico: ferma Jenkins, ripristina i file salvati, riallinea permessi e riavvia il servizio. Prima di farlo in produzione, però, assicurati che nessun job stia scrivendo dati critici.

Controlli finali dopo l’installazione

Una volta completata la configurazione, fai una verifica completa e non solo “la pagina si apre”. Il controllo minimo dovrebbe includere questi punti:

  • Servizio attivo: systemctl status jenkins mostra active (running).
  • Porta in ascolto: ss -lntp | grep 8080 o la porta configurata restituisce il listener atteso.
  • Accesso web: il browser carica la dashboard senza errori 5xx o redirect infiniti.
  • Proxy coerente: il dominio pubblico corrisponde al valore di Jenkins URL.
  • Log puliti: journalctl -u jenkins -b non mostra stack trace ripetuti o errori di binding.

Se qualcosa non torna, il percorso diagnostico migliore è sempre lo stesso: prima stato del servizio, poi log, poi rete, poi configurazione applicativa. Saltare direttamente alla modifica della configurazione senza osservare l’errore reale è il modo più rapido per introdurre un secondo problema sopra al primo.

Assunzione operativa: il server è Linux recente con systemd, Jenkins è esposto solo quanto necessario e ogni modifica a rete o configurazione viene prima verificata in staging o in una finestra controllata.

Risoluzione rapida dei problemi più comuni

Se Jenkins non parte, i casi più frequenti sono Java non compatibile, porta già occupata o permessi errati sulla directory dati. In pratica: controlla il journal, verifica la porta con ss e conferma che /var/lib/jenkins sia leggibile e scrivibile dall’utente di servizio.

Se la pagina resta bianca o non completa il bootstrap iniziale, il problema spesso non è Jenkins in sé ma un proxy mal configurato, un URL pubblico sbagliato o una versione di Java non allineata. Se invece il login funziona ma i link puntano all’indirizzo interno, quasi sempre manca l’impostazione corretta del Jenkins URL.

Se vuoi un’installazione solida, non fermarti al servizio acceso: controlla subito accesso, sicurezza, proxy e backup. Jenkins tende a diventare il centro operativo del ciclo di build, quindi va trattato come un componente infrastrutturale, non come una web app qualunque.