Script su server x prevenire i fake boot

[massimilianonball]

Ciao ragazzi, ho deciso di scrivere xké dopo essermi documentato in rete, mi rimangono cmq dei dubbi che spero qualcuno mi possa chiarire..

Il pc in questione è quello in firma sul quale è installato windows sette e attraverso wubi è installato anche ubuntu 10.04 LTS 32 bit versione Desktop.

Il problema che si presenta è che occasionalmente (diciamo circa una volta al mese..), mi succede che accendendo da remoto il pc come faccio tutti i giorni, il computer parte, ma poi ubuntu non si avvia correttamente e rimane irraggiungibile, a questo mi tocca chiamare a casa x farlo riavviare manualmente.

L'idea era quindi di fare un semplicissimo script che x esempio mi pinghi "www.google.com" o il router di casa 1 volta al minuto x 3 minuti: se non pinga si riavvia da solo e dopo 3 riavvii si spegne.
Nessun problema x lo script, io volevo sapere solamente come farlo eseguire, nel senso che mi serve un livello più "basso" possibile in modo da prevenire questi fake boot e/o crash del sistema, riavviandolo se necessario..

Cercando in rete ho trovato 2 soluzioni:
1. http://openskill.info/infobox.php?ID=129 --> potre x esempio sistemare lo script nel runlivel 2..
2. i classici if-pre-up.d, if-up.d, if-pre-down.d, if-down.d --> in questo caso collocherei lo script nel pre-up

Voi quale dei 2 mi consigliate..? ..o in alternativa conoscete un modo igliore x fare sta cosa..??

Grazie!!

[Gimli[2BV!2B]]

Motivi dei blocchi all'avvio?

• Se si tratta del kernel che nemmeno riesce a partire si può fare un fallback in Grub2... ok, forse, essendoci di mezzo wubi.
• Se dovesse rimanere fermo a far nulla, non arrivando mai all'avvio della rete, potrebbe bastare uno script di questo tipo da pianificare in Cron.
• In caso di sistema che non reagisce più ma kernel "cosciente": watchdog software.

È anche possibile riavviare un sistema molto bloccato (non "defunto") manualmente via rete: sysrqd.

Hai valutato di installarlo in modo più canonico rispetto a Wubi?

La frequenza "una volta al mese" mi fa pensare al controllo periodico della partizione all'avvio, può essere?

Il pre-up viene eseguito solo nel momento immediatamente precedente alla configurazione delle interfacce di rete; inoltre uno script lanciato in quella fase deve terminare perché possa proseguire la configurazione dell'interfaccia.

[massimilianonball]

Grazie x la risposta dettagliata e veloce!!

Vado con le risposte:

1. wubi non è il massimo in effetti ma visto che uso il pc anche x giocare windows mi serve x forza.. In più uno dei punti a favore di wubi è che mi evita di fare partizioni..

2. mi spiace di aver scritto genericamente "fake boot" e di non aver potuto postare i dettagli dei blocchi ma come scrivevo, questi problemi random avvengono da remoto quindi non ho modo di vedere il monitor.. Ho comunque provato a fare il "tail" o il "cat" dei vari syslog o kern.log o faillog o di tutti quelli che mi sembravano sospetti.. ma non ho trovato nulla di strano..

3. Non penso si tratti di un problema di kernel xké il problema si manifesta già da un po' quindi visto che aggiorno regolarmente, di aggiornamento in aggiornamento avrei dovuto trovare dei cambiamenti, invece niente..

4. Ho già usato il fallback in Grub2 sul portatile di mia moglie quando l'ultimo kernel uscito (sempre x il 10.04) faceva andare a singhiozzo la scheda wifi, ma come ti accennavo nel punto precedente non dovrebbe essere un problema di kernel..

5. ho già altri script in crontab, a sto punto aggiungerei anche questo.. --> PROVA DA FARE

6. Mi sa che il problema non è nemmeno il controllo della partizione in avvio in quanto a volte mi è capitato che la facesse quando ero fisicamente davanti al pc e non mi ha dato nessun problema.

7. Hai ragione, il pre-up si "blocca" fino a quando lo script non termina, mi ero già inbattuto in questo "problema" e me ne ero dimenticato..

8. Non conoscevo watchdog né sysrq sono ottime soluzioni: mi sa che proverò prima la seconda anche se non riuscendo a collegarmi al in pc in ssh mi sa che anche in telnet sarebbe dura.. Comunque proverò entrambe..

