In questo brevissimo articolo andiamo a coprire quelle che sono le operazioni più comuni durante l’amministrazione di un sistema Linux, parleremo quindi di una serie di comandi da dover utilizzare in disparate situazioni per analizzare e risolvere meglio eventuali problematiche o richieste.

Attenzione: Questa non sarà una guida “all’amministrazione di un sistema”, ma una raccorda di comandi utili da utilizzare.

Partiamo dalla rete

E’ fondamentale sapere come siamo connessi, su quali e quante interfacce e sopratutto qual’è il nostro indirizzo fisico. Per chi usa linux da molto sarà da sempre stato abituato al comando ifconfig, ebbene, questo comando è ormai desueto, ma dato che ancora funzionante su sistemi datati lo tratteremo lo stesso. ifconfig ci permette di ottenere tutte le informazioni del caso sulle nostre schede direte, semplicemente lanciandolo otterremo informazioni che riguardano: ipv4, ipv6, gateway e maschere di rete per ogni scheda di rete collegata alla nostra macchina (comprese quelle virtuali). Se siamo invece su in sistema recente conviene utilizzare il più comodo comando ip. Ad esempio:

ip address show 

per ottenere le stesse informazioni che ottenevamo con ifconfig

ip add show eth0

per ottenere le informazioni su un singolo device di rete (in questo caso eth0)

Le porte utilizzate e i socket occupati

Altra fondamentale operazione d’esser capaci di compiere è quella di conoscere quali porte/socket sono attualmente utilizzate dal sistema e sopratutto quali processi sono utilizzatori e quali ipotetici client nella nostra LAN o WAN possono connettervi. Per fare ciò dobbiamo utilizzare netstat. Utilizzare da solo netstat però ci fornisce una serie molto vasta di informazioni che vanno organizzate secondo criterio ed utilità, ad esempio possiamo passare argomenti a netstat per ottenere risultati utili alla nostra analisi nel seguente modo

netsat -tulpn

così facendo andiamo a filtrare tutte le connessioni udp e tcp (v4 e v6), lo stato di connessione (in ascolto o disconnesso), l’indirizzo di ascolto e il PID/processo che sta occupando quel socket. (Attenzione, per ottenere informazioni sul PID/processo bisogna eseguire netstat come root a meno che non vi siano processi che occupano socket e che sono lanciati dall’utente che esegue il comando).

Così come vale per ifconfig, anche netstat è ormai “obsoleto”, all’interno delle nuove distro troviamo infatti ss che può essere utilizzato come netstat e quindi chiamando ss con i seguenti parametri otteniamo lo stesso risultato

ss -tulpn

E’ interessante poi andare ad analizzare il risultato, che sarà una cosa del genere:

Netid  State   Recv-Q  Send-Q   Local Address:Port    Peer Address:Port                                             
udp    UNCONN  0       0              0.0.0.0:60389        0.0.0.0:*      users:(("avahi-daemon",pid=460,fd=14))    
udp    UNCONN  0       0          224.0.0.251:5353         0.0.0.0:*      users:(("chrome",pid=15588,fd=95))        
udp    UNCONN  0       0          224.0.0.251:5353         0.0.0.0:*      users:(("chrome",pid=15588,fd=44))        
udp    UNCONN  0       0          224.0.0.251:5353         0.0.0.0:*      users:(("chrome",pid=15525,fd=144))       
udp    UNCONN  0       0          224.0.0.251:5353         0.0.0.0:*      users:(("chrome",pid=15525,fd=81))        
udp    UNCONN  0       0              0.0.0.0:5353         0.0.0.0:*      users:(("avahi-daemon",pid=460,fd=12))    
udp    UNCONN  0       0        192.168.0.100:68           0.0.0.0:*      users:(("NetworkManager",pid=465,fd=19))  
udp    UNCONN  0       0                    *:1716               *:*      users:(("kdeconnectd",pid=1395,fd=12))    
udp    UNCONN  0       0                    *:54234              *:*      users:(("avahi-daemon",pid=460,fd=15))    
udp    UNCONN  0       0                    *:5353               *:*      users:(("avahi-daemon",pid=460,fd=13))    
tcp    LISTEN  0       0            127.0.0.1:631          0.0.0.0:*      users:(("cupsd",pid=2219,fd=8))           
tcp    LISTEN  0       0                    *:3306               *:*      users:(("docker-proxy",pid=817,fd=4))     
tcp    LISTEN  0       0                    *:6379               *:*      users:(("docker-proxy",pid=21854,fd=4))   
tcp    LISTEN  0       0                    *:8080               *:*      users:(("docker-proxy",pid=21840,fd=4))   
tcp    LISTEN  0       0                    *:80                 *:*      users:(("docker-proxy",pid=845,fd=4))     
tcp    LISTEN  0       0                    *:1716               *:*      users:(("kdeconnectd",pid=1395,fd=13))    
tcp    LISTEN  0       0                [::1]:631                *:*      users:(("cupsd",pid=2219,fd=7))           
tcp    LISTEN  0       0                    *:443                *:*      users:(("docker-proxy",pid=831,fd=4))     

