Newsgroup: it.comp.macintosh
Titolo: il puntatore del mouse si muove

ma tutto il resto no :(
qualcuno, tempo fà, mi disse che quando riesci a muovere anche solo il
puntatore del mouse X non è in bomba (cioè, non in bomba totale), quindi
sarebbe possibile intervenire in remoto per killare il processo che
rompe i coglioni.
mettiamo che io ci voglia tentare: che faccio?
-- 
.zen

zen <SegataS...@Sega.com> wrote:

da un altro computer connesso in rete col mac fermo, digiti ssh
IPAddress, ti autentichi con username e password, e poi con top (digiti
top seguito da return) vedi i processi attivi e il relativo PID (nuemro
di identificazione). Individuato quello in blocco, esci da top con
control-c e digiti "kill -HUP pid", dove a pid sostituisci il numero di
cui sopra...
Nella peggiore, puoi sempre terminare con "sudo reboot now", che almeno
fa un flush della filesystem cache, cioe' non ti lascia files aperti.
-- 
"La prova sicura che nell'Universo esiste vita intelligente,
e' che non ha mai cercato di contattarci"
Calvin and Hobbes (Bill Watterson)

 IPAddress,
Il problema è che deve essere abilitato il login remoto sulla macchina
impallata.
-- 
Ci sono 10 categorie di persone al mondo: quelle che capiscono
il sistema binario e quelle che non lo capiscono.

fa un flush della filesystem cache, cioe' non ti lascia files aperti.
pero' devi avere sshd gia' attivo...
puoi anche usare killall nomeprocesso o killall -9 nomeprocesso.
comunque a meno che non sai quale processo sta bloccando tutto,
chiuderli a uno a uno puo' essere noioso...
Io consiglio la strada del sudo reboot now, che e' molto piu' rapida...
Comunque fai conto che la strada da remoto e' un po' macchinosa...
Prima prova con il famoso forcequit...
-- 
(setq RiK0 "Enrico Franchi")
(setq url "
www.anubics.org
")
(setq quote "Se mi prendo sul serio, 
 c'e' da mettersi a ridere." )

 impallata.
che potrebbe permettere a chiunque di farsi un giretto quě, giusto?
quindi la soluzione č il solito bottone del power? :(
-- 
.zen

 di identificazione). 
esempio, l'eMac č inpallato, collego il cavo di rete dall'iBook e
aggancio l'ip della macchina impallata (mela+k/ip/connect), entro con
user/pssw, apro il terminale (sull'eMac) e digito "ssh 192.168.X.X", mi
autentico di nuovo e dal "top" guardo cosa usa il 100% della cpu, lo
killo e amen, giusto?
scommettiamo che se ci provo mi di dą errore del gaiser? ^_^"
-- 
.zen

 Prima prova con il famoso forcequit...
la tastiera non rispondeva più, solo il topo...
-- 
.zen

 scommettiamo che se ci provo mi di dą errore del gaiser? ^_^"
Si, possibile :-))


 che potrebbe permettere a chiunque di farsi un giretto quì, giusto?
a chiunque sappia la password e il tuo ip.
poi che io sappia il server ssh del MacOS non e' buggato (fai un giro
sui siti specializzati per verificare).
Quindi non sei forabile... inoltre non credo che il tuo computer sia
online 24 ore al giorno (ok.. ci ho provato, il mio lo e')...
e per lo meno non dovrebbe ospitare servizi pubblici accessibili...
inoltre fai conto che i lameroni di solito scannano sulla 80 e i
NetBIOS, non fanno attacchi su ssh (cosa comunque fattibile solo se
fosse buggato).
Un bruteforce su ssh e' impensabile (o per lo meno dobbiamo considerarlo
tale), nel senso che a meno di usare password tipo ciao e gatto il
numero di tentativi e' sufficientemente alto per lasciare tracce
veramente notevoli su un log.
Un ultima cosa che non abbiamo tenuto conto...
se hai il firewall su e hai chiuso la 22 (sshd), non c'e' cristo, li'
non ti ci connetti...
in teoria puoi abilitare solo una certa classe di ip ad accedere a
quella porta (per esempio una classe locale), quindi in effetti ti
potresti connettere con l'ibook.
credo pero' che quest'ultima cosa si possa fare solo scriptando l'ipfw a
mano... 


 scommettiamo che se ci provo mi di dą errore del gaiser? ^_^"
proviamo?


 quindi la soluzione è il solito bottone del power? :(
ssh e' telnet crittografato (Secure SHell, i belive...) e se hai messo
una password, non dovrebbe creare problemi lasciarlo attivo. 


 Si, possibile :-))
