Installare GNS3 Server su Ubuntu 24.04 LTS passo dopo passo

Installare GNS3 Server su Ubuntu 24.04 LTS: cosa serve davvero

GNS3 Server non è il software grafico che usi sul desktop: è il componente che esegue i nodi, gestisce le immagini e parla con il client GNS3. Su Ubuntu 24.04 LTS conviene trattarlo come un servizio di infrastruttura, non come una semplice app da installare e dimenticare. La differenza pratica è questa: se lo metti bene, il server diventa stabile, aggiornabile e riavviabile da systemd; se lo configuri in fretta, finisci con permessi sbagliati, porte chiuse e immagini che non partono.

La strada più pulita è usare un host dedicato o una VM con risorse coerenti con i laboratori che devi far girare. Per scenari piccoli basta poco, ma appena entrano in gioco più appliance, immagini QEMU, container o topologie con molte interfacce virtuali, la parte che cede per prima è quasi sempre RAM o I/O disco, non CPU.

Prerequisiti reali su Ubuntu 24.04

Prima di installare, verifica tre cose: accesso sudo, rete funzionante e spazio disco sufficiente. GNS3 Server scrive log, immagini e file di progetto; se lo installi su una macchina con storage stretto, il problema emerge dopo, quando i progetti iniziano a crescere.

Per un’installazione base considera almeno 2 vCPU, 4 GB di RAM e 20 GB liberi. Per uso serio, soprattutto con QEMU, alza il margine. Non è un valore “ufficiale” universale: dipende dalle immagini e dal numero di nodi, quindi la metrica vera da osservare è la saturazione di RAM e disco durante l’avvio dei lab.

Controlla subito release e kernel, così sai su cosa stai lavorando:

lsb_release -a
uname -r
free -h
df -h /

Se il filesystem di root è già vicino al limite, fermati e sposta dati e immagini su un volume dedicato prima di andare oltre.

Metodo consigliato: pacchetti ufficiali e servizio systemd

Su Ubuntu 24.04 la scelta più sensata è installare GNS3 Server da repository compatibili con la tua versione, oppure dal canale indicato dal progetto se il repository distro non basta. Qui il punto non è “fare prima”, ma avere dipendenze risolte in modo ripetibile e un servizio gestibile con systemd.

Prima aggiorna l’indice pacchetti e prepara i tool di base:

sudo apt update
sudo apt install -y software-properties-common curl ca-certificates gnupg

Se il repository che userai fornisce una chiave firmata, importala con il meccanismo previsto dal fornitore. Evita scorciatoie tipo chiavi globali in posizioni vecchie o script che aggiungono sorgenti senza verifica. Su un server esposto in rete, la pulizia del trust chain conta più della comodità.

In pratica, la sequenza tipica è: aggiunta repository, installazione pacchetto, verifica binario, avvio servizio. La sintassi esatta del repository dipende dal canale scelto, quindi qui il punto importante è il metodo, non una riga magica che rischia di diventare obsoleta. Se hai già una fonte ufficiale per la tua versione, segui quella e conserva il file `.list` o `.sources` sotto versionamento operativo.

Dipendenze che non devi saltare

GNS3 Server non vive da solo. A seconda di come lo usi, possono servire componenti per QEMU, Docker, dinamips, ubridge e librerie Python. Il punto operativo è semplice: installa solo ciò che ti serve davvero, ma verifica che il server riesca a trovare i backend necessari quando avvii un progetto.

Un controllo utile dopo l’installazione è questo:

gns3server --version
which gns3server
systemctl status gns3server

Se il binario non esiste, il pacchetto non è stato installato nel modo giusto o il repository non è quello previsto. Se il servizio non parte, vai subito nei log e non perdere tempo a riavviare a caso.

Per i log di systemd:

journalctl -u gns3server -b --no-pager

Le cause più frequenti in questa fase sono tre: dipendenze mancanti, porta già occupata oppure permessi insufficienti sulle directory usate dal servizio.

Creare l’utente di servizio e le directory corrette

Un server ben tenuto non gira come root se non è strettamente necessario. Crea un utente dedicato, assegna le directory di lavoro e limita i permessi al minimo. Questo riduce il danno potenziale se un’immagine o un progetto fa cose che non dovrebbe fare.

