Come installare Splunk Data Platform su Ubuntu 20.04

Prerequisiti reali prima di scaricare il pacchetto

Su Ubuntu 20.04 l’installazione di Splunk Data Platform non è il punto difficile; il punto difficile è evitare di portarsi dietro un host mal preparato, con spazio insufficiente, limiti kernel inadatti o una rete che poi blocca l’accesso all’interfaccia web. Se l’obiettivo è una macchina stabile, conviene trattare l’installazione come un change controllato: prima si verifica il contesto, poi si installa, poi si apre il servizio verso l’esterno solo se serve davvero.

© TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster — https://trgtkls.it — tutti i diritti riservati.

Assumo un host Ubuntu 20.04 aggiornato, con accesso sudo, almeno 8 GB di RAM per un uso non banale e uno storage separato o comunque ben dimensionato. Per un test minimale si può scendere, ma in produzione il collo di bottiglia più frequente è il disco, non la CPU. Splunk scrive molto, indicizza molto e soffre appena il filesystem viene riempito o latenza e IOPS peggiorano.

Prima di scaricare il pacchetto, controlla quattro cose: versione del sistema, spazio disco, risoluzione DNS e raggiungibilità di rete verso il repository o il file di installazione. Se una di queste manca, il problema non è Splunk ma l’ambiente.

Comandi utili per un check rapido:

lsb_release -a
uname -r
df -h
free -h
ip a
resolvectl status
curl -I https://download.splunk.com/

Se il DNS non risolve o il proxy aziendale intercetta il traffico, è meglio saperlo subito. In particolare, l’errore più comune nei deployment interni è una rete che permette il download iniziale ma poi impedisce gli aggiornamenti o la telemetria. Se vuoi evitare sorprese, definisci fin da subito se l’host avrà accesso diretto a internet oppure no.

Scelta del pacchetto: .deb, servizio locale e impostazione del nome host

Su Ubuntu la strada più lineare è usare il pacchetto .deb ufficiale. La logica è semplice: si installa il software come servizio locale, si lascia a systemd la gestione del processo e si decide dopo se esporre la GUI sulla rete interna o dietro reverse proxy. Evita installazioni improvvisate in directory casuali o sotto un utente non documentato: poi il troubleshooting diventa inutilmente costoso.

Prima di installare, conviene definire il nome host e, se possibile, la FQDN che userai per l’accesso. Splunk registra molti riferimenti interni al nome host; cambiarlo dopo è possibile, ma non è un dettaglio da trascurare. Se sei in una rete con DNS interno, prepara già il record A o il CNAME che punterà al server.

Scarica il pacchetto solo da fonte ufficiale e verifica l’integrità del file se il workflow lo richiede. In ambienti regolati, il controllo del checksum non è opzionale.

wget -O splunk-9.x.x-linux-amd64.deb 'https://download.splunk.com/products/splunk/releases/9.x.x/linux/splunk-9.x.x-linux-amd64.deb'
sha256sum splunk-9.x.x-linux-amd64.deb

Se il checksum pubblicato dal vendor non coincide, fermati. Non forzare l’installazione “per provare”. Il costo di un pacchetto corrotto o alterato è molto più alto del tempo perso a fare una verifica in più.

Installazione del pacchetto su Ubuntu 20.04

La fase di installazione è breve, ma va fatta con un minimo di disciplina. Se usi un host destinato alla produzione, conviene registrare il pacchetto installato e salvare il file .deb in un repository interno o in una share controllata. Così hai una base ripetibile per eventuali reinstallazioni.

Installa il pacchetto con dpkg o apt. Se il file locale è già presente, dpkg è immediato; se vuoi che il sistema risolva eventuali dipendenze mancanti, apt è più comodo. In entrambi i casi, il servizio viene registrato con unit systemd.

sudo dpkg -i splunk-9.x.x-linux-amd64.deb
sudo apt-get -f install

Dopo l’installazione, verifica che il binario sia presente e che l’utente di servizio esista. Il percorso tipico è /opt/splunk. È utile anche controllare i permessi della directory, perché errori di ownership sui volumi dati sono una delle cause più noiose da diagnosticare.

ls -ld /opt/splunk
id splunk
systemctl status Splunkd --no-pager

