View Single Post
Old 20-04-2012, 23:28   #24
eaman
Senior Member
 
L'Avatar di eaman
 
Iscritto dal: Feb 2002
Messaggi: 2454
Quote:
Originariamente inviato da Gimli[2BV!2B] Guarda i messaggi
apt-file search /usr/share/keymaps
Oh grazie, ma te pensa quanto mi sono dannato per 2.5MB... A volte quando vai a cercare di ottimizzare lo spazio sulle locales o i tools di base e' devastante: una volta mi son beccato un host con la tastiera russa e appunto non riuscivo neanche a caricarmi una maleddetta keymap che sara' pesata pochi KB...


Quote:
gpm non lo conoscevo, dalla descrizione mi sembra avere un discreto potenziale di utilità.
E' il mouse da terminale: se ti serve il copia incolla o per quelle utility che prevedono i 'click'.

Quote:
La configurazione che hai descritto sembra molto comoda per laboratori ed internet point. Un pezzo in meno, destinato a rompersi, da comprare.
Quello e' il punto, a parte il costo dell'oggetto, nei lab in genere sei fermo perche' ti si rompe l'hd o l'alimentatore. E con le cpu / motherboard attuali piu' o meno passive + i monitor piatti che consumano poco i picchi di corrente e rumori' sulla corrente sono molto diminuiti.

Quote:
Una bella immagine preconfezionata per tutti e via andare (è necessario che ogni client abbia una sua root nel server o possono condividerne una sola?).
Puoi fare entrambe le cose. Semplificando:
A. Immagine unica per tutti con home (variabili e persistenti) sul file server.
B. Immagini dedicate per ogni macchina (scelte via MAC ADRESS)
C. Immagine base e differenze delle singole macchine usando qualcosa tipo AUFS.

Se e' un lab per corsi da sistemisti direi da B in giu', se non si possono usare macchine virtuali. Che poi basterebbe tenere queste su un server, o usare User Mode Linux o Vserver (che e' ancora dentro debian ), ma oggi va di moda la virtualizzazione full...



Quote:
Un po' di spazio su server se gli utenti sono registrati in qualche modo, altrimenti al riavvio si azzera tutto e sia il server che il client si scordano di quel che è successo.
LDAP per la gestione degli utenti, 20KB per un client web per aggiungere un utente e cambiare la password per gli operatori, le /home su servers nfs che vengono caricate su qualunque macchina.

Quote:
Con reti gigabit dovrebbe girare abbastanza bene
Con un server 'vecchio' e tutto super economico tieni sui 70MB/s di accesso 'sequenziale', che va bene per caricare una macchina virtuale. Per file piccoli e accessi frequenti si sente la latenza, ma se e' hardware molto vecchio delle volte sono piu' usabili cosi' che con gli hd locali. E se fai una cosa nuova ci metti 2/4GB di RAM e puoi considerare cose feroci come tenerti delle grosse cache in RAM.
Quote:
(forse avrei qualche timore in caso di avvio contemporaneo di tutte le macchine).
Lo senti di piu' se usi tipo una debian-live che ti carica tutto in RAM. Se hai la root su NFS in fin dei conti carichi 100/300MB per fare il boot di un host, e puoi sempre mettere in parallelo piu' switch: adesso trovi dei 8 / 16 porte gigabit a 25 /50 euro...

Ma hey: se ti capita spesso di fare il boot all togheter considera un boot in multicast !

Quote:
C'è il classico rischio che il server decida di prendere una pausa, ma ipotizzerei che ci si potrebbe coprire le spalle usando due server un po' meno potenti su cui spartire dinamicamente i client. Se uno fallisce il secondo prende temporaneamente le redini per non interrompere il servizio finché non si sistema l'altro. Immagino ci sia qualche modo per farlo...
Be' il server si suppone che stia su' e non faccia pause, per quanto quello descritto sia il contro prezzo di un paradigma accentrato.

Alta disponibilita' per LDAP / storaggio dati non e' un problema, ma la soluzione piu' fattibile per molte realta' secondo me e' avere un server di back-up speculare da usare come 'supporto di backup' e da rendere autoritativo (meccanicamente: tipo attacca il cavo rosso e stacca il cavo verde) per non piantare tutto in caso di failure hardware mentre aspetti il sistemista.


Quote:
La magata suspend to disk in rete potrebbe essere sfiziosa, però, se l'ho capita bene, può funzionare?
Be' tecnicamente dovrebbe essere simile alla migrazione di una virtual machine: c'e' il filesystem (che se' e' remoto non e' neanche da migrare) e la RAM da copiare / sincronizzare (io penso a un suspend to RAM).

Effettivamente rileggendo il tuo commento si potrebbe pensare anche a un ripristino da suspend to disk con il disk che e' remoto.

Io pensavo anche a 'spostare' la sessione di lavoro corrente da una macchina a un'altra (vado a casa e mi sposto il desktop sul portatile), certo che c'e' tutto il kernel / OS / applicativi da sbolognare. Bisognerebbe farlo girare su una macchina virtuale se no ti tocca avere l'hardware identico (e senza firmware buffi ;-) )

L'ideale (e scommeto che in un paio di anni qualcuno lo fara') sarebbe un hypervisor (ala virtual machine) che fa diretto il boot da rete. Al momento magari sarebbe fattibile un OS che fa il boot da rete e' poi carica un hypervisor e il supporto di storaggio di questo da rete.

Oppure usare un paradigma come xpra ( http://xpra.org/ ), thin client persistente.

Quote:
Anche ipotizzando di ibernare, salvare e ripristinare su un sistema gemello del primo, temo possano esserci variabili (per esempio il MAC address salvato nell'immagine della memoria) che rischierebbero di creare scompiglio ed errori...
He gia' ci vuole il suspend to pxe ;-)
Tenere un ID della sessione da associare a una MAC. Del resto quando fai partire il nuovo host bisognera' pur dirgli cosa deve traslarsi sopra.

Comunque c'e' fortunatamente un layer di astrazione tra MAC e indirizzo IP: magari un dhcp server un po' sgaggio puo metterci una pezza veloce.

...poi resta il problema della compatibilita' di tutto il resto dell'hardware, ma si supererebbe con un hypervisor.

Chiedo scusa sono stato un po' lungo.

Ultima modifica di eaman : 20-04-2012 alle 23:39.
eaman è offline   Rispondi citando il messaggio o parte di esso