Debianizzati.Org | Forum | Blog | Guide | IRC
 
 
Forum Italiano Debian - Debianizzati.Org
Novembre 22, 2008, 08:10:27 pm *
Benvenuto! Accedi o registrati.
Hai dimenticato l'e-mail di attivazione?

Accesso con nome utente, password e durata della sessione
Notizia:
 
   Indice   Aiuto Ricerca Agenda Accedi Registrati  
Pagine: [1]   Vai giù
  Stampa  
Autore Discussione: debsums utilizzo, e integrità generale del sistema  (Letto 312 volte)
0 utenti e 1 Utente non registrato stanno visualizzando questa discussione.
leptone
Jr. Member
**

Karma: +0/-0
Scollegato Scollegato

Messaggi: 84


GNU Breaking Windows


Mostra profilo E-mail
« inserita:: Agosto 20, 2007, 11:12:14 pm »

In seguito ad alcuni blocchi(e successivo reset) e altre cose del genere, il filesystem del mio sistema si è danneggiato. Al successivo riavvio, è stato operato  correttamente il "trasactions replaing" del file sistem jounaled reiserfs che utilizzo. Poi con la live grml ho controllatto tutte le partizioni eliminando tutti i problemi, sono sicuro in quanto ho accumulato una certa esperienza con "reiserfscheck" e i problemi erano fortunatamente risolvibili tramite l'opzione "--fix-fixable" (insomma niente di grave, e niente rebuild-tree).
Insomma il problema de filesystem è stato correttamente superato, faccio verifiche periodiche e va tutto a posto.

Il secondo passo è stato quello di eseguire "dpkg-reconfigure -a", mi ha dato degli errori a un certo punto ma ho risolto reinstallando determinati pacchetti (come detto in un altro post).
Forse non è il metodo + veloce e migliore, ma è quello che conosco. Infatti ho ripetuto la procedura 3 o 4 volte fino a quando non si bloccava, dopo aver reinstallato i pacchetti inconsistenti, fino a quando il programma non ha terminato correttamente, verificando la cosa con "echo $?" avendo 0 come output (per chi non lo sapesse $? è la variabile che contine l'exit-code dell'ultimo programma eseguito e "0" significa terminato correttamente)

Scusate la lunga introduzione(spero che almeno possa giovare a qualcuno), vengo al dunque.

Ora va tutto bene a meraviglia, però mi è capitato che il sistema si congelasse dopo aggiornamenti, dato che io non ho eseguito il reboot tenendo la macchina accesa per circa 8 ore.(e non sono serviti a nulla i "Linux Magic System Request Key Hacks" che molte volte mi salvano, e che ritengo utilissimi, dato che il congelamento era totale , ma non veniva riportato un kernel-panic)
So che non serve sempre riavviare, perchè in caso di aggiornamenti i servizi/demoni si riavviano, ma utilizzando prevalentemente il pc come desktop la sessione di 8 ore includeva anche Gnome. Inoltre ciò si verifica quando non riavvio per parecchie ore, ma minimo 2 ore il sistema tiene(non penso sia una questione di tempo ma di applicazioni, ma anche se non faccio nulla, tipo apro gnome , aggiorno , carico amule e poi magari esco, o comunque sto lontano dal pc a dopo circa 8 ore si è sempre bloccato. questa la mia esperienza)

Non voglio farla lunga ma so che il sistema si deve riavviare soprattutto se si aggiornano le librerie, non so precisamente quale è il meccanismo, ma a volte caricando le applicazioni, esse chiamano(o linkano) le librerie aggiornate, che dipendono da quelle non aggiornate perchè caricate in Ram prima dell'aggiornamento dei pacchetti o viceversa(mi sono espresso velocemete dato che il post è già lungo, ma spero che abbiate capito, anzi gradirei dei links per capire bene quando è necessario riavviare il sistema. Debian a volte informa dicendo "reboot is needed" dopo aggiornamenti importanti. Comunque credo che il mio problema si verifichi solo se si utilizza una sessione X, o al massimo da console pure basta rieffettuare il login. Comunque penso che il problema sia relativo alle dipendenze, librerie ecc che sono state aggiornate, ma sono già in uso e caricate in ram. Potrei controllare se tra gli aggiornamenti ci sono applicazioni o librerie in uso. Per controllare le librerie in uso conosco solo il metodo tramite gnome-system-monitor, ma va fatto per ogni singola applicazione[voce mappe di memoria] gradirei dei links sull'argomento: librerie usate e linkate al momento immagino che forse si fa via proc fs).

Insomma tra "reiserfsck" e "dpkg-reconfigure -a" e reinstallando pacchetti corrotti, riesco a tenere il sitema in salute, ma oltre a voler capire il problema dell'aggiornamento/riavvio (dato che quando eseguo il reboot non avviene mai nessun blocco e ormai uso debian testind da 4 anni [nel senso di esperienza e non di conoscienza del sistema dato che uso il pc come desktop]).

Ora vorrei imparare ad usare debsums. Nessun problema ho letto la pagina di man ed è tutto abbastanza chiaro.
Il problema e che vorrei sapere come eseguire debsums su tutti i pacchetti installati(oviamente tralasciando quelli che non sono dotati di hash md5). Per esempio per "dpkg-reconfigure" basta l'opzione
"-a" che sta per tutti, invece in debsums "-a" rigurda i file di configurazione.
Quindi ripeto vorrei sapere come eseguire "desums" su tutti i pacchetti installati(tipo "dpkg-reconfigure -a").

