Amministrazione Linux/Windows, Networking e Troubleshooting — Cheat Sheet

Tag: linux, windows, networking, tcp-udp, monitoring, troubleshooting, apache, openssl, cron, active-directory, vpn, nagios, incident-management

Livello: intermedio | avanzato

TL;DR: 19 domande operative da colloquio (supporto/ops) con risposte pronte in prima persona: percorsi e log di Apache, riavvio servizi Windows/Linux, schedulazione, OpenSSL, monitoraggio, lettura di top/vmstat, metodo di troubleshooting, incident management, TCP/UDP, switch/router, lsof, df/mount, Active Directory, VPN, Nagios/Checkmk, crontab.

1. Dove si trovano i file di configurazione di Apache e i log

Apache è un web server HTTP; i percorsi dipendono dal sistema operativo e dalla distribuzione.

Su Ubuntu/Debian:

  • Configurazione principale: /etc/apache2/apache2.conf
  • Virtual host: /etc/apache2/sites-available/ e /etc/apache2/sites-enabled/
  • Moduli: /etc/apache2/mods-available/ e /etc/apache2/mods-enabled/
  • Log: /var/log/apache2/access.log e /var/log/apache2/error.log

Su RHEL, Rocky Linux e AlmaLinux:

  • Configurazione principale: /etc/httpd/conf/httpd.conf
  • Configurazioni aggiuntive: /etc/httpd/conf.d/
  • Log: /var/log/httpd/access_log e /var/log/httpd/error_log

Analisi dei log:

tail -f /var/log/apache2/error.log
tail -f /var/log/apache2/access.log
grep "500" /var/log/apache2/access.log

Verifica e reload:

sudo apachectl configtest
sudo systemctl reload apache2

Su RHEL il servizio si chiama normalmente httpd. Controllerei anche virtual host, certificati TLS, porte in ascolto ed errori di proxy verso il backend.

2. Come riavviare un servizio su Windows e Linux

Su Windows, con PowerShell:

Get-Service -Name Spooler
Restart-Service -Name Spooler
Get-Service -Name Spooler

Per gli errori consulto il Visualizzatore eventi (registri System e Application).

Su Linux, con systemd:

sudo systemctl status nginx
sudo systemctl restart nginx
sudo systemctl is-active nginx
sudo journalctl -u nginx -n 100 --no-pager

restart arresta e riavvia; reload, se supportato, ricarica la configurazione senza interrompere il servizio. Prima di riavviare in produzione verifico impatto, configurazione e dipendenze; dopo, controllo stato, log e funzionamento reale.

3. Come pianificare uno script su Windows e Linux

Su Windows: Utilità di pianificazione (Task Scheduler).

$action = New-ScheduledTaskAction `
    -Execute "PowerShell.exe" `
    -Argument "-NoProfile -File C:\Scripts\maintenance.ps1"

$trigger = New-ScheduledTaskTrigger -Daily -At "02:00"

