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.
Apache è un web server HTTP; i percorsi dipendono dal sistema operativo e dalla distribuzione.
Su Ubuntu/Debian:
/etc/apache2/apache2.conf/etc/apache2/sites-available/ e /etc/apache2/sites-enabled//etc/apache2/mods-available/ e /etc/apache2/mods-enabled//var/log/apache2/access.log e /var/log/apache2/error.logSu RHEL, Rocky Linux e AlmaLinux:
/etc/httpd/conf/httpd.conf/etc/httpd/conf.d//var/log/httpd/access_log e /var/log/httpd/error_logAnalisi 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.
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.
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.
OpenSSL è una libreria e suite di strumenti per operazioni crittografiche e protocolli TLS. Permette di:
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.
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.
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.
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.
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:
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.
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.
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.
| Caratteristica | TCP | UDP |
|---|---|---|
| Connessione | Sì | No |
| Handshake | Sì | No |
| Consegna affidabile | Sì | Non garantita |
| Ordinamento | Sì | Non garantito |
| Overhead | Generalmente maggiore | Generalmente minore |
| Esempi | HTTP/1.1, HTTP/2, SSH, SMTP | DNS 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.
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.
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à.
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.
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.
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.+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.
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.
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:
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.
Per scopo:
Per tecnologia:
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.
Sono strumenti di monitoraggio di infrastrutture e servizi IT. Controllano:
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.
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.
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.
top e vmstat: load average non è solo CPU.lsof +L1 e la differenza tra df e mount.