Se il servizio non parte subito, non andare a tentativi con restart ripetuti. Leggi prima i log di bootstrap. Il primo avvio crea directory, file di default e struttura interna; se qualcosa fallisce qui, il sintomo successivo è quasi sempre più ambiguo del problema originale.

Primo avvio e accettazione della licenza

Splunk richiede l’accettazione della licenza al primo avvio. In un ambiente interattivo puoi farlo da shell; in automazione conviene preparare un provisioning script che includa il consenso esplicito, altrimenti il deployment si pianta a metà. È una di quelle cose che sembrano banali finché non entrano in un flusso Ansible o in una pipeline di bootstrap.

Avvia il servizio e accetta la licenza in modo esplicito. Se non vuoi usare il percorso interattivo, puoi parametrizzare il comando. L’idea è semplice: il primo startup deve essere ripetibile e documentato.

sudo /opt/splunk/bin/splunk start --accept-license

Al termine, Splunk espone di default la web UI sulla porta 8000 e il daemon di gestione sulla 8089. Se il firewall è attivo, la GUI non sarà raggiungibile finché non apri esplicitamente la porta. Su Ubuntu con UFW il comportamento è lineare: se la regola non esiste, la connessione viene bloccata.

Verifica lo stato con systemd e con una richiesta HTTP locale. È il controllo più semplice per distinguere un problema di servizio da un problema di rete.

systemctl is-active Splunkd
curl -I http://127.0.0.1:8000

Se il servizio è attivo ma la porta non risponde, guarda i log di avvio in /opt/splunk/var/log/splunk/. I file più utili sono in genere splunkd.log e web_service.log. In fase iniziale, questi due file dicono molto più di qualunque ipotesi astratta.

Impostare password amministrativa e accesso iniziale

La password iniziale dell’utente amministrativo non va lasciata a valori deboli o a procedure manuali non tracciate. In un setup serio, la password deve essere definita al bootstrap e poi ruotata secondo policy. Se usi automation, evita di scriverla in chiaro nei playbook: usa un vault, un secret manager o almeno un input protetto dall’orchestratore.

Il primo accesso via browser avviene di solito su https://server:8000 o http://server:8000 a seconda della configurazione iniziale. Nelle versioni moderne, il traffico web è spesso protetto con TLS; se hai un certificato custom, conviene impostarlo subito, non dopo che gli utenti hanno già iniziato a usare l’istanza.

Se vuoi impostare la password da CLI durante il provisioning, il comando tipico è quello di avvio con username e password iniziali. In ambienti con automazione, questa è la parte che va trattata con più attenzione dal punto di vista della sicurezza operativa.

sudo /opt/splunk/bin/splunk start --accept-license --answer-yes --no-prompt \ --seed-passwd 'PASSWORD_INIZIALE'

Quella password non deve restare in uno script in chiaro. Se la usi in un test locale, ruotala subito dopo e cancella la traccia dal file di provisioning. In contesti condivisi, la regola è semplice: niente segreti in chiaro, nemmeno temporanei.

Firewall, porte e raggiungibilità della web UI

Splunk usa alcune porte chiave che vanno pianificate prima della messa in esercizio. La più visibile è la 8000 per l’interfaccia web. La 8089 è la porta del management service. Se devi ricevere dati in ingresso, altre porte entrano in gioco a seconda del ruolo dell’istanza. Non aprire tutto “per sicurezza”: apri solo ciò che serve al profilo della macchina.

Su Ubuntu con UFW, una configurazione minima per consentire accesso alla GUI da una rete amministrativa potrebbe essere questa:

sudo ufw allow from 192.0.2.0/24 to any port 8000 proto tcp
sudo ufw allow from 192.0.2.0/24 to any port 8089 proto tcp
sudo ufw status verbose

Se l’istanza deve essere raggiunta solo tramite reverse proxy, puoi evitare l’esposizione diretta della 8000 verso reti più ampie. È una scelta più pulita, soprattutto se vuoi centralizzare TLS, rate limiting e logging di accesso. In quel caso, il firewall deve permettere l’accesso solo dal proxy o dalla subnet di front-end.

