Domande? Problemi?

Iscriviti al Google group:

Isi-checkup

Scopo

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:

    • ssh
    • dns (bind9)
    • samba
    • ldap (slapd)
  • Disattivare i test relativi ai servizi non voluti modificando opportunamente il file di esclusione /etc/isi/checkup/exclude.

  • Verificare i permessi utente.

Setup

Questa esperienza usa

  • un server isi con installato il sistema di checkup

Esercizio

  • 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

    • Il file è composto da righe con quattro campi. Il primo campo non ci interessa.
    • Il secondo campo è importante che non contenga il valore numerico corrispondente al runlevel di boot (2)
    • Il terzo dovrà contenere il numero corrispondente al runlevel di boot (2)
    • Potrebbe capitare di trovare nel file /etc/runlevel.conf. due linee identiche; rimuovete o commentate pure il doppione.
    • /etc/runlevel.conf viene utilizzato nelle distribuzione debian ISI basate su ETCH.
  • 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

Letture