Linux e il RAID Software (Tips)

Questo script calcola i settaggi raccomandati per la creazione di filesystem ext2, etx3 e ext4 su device RAID.

RAID level
Number of physical disks
RAID chunk size (in KiB)
number of filesystem blocks (in KiB)

Utilizziamo per questi test:
a) un HP MiniServer dotato di due slot PCIe
b) due schede DVB-T linux compatibili

Per un cliente dotato di numerose postazioni utente e sedi distaccate abbiamo effettuato una serie di test funzionali al file di trasmettere in rete locale il maggior numero di canali del digitale terrestre.
La trasmissione avverrà senza ricompressione o alterazione del flusso e sfruttando i multicast offerti dalla loro infrastruttura.

E’ risaputo che la trasmissione dei flussi digitali avviene per blocchi di frequenze (Multiplexer) ed è quindi sufficiente sintonizzare una scheda su una di queste frequenze per ricevere, e potenzialmente trasmettere, tutti i flussi video e audio presenti in quello specifico multiplex.

Abbiamo valutato che con due schede DVB-T dotate di due sintonizzatori avremmo coperto un discreto range di canali senza saturare le risorse hardware a disposizione (CPU e banda).

Abbiamo scelto Ubuntu Server su piattaforma 64 con un setup minimo che comprenda i tools di sviluppo per linux.

Abbiamo acquistato due schede PCIe DBV-T/T2 T982 Dual Twin Tuner e le abbiamo installate nei due slot liberi del Microserver.

Abbiamo compilato i drivers della scheda video resi disponibili dal produttore insieme all’ultimo layer Multimediale del kernel di linux.

Collegate le quattro prese antenna e riavviato il Microserver le schede ci rendono quindi disponibili 4 diversi sintonizzatori.

Effettuiamo quindi una scansione dei canali:

scan /usr/share/dvb/dvb-t/ ... -u > channels.txt

Ottenendo:

CBBC Channel:505833330:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_3_4:QAM_16:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:620:621:4671
BBC Red Button:505833330:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_3_4:QAM_16:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:0:4479
BBC NEWS:505833330:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_3_4:QAM_16:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:640:641:4415
BBC THREE:505833330:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_3_4:QAM_16:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:0:0:4351
BBC TWO:505833330:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_3_4:QAM_16:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:610:611:4228
BBC ONE:505833330:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_3_4:QAM_16:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:600:601:4164
ITV1:481833330:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:520:521:8261
ITV2:481833330:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:530:531:8325
Channel 4:481833330:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_1_2:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE:560:561:8384

Dove:
Column A is the channel name.
Column B is the frequency (in Hz) of the multiplex this channel broadcasts on. The channels will be grouped together in the file by multiplex, so the frequency won’t change on every line.
Column D is the bandwidth. In the UK it will almost certainly be 8MHz.
Column G is the phase modulation type for the channel. I won’t try to explain it (you can delve into Wikipedia for that), suffice to say you’ll need to know it later. This should be the same for each channel that broadcasts on the same multiplex.
Column M (the last one) is the SID (service identifier) for the channel. This is very important as it is what dvblast uses to identify which channel to broadcast. Note that this is not the same as the EPG channel number, which isn’t shown in the file.

Multiplex 1

;BBC News
239.255.1.80:5004 1 4415
;BBC One
239.255.1.1:5004 1 4164
;BBC Red Button
239.255.1.105:5004 1 4479
;BBC Three
239.255.1.7:5004 1 4351
;BBC Two
239.255.1.2:5004 1 4228
;CBBC Channel
239.255.1.70:5004 1 4671

If your network switches support multicast, pick a multicast address. There’s a long and detailed document from the IANA about picking one, but unless you are already using multicast on your network then you really just need to pick something in the 239.255.000.000-239.255.255.255 range, which is identified by the IANA as the Site-Local Scope. Anything in this range should work. I used 239.255.1.1 as shown below.
If your network doesn’t support multicast, or you don’t want to use it for whatever reason, then enter the broadcast address for your local subnet.

