Sysadmin panics: stranezze

chmod? chown!

Piu' volte ho visto l'uso di chmod al posto di chown.
Situazione: si vuole dare accesso ad un file o una directory ad un utente che non e' proprietario o non risulta
nel gruppo proprietario.
Cosa si fa quindi?
Un bel chmod 777 e si risolve il problema.
O se ne creano altri (di problemi)?

Eh si, perche' un chmod 777 implica dare anche il permesso di esecuzione a tutto il mondo. E' veramente questo che si vuole? Si vuole poter eseguire un file di testo (che magari viene inavvertitamente infettato e si  tramuta in uno script malevolo)? 

No, quello che si vuole e' zittire rapidamente l'utente dandogli l'accesso. 

La soluzione corretta e' quella di inserire l'utente nel gruppo giusto, facendo nel caso un chown del 

file/directory in modo da consentire la corretta profilazione. 

Se poi si e' dei virtuosi, le ACL possono aiutare!

crontab & chmod = chmod on steroids!

Si e' mai visto una linea in crontab del tipo:

* * * * * * chmod 777 /path/to/some/public/share/*

Io l'ho vista!
Cosa fa?
Modifica ogni minuto i permessi di ogni file in una cartella pubblica dando ogni permesso ad ogni possibile
utente del mondo. Si valuti se la configurazione della share e' quella desiderata e se veramente lo spool del
server debba essere usato come un keyboard-monkey!




Pippo, Pluto e Paperino

Come non sopporto la gente che continua a nominare i file come "pippo", oppure "pluto" oppure "paperino".

Alcuni studenti lasciano la loro home directory piena anche di file dai nomi ben piu' volgari, ma che un  sysadmin debba usare ancora nomi cosi' ridicoli per i propri file di configurazione e' una vergogna.  

Ma ancora peggio e' chi inserisce tali file in un sistema di controllo delle versioni: che senso ha memorizzare la storia di un file di nome pippo127.sh che, evidentemente, o non cambiera' mai (sara' sostituito da pippo128.sh) oppure cambiera' totalmente!

Cavi, label, diagrammi e mount point

Ovvero: siate ordinati, siate coerenti. Se un server dispone di piu' schede di rete, le si rinomini opportunamente e si etichettino i cavi e le prese. E possibilmente, quando si modifica qualcosa si tenga il sistema dei nomi aggiornato! E' frustrante cercare di capire come mai il firewall sta facendo passare il traffico  fra l'interfaccia WAN1 e DMZ indiscriminatamente solo per scoprire che la prima interfaccia e' stata riconfigurata per operare come LAN...
E a tal proposito, si scelgano dei mount point con nomi significativi: non serve a niente montare un device in rete come /mnt/storage, a meno che il dispositivo remoto non si chiami effettivamente "storage". Molto meglio codificare il nome del dispositivo, come ad esempio NAS_p1_s37 (NAS al primo piano nella stanza 37) e si usi un mount point opportuno come /mnt/NAS_p1_s37. Meglio ancora, si suddividano i mount point  per tipo e priorita', cosi' che gli script possano smontare o rimontare tutti i device agilmente come ad esempio /mnt/NAS/NAS_p1_s37.



Commenti da lasciare senza commenti!

Gran cosa i commenti: consentono al sysadmin di aggiungere delle annotazioni nei file di configurazione per  indicare perche' si sta facendo quello che si sta facendo. O almeno per esprimere al mondo quello che si vorrebbe fare (che poi ci si riesca e' un'altra cosa!). Ma i commenti sono utili solo se sono mirati, ossia se sono posizionati nel punto della configurazione alla quale il commento si riferisce. In altre parole, mettere dei commenti in cima ad un file specificando cosa si fa nel file in un punto imprecisato (tipicamente almeno una  videata sotto) e' totalmente inutile. E peggio ancora e' tenere la storia dei commenti nello stesso file: si usi un  sistema di controllo delle versioni per tenere traccia della storia evolutiva di un file.