Esempio tipico:

sudo adduser --system --group --home /var/lib/gns3 gns3
sudo mkdir -p /var/lib/gns3 /var/log/gns3
sudo chown -R gns3:gns3 /var/lib/gns3 /var/log/gns3

Se i tuoi progetti stanno su un filesystem separato, monta lì le immagini e i file di lavoro. Il vantaggio non è solo organizzativo: quando il disco di sistema si riempie, hai più controllo su crescita e manutenzione.

Controlla anche la presenza delle porte che vuoi usare. GNS3 Server di solito ascolta su una porta TCP dedicata, e il client si connette lì. Verifica con:

ss -ltnp | grep -E '3080|gns3'

Se la porta è diversa per la tua installazione, annotala subito e usala sempre nello stesso modo nel client e nei test di rete.

Configurazione del server: file, porta e bind address

La configurazione di GNS3 Server va trattata come quella di qualunque altro demone: file chiaro, valori espliciti, nessuna ambiguità su indirizzo di bind e accesso remoto. Se il server deve essere raggiungibile da altri host, non lasciarlo legato solo a localhost.

Il file di configurazione può variare in base al pacchetto e al metodo di installazione, ma il concetto resta lo stesso: definisci interfaccia, porta e directory. Un esempio di logica corretta è questo, da adattare al percorso effettivo della tua installazione:

[server]
host = 0.0.0.0
port = 3080
project_directory = /var/lib/gns3/projects
images_directory = /var/lib/gns3/images

Non copiare questo blocco alla cieca se il tuo pacchetto usa un formato diverso. Prima individua il file effettivo con:

systemctl cat gns3server
find /etc -maxdepth 3 -iname '*gns3*' -o -iname '*.conf' | grep -i gns3

Il punto non è trovare “un file”, ma trovare quello realmente usato dal servizio. Su server Linux questa distinzione evita metà degli errori di troubleshooting.

Unità systemd: avvio automatico e logging pulito

Se il pacchetto non crea già l’unità systemd, puoi costruirla in modo minimale e leggibile. L’obiettivo è avere restart automatico, log nel journal e un avvio coerente dopo reboot.

[Unit]
Description=GNS3 Server
After=network-online.target
Wants=network-online.target

[Service]
User=gns3
Group=gns3
ExecStart=/usr/bin/gns3server
Restart=on-failure
RestartSec=3
WorkingDirectory=/var/lib/gns3

[Install]
WantedBy=multi-user.target

Dopo aver creato o modificato l’unità, ricarica systemd e abilita il servizio:

sudo systemctl daemon-reload
sudo systemctl enable --now gns3server
sudo systemctl status gns3server --no-pager

Se il servizio fallisce, il journal ti dice subito se il problema è un percorso sbagliato, un permesso negato o un argomento non riconosciuto dal binario. Non andare avanti senza leggere quelle righe.

Firewall e accesso remoto senza aprire troppo

Se il server deve essere raggiunto dal client GNS3 su un’altra macchina, apri solo la porta necessaria e solo verso le reti che ti servono. Su Ubuntu 24.04, se usi UFW, la regola minima è semplice.

sudo ufw allow 3080/tcp
sudo ufw status verbose

Se hai un firewall perimetrale o una security group nel cloud, la logica è identica: consenti il traffico verso la porta del server e lascia chiuso il resto. Non esporre servizi di laboratorio su Internet senza una ragione forte e senza un controllo di accesso serio.

Per verificare la raggiungibilità da un host client:

curl -I http://IP_DEL_SERVER:3080/

Se ottieni risposta HTTP, il layer rete è corretto. Se il timeout è immediato o la connessione viene rifiutata, il problema è prima dell’applicazione: firewall, bind address o servizio non in ascolto.

Integrazione con il client GNS3

Una volta che il server è su, il passo che spesso viene fatto male è l’associazione dal client. Sul client GNS3 devi aggiungere il server remoto indicando IP o hostname, porta corretta e credenziali se previste dalla tua configurazione. Qui gli errori classici sono banali: IP sbagliato, DNS non risolto, porta diversa da quella del servizio.