ciò ci aiuta a capire quale servizio è possibile che sia raggiunto internamento dalla macchina che lo esegue e quale anche dalle macchine della rete a cui la macchina è connessa. Osservando i campi di indirizzo infatti possiamo subito distinguere i servizi locali (127.0.0.1) e quelli “pubblici” (0.0.0.0)

La gestione di base del filesystem

Altra operazione di sistema pressoché basilare consiste nel montare semplici partizioni e constatare quanto spazio è occupato da una particolare cartella. Tutte le distribuzioni linux hanno una cartella /mnt solitamente dedicata come “punto di mount” canonico, bisogna ricordare però che è possibile montare una qualsiasi partizione/unità locale o remota in qualsiasi cartella ovunque vi siano i permessi per farlo. Il comando mount se lanciato senza argomenti mostra un listato di tutto ciò che è montato sul sistema, se invece vogliamo montare un’unità ci basterà lanciare

mount *cosa voglio montare* *dove voglio montare*

Che nella realtà dei fatti, immaginando di voler montare la partizione /dev/sda2 sarà

mount /dev/sda2 /mnt

Nel caso in cui volessimo montare automaticamente una o più partizioni/volumi remoti automaticamente al boot dovremo modificare il file fstab con un qualsiasi editor di testo. Tale file si trova in /etc

E se volessimo controllare lo stato di utilizzo di uno o più dischi in un formato “umanamente leggibile?” Per fare ciò possiamo utilizzare df nel seguente modo:

df -h

per visualizzare le partizioni fisiche o remote

df -ah

per visualizzare tutte le partizioni (anche ad esempio i punti di mount virtuali di un’ipotetica applicazione o servizio dockerizzato sulla nostra macchina)

Se invece vogliamo sapere quanto occupi una particolare cartella possiamo utilizzare il comando ls in funzione estesa con il paramertro -l o più professionalmente il comando du

du -sh miacartella/

che restituirà la dimensione della cartella denominata miacartella

La gestione dei processi e dei servizi

Altra cosa fondamentale da saper fare è quella di saper gestire i processi e i servizi/demoni. In primo luogo ci interessa sapere quante risorse un determinato processo sta utilizzando, e in questo caso possiamo utilizzare le utility top o htop (il primo solitamente sempre installato in qualsiasi versione). Se vogliamo però essere più diretti ed individuare un singolo processo e tutti i thread in esso coinvolti possiamo utilizzare ps e grep in pipe e nel seguente modo:

ps aux | grep *nomeprocesso* 

Che restituirà l’utilizzo delle risorse (CPU) occupate da un processo e dai suoi figli.

Se invece parliamo di servizi, oltre a poter usare una pipe come quella sopra descritta per valutare lo stato d’esecuzione, è fondamentale poter operare su questi ed in particolar modo conoscerne lo stato (running, not running, error) e operare su quest’ultimo. Può essere utilizzato il comando service, anch’esso però deprecato nelle distribuzioni più recenti che sono passate alla gestione dei servizi utilizzando systemd. Prima di vedere la differenza d’approccio è però importante sapere cosa possiamo chiedere al gestore dei servizi/demoni:

  • status
  • start
  • stop
  • reload

Utilizzando il comando service la sintassi si presenta in questo modo:

service *nomeservizio* *operazione*

dove nomeservizio è il servizio su cui investigare e operazioni è invece una tra quelle descritte in precedenza. Se ad esempio volessimo conoscere lo stato del servizio nginx utilizzando questo comando dovremo digitare:

service nginx status

Tenendo invece in considerazione il nuovo approccio della maggior parte delle distribuzioni di nuova release che utilizzando systemd come gestore dovremo digitare:

systemctl status nginx

L’unica differenza tra i due comandi è quindi relativa al posizionamento dei loro argomenti, che risultano invertiti.

E se c’è qualcosa che non sappiamo?

In tutte le distro è presente l’utililty man che non è altro che un manuale per ogni comando, se quindi vogliamo sapere come funziona un programma o comando e come utilizzarlo ci basterò fare

man *comando*

che restituirà tutte le informazioni necessarie ad un utilizzo anche molto approfondito del *comando* passato come argomento.

Una cosa fondamentale che manca in questo breve articolo è la trattazione delle operazioni schedulate, il cron, che verrà trattato in un articolo interamente dedicato ad esso.