1 21/05/2026 10 min

Rimuovere Webmin da un server Linux non significa solo disinstallare un pacchetto. Se il pannello è stato installato anni fa, spesso lascia dietro di sé un servizio systemd, una porta ascoltata, repository aggiuntivi, regole firewall e, in certi casi, file di configurazione che possono riattivare il demone al prossimo aggiornamento o reboot. La sequenza corretta è semplice: verificare come è stato installato, fermare il servizio, rimuovere il pacchetto, ripulire ciò che è rimasto e controllare che la superficie esposta sia davvero sparita.

La differenza tra una rimozione pulita e una disinstallazione approssimativa è tutta qui: nel primo caso il sistema torna allo stato atteso, nel secondo ti ritrovi una porta 10000 ancora in ascolto o una web UI richiamabile da browser mesi dopo. In ambienti di produzione, questo è un problema di sicurezza prima ancora che di ordine amministrativo.

Capire come Webmin è stato installato

Prima di toccare il sistema, identifica il metodo di installazione. Webmin può arrivare da un pacchetto nativo, da un repository esterno, oppure da installazioni manuali con script o archivi estratti in percorsi non standard. Questa distinzione cambia il metodo di rimozione e i file da cercare.

Il controllo più rapido è questo:

rpm -qa | grep -i webmin dpkg -l | grep -i webmin systemctl status webmin --no-pager

Su sistemi RPM-based, il nome del pacchetto è spesso webmin. Su Debian e derivate, compare come pacchetto installato via APT. Se systemctl status webmin restituisce un servizio attivo o fallito con unit file presente, hai almeno un demone da fermare. Se non trovi nulla nei package manager ma il pannello risponde ancora su :10000, probabilmente non stai guardando il metodo di installazione giusto o il binario è stato piazzato manualmente.

Se il server è in produzione, considera il blast radius: la rimozione di Webmin non dovrebbe toccare applicazioni, ma può impattare eventuali automazioni, account amministrativi creati nel pannello, task schedulati o moduli usati come scorciatoia operativa. Prima di procedere, annota chi usa il pannello e per cosa. Se mancano dati, chiudi il gap verificando i log di accesso del servizio e la cronologia dei task gestiti da Webmin.

Fermare Webmin senza lasciare processi vivi

La prima azione reversibile è fermare il servizio. Questo riduce subito l’esposizione e ti dice se il sistema è davvero gestito da systemd.

sudo systemctl stop webmin
sudo systemctl disable webmin
sudo systemctl is-enabled webmin
sudo systemctl is-active webmin

Il risultato atteso è disabled per il primo comando di controllo e inactive per il secondo. Se il servizio resta attivo, osserva il motivo con:

sudo journalctl -u webmin -n 50 --no-pager

Se il demone non è gestito da systemd, cerca il processo direttamente:

ps -ef | grep -i [w]ebmin
ss -lntp | grep 10000

Se trovi un listener su 10000/tcp, la rimozione non è ancora completa. In quel caso, identifica il binario che lo mantiene vivo e fermalo con il metodo più coerente con l’installazione. Non uccidere processi a caso se non hai confermato il parent service o lo script di avvio; il rollback più pulito è sempre un systemctl start webmin o il riavvio del processo gestito, non un kill -9 usato come martello.

Rimozione del pacchetto su Debian e derivate

Se il sistema usa APT, la rimozione standard è questa. Prima disinstalla, poi valuta se eliminare anche i file di configurazione residui. La scelta dipende da quanto vuoi essere netto.

sudo apt remove webmin
sudo apt purge webmin

remove elimina i binari installati; purge aggiunge la rimozione dei file di configurazione del pacchetto. Se vuoi conservare una traccia per audit o rollback, fermati a remove e conserva il backup dei file prima di purgare. Se invece l’obiettivo è chiudere definitivamente il pannello, purge è la scelta più pulita.

Dopo la rimozione, controlla se esistono ancora directory tipiche:

ls -ld /etc/webmin /var/webmin /usr/share/webmin 2>/dev/null

Se restano directory, non assumere che siano innocue. Verifica il contenuto prima di cancellarle, soprattutto se il server ospita moduli o personalizzazioni installate a mano. Un controllo rapido è:

sudo find /etc/webmin -maxdepth 2 -type f 2>/dev/null | head
sudo find /var/webmin -maxdepth 2 -type f 2>/dev/null | head