Register-ScheduledTask `
    -TaskName "DailyMaintenance" `
    -Action $action `
    -Trigger $trigger

Su Linux: cron oppure un timer systemd.

0 2 * * * /usr/bin/python3 /opt/scripts/maintenance.py >> /var/log/maintenance.log 2>&1

Esegue lo script ogni giorno alle 02:00.

Verifico permessi dell'utente che esegue il job, percorsi assoluti, gestione di stdout/stderr, fuso orario, ambiente di esecuzione, sovrapposizioni tra esecuzioni e gestione delle credenziali.

4. Che cosa permette di fare OpenSSL

OpenSSL è una libreria e suite di strumenti per operazioni crittografiche e protocolli TLS. Permette di:

  • Generare chiavi pubbliche e private.
  • Creare e analizzare CSR.
  • Leggere e verificare certificati X.509.
  • Verificare catene di certificazione.
  • Calcolare hash e generare firme digitali.
  • Cifrare e decifrare dati nei formati supportati.
  • Testare connessioni TLS e diagnosticare problemi di certificati.
  • Analizzare certificati scaduti o non attendibili.
openssl version
openssl x509 -in certificate.pem -noout -text
openssl req -in request.csr -noout -text
openssl verify -CAfile root.pem certificate.pem
openssl s_client -connect example.com:443 -servername example.com

In s_client, -servername invia il nome SNI corretto.

Lo userei per capire perché una connessione HTTPS fallisce, verificare la catena, controllare date e nomi host e identificare incompatibilità TLS. Non disabiliterei la verifica dei certificati: cercherei la causa effettiva.

5. Come monitorare lo stato di una macchina Linux

Parto da CPU, memoria, disco, rete e processi, poi correlazione con i log.

uptime
free -h
df -h
df -i
top
vmstat 1
iostat -xz 1
ip -s link
ss -lntup
systemctl --failed
journalctl -p err -b

Verifico: CPU (utilizzo, load average, processi pesanti); RAM (disponibile, cache, swap); disco (spazio, inode, latenza I/O); rete (errori interfacce, connessioni, porte in ascolto); servizi (processi terminati o in errore); log (kernel, applicativi, sistema).

Con Nagios o Checkmk configuro controlli e soglie per rilevare anomalie e ricevere alert. Non mi baso su una sola metrica: correlazione tra orario del problema, risorse, log e modifiche recenti.

6. Come leggere top e vmstat

top mostra processi attivi e uso risorse in tempo reale. Osservo:

  • %us: CPU in user space; %sy: kernel; %id: inattiva; %wa: attesa I/O.
  • load average: carico medio su 1, 5 e 15 minuti.
  • RES: memoria fisica residente; %MEM: percentuale di RAM del processo.

Un load average elevato non significa automaticamente CPU satura: può indicare attesa I/O.

Con vmstat 1 osservo: r (pronti), b (bloccati, spesso su I/O), si/so (swap-in/out), bi/bo (blocchi letti/scritti), wa (attesa I/O), us/sy/id (tempo CPU). La prima riga rappresenta medie dall'avvio: analizzo le righe successive.

Swap continuo, processi bloccati o attese I/O elevate → approfondisco memoria, disco e processi coinvolti.

7. Come affrontare un problema applicativo

  1. Raccolgo sintomi, utente, operazione, timestamp e messaggio d'errore.
  2. Verifico se riesco a riprodurre il problema, in ambiente controllato.
  3. Controllo stato del servizio e raggiungibilità dell'applicazione.
  4. Correlo i log applicativi, middleware, web server e sistema nello stesso intervallo.
  5. Verifico CPU, RAM, disco, rete, database e dipendenze esterne.
  6. Controllo modifiche recenti, deploy, configurazioni e certificati.
  7. Formulo un'ipotesi, la verifico e restringo il campo.
  8. Applico una correzione controllata e verifico la risoluzione.
  9. Documento causa, impatto, soluzione e prevenzione.

Esempio: su un HTTP 500 parto da timestamp e correlation ID, seguendo la richiesta da web server a backend e database. Evito riavvii casuali o modifiche non documentate.

8. Due utenti con problemi di accesso per motivi differenti

Non assumo che due errori simili abbiano la stessa causa. Raccolgo identificativi, orari, messaggi e passaggi; riproduco con account di test autorizzati (mai credenziali reali degli utenti).

Verifico separatamente:

  • Profilatura e autorizzazioni: ruolo, gruppi, permessi, regole applicative.
  • Autenticazione: credenziali, stato account, scadenza password, MFA, token.
  • Integrazione con Active Directory o Identity Provider: sincronizzazione, gruppi, raggiungibilità.
  • Applicazione e middleware: errori, sessioni, configurazione, dipendenze.
  • Infrastruttura: CPU, RAM, disco, rete, disponibilità servizi.

Se uno ha un ruolo errato e l'altro un problema di autenticazione, documento due cause distinte. Correggo la configurazione o il difetto, poi eseguo test di regressione sui due casi e su profili diversi.

9. Un fornitore rilascia un nuovo pacchetto: cosa fare prima della produzione

  1. Verifico versione, note di rilascio, requisiti, dipendenze, compatibilità.
  2. Controllo provenienza, integrità e firma digitale del pacchetto.
  3. Verifico ambienti supportati e procedure di installazione e rollback.
  4. Installo in ambiente di test/collaudo rappresentativo.
  5. Eseguo autotest, test funzionali, d'integrazione e regressione.
  6. Verifico log, prestazioni, sicurezza e compatibilità con gli altri sistemi.
  7. Documento gli esiti e ottengo le approvazioni.
  8. Pianifico il rilascio con backup e procedura di ripristino.
  9. Distribuisco nella finestra concordata.
  10. Eseguo smoke test e monitoraggio post-rilascio.

Se i test falliscono, blocco il rilascio e apro una segnalazione al fornitore con log e passi di riproduzione. Verifico sempre la reversibilità: come ripristinare la versione precedente e se la compatibilità dei dati lo consente.

10. Differenza tra TCP e UDP

TCP è orientato alla connessione: three-way handshake (SYN, SYN-ACK, ACK). Garantisce flusso ordinato e affidabile con conferme, ritrasmissioni e controllo della congestione.

UDP è senza connessione: nessun handshake, datagrammi senza garanzia di consegna, ordine o assenza di duplicati.

CaratteristicaTCPUDP
ConnessioneSìNo
HandshakeSìNo
Consegna affidabileSìNon garantita
OrdinamentoSìNon garantito
OverheadGeneralmente maggioreGeneralmente minore
EsempiHTTP/1.1, HTTP/2, SSH, SMTPDNS tradizionale, VoIP, streaming, QUIC

QUIC usa UDP come trasporto ma implementa affidabilità e sicurezza a un livello superiore. Scelgo TCP quando servono affidabilità e ordine; UDP quando conta la tempestività, gestendo esplicitamente le perdite.

11. Differenza tra switch e router

Uno switch collega dispositivi nella stessa rete locale e inoltra frame Ethernet tramite indirizzi MAC. Un router collega reti IP differenti e inoltra pacchetti in base agli indirizzi IP e alla tabella di routing.

  • PC, stampanti e server della stessa LAN comunicano tramite switch.
  • Per raggiungere Internet i pacchetti vanno al router/gateway predefinito.

Lo switch di livello 2 opera sul Data Link; il router sul Network. Esistono anche switch Layer 3 con routing IP.

ip addr
ip route
ping 192.168.1.1
traceroute example.com

Su Windows:

ipconfig /all
route print
tracert example.com

Verifico IP, subnet mask, gateway, VLAN, routing e raggiungibilità.

12. Un cliente segnala che il servizio non funziona

Prima chiarisco l'impatto: un utente, un gruppo o tutti? Servizio indisponibile o malfunzionante? Raccolgo timestamp, messaggio d'errore, operazione e identificativo della richiesta; se possibile riproduco con account autorizzato.

Poi verifico: disponibilità del servizio e processi; connettività e DNS; porte, certificati TLS e reverse proxy; log di web server, middleware, applicazione e sistema; database e dipendenze esterne; CPU, RAM, disco e rete; deploy o modifiche recenti.

Cerco gli eventi nel periodo esatto della segnalazione e, se disponibile, seguo la richiesta col correlation ID. Se il servizio è critico attivo subito l'escalation, senza attendere la causa definitiva. Dopo il ripristino verifico col cliente, documento la causa e propongo azioni preventive.

13. Primi 15 minuti di una segnalazione grave

Obiettivo: capire l'impatto, coordinare le persone, raccogliere evidenze senza aggravare l'incidente.

Primi 5 minuti: valuto gravità, utenti e servizi coinvolti; confermo la segnalazione e raccolgo timestamp ed errori; verifico incidenti analoghi.

Dal minuto 5 al 10: controllo monitoraggio, disponibilità, log e metriche; verifico deploy e modifiche recenti; attivo service manager/reperibile secondo procedura.

Dal minuto 10 al 15: condivido evidenze e ipotesi; concordo contenimento e ripristino; definisco un responsabile operativo e il prossimo aggiornamento; mantengo la cronologia delle decisioni.

Seguo la procedura di incident management. Non aspetto il quindicesimo minuto per avvisare il service manager se la gravità richiede escalation immediata. La comunicazione deve distinguere fatti e ipotesi e aggiornare gli stakeholder a intervalli concordati.

14. Che cosa fa lsof

lsof significa List Open Files: mostra i file aperti dai processi Unix/Linux (anche socket e pipe sono file descriptor).

lsof -i
lsof -i :8080
lsof -iTCP:443 -sTCP:LISTEN
lsof -p 1234
lsof /var/log/application.log
lsof +L1
  • -i: connessioni e socket di rete.
  • -i :8080: processi che usano la porta.
  • -iTCP:443 -sTCP:LISTEN: socket TCP in ascolto sulla 443.
  • -p 1234: file aperti dal processo.
  • Percorso file: processi che lo usano.
  • +L1: file aperti non più collegati al filesystem (link count < 1).

Lo userei se un servizio non riesce a usare una porta, se un log cancellato continua a occupare spazio, o per capire quali processi tengono aperte le risorse. In alternativa: sudo ss -lntup.

15. Differenza tra df e mount

df mostra spazio utilizzato e disponibile sui filesystem montati:

df -h
df -i
  • df -h: dimensioni leggibili.
  • df -i: utilizzo degli inode.

mount mostra i filesystem montati e le opzioni, e permette di montarne:

mount
findmnt
findmnt /var
sudo mount /dev/sdb1 /mnt/data

Il punto di mount deve esistere e il dispositivo deve contenere un filesystem appropriato.

df serve a verificare occupazione e capacità; mount/findmnt a capire quali filesystem sono collegati e dove. Se un'applicazione non scrive file, controllo spazio, inode, permessi, filesystem montato e opzioni di sola lettura.

16. Che cos'è Active Directory

Active Directory Domain Services (AD DS) è il servizio Microsoft per la gestione centralizzata di identità, computer, gruppi e policy in un dominio Windows.

Componenti principali:

  • Domain Controller: server che ospita AD DS e gestisce autenticazione e directory.
  • Domain: insieme logico di oggetti e policy.
  • Forest: struttura che può contenere più domini.
  • OU: unità organizzativa per organizzare gli oggetti.
  • Group Policy (GPO): regole applicate a utenti e computer.
  • DNS: fondamentale per l'individuazione dei servizi del dominio.
  • Kerberos: protocollo di autenticazione comunemente usato nel dominio.
  • LDAP: protocollo per interrogare e gestire la directory.

Consente di centralizzare account, gruppi, autorizzazioni e configurazioni. Per problemi di accesso verificherei stato account, gruppi, DNS, connettività col domain controller, sincronizzazione temporale e log di autenticazione. Distinguo AD DS da Microsoft Entra ID (identità cloud), che non è lo stesso prodotto rinominato.

17. Quanti tipi di VPN conosci

Per scopo:

  • Remote-access VPN: collega un singolo utente alla rete aziendale.
  • Site-to-site VPN: collega reti o sedi differenti.
  • Host-to-host VPN: collega direttamente due sistemi.

Per tecnologia:

  • IPsec/IKEv2: comune per VPN aziendali e site-to-site.
  • SSL/TLS VPN: usa TLS per l'accesso remoto (implementazione dipendente dal prodotto).
  • OpenVPN: soluzione VPN basata su TLS.
  • WireGuard: VPN moderna basata su un insieme definito di primitive crittografiche.
  • L2TP/IPsec: combinazione storicamente diffusa.
  • PPTP: obsoleto e insicuro, da evitare.

Per diagnosticare verifico autenticazione, configurazione del tunnel, indirizzi assegnati, rotte, DNS, firewall, MTU e raggiungibilità. La connessione al tunnel non garantisce l'accesso a tutte le risorse: possono esserci problemi di routing, autorizzazioni o DNS.

18. Che cosa puoi fare con Nagios e Checkmk

Sono strumenti di monitoraggio di infrastrutture e servizi IT. Controllano:

  • Disponibilità di server e servizi.
  • CPU, memoria e spazio disco.
  • Porte e connessioni di rete.
  • Processi e servizi Windows/Linux.
  • Certificati TLS e relativa scadenza.
  • Servizi applicativi e dipendenze.
  • Soglie, alert e notifiche.
  • Storico dei problemi e report operativi.

Nagios usa plugin e controlli configurati; Checkmk offre discovery, raccolta metriche, dashboard e agent/controlli specializzati.

Stati tipici Nagios: OK, WARNING, CRITICAL, UNKNOWN.

Configurerei soglie appropriate, notifiche ai gruppi responsabili e controlli che riflettano il servizio realmente usato. Esempio: verificare non solo che il server risponda, ma che l'API funzioni e che il certificato HTTPS non stia per scadere. Obiettivo: individuare le anomalie prima che diventino incidenti.

19. Che cos'è crontab e come si interpreta

crontab pianifica comandi e script su Unix/Linux tramite cron.

crontab -l
crontab -e
crontab -r
  • -l: mostra le pianificazioni dell'utente.
  • -e: modifica il crontab.
  • -r: elimina il crontab (usare con cautela).

Riga cron standard: cinque campi temporali + comando.

MINUTO ORA GIORNO_MESE MESE GIORNO_SETTIMANA COMANDO

Esempio:

30 8 * * 1-5 /opt/scripts/report.sh >> /var/log/report.log 2>&1

Esegue alle 08:30 dal lunedì al venerdì. Altri esempi:

*/5 * * * * /opt/scripts/check.sh
0 2 * * * /opt/scripts/backup.sh
0 0 1 * * /opt/scripts/monthly-report.sh

Ogni 5 minuti; ogni giorno alle 02:00; il primo del mese a mezzanotte.

Verifico che cron sia attivo, i permessi dell'utente, percorsi assoluti e gestione di stdout/stderr:

systemctl status cron
journalctl -u cron

Su RHEL il servizio è crond. L'ambiente di cron è più limitato di una shell interattiva: non farei affidamento su variabili non definite esplicitamente.

Ripasso finale: come rispondere bene al colloquio

  1. Verifico il sintomo: errore, timestamp, utenti coinvolti, impatto.
  2. Riproduco il problema, se possibile in ambiente controllato.
  3. Raccolgo evidenze: log applicativi e di sistema, metriche, rete.
  4. Isolo la causa: verifico un'ipotesi alla volta.
  5. Ripristino il servizio con una modifica controllata e reversibile.
  6. Verifico e documento: confermo la soluzione e prevengo le ricorrenze.

Questa impostazione conta soprattutto nelle domande 7, 8, 9, 12 e 13: al colloquio pesa più dimostrare un metodo di troubleshooting ordinato che ricordare tutti i comandi a memoria.

Da ripassare

  • [ ] Percorsi di configurazione e log di Apache (Debian vs RHEL).
  • [ ] Lettura di top e vmstat: load average non è solo CPU.
  • [ ] Metodo in 6 passi per il troubleshooting operativo.
  • [ ] Primi 15 minuti di una segnalazione grave (escalation e comunicazione).
  • [ ] lsof +L1 e la differenza tra df e mount.
Jarvis Interviews
Jarvis