Se per caso a qualcuno capitasse di avere un server con più di 26 dischi e grub, fino alla versione 1.99 incappa in un curioso bug. In pratica, grub-probe non identifica i dischi con label del tipo sdaa, sdab, cioè come da sempre vengono etichettati i dischi oltre il ventiseiesimo.
L'unica è aggiornare o patchare grub-probe (che è quasi la stessa cosa). Questo significa, per una Debian Squeeze, fare il backport da Wheezy del package grub-pc, che vince la palma come il primo necessario in Squeeze.
lunedì 9 gennaio 2012
martedì 8 novembre 2011
Tu quoque Cups
Io amo cups. Adoro cups. Cups mi ha quasi salvato la vita in almeno un'occasione.
Per chiunque abbia conosciuto la stampa da unix prima di Cups, Cups è stata la benedizione. Ma non dev'essere il mese giusto per pretendere qualcosa anche dal più consolidato dei software.
Ho configurato una stampante. Non venticinque come mio solito, una. Ma, che ci crediate o no, non è la stampante di default se uno non glielo dice. E quindi, con una stampante definita (non zero, o duemila), lpr non sa dove stampare.
Avrei un messaggio da lanciare: la linea di comando esiste e c'è pure chi la usa. Vi prego, sacri signori sviluppatori di software, ricordatevene ogni tanto.
Per chiunque abbia conosciuto la stampa da unix prima di Cups, Cups è stata la benedizione. Ma non dev'essere il mese giusto per pretendere qualcosa anche dal più consolidato dei software.
Ho configurato una stampante. Non venticinque come mio solito, una. Ma, che ci crediate o no, non è la stampante di default se uno non glielo dice. E quindi, con una stampante definita (non zero, o duemila), lpr non sa dove stampare.
Avrei un messaggio da lanciare: la linea di comando esiste e c'è pure chi la usa. Vi prego, sacri signori sviluppatori di software, ricordatevene ogni tanto.
L'esasperazione
La mia relazione con Unix compie diciott'anni giusto in questi giorni, per cui non sono neanche proprio una novellina.
Si può dire che Linux l'ho visto nascere, mettere i primi passi, sbrodolare il tappeto e anche diventare abbastanza grande. Abbastanza, però, che poteva andare bene qualche anno fa, ma certo non più adesso.
Ho un portatile nuovo fiammante, e ancora (siamo nel 2011) devo impazzire per farlo funzionare come vorrei. L'audio è un mistero: le cuffie funzionano, il microfono no. Perché? Boh. Qualcosa che segnali un errore, un modulo che manchi? Ma figuriamoci: nell'era della userfriendliness presentare un log a un utente sembra diventato un insulto. Meglio ignorare il problema: qualsiasi mixer dice che va tutto, ma poi non va un accidente.
Fino a un paio di versioni di X fa, uno doveva farsi tutto a mano: morale, si impazziva un paio di giorni (la documentazione di X è... no, non arriva nemmeno a essere), poi la cosa funzionava per l'eternità. Finché appunto editare file (ma non era Unix-like?) è diventato un impiccio e le cose han cominciato a fare quello che volevano loro. Per una come me, che aveva una configurazione di X che faceva il caffè, è un incubo: se prima potevo avere ogni cosa che desideravo (che so, una tastiera custom o una risoluzione non ortodossa o -eresia- non avere un desktop) adesso è già tanto che parta.
E perché sto trascurando shell che spariscono, device che diventano un'altra roba tra un apt-get e l'altro, renumbering degli inode di lvm, robe cioè che l'utente normale non dovrebbe neanche sapere che esistono.
E vogliamo parlare di Firefox su x86_64 o su PowerPC?
L'ultima di oggi è inkscape: si rifiuta di salvare i file. Li crea, ma vuoti e poi protesta pure.
Insomma, comincio a essere veramente esasperata. Anche perché non ci sono poi molte alternative, MacOS è troppo rigido per le mie esigenze (ma funziona) e Windows, be', è già tanto che lo si possa classificare tra i sistemi operativi.
Si può dire che Linux l'ho visto nascere, mettere i primi passi, sbrodolare il tappeto e anche diventare abbastanza grande. Abbastanza, però, che poteva andare bene qualche anno fa, ma certo non più adesso.
Ho un portatile nuovo fiammante, e ancora (siamo nel 2011) devo impazzire per farlo funzionare come vorrei. L'audio è un mistero: le cuffie funzionano, il microfono no. Perché? Boh. Qualcosa che segnali un errore, un modulo che manchi? Ma figuriamoci: nell'era della userfriendliness presentare un log a un utente sembra diventato un insulto. Meglio ignorare il problema: qualsiasi mixer dice che va tutto, ma poi non va un accidente.
Fino a un paio di versioni di X fa, uno doveva farsi tutto a mano: morale, si impazziva un paio di giorni (la documentazione di X è... no, non arriva nemmeno a essere), poi la cosa funzionava per l'eternità. Finché appunto editare file (ma non era Unix-like?) è diventato un impiccio e le cose han cominciato a fare quello che volevano loro. Per una come me, che aveva una configurazione di X che faceva il caffè, è un incubo: se prima potevo avere ogni cosa che desideravo (che so, una tastiera custom o una risoluzione non ortodossa o -eresia- non avere un desktop) adesso è già tanto che parta.
E perché sto trascurando shell che spariscono, device che diventano un'altra roba tra un apt-get e l'altro, renumbering degli inode di lvm, robe cioè che l'utente normale non dovrebbe neanche sapere che esistono.
E vogliamo parlare di Firefox su x86_64 o su PowerPC?
L'ultima di oggi è inkscape: si rifiuta di salvare i file. Li crea, ma vuoti e poi protesta pure.
Insomma, comincio a essere veramente esasperata. Anche perché non ci sono poi molte alternative, MacOS è troppo rigido per le mie esigenze (ma funziona) e Windows, be', è già tanto che lo si possa classificare tra i sistemi operativi.
Firefox a 64bit per linux
Nell'ambito delle giornate passate a sbattere la testa sul muro, quella della ricerca di software è una delle più frustranti.
Soprattutto quando una pagina su due del sito di suddetto software non fa altro che dirti che devi aggiornare, che non hai l'ultima versione e devi assolutamente passare alle nuove feature. Cosa di cui, se sei lì e premi ogni tasto download che vedi, può anche essere che tu sia già convinto.
Comunque, per quanto uno provi a girare e girare, sembra che nel sito di Firefox non ci sia traccia di Firefox a 64bit. E no, malelingue, non lo sto cercando per Windows: lo cerco per Linux. Linux x86_64, mica PowerPC. Cioè lo cerco anche per Linux PowerPC, ma su quello proprio non ci spero molto. Toccherà compilarlo, adesso che so dove sono i sorgenti.
No, perché neanche ai sorgenti c'è un collegamento. Ma non si chiamava Open Source proprio perché... doveva essere in un'altra faglia spazio-dimensionale.
Comunque, alla fine mi sono risolta a chiedere:
https://support.mozilla.com/en-US/questions/890129
e un'anima pia si è mossa a compassione. Firefox a 64bit e (miracolo) i sorgenti si trovano qui:
http://releases.mozilla.org/pub/mozilla.org/firefox/releases/latest/
Soprattutto quando una pagina su due del sito di suddetto software non fa altro che dirti che devi aggiornare, che non hai l'ultima versione e devi assolutamente passare alle nuove feature. Cosa di cui, se sei lì e premi ogni tasto download che vedi, può anche essere che tu sia già convinto.
Comunque, per quanto uno provi a girare e girare, sembra che nel sito di Firefox non ci sia traccia di Firefox a 64bit. E no, malelingue, non lo sto cercando per Windows: lo cerco per Linux. Linux x86_64, mica PowerPC. Cioè lo cerco anche per Linux PowerPC, ma su quello proprio non ci spero molto. Toccherà compilarlo, adesso che so dove sono i sorgenti.
No, perché neanche ai sorgenti c'è un collegamento. Ma non si chiamava Open Source proprio perché... doveva essere in un'altra faglia spazio-dimensionale.
Comunque, alla fine mi sono risolta a chiedere:
https://support.mozilla.com/en-US/questions/890129
e un'anima pia si è mossa a compassione. Firefox a 64bit e (miracolo) i sorgenti si trovano qui:
http://releases.mozilla.org/pub/mozilla.org/firefox/releases/latest/
lunedì 7 novembre 2011
Le cose belle di questo lavoro
Impazzire mezza giornata perché un client OpenVPN non parte e viene resettato nonostante tutto vada a buon fine.
Il problema? Il server era un'ora indietro, quindi i certificati non erano ancora validi.
La cosa bella è il messaggio identificativo dell'errore:
ACK output sequence broken
Ma io dico, scrivere un messaggio d'errore umano?
Il problema? Il server era un'ora indietro, quindi i certificati non erano ancora validi.
La cosa bella è il messaggio identificativo dell'errore:
ACK output sequence broken
Ma io dico, scrivere un messaggio d'errore umano?
martedì 19 luglio 2011
Continue riallocazioni delle VM
Risolti i problemi di cui al post precedente, adesso il cluster con RedHat Cluster Suite e libvirt funziona alla grande.
Così alla grande che ogni due minuti le VM vengono riallocate, quelle che erano sull'host1 finiscono nell'host2 e viceversa. E mi raccomando, non migrate, riallocate.
Nei log questo simpatico errorino:
Criptico come poche volte, no? Come si risolve un problema del genere?
Provo a testare con rg_test:
Coerente, direi. Quindi c'è un errore nel check dello status. Lo script inciminato è /usr/share/cluster/vm.sh, che usa due funzioni per verificare lo status, virsh_status e do_status (ci sarebbe anche xm_status, ma in questo momento non ci interessa):
Guardatele quanto volete, l'errore non è in nessuna delle due funzioni: se la VM è viva, virsh_status ritorna 0 e do_status pure (era dura visto che non fa altro che richiamare virsh_status).
Dov'è il problema? Si verifica più avanti, per la precisione nel case che decide quale azione è stata richiamata:
Qual è il problema? Il valore di status_program (uno dei parametri di configurazione della risorsa vm) di default è 0. Non vuoto (cosa che gli farebbe passare indenne il test in rosso e quindi farebbe uscire vm.sh), ma 0.
A questo punto, salutati i santi che uno ha tirato giù dal Paradiso, la soluzione è aggiungere l'ennesimo parametro alla configurazione della VM in /etc/cluster/cluster.conf:
Così alla grande che ogni due minuti le VM vengono riallocate, quelle che erano sull'host1 finiscono nell'host2 e viceversa. E mi raccomando, non migrate, riallocate.
Nei log questo simpatico errorino:
Jul 19 17:25:21 rgmanager status on vm "prometeo" returned 127 (unspecified)
Jul 19 17:25:21 rgmanager No other nodes have seen vm:prometeoCriptico come poche volte, no? Come si risolve un problema del genere?
Provo a testare con rg_test:
# rg_test test /etc/cluster/cluster.conf status vm prometeo
...
Hypervisor URI: qemu:///system
Migration URI format: qemu+ssh://target_host/system
Virtual machine prometeo is running
Status check of prometeo failed
Coerente, direi. Quindi c'è un errore nel check dello status. Lo script inciminato è /usr/share/cluster/vm.sh, che usa due funzioni per verificare lo status, virsh_status e do_status (ci sarebbe anche xm_status, ma in questo momento non ci interessa):
virsh_status()
{
declare state pid
if [ "$OCF_RESKEY_hypervisor" = "xen" ]; then
service xend status &> /dev/null
if [ $? -ne 0 ]; then
echo indeterminate
return $OCF_APP_ERR_INDETERMINATE
fi
fi
#
# libvirtd is required when using virsh even though
# not specifically when also using Xen. This is because
# libvirtd is required for migration.
#
pid=$(pidof libvirtd)
if [ -z "$pid" ]; then
echo indeterminate
return $OCF_APP_ERR_INDETERMINATE
fi
state=$(virsh domstate $OCF_RESKEY_name)
echo $state
if [ "$state" = "running" ] || [ "$state" = "paused" ] ||
[ "$state" = "no state" ] ||
[ "$state" = "idle" ]; then
return 0
fi
if [ "$state" = "shut off" ]; then
return $OCF_NOT_RUNNING
fi
return $OCF_ERR_GENERIC
}
#
# Simple status check: Find the VM in the list of running
# VMs
#
do_status()
{
if [ "$OCF_RESKEY_use_virsh" = "1" ]; then
virsh_status
return $?
fi
xm_status
return $?
}Guardatele quanto volete, l'errore non è in nessuna delle due funzioni: se la VM è viva, virsh_status ritorna 0 e do_status pure (era dura visto che non fa altro che richiamare virsh_status).
Dov'è il problema? Si verifica più avanti, per la precisione nel case che decide quale azione è stata richiamata:
status|monitor)
validate_all || exit $OCF_ERR_ARGS
echo -n "Virtual machine $OCF_RESKEY_name is "
do_status
rv=$?
if [ $rv -ne 0 ]; then
exit $rv
fi
[ -z "$OCF_RESKEY_status_program" ] && exit 0
[ -z "$OCF_CHECK_LEVEL" ] && exit 0
[ $OCF_CHECK_LEVEL -lt 10 ] && exit 0
bash -c "$OCF_RESKEY_status_program" &> /dev/null
exit $?
;;
Qual è il problema? Il valore di status_program (uno dei parametri di configurazione della risorsa vm) di default è 0. Non vuoto (cosa che gli farebbe passare indenne il test in rosso e quindi farebbe uscire vm.sh), ma 0.
<parameter name="status_program" reconfig="1">
<longdesc lang="en">
Ordinarily, only the presence/health of a virtual machine
is checked. If specified, the status_program value is
executed during a depth 10 check. The intent of this
program is to ascertain the status of critical services
within a virtual machine.
</longdesc>
<shortdesc lang="en">
Additional status check program
</shortdesc>
<content type="string" default="0"/></parameter> A questo punto, salutati i santi che uno ha tirato giù dal Paradiso, la soluzione è aggiungere l'ennesimo parametro alla configurazione della VM in /etc/cluster/cluster.conf:
<vm autostart="0" domain="domainseminole" exclusive="0" migrate="live"
status_program="" name="prometeo"
xmlfile="/etc/libvirt/qemu/prometeo.xml" recovery="relocate"/>
(libvirt) Timed out during operation: cannot acquire state change lock
Bell'errore di stamattina, durante un tentativo di migrazione di una VM da un host all'altro.
Sembra che il problema sia un non meglio identificato bug di libvirt versione 0.8, e sembra che sparisca dalla 0.9:
https://bugzilla.redhat.com/show_bug.cgi?id=676205
Ma per chi come me è su una Debian Squeeze e non ha voglia di iniziare la trafila del backport dei pacchetti a neanche due mesi dall'aggiornamento, non è che sia di molta consolazione.
Comunque a quello che ho visto è un qualcosa che manda a funghi libvirt. Il sintomo principale non è tanto il messaggio del titolo, quanto che libvirt non dà più la situazione corretta. Per verificarlo basta vedere la dissonanza tra:
e
Dei due, è il secondo che ha ragione.
La soluzione è stata riavviare libvirt, ma se in uno dei due server la cosa è andata liscia con
Restano un processo nc (netcat, che si individua con ps -elf | grep libvirt), anche quello da killare, e due socket: /var/run/libvirt-sock e /var/run/libvirt-sock-ro, entrambi da cancellare.
A questo punto, riavviato libvirtd, la situazione è allineata e la migrazione funziona. Per la cronaca, via ssh con:
Sembra che il problema sia un non meglio identificato bug di libvirt versione 0.8, e sembra che sparisca dalla 0.9:
https://bugzilla.redhat.com/show_bug.cgi?id=676205
Ma per chi come me è su una Debian Squeeze e non ha voglia di iniziare la trafila del backport dei pacchetti a neanche due mesi dall'aggiornamento, non è che sia di molta consolazione.
Comunque a quello che ho visto è un qualcosa che manda a funghi libvirt. Il sintomo principale non è tanto il messaggio del titolo, quanto che libvirt non dà più la situazione corretta. Per verificarlo basta vedere la dissonanza tra:
# virsh --connect qemu:///system list --all
e
# ps -elf | grep qemu
Dei due, è il secondo che ha ragione.
La soluzione è stata riavviare libvirt, ma se in uno dei due server la cosa è andata liscia con
# /etc/init.d/libvirt-bin restartl'altro non voleva saperne di morire. Quindi:
# kill -9 <piddilibvirt>(sì, ok, andava bene anche pkill libvirt-bin).
Restano un processo nc (netcat, che si individua con ps -elf | grep libvirt), anche quello da killare, e due socket: /var/run/libvirt-sock e /var/run/libvirt-sock-ro, entrambi da cancellare.
A questo punto, riavviato libvirtd, la situazione è allineata e la migrazione funziona. Per la cronaca, via ssh con:
# virsh --connect qemu:///system migrate --live <vm> qemu+ssh://<altro>/system
Iscriviti a:
Post (Atom)