Lo scopo di questa esperienza è di familiarizzare con il sistema di checkup del server isi. In realtà questa non è propriamente una esperienza di rete, e netkit è utile solo per la semplicità con sui possiamo attivare il server.
Il comando da imparare ad usare è quindi: isi-checkup.
Vogliamo raggiungere i seguenti obiettivi didattici:
Verificare che sul nostro sistema siano correttamente configurati avvio automatico al boot, file di configurazione del servizio e che il processo sia attivo in memoria. In caso così non fosse (e non lo sarà :p) dovremo apportare qualche modifica al sistema.
Fisseremo le seguenti specifiche didattiche:
Il sistema dovrà avere attivi e configurati per partire al boot i seguenti servizi:
Disattivare i test relativi ai servizi non voluti modificando opportunamente il file di esclusione /etc/isi/checkup/exclude.
Verificare i permessi utente.
Prima di iniziare, assicuriamoci che il DOMINIO sia inizializzato correttamente utilizzando il comando “isi-domain DOMINIO srv-dominio password”
Lanciamo ora il comando isi-checkup -s (esegue i test relativi al sistema).
Qualche test non è andato a buon fine, la maggior parte riguarda la configurazione dell’avvio al boot di alcuni servizi, non attivati in questa macchina virtuale.
Nella parte riepilogatrice noterete due colonne: il nome del file che contiene il test ed il nome della classe python corrispondente al test.
Nota
Talvolta il nome della classe potrebbe essere sostituito da un nome, pre-configurato dal creatore del test, più descrittivo
Lanciato il comando, assisteremo al fallimento del test BootProcessBind9, test che verifica che bind9 sia impostato per partire al boot, così come di altri, sempre relativi al boot, quali squid, dansguardian, postfix, ...
Servizio non configurato per partire al boot: dhcp3-server
Servizio non configurato per partire al boot: squid
Servizio non configurato per partire al boot: dansguardian
Servizio non configurato per partire al boot: postfix
Servizio non configurato per partire al boot: nscd
Servizio non configurato per partire al boot: bind9
Parametro ldap "sizelimit" inferiore a 1500
sizelimit : 500
I seguenti test non sono andati a buon fine
-------------------------------------------
dhcp3-server_run_on_boot.py BootProcessDhcp3Server
squid_run_on_boot.py BootProcessSquid
dansguardian_run_on_boot.py BootProcessDansguardian
postfix_run_on_boot.py BootProcessPostfix
nscd_run_on_boot.py BootProcessNscd
bind9_run_on_boot.py BootProcessBind9
ldap_sizelimit.py LdapSizelimit
Alcuni dei servizi(bind9) da noi voluti sono compresi tra quelli che non partono al boot!. Armati di editor di testo modifichiamo il file /etc/runlevel.conf affinchè le linee relative ai servizi da avviare al boot non siano commentate, assenti, o malconfigurate. Volendo, per esempio, che bind9 parta al boot (e lo vogliamo), dovremo assicurarci che sia presente una riga del tipo
15 - 2,3,4,5 /etc/init.d/bind9
Nota
Proviamo ora a rilanciare isi-checkup -s. Se non abbiamo fatto errori il primo ostacolo dovrebbe essere superato. Ma ecco presentarsi il prossimo riguardante Bind9
need_process_named.py ProcessBind9
Il processo non viene trovato in memoria; bind9 non è avviato, avviamolo:
/etc/init.d/bind9 start
Finalmente anche l’ultimo avviso relativo ai servizi che ci servivano è sparito.
Notate l’output di riepilogo restante
dhcp3-server_run_on_boot.py BootProcessDhcp3Server
squid_run_on_boot.py BootProcessSquid
dansguardian_run_on_boot.py BootProcessDansguardian
postfix_run_on_boot.py BootProcessPostfix
nscd_run_on_boot.py BootProcessNscd
bind9_run_on_boot.py BootProcessBind9
ldap_sizelimit.py LdapSizelimit
isi-checkup si aspetta che anche il servizio Squid parta al boot, servizio che a noi non interessa o che magari non abbiamo neanche installato sul nostro sistema. Come dire ad isi-checkup di saltare un test? Baste inserire nome del test nel file delle esclusioni. Modifichiamo quindi il file /etc/isi/checkup/exclude aggiungendo la riga relativa ai test falliti dei servizi non voluti.
es.
squid_run_on_boot.py BootProcessSquid
Nota
E`possibile copiare le righe prodotte dell’output anche se composte da due colonne e non dal solo nome-test.
Rilanciamo ancora isi-checkup -s e osserviamone nuovamente l’output: La precedente segnalazione relativa a squid è scomparsa in quanto il test è stato escluso ed il suo avvio impedito.
Procediamo escludendo anche gli altri servizi non previsti dalle specifiche.
Nota
Dalla versione 0.6.7 di IsiCheckup, escludendo un test, si escluderanno anche tutti i test ad esso dipendenti.
Dopo le esclusioni dei test relative ai servizi “di troppo”, dovremmo ritrovarci un file di esclusione con il seguente contenuto
dhcp3-server_run_on_boot.py BootProcessDhcp3Server
squid_run_on_boot.py BootProcessSquid
dansguardian_run_on_boot.py BootProcessDansguardian
postfix_run_on_boot.py BootProcessPostfix
nscd_run_on_boot.py BootProcessNscd
Resterà però ancora un altro “errore” da correggere
Parametro ldap "sizelimit" inferiore a 1500
sizelimit : 500
La direttiva sizelimit limita il numero di interrogazioni fatte al db ldap. Modifichiamo il file /etc/ldap/slapd.conf e aumentiamo il valore assegnato alla direttiva sizelimit a 2000.
Proviamo ora a vedere cosa succede quando il gruppo Domain Admins, a cui appartiene l’utente administrator (usato per per fare il join ma non solo...) manca di qualche privilegio.
Vediamo attualmente di quali privilegi dispone il gruppo
net rpc rights list 'Domain Admins' -Uadministrator%password
Nota
con password si fa riferimento alla password impostata in precedenza con isi-domain
Revochiamo il privilegio SeMachineAccountPrivilege, indispensabile per effettuare il join:
net rpc rights revoke 'Domain Admins' SeMachineAccountPrivilege -Uadministrator%password
Lanciamo ora isi-checkup -s.
L’esito sarà abbastanza scontato... ma vale comunque la pena provare.
Ora possiamo rimettere tutto a posto, riassegnando a Domain Admins i privilegi sottratti in precedenza:
net rpc rights grant 'Domain Admins' SeMachineAccountPrivilege -Uadministrator%password
Per approfondire meglio quali privilegi ci sono e qual’è la loro utilità si rimanda al sito ufficiale
Attualmente il test verifica che il gruppo “Domain Admins” abbia tutti i privilegi a disposizione, anche quelli che potrebbero sembrare superflui. Nel caso in esempio al gruppo “Domain Admins” manca “SeMachineAccountPrivilege”, necessario (vedi spiegazione sui privilegi nello stesso documento) per aggiungere macchine al dominio.
Dopo aver provato alcuni test di sistema è giunto il momento di impratichirci con quelli utente. Creiamo l’utente docente d_test con isi-adduser -s 'd_test;;;docenti;;;segreto'
cambiamo il proprietario di ~d_test (la cartella home dell’utente d_test) in root
chown -R root.root ~d_test
Verifichiamo il cambiamento di proprietà con ls -l ~d_test
Lanciamo una verifica dei permessi per il solo utente d_test
isi-checkup -u d_test
Come si potrà vedere dall’output del comando, l’utente d_test non riesce più a scrivere nè leggere od attraversare la propria home, con tutto quello che ne consegue. Mai capitato di incappare nel messaggio di windows “profilo non trovato”? Spesso questo tipo di errore è attribuibile all’impossibilità da parte di un utente di accedere al proprio profilo.
Verifichiamolo manualmente mettendoci “nei panni” dell’utente
su d_test
Proviamo ora a leggere:
ls ~d_test
scrivere:
touch ~d_test\file-di-prova
o attraversare
cd ~d_test
la home di d_test
Ora siamo pronti per risolvere il problema. Torniamo alla nostra root-shell precedente e reimpostiamo ricorsivamente il proprietario di ~d_test
exit chown -R d_test.docenti ~d_test