X adesso grazie di nuovo e complimenti (!!!) e visto che non posso aspettare questi blocchi x vedere se i rimendi funzionano, aggiungo cmq [Risolto] al titolo della discussione, (dal momento che mi hai fatto il 90% del lavoro )

[Gimli[2BV!2B]]

Per vari motivi sospetterei i driver video: che scheda video hai e che driver usi?

Da remoto puoi quindi accedere via ssh (anche VNC o altro?): è la mancata risposta via ssh che ti fa capire che il boot è andato storto?
Quando capita non riesci nemmeno a fare un tentativo di login?
Adotti contromisure ad attacchi brute-force, tipo fail2ban oppure utilizzi una chiave crittografica? Hai lasciato ssh su porta 22?

Lo script in Crontab potrebbe servire solo se il sistema dovesse fallire la configurazione della rete (rete fissa o wireless?) o se non dovesse funzionare l'avvio di un server VNC, per tutto il resto l'avvio del demone Cron avviene troppo tardi (è tra i primi del runlevel 2, la rete dovrebbe essere alla fine del single anche in Ubuntu).

L'avvio del pc Ubuntu lo comandi via WOL da un'altro pc che lasci acceso a casa?
Immagino che tu stia usando un servizio DNS dinamico, potrebbe essere un problema di disconnessione del modem, con successivo breve periodo di accesso irrealizzabile fino alla successiva sincronizzazione dell'ip?

Ok, ok, basta domande
Il fatto è che potrebbe essere praticamente qualsiasi cosa che fa deragliare l'avvio\comunicazione e riflettendo sulle possibili contromisure trovo continui possibili punti di fallimento...

[massimilianonball]

Ciao!! Non preoccuparti delle domande: fossimo tutti come te, i problemi si risolverebbero molto prima..

Non ti avevo parlato della scheda video x non scrivere un poema e xké il problema si presentava solamente ad ogni aggiornamento del kernel.. cmq in effetti avevo questo problema. Ho "risolto" disinstallando i driver video prima di ogni aggiornamento del kernel e reinstallandoli successivamente..
Scrivendoti però mi sono accorto che ne è uscita una nuova versione, quindi appena ho 2 minuti li provo..

Per rispondere alle altre domande ti dico che si, mi collego in ssh e la mancata connessione mi fa pensare che ci sia stato il problema in questione. L'ssh è sulla porta 22, uso le porte standard xké in base a quello che leggo, se ti attaccano il pc, x prima cosa fanno una scansione delle porte, quindi anche se sposto il demone su un'altra porta, cmq non risolvo una ceppa.. (ovviamente imho)

Non uso nemmeno fail2bin e company xké il server in questione, di fatto parte con tutte le porte chiuse tranne proprio la 22 e poi ho fatto uno script col quale lo controllo da remoto, che lanciando un'applicazione, apre di conseguenza le relative porte e chiudendola le richiude, quindi direi abbastanza sicuro..

Inoltre queste porte non sono aperte lato "wan", quindi non ho la 22 esposta in internet xké mi collego a casa attraverso openvpn che gira sul mio router moddato modello fritzbox; quindi di fatto esposta ad internet ho solo la 1194 di openvpn aperta sul fritz stesso (e un altro paio), arrivato al quale posso accendere i pc che ho a casa.. Con questo ti ho risposto anche al possibile problema (escludendolo) di indirizzi dinamici..

Dovrei aver risposto a tutto.. Provo i nuovi driver più (x addesso) sysrq, intanto grazie ancora!!

[Gimli[2BV!2B]]

Mi sembra una configurazione abbastanza sicura e robusta.
Ora che ho chiaro il quadro sono portato anch'io ad escludere problemi di comunicazione, dev'essere qualcosa nel server ssh Ubuntu.

Usando i driver Catalyst sarei meno portato a pensare male della scheda video: mi risulta che, in caso di modulo del kernel non aggiornato, al massimo non parta Xorg.
Questo non dovrebbe impedire né la configurazione della rete (che mi risulta avvenga ben prima, anche se Ubuntu tende ad allontanarsi sempre più da mamma Debian) né le connessioni ad ssh.

[massimilianonball]

Sinceramente non conosco questi tecnicismi del comportamento di ubuntu: speriamo bene.. Nel frattempo ho aggiornato i driver senza problemi.. Grazie mille x la collaborazione!!