Archivio della categoria Scripting e Sysadmin
OpenVZ + broadcast con l’uso delle VETH
Inviato da Giuseppe Mena il Scripting e Sysadmin, Simple Tips il 23 giugno 2009
La necessita’
Avere piu’ server virtuali (container o CT) con servizi di server multimediali (Logitech Squeezecenter e Upnp) che condividono la stessa partizione dati e siano pero’ piu’ flessibili da gestire e eventualmente replicare/duplicare.
L’idea
Sfruttare le potenzialita’ e le prestazioni di OpenVZ configurando la macchina host (container0 o CT0) che gestisce i dischi in raid5 e ne condivide il contenuto via NFS ai vari CT.
Con NFS, unito alla ottima ed efficiente gestione delle risorse da parte di OpenVZ, le prestazioni di accesso ai dati multimediali (musica, video e foto) sono paragonabili a quelle di un’installazione standard con accesso diretto ai dischi.
OpenVZ consente, semplicemente copiando la directory del CT desiderato e modificando un paio di files di configurazione, di replicare e duplicare facilmente server virtuali e di avere quindi una flessibilita’ notevole nei servizi offerti in rete.
Il problema
OpenVZ utilizza di default delle interfacce di rete (VENET, ) virtuali che tramite un routing interno collegano le ETH dei vari CT alla rete lan fisica garantendo l’isolamento dei vari CT.
Il problema e’ che questa gestione delle interfacce virtuali impedisce a servizi quali l’upnp di annunciarsi in rete (tramite broadcast).
Ho quindi valutato di testare la configurazione alternativa di interfacce di rete virtuali offerta da OpenVZ, conosciute anche come VETH, che danno la possibilita’ di unire al routing anche bridging riuscendo quindi ad esempio a far “passare” i broadcast dei vari CT.
Un altro vantaggio delle VETH e’ la possibilita’ di assegnare a ogni interfaccia un suo MAC address univoco.
Per ora mi limito a rendere disponibile lo schema definitivo della configurazione realizzata, in attesa di terminare la stesura dell’howto.
Reboot automatico in caso di KERNEL PANIC
Inviato da Giuseppe Mena il Scripting e Sysadmin, Simple Tips il 19 maggio 2009
Per fare in modo che un server GNU/Linux si riavvii automaticamente in caso di kernel panic e’ sufficiente editare il file /etc/sysctl.conf aggiungendo questa riga:
kernel.panic = #n#
in cui al posto di #n# va un numero indicante i secondi prima del riavvio automatico.
Fatto questo per rendere attive le modifiche a /etc/sysctl.conf e’ sufficiente un:
sysctl -p
Questo e’ solo un esempio di tweak possibile tramite sysctl…
Backup automatici su USB tramite UDEV
Inviato da Giuseppe Mena il Scripting e Sysadmin il 9 maggio 2009
Utilizzando le rules di UDEV e’ possibile configurare in modo semplice, il sistema in modo tale che all’inserimento di uno specifico device USB (flash o hard disk) esegua uno script predefinito.
Due parole su Udev
Nel momento in cui una qualsiasi periferica HW genera un evento (es. collegamento/scollegamento periferica, cambio di stato, ecc…) il gestore del bus a cui la periferica e’ collegata genera un interrupt a cui fa seguito la risposta del kernel che recupera informazioni sull’evento e dettagli sulla periferica che rende quindi disponibili al sistema tramite Sys-fs.
A questo punto entra in gioco Udev che e’ in grado di analizzare questi eventi hw e, quando configurato per farlo (tramite gli script in /etc/udev/rules.d/), di agire di conseguenza generando azioni software (quali ad esempio il caricamento dei driver corretti, la configurazione dei relativi files di sistema, fino al lancio di applicazioni esterne specifiche).
Come Udev puo’ aiutare chiunque non sia uno sviluppatore del kernel?
Nel mio caso il cliente voleva poter sincronizzare alcuni dati salvati sul proprio fileserver linux su un hard disk usb, il tutto senza aver alcun monitor/tastiera collegato alla macchina server e senza voler sapere nulla di comandi linux o collegamenti ssh, insomma un sistema “for dummies”.
Tramite udevmonitor e’ possibile vedere le informazioni intercettate da udev in seguito a eventi hardware.
Ad esempio lanciando udevmonitor con l’opzione “–env” (che consente di visualizzare tutte le informazioni di udev in modo esteso) e quindi collegando un device usb verranno stampate a video molte informazioni tra cui, verso la fine, queste:
gordon ~ # udevmonitor --env
udevmonitor prints the received event from the kernel [UEVENT]
and the event which udev sends out after rule processing [UDEV]
UDEV [1241867355.712496] add /devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1:1.0/host8/target8:0:0/8:0:0:0/block/sda/sda1 (block)
UDEV_LOG=3
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1:1.0/host8/target8:0:0/8:0:0:0/block/sda/sda1
SUBSYSTEM=block
MAJOR=8
MINOR=1
DEVTYPE=partition
SEQNUM=3717
UDEVD_EVENT=1
ID_VENDOR=USB2.0
ID_MODEL=Mobile_Disk
ID_REVISION=1.00
ID_SERIAL=USB2.0_Mobile_Disk_b506f9b3e4b2e5-0:0
ID_SERIAL_SHORT=b506f9b3e4b2e5
ID_TYPE=disk
ID_INSTANCE=0:0
ID_BUS=usb
ID_PATH=pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0
ID_FS_USAGE=filesystem
ID_FS_TYPE=vfat
ID_FS_VERSION=FAT16
ID_FS_UUID=E2C6-1A06
ID_FS_UUID_ENC=E2C6-1A06
ID_FS_LABEL=MELY
ID_FS_LABEL_ENC=MELY
ID_FS_LABEL_SAFE=MELY
DEVNAME=/dev/sda1
DEVLINKS=/dev/disk/by-id/usb-USB2.0_Mobile_Disk_b506f9b3e4b2e5-0:0-part1 /dev/disk/by-path/pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0-part1 /dev/disk/by-uuid/E2C6-1A06 /dev/disk/by-label/MELY /dev/block/8:1
Come si puo’ vedere UDEV ci dice che e’ stato collegato un dispositivo USB2, che il kernel l’ha associato a /dev/sda
Nel caso ad esempio del collegamento di un hard disk usb compariranno informazioni relative al device che il kernel ha associato al disco (es. sda), il numero di partizioni presenti, il modello del disco e del controller, il nome (label) dato al disco.
Tutte queste informazioni possono essere utilizzate nelle rules di udev.
E’ quindi sufficiente preparare l’hard disk usb impostando come label, ad esempio, “BACKUP_1″ e creare un nuovo file in /etc/udev/rules.d come ad esempio “70-persistent-backupusb.rules” contenente queste 3 righe:
ACTION!="add", GOTO="persistent_storage_end"
SUBSYSTEM=="block", KERNEL=="sd[a-z][1-9]", ENV{ID_FS_LABEL}=="BACKUP_1", RUN+="/usr/bin/backup_usb %k &"
LABEL="persistent_storage_end"
Con queste informazioni ogni volta che udev rilevera’ il collegamento di un dispositivo di tipo “block” associato a un device di tipo “/dev/sd” (ad es. /dev/sda1) con etichetta di volume “BACKUP_1″ eseguira’ lo script “/usr/bin/backup” passandogli come parametro “%k” ossia il valore del campo KERNEL (ossia il nome del device associato al dispositivo).
Banalmente lo script “/usr/bin/backup” si occupera’ di montare il device, eseguire il backup, smontare il device ed eventualmente segnalare, ad esempio tramite l’invio di una e-mail, l’esito dell’operazione.
Questo e’ solo un esempio molto semplice e banale dell’utilizzo delle rules di Udev, penso si possano pero’ apprezzare le enormi potenzialita’ di questo strumento (abbinate a della buona documentazione reperibile online) nel campo dell’automatizzazione di operazioni di sistema (anche le piu’ disparate) triggerate da eventi hardware.