Se i percorsi sono solo residui vuoti, puoi rimuoverli con cautela. Se contengono file di configurazione o backup del pannello, valuta prima se servono per migrazione o audit.

Rimozione del pacchetto su RHEL, AlmaLinux, Rocky e affini

Su sistemi RPM-based la logica è la stessa, ma i dettagli cambiano. Il pacchetto spesso arriva da un repository esterno o da un RPM installato manualmente. Verifica il nome esatto prima di rimuoverlo.

rpm -qa | grep -i webmin
sudo dnf remove webmin

Se il pacchetto non compare con dnf ma è presente nel database RPM, la rimozione via rpm -e può essere necessaria, ma va usata solo se sai cosa stai facendo e dopo aver verificato dipendenze e script di post-uninstall. In pratica, dnf remove è preferibile perché gestisce meglio il grafo dei pacchetti e dei repository.

Controlla poi se il repository Webmin è ancora presente. Spesso il file è in uno di questi percorsi:

ls -1 /etc/yum.repos.d/ | grep -i webmin
ls -1 /etc/zypp/repos.d/ | grep -i webmin

Se trovi un repo dedicato, rimuovilo solo dopo aver disinstallato il pacchetto, altrimenti rischi di perdere la sorgente utile al rollback. Una buona pratica è prima disabilitarlo rinominando il file o impostando enabled=0, poi cancellarlo in un secondo passaggio se non serve più.

Repository esterni e chiavi: pulizia senza lasciare aggiornamenti involontari

Webmin spesso viene installato tramite repository dedicato. Anche se il pacchetto è stato rimosso, lasciare il repository attivo significa che il sistema continuerà a fidarsi di una sorgente che non usi più. Non è sempre un problema immediato, ma è rumore inutile e, in ambienti curati, una superficie d’attacco evitabile.

Su Debian e derivate, cerca in /etc/apt/sources.list e in /etc/apt/sources.list.d/. Su RPM-based, controlla /etc/yum.repos.d/ o /etc/zypp/repos.d/. Se è presente una chiave GPG associata, verifica come è stata installata prima di rimuoverla. Non cancellare chiavi a caso se altri repository le condividono.

grep -Rni webmin /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null
rpm -qi gpg-pubkey 2>/dev/null | grep -i webmin

Se hai aggiunto il repository con un file dedicato, il rollback è banale: ripristini il file e fai apt update o dnf makecache. Per questo, prima di cancellarlo, conviene conservarne una copia in una directory di change management o nel sistema di versioning interno.

Pulizia della porta 10000 e verifica della superficie esposta

Webmin usa tipicamente la porta 10000 in HTTPS. Dopo la rimozione, questa porta non dovrebbe più risultare in ascolto. La verifica deve essere fatta sia localmente sia, se il server è esposto, da un host esterno controllato.

sudo ss -lntp | grep 10000
curl -kI https://127.0.0.1:10000/

Il risultato atteso è assenza di listener e fallimento della connessione o rifiuto. Se la porta risponde ancora, il problema non è il pacchetto ma un processo residuo, un container, un service wrapper o una regola di port forwarding. In quel caso, isola il layer: controlla systemctl, poi ss, poi eventuali container con docker ps o podman ps se il server usa questi runtime.

Se il server è dietro firewall host-based, verifica anche che eventuali regole specifiche non continuino a esporre la porta. Esempi comuni:

sudo nft list ruleset | grep -n 10000
sudo iptables -S | grep 10000

Non serve sempre rimuovere una regola dedicata se il servizio è già sparito, ma in una pulizia seria è corretto verificare che non rimanga nessuna eccezione firewall pensata per Webmin.

Rimozione manuale quando Webmin non è gestito dal package manager

Se non trovi il pacchetto nei gestori standard, probabilmente Webmin è stato installato manualmente. In questo scenario, il percorso di installazione può variare, ma i punti da cercare sono quasi sempre gli stessi: binari in /usr/libexec/webmin, /usr/share/webmin, /etc/webmin, script in /etc/init.d/ o unit file in /etc/systemd/system/.

Per individuare i file, usa una ricerca mirata senza partire subito con cancellazioni massive:

sudo find / -xdev \( -iname '*webmin*' -o -path '/etc/systemd/system/*webmin*' -o -path '/etc/init.d/*webmin*' \) 2>/dev/null