Inoltre vorrei sapere (links dato che credo in rtfm), se debsums per quanto riguarda i files di configurazione verifica la consistenza dei files, oppure agisce sulla configurazione vedendo se è corretta e o compatibile con altri pacchetti(in relazione alle dipendenze) o riconfigura i pacchetti inquestione(non penso l'ultima dato che per questo c'è dpkg-reconfigure, ma è anche vero che un stessa cosa si può fare in modi diversi)

Scusate il post lungo, ma gradirei oltre alle risposte, soprattutto che si aprisse un mini dibattito, in modo che questo thread, posssa essere utile a tutti, e non essere una serie di semplici e singole risposte x i miei problemi. Se si sviluppa un mini dibattito si potrebbe da qui anche creare una articolo da inserire nella sezione guide da affiancare all'utilissimo "Pulire Debian", magari creandone una dal titolo tipo "controlare l'integrità del sistema", o cose simili.
In fine secondo voi è giusto, ai fini di verificare l'integrità del sistema, in ordine verificare, il filesistem, i files di configurazione, e poi la consistenza dei files?

x l'ennesima volta scusate il post lungo

ultimissima cosa:
e giusto eseguire questi comandi
# debsums -a [pacchetto]> debsums-output 2>&1 &
# tai -f debsums-output

di solito con 1>foo 2>&1 si ridireziona sia lo standard-output che standard-error su un unico file, funziona anche se si omette 1 come nell'esempio ?
« Ultima modifica: Agosto 20, 2007, 11:22:50 pm da leptone » Registrato
mark
Newbie
*

Karma: +0/-0
Scollegato Scollegato

Messaggi: 6


Mostra profilo
« Risposta #1 inserita:: Agosto 28, 2007, 11:23:25 am »

mesi fa ho avuto un problema di freeze causato da un demone (automount) su sarge-backport
ho scoperto la cosa quando avendo aperto una finestra di terminale si è verificato il problema, e fortunatamente è apparso un messaggio molto istruttivo ....
potrebbe essere una cosa facile da provare  Wink
Registrato
leptone
Jr. Member
**

Karma: +0/-0
Scollegato Scollegato

Messaggi: 84


GNU Breaking Windows


Mostra profilo E-mail
« Risposta #2 inserita:: Agosto 31, 2007, 06:13:42 pm »

Ho sempre 3 terminali aperti. Uso gnome e ho un gnome-terminal da utente, uno da root, e poi apro un urxvt per lanciare amule e leggere standard output ed error.
Quindi i messaggi da terminale li vedo, quando ci sono.
L'altro giorno ho avuto un altro blocco con aperti i terminali, firefox , e amule. Non ero al pc da qualche ora e ho dovuto resettare perkè non funzionava nè ctrl+alt+F1 per avere la consol pura, cosa cher credo sia dovuta a un blocco di X, che controlla mouse e tastiera, e quindi quando va in tilt la tastiera è fuori uso(lo vedo anche dal fatto che non funziona la luce del caps-lock), e fin qui ci capiamo. Ma se la tastiera è bloccata  da X, i "Linux Magic System Request Key Hacks" dovrebbero funzionare perchè controllati dal kernel. Ma la tastira è comunque bloccata. Comunque quando ho dei blocchi spingo il tasto di accensione(sul case) che da il comando halt, e molte volte mi salva.
Sono consapevole di usare testing, e che su stable certe cose non succedono.

Comunque io vorrei capire come fare, dopo aver verificato la consistenza del file-system, a verificare la consistenza dei files sulla root-partition. Credo che debsums sia lo strumento adatto, ma non ho ancora imparato ad usarlo bene. Ho scoperto facendo una prova, che se si omette il pacchetto da analizzare, debsums inizia ad analizzare tutti i files (o almeno crredo, come se lo facesse su tutti i pacchetti, almeno questa è l'idea che mi sono fatto dall'output). Ma debsums ad un certo punto si è fermato ad un determinato files, e ripetendo la procedura si comporta allo stesso modo, e l'exit-code non è 0.

Io vorrei sapere solo se debsums è lo strumento giusto per analizzare la consistenza\corruzione dei files
Io (tempo permettendo) sto imparando gradualmente ad usare questo strumento, ma sono ancora alle basi. gradirei qualche link a qualche howto.
Cmq dopo reset forzati e controllo del file-system tutto funziona normalmente, ma penso che ciò in parte si dovuto alla natura di sid-testing che anno un veloce cambio di componenti e librerie, e i DD badano + a eliminare i bug di sicurezza + che quelli di funzionalità e stabilità. E poi comunque uso beryl non dal repository ufficiale debian
Registrato
Pagine: [1]   Vai su
  Stampa  
 
Vai a:  

Altri Topic Correlati
Oggetto Aperta da Risposte Visite Ultimo messaggio
amule e apt-get in generale Apt-get & friends fantasma 6 372 Ultimo messaggio Ottobre 14, 2005, 09:35:06 pm
da Tacco
integrità dei pacchetti scaricati con apt-get Apt-get & friends decola 2 175 Ultimo messaggio Dicembre 10, 2005, 09:55:07 pm
da decola
Contenere utilizzo memoria ram Tuning Smjert 2 712 Ultimo messaggio Agosto 26, 2006, 10:56:06 pm
da Smjert
Rallentamento generale Generale fastlane 12 363 Ultimo messaggio Giugno 27, 2007, 05:17:12 pm
da Finn
Linux: Utilizzo della RAM Generale Schumy 5 396 Ultimo messaggio Aprile 05, 2008, 02:19:37 pm
da kiroken
Powered by MySQL Powered by PHP Powered by SMF 1.1.7 | SMF © 2006-2008, Simple Machines LLC XHTML 1.0 valido! CSS valido!
Pagina creata in 0.081 secondi con 20 interrogazioni al database.