dvblast -a 0 -c /root/M1.cfg -f 505833330 -m qam_16 -b 8 -e

-a n tells dvblast to use tuner number n for this multiplex. Obviously, you can’t use each tuner more than one at any one time. Numbering starts at 0, not 1, you idiots.
-c nameoffile.cfg tells dvblast to use the config file you just write. It doesn’t matter where you save it.
-f 000000000 is where you specify the frequency for this multiplex. Remember how you noted that down from the scan listing earlier? You better have done, because next you’ll need…
-m qam_x the modulation type for this multiplex. And then…
-b n the bandwidth for this multiplex.
-e Finally, -e tells dvblast to also stream the EPG data. You’ll see how to use this in VLC later, and it’s very exciting. No, really. Shut up, it’s exciting, damnit.

Dopo alcuni test abbiamo scelto di utilizzare singoli indirizzi IP per ogni canale invece di utilizzare lo stesso ip con porte diverse al fine di mantenere sotto controllo la banda utilizzata.
Infatti utilizzando lo stesso ip per tutti i canali si otteneva una ricezione da parte del client connesso di tutto il flusso dati emesso dal server e non del solo flusso relativo al canale desiderato.

Abbiamo poi implementato la trasmissione ciclica di filmati in diversi formati (MPEG4, H264, MPEG2) utilizzando VLC

vlc -vvv file:////path/to/file --sout '#rtp{access=udp,mux=ts,dst=224.3.1.100,port=1000,sap,group="Video",name="Test Multicast 1"}'

Dovrebbe anche essere possibile definire in ingresso un flusso dati (RadioWeb ad esempio) ed effettuarne il Multicast in rete, come dovrebbe essere possibile ricodificare il flusso audio/video all’interno dello stesso comando.
Funzioni che testeremo alla prima necessità.

Radio24 http://shoutcast.radio24.it:8000/

Riferimenti:
LINK
LINK
LINK
LINK
LINK
LINK

A.Gagliardi 2014