Una volta identificati i percorsi, il flusso corretto è: fermare il servizio, salvare una copia dei file di configurazione se servono, rimuovere il servizio e poi i directory tree associati. Il backup minimo è sempre preferibile a una rimozione cieca:

sudo mkdir -p /root/backup-webmin-$(date +%F)
sudo cp -a /etc/webmin /root/backup-webmin-$(date +%F)/ 2>/dev/null

Solo dopo aver creato un backup sensato, puoi eliminare i file. Il blast radius resta limitato, ma il rollback è disponibile se scopri che qualche automazione dipende ancora dal pannello.

Verifiche post-rimozione: non fidarti solo del pacchetto sparito

Una disinstallazione corretta si considera chiusa solo quando tre controlli tornano coerenti: nessun servizio attivo, nessuna porta in ascolto, nessun riferimento residuo nei repository o nei task di avvio. Il pacchetto rimosso da solo non basta.

systemctl status webmin --no-pager
ss -lntp | grep 10000
grep -Rni webmin /etc/systemd/system /etc/init.d /etc/cron* /etc/apt/sources.list* /etc/yum.repos.d /etc/zypp/repos.d 2>/dev/null

Il primo comando deve mostrare un servizio inesistente o inattivo. Il secondo non deve restituire righe. Il terzo serve a scovare riferimenti indiretti: startup script, cron, file repo, unit file rimasti per errore. Se compare un file di avvio, rimuovilo solo dopo aver confermato che non è usato da altri servizi.

Controlla anche il browser o i proxy interni: se il pannello era dietro reverse proxy, una route dedicata potrebbe continuare a puntare a un backend morto. In quel caso il sintomo lato utente può essere un 502, ma la causa reale è una configurazione ancora presente nel front-end.

Se Webmin gestiva anche servizi critici

Questo è il punto che molti saltano. Webmin spesso viene usato per amministrare utenti, cron, DNS locali, Samba, firewall o virtual host. Rimuovere il pannello non rimuove quei servizi, ma può interrompere la modalità con cui venivano gestiti. Se l’operatività quotidiana dipendeva da Webmin, prima di disinstallare devi sapere qual è il canale alternativo.

Verifica almeno questi aspetti:

  • utenti creati o amministrati solo dal pannello;
  • task schedulati modificati da Webmin e non documentati altrove;
  • file di configurazione toccati tramite editor web e non versionati;
  • moduli aggiuntivi installati per servizi specifici.

    • Se trovi dipendenze operative, il cambio va trattato come change controllato, non come semplice uninstall. Il rollback, in quel caso, è il ripristino del pacchetto e dei file salvati dal backup, non un tentativo improvvisato di ricostruire la configurazione a memoria.

    Rimozione sicura: sequenza consigliata

    Se vuoi una sequenza pratica e prudente, questa è quella che userei su un server reale:

  • Conferma installazione e metodo con dpkg -l, rpm -qa e systemctl status webmin.
  • Ferma e disabilita il servizio con systemctl stop webmin e systemctl disable webmin.
  • Verifica che non ascolti più su 10000/tcp con ss -lntp.
  • Rimuovi il pacchetto con apt remove/apt purge oppure dnf remove.
  • Elimina il repository dedicato solo dopo averne salvato una copia se serve al rollback.
  • Controlla residui in /etc/webmin, unit file, cron e firewall.

    • Questa sequenza minimizza il rischio di lasciare un servizio vivo o di cancellare file utili prima del tempo. È anche il modo più rapido per capire, in caso di problema, dove si è rotto il flusso: servizio, pacchetto, repository o residui di configurazione.

    Rollback ragionato se qualcosa dipende ancora da Webmin

    Se dopo la rimozione scopri che un processo operativo dipendeva dal pannello, il rollback più pulito è reinstallare il pacchetto dalla stessa fonte e ripristinare i file salvati. Su Debian e derivate:

    sudo apt install webmin

    Su RPM-based:

    sudo dnf install webmin

    Se il repository è stato rimosso, ripristina prima il file repo o usa il pacchetto locale già archiviato. Dopo la reinstallazione, riavvia il servizio solo se necessario e verifica che la porta torni in ascolto. In seguito puoi correggere con calma le dipendenze operative e ripetere la rimozione con più contesto.

    Assunzione: il server è Linux recente con systemd, Webmin usa la porta predefinita 10000 e la rimozione avviene in ambiente amministrato, con accesso root o sudo e possibilità di verificare repository, firewall e unit file.