seguro :-D
-- 
.zen

 a chiunque sappia la password e il tuo ip.
grazie mille per la spiegazione! :)
-- 
.zen

 una password, non dovrebbe creare problemi lasciarlo attivo. 
ottimo, ty anche a te :)
-- 
.zen

 proviamo?
domani sicuramente farò una prova, ora devo scappare...
-- 
.zen

 domani sicuramente farň una prova, ora devo scappare...
funziona! ^_^
-- 
.zen

 funziona! ^_^
yeeeeh..
con l'augurio di non averne mai bisogno!!!


 con l'augurio di non averne mai bisogno!!!
nell'ultimo anno avrň visto, al massimo, tre bombe di cui due cosě
(mouse che risponde ancora) e una totale (scritta multilingua e bottone
power).
X is rock solid :)
(SGRAT,SGRAT..)
-- 
.zen

 
mi collego qui, dopo aver visto che sei riuscito a riconquistare il tuo
eMac, per questionare su questo post.
Non serve collegarsi con condivisone (mela+k) perche' quando lanci il
terminale, l'applicazione risiede sull'eMac, poi viene trasferita via
rete sull'iBook, ecc.
Basta che lanci direttamente il terminale dall'iBook e parti da li.


 rete sull'iBook, ecc.
l'applicazione viene trasferita via rete sull'iBook?
mi sa di non avere capito cosa intendi...
:-)


 mettiamo che io ci voglia tentare: che faccio?
Prova a tenere sul  dock un alias del terminale... quando appare la
rotella prova ad aprire il terminale, fai top, trova il numero del
processo responsabile del blocco, killalo... se sei fortunato riuscirai
a recuperare il sistema :)
-- 
"Imagination is more important than knowledge"
Albert Einstein 
1879-1955 

 "kill -HUP pid"
Che deffirenza c'è con "kill pid" senza specificare "-HUP" (hang up)? io
ho sempre fatto senza HUP :)


 :-)
Provo: se tu dall'iBook ti colleghi con mela+k all'eMac, il disco
dell'eMac ti apparira' sul desktop dell'iBook.
Ora, se tu doppioclicchi un'applicazione che risiede su un disco di
rete, il codice eseguibile di questa app viene trasferito via rete dal
disco remoto alla ram dell'iBook e quindi eseguito.
Perfettamente equivalente a doppiocliccare un'applicazione che risiede
sull'hard disk locale: viene trasferita - via bus interno - dall'HD alla
ram dell'iBook ed eseguita.
Quindi, doppiocliccando Terminale che sta sul disco dell'iBook senza
preventivamente montare il disco remoto della macchina semi bloccata, si
ottengono le stesse prestazioni, posto che il blocco sula macchina
remota permetta di fare tutto cio'...


 remota permetta di fare tutto cio'...
si appunto... non capivo cosa c'entrava trasferire le applicazioni...
l'importante e' il server ssh...
tutto il resto puo' variare...


 ho sempre fatto senza HUP :)
E' una cosa legata alla gestione dei segnali in Unix.
se metti HUP, kill manda SIGHUP altrimenti manda (se non ricordo male)
SIGTERM. 
In generale e' meglio mandare un SIGTERM perche' non forza
l'applicazione ma le dice di porsi in uno stato coerente, eventualmente
salvare e poi uscire.
In questo caso pero' l'applicazione non risponde, quindi SIGTERM non
servirebbe. Meglio SIGHUP, o piu' forte ancora il famigerato -9 aka
SIGKILL.
comunque dai un occhio al man di kill e della funzione di libreria
signal...
(potrei avere detto qualche imprecisione dovuta al fatto che io con i
sig ci lavoravo con kernel Linux, e da quello che ho visto, le cose sono
un poco diverse, anche se non di molto)


 E' una cosa...
Grazie 1000 :)


 Non serve collegarsi con condivisone (mela+k)
vero, infatti provando ho solo fatto:
(dopo aver abilitato il login remoto)
terminale, ssh 192.XXX.X.X, password ed il mio terminale è diventato
quello della macchina in cui sono entrato, cambiando solo il nome prima
del prompt :)
poi ho provato un "sudo reboot now" e ha funzionato alla grande,
riportandomi nella macchina locale mentre l'altra rebootava.
-- 
.zen

 a recuperare il sistema :)
non appare la rotella, il puntantore resta tale ma non risponde NIENTE.
fortunamente č accaduto un paio di volte..
-- 
.zen