Se il client non vede il server, verifica prima dal lato server che il processo sia attivo e che ascolti sulla porta giusta, poi dal lato client fai una prova di connettività con `curl` o `nc`. Questo evita di inseguire problemi del desktop quando il guasto è sul server.

Quando aggiungi il server remoto, controlla anche il percorso delle immagini. Se il server usa directory diverse da quelle del client locale, i template e le appliance potrebbero comparire ma non avviarsi. In quel caso il problema non è la connessione, ma la disponibilità dei file richiesti sul server.

Test pratici dopo l’installazione

Un’installazione valida non si misura solo con “il servizio è up”. Devi provare almeno tre cose: apertura dell’API o della porta, avvio di un progetto semplice e scrittura dei log senza errori.

Comandi utili per il primo check:

curl http://127.0.0.1:3080/
journalctl -u gns3server -n 50 --no-pager
ls -ld /var/lib/gns3 /var/log/gns3

Se il server risponde ma il client non riesce ad avviare nodi, guarda il tipo di backend coinvolto. QEMU, Docker e altri emulatori hanno prerequisiti diversi; il server può essere sano e il nodo comunque fallire per mancanza di permessi o di virtualizzazione hardware.

Per verificare che la virtualizzazione sia disponibile sul nodo Ubuntu:

egrep -c '(vmx|svm)' /proc/cpuinfo

Un risultato pari a zero non blocca sempre GNS3, ma ti dice che alcune immagini o appliance saranno limitate o più lente. Se stai usando una VM, controlla anche che nested virtualization sia abilitata lato hypervisor.

Problemi tipici e come leggerli senza perdere tempo

Il primo errore frequente è il servizio che parte e poi si ferma subito. Quasi sempre trovi un path errato, un permesso negato o una porta occupata. Il secondo è il server raggiungibile in locale ma non da remoto: lì il sospetto cade su bind address e firewall. Il terzo è il nodo che non sale: in quel caso devi scendere di livello e guardare il backend specifico, non GNS3 in astratto.

Per vedere se la porta è occupata da altro:

sudo lsof -iTCP:3080 -sTCP:LISTEN -n -P

Per controllare se il processo è stato ucciso per memoria insufficiente, cerca nel kernel log eventi OOM:

journalctl -k -b | grep -i oom

Se trovi OOM, il fix non è riavviare il servizio e sperare. Devi aumentare RAM, ridurre la topologia o introdurre swap con criterio, sapendo che la swap non sostituisce la memoria per carichi pesanti di emulazione.

Manutenzione minima dopo il go-live

Una volta operativo, il server va tenuto sotto controllo come qualsiasi altro servizio di laboratorio. Monitora spazio disco, uso RAM, stato del servizio e crescita dei log. Se hai più utenti, definisci una convenzione per i progetti e una politica di retention per i file vecchi, altrimenti il filesystem si riempie di materiale abbandonato.

Un controllo periodico essenziale può essere questo:

systemctl is-active gns3server
journalctl -u gns3server --since today --no-pager | tail -n 100
df -h /var/lib/gns3

Se usi backup, includi configurazione, unità systemd personalizzate e directory dei progetti. Non includere segreti in chiaro; se nel tempo hai aggiunto credenziali o token in file di configurazione, vanno redatti o ruotati prima di archiviarli.

Quando conviene fermarsi e cambiare approccio

Se hai bisogno di alta affidabilità, più utenti concorrenti e topologie pesanti, il nodo singolo su Ubuntu 24.04 può diventare presto un collo di bottiglia. In quel caso ha senso separare storage, pianificare backup, mettere monitoraggio serio e valutare se distribuire il carico su più server GNS3 o su host dedicati per team diversi.

La regola pratica è semplice: se il server è usato per studio o test controllati, una singola macchina ben configurata basta; se diventa piattaforma condivisa, la parte importante non è solo installarlo, ma governarlo. E lì entrano in gioco capacity planning, permessi, rete e osservabilità.

Assunzione: i comandi e i percorsi indicati vanno adattati al pacchetto GNS3 effettivamente installato e al metodo di distribuzione scelto sul tuo host Ubuntu 24.04.