Controlla sempre la raggiungibilità con un test reale, non solo con l’idea che “la porta è aperta”. Un curl dalla stessa subnet amministrativa evita di confondere problemi di routing, firewall o policy di sicurezza a monte.

curl -I http://IP_DEL_SERVER:8000

Hardening minimo utile su Ubuntu 20.04

Il hardening non è un add-on estetico. Se l’istanza resta esposta, va trattata come un servizio di amministrazione sensibile. Il primo passo è aggiornare il sistema e tenere sotto controllo i pacchetti installati. Il secondo è limitare l’accesso alla GUI e al management service. Il terzo è assicurarsi che i file di configurazione non siano modificabili da utenti non autorizzati.

Un controllo base dei pacchetti e degli aggiornamenti disponibili è utile anche per Splunk, perché il sistema operativo resta parte della superficie d’attacco. In ambienti con manutenzione periodica, conviene pianificare finestre di update e riavvio, soprattutto se il kernel o librerie di base vengono aggiornate.

sudo apt update
sudo apt list --upgradable

Per Splunk, verifica il file /opt/splunk/etc/system/local/server.conf solo se hai necessità di personalizzare bind address, hostname o parametri di rete. Evita di toccare i file di default nel tree applicativo: il pattern corretto è usare gli override in etc/system/local o in app dedicate. Così il rollback è semplice e il diff resta pulito.

Un esempio tipico di configurazione minimale per forzare il nome host o parametri correlati va inserito con cautela e salvato in backup prima della modifica. Non c’è nulla di peggio di una configurazione fatta a mano e poi dimenticata.

[general]
hostname = splunk01.example.local

Dopo ogni modifica, riavvia solo se serve e misura l’effetto. Se la modifica riguarda la rete o il binding, il controllo giusto è la combinazione di ss -lntp, stato systemd e accesso HTTP locale.

ss -lntp | grep -E '8000|8089'
systemctl status Splunkd --no-pager

Verifica operativa: cosa deve funzionare davvero

A installazione conclusa, il controllo non è “il processo è vivo”, ma “il servizio è usabile”. In pratica devi verificare almeno quattro cose: il demone è attivo, la web UI risponde, i log non mostrano errori ricorrenti e il filesystem non è già vicino alla saturazione. Se manca uno di questi punti, l’installazione è solo parzialmente riuscita.

Un set di controlli essenziale è questo:

systemctl is-active Splunkd
curl -I http://127.0.0.1:8000
sudo tail -n 50 /opt/splunk/var/log/splunk/splunkd.log
sudo tail -n 50 /opt/splunk/var/log/splunk/web_service.log
df -h /opt/splunk

Se trovi errori di binding sulla porta, di permessi o di spazio disco, risolvili prima di procedere con l’onboarding dei dati. Un’istanza appena installata che già scrive warning continui nei log tende a peggiorare rapidamente quando iniziano gli input reali.

Se vuoi esporre Splunk dietro un reverse proxy, verifica anche che gli header e il redirect siano coerenti. Un proxy configurato male può generare loop di login, redirect sbagliati o contenuti misti. In quel caso il problema non è Splunk in sé, ma l’integrazione con il front-end.

Persistenza, backup e rollback ragionato

Una volta che l’istanza è operativa, il passo successivo è rendere reversibili le modifiche. La regola pratica è semplice: ogni file che tocchi va salvato prima, ogni change va documentato e ogni servizio coinvolto deve avere un punto di ritorno chiaro. In un ambiente con change management, questo vale ancora di più per un sistema che gestisce dati e indicizzazione.

Prima di modificare configurazioni in /opt/splunk/etc, crea una copia del file o usa un controllo versione locale. Per esempio:

sudo cp /opt/splunk/etc/system/local/server.conf /opt/splunk/etc/system/local/server.conf.bak

Se qualcosa va storto, il rollback deve essere immediato e comprensibile: ripristino del file, riavvio del servizio, verifica della porta e controllo log. Non serve una procedura complessa; serve una procedura affidabile e già provata.

In sintesi operativa, l’installazione su Ubuntu 20.04 funziona bene quando il sistema è preparato, il pacchetto è verificato, l’avvio iniziale è documentato e la superficie esposta è ridotta al minimo necessario. Il resto è manutenzione: aggiornamenti, log, capacità disco e disciplina sulle modifiche.