Mi è capitato di dover effettuare un backup di un volume LVM di una macchina guest in ambiente virtualizzato (kvm-proxmox) subito dopo un aggiornamento che ha reso la proxecura automatica (vzdump inefficace a seguito di questo errore:

INFO: starting new backup job: vzdump 103 --mode snapshot --storage BACKUP
INFO: Starting Backup of VM 103 (qemu)
INFO: status = running
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: skip unused drive 'local:103/vm-103-disk-1.raw' (not included into backup)
INFO: creating archive '/VM/BACKUP/dump/vzdump-qemu-103-2014_06_06-12_19_45.vma'
unable to connect to VM 103 socket - No such file or directory
ERROR: unable to connect to VM 103 socket - No such file or directory
INFO: aborting backup job
ERROR: Backup of VM 103 failed - unable to connect to VM 103 socket - No such file or directory
INFO: Backup job finished with errors
job errors

Prima di riavviare la macchina host, come consugliato dal forum, ho preferito effettuare un backup dei dati seguendo questa procedura.

Prima di tutto installo i pacchetti necessari:

#apt-get install ntfsprogs kpartx

Poi attivo uno snapshot per il volume NETLITE-vm–131–disk–1:

#lvcreate -L 1G -s -n 131-snap /dev/mapper/NETLITE-vm--131--disk--1

A questo punto ho un’immagine consistente del disco ma non è possibile usare tools come ntfsclone direttamente in quanto la partizione del disco NTFS non è presente in /dev/mapper, quindi la rendo visibile con:

#kpartx -a /dev/NETLITE/131-snap

Ed effettuo il backup:

#ntfsclone -s /dev/mapper/NETLITE-131--snap1 -o /mnt/pve/BACKUP_NFS/131-ntfs_clone.img
ntfsclone v2012.1.15AR.5 (libntfs-3g)
NTFS volume version: 3.1
Cluster size       : 4096 bytes
Current volume size: 34348736512 bytes (34349 MB)
Current device size: 34348737024 bytes (34349 MB)
Scanning volume ...
100.00 percent completed
Accounting clusters ...
Space in use       : 4282 MB (12.5%)
Saving NTFS to image ...
100.00 percent completed
Syncing ...

A questo punto ho una copia “ottimizzata” del filesystem e posso rimuovere puntamenti e snapshot:

#kpartx -d /dev/NETLITE/131-snap
#lvremove /dev/mapper/NETLITE-131--snap
Do you really want to remove and DISCARD active logical volume 131-snap? [y/n]: y
Logical volume "131-snap" successfully removed

A.Gagliardi 2014

Stando alla documentazione la procedura ideale di migrazione di un’installazione Windows verso Proxmox (KVM) prevede l’utilizzo di Clonezilla, purtroppo la ISO di Clonezilla non parte sulle VM già virtualizzate con XEN rendendo necessario un cambio di strategia.

Avviamo una VM m minimale su XEN utilizzando la ISO di sysrescuecd e configurando come disco uno snapshot della vm originale ove sia stato installato preventivamente il mergeide.reg

A questo punto copiamo il partizionamento.
Possiamo usare sfdisk con netcat.

Sulla VM di destinazione digitare:

nc -l -p 1234 | sfdisk /dev/sda
Sulla VM di origine digitare:
sfdisk -d /dev/xvda | nc XX.XX.XX.XX 1234
dove XX.XX.XX.XX è l’indirizzo ip della macchina destinazione.
A questo punto è buona norma riavviare la VM destinazione.
Per copiare il filesystem NTFS procediamo con ntfsclone.
Sulla VM di destinazione digitare:
nc -l -p 1234 | ntfsclone -r -O /dev/sda1 -
Sulla VM di origine digitare:
ntfsclone -s -o - /dev/vxda1 | nc XX.XX.XX.XX 1234
La procedura non esce al termine automaticamente, resta come appesa, solitamente basta attendere un po’ affinchè si svuoti il buffer di copia, con un bmon si nota chiaramente quando la procedura smette di usare la rete. A quel punto si può interrompere con ctrl-c.

Può essere necessario ridimensionare il filesystem sfruttando il maggior spazio concesso dal nuovo hardware quindi qualora il disco della VMsia più grande di quello originario si può procedere così:
Ridimensionare la partizione numero 1 alla massima possibile con sfdisk:

echo ",+," | sfdisk -N1 /dev/sda
Ridimensionamento del filesystem tramite ntfsresize:
ntfsresize -x /dev/sda1
oppure
ntfsresize -s 100G /dev/sda1

Al termine il Windows tendenzialmente non parte.
Si utilizza quindi il CD originale per partire in modalità rescue e si digitano i comandi fixboot e fixmbr.
A questo punto si riavvia e Windows dovrebbe partire.
Nel caso si sia ridimensionata la partizione Windows effettuerà un controllo approfondito del filesystem.
Prima di installare gli eventuali drivers virtio è meglio disinstallare servizi relativi a Xen, VMWARE, etc che potrebbero entrare in conflitto con il nuovo sistema di virtualizzazione.

WordPress Tips&Tricks

Aggiungere in wp-config.php le seguenti direttive per velocizzare l’installazione e l’aggiornamento del sito eliminando la necessità di transitare attraverso l’FTP e per permette la gestione di un sito multidominio.

Nel caso si desideri attivare il Multisite occorre prima di tutto disattivare tutti i plugin.

/* Multisite */
define('WP_ALLOW_MULTISITE', true);
/* Direct install/update */
define('FS_METHOD', 'direct');

Nel menù Strumenti – Configurazione di Rete è necessario scegliere se la rete di siti dovrà essere pubblicata come sottodomini o sottocartelle del dominio principale. Questa decisione è squisitamente personale, ma non sarà più possibile modificarla in futuro.
Nel caso si optasse per i sottodomini, consiglio di aggiungere una wildcard DNS nella zona DNS del dominio per fare in modo che qualsiasi sottodominio si andrà a creare sia già immediatamente accessibile a livello DNS e non si debba editare la zona ogni volta.
Vedrete sullo schermo la richiesta di inserire nei files wp-config.php e .htaccess del codice. Le stringhe sono personalizzate per ogni installazione.

Ora al prossimo login comparirà il menù “I miei siti” da cui amministrare tutta la rete di siti.
Riabilitare tutti i plugin necessari.

Speedtest Internet da console Linux

Test di velocità link Internet xDSL da console Linux

Spesso è utile valutare la velocità e la latenza di un link ad internet di un server Linux al quale non si ha accesso diretto tramite un desktop remoto. Tramite questo tool è possibile utilizzare l’infrastruttura geografica di Speedtest.net ed ottenere una valutazione oggettivamente valida.

# wget https://github.com/sivel/speedtest-cli/raw/master/speedtest.py --no-check-certificate
# chmod a+rx speedtest_cli.py
# ./speedtest_cli.py

Lo script in python si collega al nodo più prossimo ed effettua un test di upload, uno di download e riporta anche la latenza in millisecondi.

root@farm ~ # ./speedtest_cli.py
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Hetzner Online AG (XX.XX.XX.XX)...
Selecting best server based on ping...
Hosted by Vodafone DE (Frankfurt) [100.73 km]: 6.358 ms
Testing download speed........................................
Download: 87.87 Mbit/s Testing upload speed..................................................
Upload: 66.08 Mbit/s

E’ possibile condividere il test aggiungendo –share al comando e si ottiene questo:

Speedtest CLI linux

Andrea Gagliardi – netlite.it

PROXMOX tips venet e /usr/portage

Tips per la personalizzazione di contenitori (CT) PROXMOX

Mount automatico di /usr/portage

Utilizzando Gentoo come distribuzione Linux all’interno dei contenitori OpenVZ può essere utile condividere tra i contenitori la /usr/portage/ in modo da poter sincronizzarla tramite la macchina host e ridurre drasticamente l’occupazione di spazio disco.
Per ottenere questo è possibile far svolgere queste operazioni ad ogni boot della VM creando o modificando tramite shell ed editor di testo lo script {VMID}.mount nella stessa directory dove è presente il file {VMID}.conf.
Spostiamoci quindi nella directory:

 cd /etc/pve/nodes/$(hostname -s)/openvz/ 

E creiamo (o modifichiamo) il file:

 vim {VMID}.mount 

Inserendo queste righe di codice:

#!/bin/bash
. /etc/vz/vz.conf
. ${VE_CONFFILE}
SRC=/var/lib/vz/portage
DST=/usr/portage
if [ ! -e ${VE_ROOT}${DST} ]; then
        mkdir -p ${VE_ROOT}${DST};
fi
mount -n -t simfs ${SRC} ${VE_ROOT}${DST} -o ${SRC}

Lo script è molto comprensibile e non contiene alcun riferimento alla singola macchina virtuale per cui è possibile copiarlo per ogni macchina Gentoo ospitata.
Al termine è necessario cambiare i diritti di esecuzione:

 chmod 700 {VMID}.mount 

Nel caso, ad esempio, di volere mantenere lo storage ed il sistema su supporto diversi per questioni di spazio o performance può essere utile aggiungere allo script il mount anche di questi mountpoint:

#!/bin/bash
. /etc/vz/vz.conf
. ${VE_CONFFILE}
SRC=/var/lib/vz/portage
DST=/usr/portage
if [ ! -e ${VE_ROOT}${DST} ]; then
        mkdir -p ${VE_ROOT}${DST};
fi
mount -n -t simfs ${SRC} ${VE_ROOT}${DST} -o ${SRC}
SRC=/storage/${VEID}/home
DST=/home
if [ ! -e ${VE_ROOT}${DST} ]; then
       mkdir -p ${VE_ROOT}${DST};
fi
mount -n -t simfs ${SRC} ${VE_ROOT}${DST} -o ${SRC}

Qusto permette di avere la home di ogni contenitore su di uno storage separato.
Utilizzo questo sistema, ad esempio, per avere lo storage su di un filesystem ZFS con compressione realtime attiva.

Utilizzo delle interfaccie veth al posto di venet

Può essere necessario utilizzare caratteristiche di rete che le interfaccie venet non forniscono (ad esempio ARP) QUI.
Seguendo quindi la guida QUI, dopo aver configurato tramite l’interfaccia web di PROXMOX la nuova scheda di rete questa risulta correttamente aggiunta al bridge di rete ma la VM può risultare isolata.

#!/bin/bash
. /etc/vz/vz.conf
. ${VE_CONFFILE}
SRC=/var/lib/vz/portage
DST=/usr/portage
if [ ! -e ${VE_ROOT}${DST} ]; then
        mkdir -p ${VE_ROOT}${DST};
fi
mount -n -t simfs ${SRC} ${VE_ROOT}${DST} -o ${SRC}
SRC=/storage/${VEID}/home
DST=/home
if [ ! -e ${VE_ROOT}${DST} ]; then
       mkdir -p ${VE_ROOT}${DST};
fi
mount -n -t simfs ${SRC} ${VE_ROOT}${DST} -o ${SRC}
IP="XX.XX.XX.XX"
/sbin/ip route del $IP dev vmbr0 2>/dev/null
/sbin/ip route add $IP dev vmbr0 2>/dev/null

Alla fine dello script si nota la rimozione e l’aggiunta di una rotta verso il bridge che ospita la VM con l’indirizzo XX.XX.XX.XX.
Lo script purtroppo contiene una configurazione specifica per cui è necessario modificarlo per utilizzarlo per altre VM.

Esecuzione comandi all’interno di un Contenitore (CT) OpenVZ

Per eseguire comandi in un contenitore OpenVZ è possibile utilizzare il comando:

# vzctl exec 103 /etc/init.d/sshd status
openssh-daemon is stopped
# vzctl exec 103 /etc/init.d/sshd start
Starting sshd: [  OK  ]

Andrea Gagliardi – netlite.it

Emerge spesso la necessità di clonare una macchina Windows esistente su hardware fisico, per utilizzarla poi come macchina virtuale su Debian PROXMOX.

Qui di seguito indicherò la procedura da noi adottata per clonare un Windows 2003 Server on the fly utilizzando CLONEZILLA.

On the fly intendo senza alcuna necessità di creare immagini su dischi esterni, ma direttamente sul disco remoto virtuale precedentemente configurato su PROXMOX.

Operazioni Preliminari:

  1.  Installare sulla macchina windows esistente mergeide.reg , permette di abilitare i driver standard IDE su macchine del tipo winxp/win2003, il file è scaricabile dal seguente link mergeide.
  2. Scaricare la iso di CloneZilla e realizzare un cdrom/DVD.
  3. Preparare utilizzando l’interfaccia PROXMOX una macchina VM definita TARGET definendo un disco di dimensione >= al disco origine presente sul server Windows 2003 (con almeno 1Gb in eccesso rispetto all’originale).
  4. Assicurarsi di aver caricato sullo Storage PROXMOX la iso virtio-win.iso per l’installazione dei driver necessari alla macchina Windows una volta clonata (rete, disco) e la iso precedentemente scaricata di CloneZilla.

A questo punto è possibile procedere come descritto di seguito.

Inserire il cd di clonezilla nel lettore della macchina fisica da clonare che chiameremo SOURCE. Riavviare la macchina e se server configurare il bios per fare il boot da lettore cdrom.

Da interfaccia CloneZilla presente sulla macchina SOURCE selezionare l’opzione “disk_to_remote_disk” (copia disco da rete).

018

 

Procedere oltre e scegliere

se presente di configurare la rete tramite dhcp o manualmente (static). Nel nostro caso essendo Windows 2003 un dhcp server abbiamo scelto static inserendo l’ip a mano.

019

Passo successivo selezionare il disco da copiare come SOURCE.

 

0201

A questo punto dopo alcuni altri passi di semplice comprensione la macchina source sarà pronta

per il trasferimento del disco via rete alla macchina TARGET.

022

Macchina TARGET (precedentemente configurata tramite interfaccia PROXMOX)

Selezionare tramite interfaccia PROXMOX il boot della macchina TARGET da iso di clonezilla. Premere start e iniziare la configurazione da interfaccia Clonezilla

Entrare in modalità shell di ConeZilla.

021

Eseguire i seguenti comandi nell’ordine indicato :

  1. sudo su
  2. fdisk /dev/sda (assicurarsi che il disco della macchina TARGET sia sda o simile) , uscire da fdisk digitando il comando ‘w’.

Sempre da shell di CloneZilla Eseguire

  1. ocs-live-netcfg
  2. ocs-onthefly -s IPSOURCE -t sda (IPSOURCE = indirizzo ip macchina source)

A questo punto inizierà la copia del disco.

Apparirà una finestra che indica il tempo stimato e le partizioni da copiare (copiare anche la partizione di boot di windows).

024

Una volta finito il processo, basterà toglire da proxmox il boot da iso di clonezilla ed avviare la macchina clonata con Start.

Una volta avviata sarà, come indicato nei preliminari, necessario installare i driver di rete virt0 o intel e1000 (consigliata in questo ultimo caso l’installazione direttamente

usando i driver scaricati dal sito Intel).

Sarà necessario riattivare la licenza di Windows 2003 server e inserire o verificare i parametri di rete della macchina TARGET.

La macchina source potrà essere spenta dopo aver verificato il corretto funzionamento della macchina TARGET.

PROXMOX calcolo cpu units

Con Proxmox è possibile assegnare tempo macchina garantito alle VM tramite l’assegnazione di CPU UNITS.

Tramite il comando

# vzcpucheck
Current CPU utilization: 4000
Power of the node: 3191600

E’ possibile stabilire la potenza del nodo.

Quindi per assegnare l’1% della potenza ad una VM occorre fare questo calcolo:

3191600 / 100 * 1 = 31916

Allo stesso modo per assegnare il 5% della potenza ad una VM occorre fare questo calcolo:

3191600 / 100 * 5 = 159580

Da quello che abbiamo potuto verificare per i contenitori openvz la modifica è istantanea per le vm KVM occorre spegnerle e riaccenderle.

andrea gagliardi – netlite.it

Installando un sistema Linux Server, tipo Proxmox (Debian), è possibile monitorare lo stato di funzionamento del controller RAID PERC H700 alias LSI MegaRAID.

Seguendo le indicazioni sul sito hwraid.le-vert.net

E’ possibile aggiungere in /etc/apt/sources.list il repository

deb http://hwraid.le-vert.net/debian wheezy main

ed aggiungere la chiave:

wget -O - http://hwraid.le-vert.net/debian/hwraid.le-vert.net.gpg.key | apt-key add

ad un successivo apt-get update verranno resi disponibili alcuni tools

apt-get install megaclisas-status megacli

è possibile invocare direttamente megaclisas-status

# megaclisas-status
-- Controller informations --
-- ID | Model
c0 | PERC H700 Integrated
-- Arrays informations --
-- ID | Type | Size | Status | InProgress
c0u0 | RAID10 | 2454G | Optimal | None
-- Disks informations
-- ID | Model | Status
c0u0p0 | SEAGATE ST900MM0006 LS08S0N08XHB | Online, Spun Up
c0u0p1 | SEAGATE ST900MM0006 LS08S0N08896 | Online, Spun Up
c0u0p0 | SEAGATE ST900MM0006 LS08S0N08X1K | Online, Spun Up
c0u0p1 | SEAGATE ST900MM0006 LS08S0N08875 | Online, Spun Up
c0u0p0 | SEAGATE ST900MM0006 LS08S0N07EBR | Online, Spun Up
c0u0p1 | SEAGATE ST900MM0006 LS08S0N084P0 | Online, Spun Up

oppure fare affidamento sul demone già attivo dopo l’installazione e far rilevare la presenza in /var/run del file megaclisas-statusd.status

Andrea – netlite.it