BackupPC – backup dell’intero pool su nastro o file

Supponiamo che vogliate migrare una installazione di BackupPc su un’altra macchina o che vogliate fare un backup “dei backup”. Di seguito vi propongo una soluzione molto semplice che il comando dump per copiare il contenuto del pool su nastro o su file.
Perché il codice funzioni correttamente è necessario che il pool sia su un filesystem diverso da quello usato per montare la root “/”. A mio avviso, usare un mountpoint per il pool è utile non solo per il backup ma consente di ripristinare il sistema operativo senza dover spostare i dati.
supponiamo quindi che l’installazione di BackupPc sia fatta usando i percorsi di default ma utilizziamo un link che punti su un mountpoint fuori dal filesystem di root. Supponiamo di avere i seguenti mount point:

[root@morzello ~]# mount
/dev/mapper/VolGroup01-LogVol00 on / type ext3 (rw)
/dev/mapper/vgData-Data on /mnt/data type ext3 (rw)
//server-esterno/repository on /mnt/repository type cifs (rw,mand)
...

la prima cosa da fare è quella di portare l’installazione di BackupPC sotto /mnt/data creando un link simbolico su /var/lib/backuppc:

ln -s /var/lib/backuppc /mnt/data/backuppc
ls -l /var/lib/backuppc
lrwxrwxrwx  1 root  root 18 May 13  2010 backuppc -> /mnt/data/backuppc

Consiglio di creare il link prima di procedere con l’installazione altrimenti dovrete spostare i dati da un filesystem all’altro.

Lo script
Lo script non fa altro che spegnere i servizi che utilizzano il filesystem prima di procedere con il dump della partizione. Nel nostro esempio viene preso in considerazione solo BackupPc ma se ci fossero altri servizi bisogna gestirli correttamente altrimenti il comando mount usato per smontare la partizione fallirebbe:

#!/bin/bash
# Esegue il backup di /mnt/data su nastro.
# Da rirpistinare con restore rf /dev/nst0 nella
# root della partizione 

#MYDIR=$(pwd)
#cd /

echo "Controllo esecuzione backup"
ps U 'backuppc' | grep -e 'BackupPC_' && \
	echo "Impossibile proseguire. Backup in corso." && \
	exit 0

echo "Stop ai servizi che accedono alla partizione"
/sbin/service backuppc stop
/sbin/service backuppc_httpd stop

echo "Smontaggio della partizione"
/bin/umount /mnt/data

echo "Controllo con fsck"
/sbin/fsck.ext3 /dev/vgData/Data

echo "dump della partizione su nastro"

#backup su nastro:
/sbin/dump -0 -a -f /dev/nst0 -b64 -j9 /dev/vgData/Data

#backup su file
#/sbin/dump -0 -a -f /mnt/repository/backuppc-dump.bz -b64 -j9 /dev/vgData/Data

echo "Montaggio della partizione"
/bin/mount /mnt/data

echo "Riavvio dei servizi che accedono alla partizione"
/sbin/service backuppc start
/sbin/service backuppc_httpd start

#cd $MYDIR
echo "Fatto."

Prima di eseguire il dump lo script controlla che non vi siano backup in esecuzione da parte dell’utente backuppc. Anche in questo caso se l’utente fosse diverso è necessario modificare il codice.
Il servizio backuppc_httpd è una istanza di apache modificata proprio per backuppc; per maggiori informazioni visitare questo link:

http://www.morzello.com/index.php/installare-backuppc-su-centos/

Se invece utilizzate l’istanza di default potete sostituire il servizio con httpd.
Per quanto riguarda la destinazione, se non aveste a disposizione una unità a nastro potete cambiare il percorso di destinazione ovunque vogliate. Prendendo come esempio il comando mount indicato in precedenza potremmo ad esempio creare un file sotto /mnt/repository

Alla prossima.

Data remanence con dd e shred, un modo economico e sicuro per cancellare i dati su disco.

Qualche giorno fa un amico mi chiese un parere su alcuni programmi per la cancellazione sicura dei dati perchè aveva un portatile che avrebbe dovuto restituire da li a breve.  Mi chiese anche se la formattazione a basso livello era una opzione oppure no.

Intanto c’è da rilevare che la richiesta è del tutto legittima dal momento che la semplice cancellazione del dato all’interno del sistema operativo è il più delle volte insufficiente. In effetti esiste un problema legato alla persistenza dei dati dopo la cancellazione (Data Remanence). Per maggiori informazioni visitare la wikipedia:

http://en.wikipedia.org/wiki/Data_remanence

Esistono tanti programmi, alcuni anche molto costosi, in grado di riscrivere diverse volte dati arbritari sul disco al fine di eliminare la persistenza dei dati (Overwriting) ma io ho pensato che ancora una volta il comando dd poteva essere utile, veloce e sopratutto gratuito.

Per maggiori informazioni sull’uso di dd potete visitare l’articolo:

http://www.morzello.com/?p=28

L’idea di base è quella di utilizzare dd per sovrascrivere il contenuto dell’intero disco eseguendo il comando diverse volte utilizzando /dev/urandom come input.

/dev/urandom sui sistemi unix-like è un file particolare in grado di generare un flusso binario pseudo casuale che viene utilizzato a vari scopi come ad esempio la crittografia.

A questo punto, per cancellare completamente il contenuto di un disco, potremmo impartire il comando:

dd if=/dev/urandom of=/dev/sdX

dove sdX è il disco in questione.
Ovviamente la soluzione proposta presuppone la cancellazione dei dati sull’intero disco e non consente la sovrascittura in caso di singoli file come ad esempio è possibile fare tramite il comando shred ma è comunque un’idea come un’altra di portare a termine il lavoro a basso costo.

Usare shred
shred invece nasce proprio per sovrascrivere e nascondere o cancellare il contenuto di file. Ovviamente, dato che /dev/sdX è anche esso un file, è possibile ottenere un ottimo risultato impartendo il comando:

shred -n N -zv /dev/sdX

dove N è il numero di scritture da fare mentre -z provvede a fare l’ultima scritura con una serie di zeri al fine di nascondere l’esecuzione del programma (come se fosse stato impartito un semplice dd if=/dev/zero of=/dev/sdX).

Alla prossima.

CentOS: accedere alle partizioni NTFS

Capita a volte di dover accedere a partizioni Windows (NTFS) da Linux ma non tutte le distribuzioni supportano nativamente la lettura/scrittura di queste partizioni. CentOS in particolare non ha il supporto a queste partizioni ne dentro il kernel ne dentro il repository ufficiale.

E’ comunque possibile accedere alle partizioni di Windows mediante il pacchetto fuse disponibile sul repository di rpmforge. Per maggiori informazioni su come aggiungere ed abilitare un repository aggiuntivo per CentOS, potete consultare questo link:

http://www.morzello.com/dblog/articolo.asp?articolo=68

Nell’esempio che segue, vedremo come montare una partizione ntfs in una cartella di linux come ad esempio /mnt/usb.

Per prima cosa, verifichiamo la tavola delle partizioni del disco. Nel nostro caso si tratta di un disco usb esterno:

fdisk -l /dev/sdb

Disk /dev/sdb: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1       15298   122881153+   6  FAT16
/dev/sdb2           15299       22947    61440592+   7  HPFS/NTFS

Nel caso volessimo montare la seconda partizione senza supporto, riceveremmo un messaggio simile a questo:

mount /dev/sdb2 /mnt/usb
mount: unknown filesystem type 'ntfs'

Per risolvere il problema procediamo dunque all’installazione dei pacchetti necessari dal repository di rpmforge:

yum install fuse fuse-ntfs-3g
Loaded plugins: fastestmirror, priorities
Determining fastest mirrors
 * addons: ftp.uni-bayreuth.de
 * base: ftp.uni-bayreuth.de
 * extras: ftp.uni-bayreuth.de
 * rpmforge: apt.sw.be
 * updates: ftp.hosteurope.de
addons                                                   |  951 B     00:00
base                                                     | 2.1 kB     00:00
extras                                                   | 2.1 kB     00:00
rpmforge                                                 | 1.1 kB     00:00
updates                                                  | 1.9 kB     00:00
updates/primary_db                                       | 554 kB     00:00
478 packages excluded due to repository priority protections
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package fuse.i386 0:2.7.4-8.el5 set to be updated
---> Package fuse-ntfs-3g.i386 0:2009.11.14-1.el5.rf set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package            Arch       Version                     Repository      Size
================================================================================
Installing:
 fuse               i386       2.7.4-8.el5                 base            83 k
 fuse-ntfs-3g       i386       2009.11.14-1.el5.rf         rpmforge       552 k

Transaction Summary
================================================================================
Install      2 Package(s)
Update       0 Package(s)
Remove       0 Package(s)

Total download size: 635 k
Is this ok [y/N]: y
Downloading Packages:
(1/2): fuse-2.7.4-8.el5.i386.rpm                              |  83 kB     00:00
(2/2): fuse-ntfs-3g-2009.11.14-1.el5.rf.i386.rpm              | 552 kB     00:00
--------------------------------------------------------------------------------
Total                                                352 kB/s | 635 kB     00:01
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing     : fuse                                                      1/2
  Installing     : fuse-ntfs-3g                                              2/2

Installed:
  fuse.i386 0:2.7.4-8.el5
  fuse-ntfs-3g.i386 0:2009.11.14-1.el5.rf

Complete!

Ora è possibile ripetere il comando mount come mostrato in precedenza.

Alla prossima.

Resize di partizioni LVM

Mi è capitato di recente, di dover migrare un piccolo server Linux su un server ESXi 4. La memoria ram della versione virtualizzata è stata espansa di 512 MB rendendo necessario una espansione della partizione di swap. Come accade per diverse distribuzioni che utilizzano LVM per gestire il file system (CentOS, Fedora,…) per variare le dimensioni di una partizione (resizing) bisogna tenere in considerazione alcuni fattori critici come ad esempio il rischio di perdere dati importanti presenti sul disco.

L’esempio che segue mostra come ridurre la partizione LVM destinata al sistema operativo al fine di estenderne quella di swap. I comandi elencati però possono essere utilizzati ovunque sia necessario fare il resize di partizioni LVM.

Individuare e gestire le partizioni LVM
Nel caso in cui il sistema operativo sia stato installato come consigliato dalla distribuzione, allora i volumi logici presenti sul disco conterranno l’intera distribuzione ad esclusione della partizione di boot. Questo vuol dire che per accedere al disco per fare le opportune modifiche è necessario accedervi dall’esterno. Per fare questo è sufficiente fare il boot da chiavetta usb o da distribuzione live.

A me piace tanto Fedora, di conseguenza, per questo esempio, prenderò in considerazione il cd live di Fedora, disponibile sul sito:

http://fedoraproject.org/get-fedora

Una volta fatto il boot da cdrom avremo la possibilità di verificare l’esistenza di partizioni LVM sul disco fisso. Basta aprire una finestra terminale ed impartire i seguenti comandi con credenziali di root:

[root@localhost liveuser]# su
[root@localhost liveuser]# pvscan
  PV /dev/sda2   VG VolGroup01   lvm2 [79.88 GB / 0    free]
  Total: 1 [79.88 GB] / in use: 1 [79.88 GB] / in no VG: 0 [0   ]

[root@localhost liveuser]# vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "VolGroup01" using metadata type lvm2

[root@localhost liveuser]# lvscan
  ACTIVE            '/dev/VolGroup01/LogVol00' [78.88 GB] inherit
  ACTIVE            '/dev/VolGroup01/LogVol01' [1.00 GB] inherit

Si tratta di un disco da 80 GB  (sda) con due partizioni fisiche: sda1 per il boot ed sda2 per LVM.
Dai comandi impartiti si evince che il dispositivo /dev/sda2 contiene un gruppo logico (VolGroup01) con due partizioni (LogVol00 per il sistema operativo e LogVol01 per lo swap).

Prima di procedere con il resize delle partizioni logiche bisogna essere certi che non vi siano dati nella parte finale del primo volume (LogVol00) altrimenti questi saranno irrimediabilmente persi. Questa considerazione va fatta dal momento che per aggiungere un numero variabile di byte alla partizione di swap, bisogna prima sottrarli a quella del sistema operativo. Ovvio che se la partizione del SO è piena, il resize non sarà possibile.

Il resize delle partizioni logiche
Poichè LogVol00 è di tipo ext3, possiamo deframmentare l’unità in modo da lasciare libero lo spazio in coda (shrinking):

[root@localhost liveuser]# e2fsck -f /dev/VolGroup01/LogVol00
e2fsck 1.41.9 (22-Aug-2009)
Adding dirhash hint to filesystem.

Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/VolGroup01/LogVol00: ***** FILE SYSTEM WAS MODIFIED *****
/dev/VolGroup01/LogVol00: 107628/20676608 files (1.3% non-contiguous), 1409699/20676608 blocks

Fatto questo procediamo con il resize della partizione ext3

[root@localhost liveuser]# resize2fs /dev/VolGroup01/LogVol00 77880M
resize2fs 1.41.9 (22-Aug-2009)
Resizing the filesystem on /dev/VolGroup01/LogVol00 to 19937280 (4k) blocks.
The filesystem on /dev/VolGroup01/LogVol00 is now 19937280 blocks long.

Con il comando precedente abbiamo tolto alla partizione 1 G definendo le nuove dimensioni (77880M)

Adesso finalmente possiamo contrarre la partizione logica del primo volume ed estendere la seconda:

[root@localhost liveuser]# lvresize /dev/VolGroup01/LogVol00 --size -1G
  WARNING: Reducing active logical volume to 77.88 GB
  THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce LogVol00? [y/n]: y
  Reducing logical volume LogVol00 to 77.88 GB
  Logical volume LogVol00 successfully resized

[root@localhost liveuser]# lvresize /dev/VolGroup01/LogVol01 --size +1G
  Extending logical volume LogVol01 to 2.00 GB
  Logical volume LogVol01 successfully resized

In questo caso abbiamo utilizzato valori relativi (-/+1 G)

Per finire, possiamo procedere con la formattazione della nuova partizione di swap

[root@localhost ~]# mkswap /dev/VolGroup01/LogVol01
Setting up swapspace version 1, size = 2147479 kB

Dopo un reboot tutto è pronto.
Alla prossima.

Repository aggiuntivi in CentOS e Fedora

Come tutte le grandi distribuzioni open source, sia CentOS che Fedora godono di un ampio repository ed offrono supporto ad una vasta gamma di programmi.

Non tutte le applicazioni però sono disponibili all’interno della distribuzione e di conseguenza nel repository ufficiale.

Repository non ufficiali possono essere utilizzati come valida alternativa alla compilazione dei sorgenti.

Bisogna però fare attenzione perché utilizzare repository sconosciuti potrebbe compromettere il sistema operativo, sia dal punto di vista della sicurezza che da quello della stabilità.

In questo articolo spiegheremo brevemente come accedere a repository non ufficiali tramite yum.

La priorità dei repository
Quando si ha a che fare con più repository esiste un concetto di priorità che bisogna tenere in considerazione altrimenti si rischia di fare l’aggiornamento dei pacchetti di base su un repository non ufficiale come ad esempio quello di test.

Yum consente di priorizzare i repository in base alle proprie esigenze mediante un apposito plugin che può essere installato con il seguente comando:

yum install yum-priorities

Per consentire l’uso dei plugin in yum è necessario modificare il file /etc/yum.conf:

[main]
cachedir=/var/cache/yum
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
distroverpkg=redhat-release
tolerant=1
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1

# Note: yum-RHN-plugin doesn't honor this.
metadata_expire=1h

installonly_limit = 5

# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d

aggiungendo eventualmente la riga “plugins=1″

Un seconda abilitazione deve essere fatta per ogni singolo plugin installato. Nel nostro caso quindi bisogna modificare il file /etc/yum/pluginconf.d/priorities.conf impostando il parametro enabled:

[main]
enabled = 1

Una volta abilitato il plugin è possibile gestire la priorita di ogni repository aggiungendo il parametro priority=N in nel relativo file di configurazione. N è un numero che va da 1 a 99 ed esprime una gerarchia. A valori di N più elevati corrispondono repository con priorità più bassa.

Nella cartella /etc/yum.repos.d sono presenti i files relativi ai singoli repository. L’esempio seguente si riferisce al file /etc/yum.repos.d/CentOS-Base.repo:

[base]
name=CentOS-$releasever - Base
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
priority=1

#released updates
[updates]
name=CentOS-$releasever - Updates
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
priority=1

#packages used/produced in the build but not released
[addons]
name=CentOS-$releasever - Addons
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=addons
#baseurl=http://mirror.centos.org/centos/$releasever/addons/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
priority=1

#additional packages that may be useful
[extras]
name=CentOS-$releasever - Extras
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras
#baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
priority=1

#additional packages that extend functionality of existing packages
[centosplus]
name=CentOS-$releasever - Plus
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus
#baseurl=http://mirror.centos.org/centos/$releasever/centosplus/$basearch/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
priority=2

#contrib - packages by Centos Users
[contrib]
name=CentOS-$releasever - Contrib
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=contrib
#baseurl=http://mirror.centos.org/centos/$releasever/contrib/$basearch/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
priority=2

Da notare come i repository di base abbiano tutti priorità 1.

Importare il repository di rpmforge
Prima di importare un nuovo repository è bene verificarne l’autenticità. Ogni repository inoltre dovrebbe essere dotato di una chiave GPG che consenta a yum di verificare la provenienza dei pacchetti.

Nell’esempio che segue, aggiungeremo una chiave valida per rpmforge:

rpm --import http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt

Anche se può sembrare strano, è necessario importare la chiave prima del repository stesso altrimenti yum non sarà in grado di certificarne l’installazione.

Prima di installare il repository bisogna identificare l’architettura hardware che si intende utilizzare (ad esempio i386 oppure x86_64). Fare uqesta sceltà è necessaria perché ogni architettura ha un percorso diverso. Per capire con ragionevole certezza quale sia l’architettura corretta è sufficiente impartire il seguente comando:

uname -i

A questo punto possiamo scegliere tra:

dopo aver scaricato il pacchetto procediamo con la verifica:

wget http://apt.sw.be/redhat/el5/en/$(uname -i)/RPMS.dag/rpmforge-release-0.3.6-1.el5.rf.$(uname -i).rpm
rpm -K rpmforge-release-0.3.6-1.el5.rf.*.rpm

Con una risposta simile a:

rpmforge-release-0.3.6-1.el5.rf.i386.rpm: (sha1) dsa sha1 md5 gpg OK

Ora possiamo procedere con l’installazione:

rpm -i rpmforge-release-0.3.6-1.el5.rf.*.rpm

Infine aggiungiamo una priorità più alta per questo repository:

echo "priority = 5" >> /etc/yum.repos.d/rpmforge.repo

Installare repository di test
Possiamo fare lo stesso discorso con i repository di test. L’esempio che segue si applica a CentOS 5:

cd /etc/yum.repos.d
wget http://dev.centos.org/centos/5/CentOS-Testing.repo

Dando un’occhiata al file noterete che il repository è disabilitato. Questo è molto importante perché in genere i repository di test sono molto instabili ed il loro uso potrebbe essere causa di instabilità in ambienti di produzione.

Quando si intende usare un repository disabilitato è possibile eseguire yum con il parametro –enablerepo=REPO dove REPO è il nome del repository. Ad esempio:

yum --enablerepo=c5-testing install pacchetto

Altro sui repository
A fronte di più repository, quando si esegue yum per un aggiornamento del sistema si noterà certamente l’esclusione di alcuni pacchetti:

yum update

Loaded plugins: fastestmirror, priorities
Loading mirror speeds from cached hostfile
 * addons: centos.bio.lmu.de
 * base: ftp.halifax.rwth-aachen.de
 * extras: centos.bio.lmu.de
 * rpmforge: fr2.rpmfind.net
 * updates: mirror.avalonsys.eu
478 packages excluded due to repository priority protections
Setting up Update Process
No Packages marked for Update

Alcuni pacchetti marcati come da aggiornare non saranno scartati se sono marcati come da non aggiornare in un repository con priorità più bassa. Per verificare quali pacchetti sono stati esclusi è possibile usare il parametro –d3:

yum -d3 update
Loaded plugins: fastestmirror, priorities
Config time: 0.136
Yum Version: 3.2.22
Setting up Package Sacks
Loading mirror speeds from cached hostfile
 * addons: mirror.silyus.net
 * base: ftp.halifax.rwth-aachen.de
 * extras: mirror.silyus.net
 * rpmforge: fr2.rpmfind.net
 * updates: mirror.avalonsys.eu
 --> subversion-perl-1.6.3-0.1.el5.rf.i386 from rpmforge excluded (priority)
 --> php-pecl-memcache-2.1.2-1.el5.rf.i386 from rpmforge excluded (priority)
 --> perl-DBD-Pg-2.10.7-1.el5.rf.i386 from rpmforge excluded (priority)
 --> qemu-0.9.0-2.el5.rf.i386 from rpmforge excluded (priority)
 --> subversion-perl-1.3.2-0.2.el5.rf.i386 from rpmforge excluded (priority)
 --> fuse-2.7.4-1.el5.rf.i386 from rpmforge excluded (priority)
 --> lftp-3.5.11-1.el5.rf.i386 from rpmforge excluded (priority)
...

Alla prossima.

IPCop – Come aprire la rete Green alla rete Blue

La Blue Net di IPCop serve ad interfacciare una connettività wifi che si ntende mantenere separata dalla rete locale LAN (Green Net). Questo per consentire una maggiore sicurezza, dal momento che gli endpoint che si collegano ad IPCop tramite wifi non vedranno la rete locale a meno di aprire le porte desiderate per i protocolli TCP ed UDP.

IPCop però non supporta nativamente il bridging delle schede di rete e non risulta agevole simulare il comportamento tipico dei router adsl comunemente in commercio nei negozi al giorno d’oggi. Non c’è modo infatti, tramite interfaccia grafica, di consentire il pieno accesso alla Green Net da parte dei computer che si collegano per mezzo della wifi (vedi ad esempio il trafico ICMP).

Mi è capitato di recente di installare una versione di IPCop con supporto wifi per mezzo dell’addon WLAN-AP e di dover simulare proprio il tipico comportamento dell’Access Point, dove la rete cablata è condivisa con quella senza fili.

Per abilitare tutto il traffico ho inserito alcune righe nel file /etc/rc.d/rc.firewall.local che è il file contenente i comandi da impartire al sistema operativo durante il boot per personalizzare le regole di firewalling senza interferire con la distribuzione:

/sbin/iptables -A CUSTOMFORWARD -i ath0 -o eth0 -p icmp -j ACCEPT
/sbin/iptables -A CUSTOMFORWARD -i ath0 -o eth0 -p tcp -j ACCEPT
/sbin/iptables -A CUSTOMFORWARD -i ath0 -o eth0 -p udp -j ACCEPT

Queste righe sono state inserite nella sezione start (ovviamente). In linea di principio, per abiitare un protocollo è sufficiente impartire il comando secondo a forma:

/sbin/iptables -A CUSTOMFORWARD -i 'blue device' -o 'green device' -p 'protocollo' -j ACCEPT

Per comodità, di seguito è riportato un esempio di rc.firewall.local che svolge questa attività:

#!/bin/sh
# Used for private firewall rules
# See how we were called.
case "$1" in
start)
## add your 'start' rules here
#morzello blue vs green
/sbin/iptables -A CUSTOMFORWARD -i ath0 -o eth0 -p icmp -j ACCEPT
/sbin/iptables -A CUSTOMFORWARD -i ath0 -o eth0 -p tcp -j ACCEPT
/sbin/iptables -A CUSTOMFORWARD -i ath0 -o eth0 -p udp -j ACCEPT
;;
stop)
## add your 'stop' rules here
;;
reload)
$0 stop
$0 start
## add your 'reload' rules here
;;
*)
echo "Usage: $0 {start|stop|reload}"
;;
esac

Spero che questo articolo possa essere utile a chi deve ottenere questo risultato.

Un Domain Controller in CentOS/Fedora per la piccola e media impresa

In questo articolo viene proposto un modo facile e veloce di creare un DC (Domain Controller) per ambienti Windows utilizzando Samba.
Va detto che la soluzione è dimensionata per la piccola e media impresa, dove il numero di utenti generalmente non supera le cento unità.
Facile e veloce perché impiega un solo server e non prevede ridondanza.
Per l’articolo ho scelto di utilizzare CentOS ma dovrebbe funzionare anche con Fedora.

Prerequisiti
La soluzione prevede il deployment all’interno di una rete locale (LAN); si presuppone dunque che i servizi di DNS (per la risoluzione dei nomi) e DHCP (per l’assegnazione automatica degli indirizzi IP) funzionino a dovere.
La lista della spesa Per far girare “il tutto” è necessario installare sulla macchina alcuni pacchetti fondamentali di samba. Per verificare i pacchetti già installati è sufficiente usare yum:

[root@myserver ~]# yum list *samba*
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: centos.fastbull.org
 * updates: centos.fastbull.org
 * addons: centos.fastbull.org
 * extras: centos.kiewel-online.ch base
Installed Packages
 samba.i386	3.0.33-3.7.el5_3.1	installed
 samba-client.i386		3.0.33-3.7.el5_3.1	installed
 samba-common.i386		3.0.33-3.7.el5_3.1	installed
 system-config-samba.noarch	1.2.41-3.el5		installed
 Available Packages
 samba-swat.i386		3.0.33-3.7.el5_3.1	updates
 sblim-cmpi-samba.i386		0.5.2-31.el5_2.1	base
 sblim-cmpi-samba-devel.i386	1-31.el5_2.1		base
 sblim-cmpi-samba-test.i386	1-31.el5_2.1		base

Nel nostro caso samba è già installato. Nel caso in cui fosse necessario installare il software possiamo sempre utilizzare yum:

yum install samba

I pacchetti fondamentali sono:

samba.i386 samba-common.i386system-config-samba.noarch

Degli altri possiamo anche farne a meno.

Personalizzare il servizio
Nel nostro caso, Samba dovrà funzionare come DC, per questo motivo è necessario editare il file /etc/samba/smb.conf indicando le corrette impostazioni. Di seguito un esempio di configurazione possibile:

[global]
        workgroup = MORZELLO
        server string = Samba Server Version %v
        netbios name = MYSERVER
        security = user
        passdb backend = tdbsam
        domain master = yes
        domain logons = yes
        logon script = %m.bat
        logon script = %u.bat
        logon path =
        add user script = /usr/sbin/useradd "%u" -n -g users
        add group script = /usr/sbin/groupadd "%g"
        add machine script = /usr/sbin/useradd -n -c "Workstation (%u)" -M -d /nohome -s /bin/false "%u"
        delete user script = /usr/sbin/userdel "%u"
        delete user from group script = /usr/sbin/userdel "%u" "%g"
        delete group script = /usr/sbin/groupdel "%g"
        username map = /etc/samba/smbusers
        lanman auth = no
        ntlm auth = Yes
        client NTLMv2 auth = Yes
        client lanman auth = no
        client plaintext auth = no
        winbind enum groups = yes
        winbind enum users = yes
        wins support = yes

[homes]
        comment = Home Directories
        browseable = no
        writable = yes

Il file di configurazione contiene solo ed esclusivamente i dati strettamente necessari per far funzionare il servizio come PDC (Primary Domain Controller). Probabilmente il lettore vorrà successivamente attivare altre voci come ad esempio le stampanti di rete e le cartelle di rete. Queste informazioni non sono strettamente necessarie e per questo motivo non sono trattate in questa sede. Per dare un senso al nostro operato cerchiamo di capire il significato delle voci principali che compongono il nostro file di configurazione:

  • workgroup: indica il nome del nostro dominio;
  • passdb backend: indica come samba gestirà le utenze windows. specificando tdbsam samba autenticherà gli utenti e le macchine appartenenti al dominio mediante il proprio database, senza utilizzare servizi esterni come ad esempio LDAP oppure un altro DC;
  • *script: sono le voci che indicano quali script eseguire per gestire gli utenti ed i gruppi;
  • logon path: è il percorso della cartella che contiene informazioni di netlogon di Windows. Nell’esempio si è deciso di non fornire questo servizio;
  • domain logons: indica se il server agirà come DC oppure no;
  • domain master: indica se il server agirà come PDC oppure no.

Per capire se la nostra configurazione è valida o meno possiamo usare il comando testparm:

[root@myserver ~]# testparm -s
Load smb config files from /etc/samba/smb.conf
Processing section "[homes]"
Loaded services file OK.
Server role: ROLE_DOMAIN_PDC
[global]
        workgroup = MORZELLO
        server string = Samba Server Version %v
        passdb backend = tdbsam
        username map = /etc/samba/smbusers
        lanman auth = No
        client NTLMv2 auth = Yes
        client lanman auth = No
        client plaintext auth = No
        log level = 2
        log file = /var/log/samba/%m.log
        add user script = /usr/sbin/useradd "%u" -n -g users
        delete user script = /usr/sbin/userdel "%u"
        add group script = /usr/sbin/groupadd "%g"
        delete group script = /usr/sbin/groupdel "%g"
        delete user from group script = /usr/sbin/userdel "%u" "%g"
        add machine script = /usr/sbin/useradd -n -c "Workstation (%u)" -M -d /nohome -s /bin/false "%u"
        logon script = %u.bat
        logon path =
        domain logons = Yes
        domain master = Yes
        wins support = Yes
        winbind enum users = Yes
        winbind enum groups = Yes

[homes]
        comment = Home Directories
        read only = No
        browseable = No

È fondamentale che la voce server role sia quella corretta.

L’utenza amministrativa
Per poter gestire il dominio è necessario aggiungere nel database di samba l’utente amministratore:

[root@myserver samba]# smbpasswd -a root
New SMB password:
Retype new SMB password:
tdbsam_open: Converting version 0 database to version 3....
Added user root.

Gli utenti di dominio
Gli utenti samba sono in realtà utenti linux e bisogna dare una regola per convertire correttamente gli utenti tra linux e windows. Per fare questo personalizziamo il file /etc/samba/smbusers:

# Unix_name = SMB_name1 SMB_name2 ...
root = administrator admin
nobody = guest pcguest smbguest

Nel nostro caso ci limitiamo a dire che l’utente administrator equivale a root e che l’utente guest equivale a nobody. Aggiungiamo anche i gruppi di utenti windows che non esistono ancora in linux:

# Map Windows Domain Groups to UNIX groups
net groupmap add rid=514 ntgroup="Domain Guests" unixgroup="nobody" type=d
net groupmap add rid=513 ntgroup="Domain Users" unixgroup="users" type=d
net groupmap add rid=512 ntgroup="Domain Admins" unixgroup="root" type=d

Si possono aggiungere anche altri gruppi di utenti, quelli specificati in alto sono quelli “canonici”. Per verificare che i gruppi siano stati creati possiamo usare il comando wbinfo:

[root@myserver samba]# wbinfo -g
domain users
domain admins
domain guests

Aggiungendo gli utenti di dominio ricordiamo sempre che questi sono anche utenti Linux. È probabile però che non tutti gli utenti dovranno avere accesso al server come utenti locali. Per inibire l’accesso alla console del server specificheremo una shell non valida. Su CentOS possiamo creare un utente con queste caratteristiche usando il comando adduser:

[root@myserver samba]# adduser -m -s /sbin/nologin testuser
[root@myserver samba]# passwd testuser
[root@myserver samba]# smbpasswd -a testuser

Con precedenti comandi abbiamo creato un utente, assegnato una password per linux ed una per samba.
Un metodo alternativo per creare gli utenti è quello di accodare direttamente gli utenti nel file /etc/passwd senza assegnare la password all’utente.
A pensarci bene non è necessario assegnare una password ad un utente che non può fare il logon. Se invece l’utente deve comunque avere l’accesso al server è sufficiente omettere il parametro “–s”.
Comunque sia per abilitare l’utente al dominio è necessario inserirlo nel database di samba con il comando smbpasswd.
Da notare che la password per linux può essere diversa da quella specificata in samba. Eseguire il servizio all’avvio In CentOS i servizi possono essere gestiti facilmente mediante il comando chkconfig.
Le righe seguenti assicurano l’avvio del servizio all’accensione del nostro server:

chkconfig smb on

Ultimi ritocchi: iptables e selinux
Samba necessita di alcune porte tcp ed udp per poter funzionare correttamente. Queste porte sono chiude per default da iptables. Di seguito le righe da inserire nel file /etc/sysconfig/iptables:

-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 137 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 138 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 139 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 445 -j ACCEPT

Le righe devono essere inserite nel file prima delle ultime due stringhe:

-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT

Per quanto concerne selinux invece bisogna consentire a samba l’uso dei comandi necessari per svolgere alcuni task:

# Se si intende usare useradd/groupadd è necessario eseguire:
setsebool -P samba_domain_controller on
#
# Se si vuole condividere la home degli utenti eseguire:
setsebool -P samba_enable_home_dirs on

Per condividere una cartella di rete bisogna assegnare alla stessa l’etichetta “samba-share_t”. Evitate le cartelle di sistema perché queste probabilmente hanno una etichetta diversa già applicata. Per verificare i dettagli di una cartella relativa a selinux è possibile usare il comando ls specificando il paramentr “–Z”:

ls -ldZ /percorso_completo

Aggiungere una workstation al dominio
La procedura di Join è totalmente trasparente in windows.
Per aggiungere una macchina al dominio possiamo cliccare con il tasto destro del mouse su “Gestione Risorse” quindi selezionare il percorso :“Proprietà->Nome Computer->Cambia”. Specificare MORZELLO nella casella “dominio” e procedere al logon di root con la password indicata in samba (mediante il comando smbpasswd).

Alla prossima.

VNC server su Fedora e CentOS

Sono lontani i tempi in cui VNC era considerato un trojan. Oggi quasi tutte le distribuzioni hanno una versione di questo demone per amministrare da remoto un computer in ambiente visuale.

Nonostante l’installazione sia alquanto banale, la messa a punto dello strumento può risultare problematica, specie la prima volta.

Di seguito riporto una breve guida che veste bene per le distribuzioni derivate da Red Hat come ad esempio CentOS e Fedora.

Diamo per scontato che il gestore delle finestre X Window sia correttamente installato e funzionante; non è necessario che sia attualmente in uso. È possibile trovare server che non hanno testiera e monitor ma che comunque offrono una interfaccia visuale con VNC.

Procediamo verificando in primo luogo l’esistenza del demone

yum list vnc-server

In caso procediamo con l’installazione

 yum install vnc-server

Consiglio vivamente di eseguire il demone con un utente non amministrativo, anzi, per dirla tutta, la cosa migliore è creare un utente ad-hoc che non appartenga al gruppo utenti “users”. Questo ci consentirà di definire policy specifiche per questo servizio

groupadd vnc
useradd -g vnc vnc
passwd vnc

Con il comando precedente abbiamo definito un nuovo gruppo, un nuovo utente ed una password per l’utente stesso.

Ora passiamo alla personalizzazione del servizio. Su Red Hat è sufficiente editare e personalizzare il file “/etc/sysconfig/vncservers“. Di seguito un esempio funzionante per la nostra dimostrazione

# The VNCSERVERS variable is a list of display:user pairs.
#
# Uncomment the lines below to start a VNC server on display :2
# as my 'myusername' (adjust this to your own).  You will also
# need to set a VNC password; run 'man vncpasswd' to see how
# to do that.
#
# DO NOT RUN THIS SERVICE if your local area network is
# untrusted!  For a secure way of using VNC, see
# .

# Use "-nolisten tcp" to prevent X connections to your VNC server via TCP.

# Use "-nohttpd" to prevent web-based VNC clients connecting.

# Use "-localhost" to prevent remote VNC clients connecting except when
# doing so through a secure tunnel.  See the "-via" option in the
# `man vncviewer' manual page.

# VNCSERVERS="2:myusername"
# VNCSERVERARGS[2]="-geometry 800x600 -nolisten tcp -nohttpd -localhost"

 VNCSERVERS="2:vnc"
 VNCSERVERARGS[2]="-geometry 1024x768"

Le righe che interessano sono le ultime due dove vengono definite le variabili necessarie al demone per “girare”.

VNCSERVERS definisce la porta e l’utente di ogni singola sessione. È possibile infatti eseguire diverse sessioni utente ovviamente ognuna su porte differenti.

vncserver si mette in ascolto a partire dalla porta TCP 5900. Impostando il primo parametro a “2″ chiediamo al demone di aprire una sessione sulla porta 5902.

Più sessioni possono essere specificate nella stessa variabile. Ad esempio

VNCSERVERS="1:utente1 2:utente2 3:utente3"

VNCSERVERARGS[X] (dove “X” indica il numero di porta) definisce i parametri da passare al demone per ogni sessione. Nel caso di più sessioni sarà necessario specificare più parametri:

VNCSERVERARGS[1]="-geometry 1024x768"
VNCSERVERARGS[2]="-geometry 800x600 -depth 16"
VNCSERVERARGS[3]="-geometry 1024x768 -localhost"

Per un dettaglio maggiore sui parametri supportati consultare la documentazione ufficiale (man Xvnc).

Poiché il servizio partirà con l’utenza vnc è necessario personalizzare l’ambiente di questo utente. In particolare è necessario impostare una password che vncserver chiederà al momento del log-on

su vnc
vncpasswd

Dopo aver impostato la password, che può essere diversa da quella specificata per l’utente, facciamo partire il servizio (sempre come utente vnc)

vncserver

Se tutto è andato a buon fine dovremmo avere una sessione attiva sulla porta 5902

vncviewer remotehost:5902:2

Dove remotehost è il nome della macchina e 5902 la porta tcp.

All’avvio del servizio verrà creato un file, una sorta di autoexec.bat contenente i comandi da eseguire per gestire l’ambiente visuale.
Nel nostro esempio questo file sarà “/home/vnc/.vnc/xstartup” ed avrà un aspetto del tutto simile a questo

xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
twm &

Questo script si occupa tra le altre cose di definire quale gestore grafico utilizzare nella sessione. Nell’esempio riportato in alto, è stato specificato twm, un gestore molto leggero ed essenziale

Chi volesse cambiare gestore può tranquillamente editare il file sostituendo l’ultima riga. Di seguito un esempio che mostra impiego di KDE

startkde &

Ed ecco una immagine dell’ambiente grafico in esecuzione

Per far partire il servizio all’avvio del sistema operativo possiamo utilizzare chkconfig (con credenziali amministrative)

chkconfig vncserver on

Concludiamo la procedura assicurandoci che il traffico di rete sia abilitato sulla macchina istruendo correttamente iptables. Di seguito le righe da aggiungere al file “/etc/sysconfig/iptables

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 5902 -j ACCEPT

Bisogna fare attenzione ad inserire la riga precedente nella esatta posizione, prima cioè delle seguenti righe

-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT

Altrimenti le regole di iptables non avranno l’effetto desiderato.


VNC e sessioni sicure
VNC non fa uso di crittografia a meno di non andare su prodotti commerciali la cui licenza è a pagamento. Questo significa che con un semplice sniffer è possibile rubare la password di accesso.

Una soluzione percorribile “out of the box” prevede l’uso di ssh (il comando utilizzato in Linux per ottenere una shell sicura).

L’idea è quella di far transitare il traffico in un tunnel ssh aperto su entrambi gli host (client e server) secondo il seguente schema:

client --> SSH --| network |-- SSH <-- server

Nel nostro esempio le terminazioni del tunnel verranno create direttamente sui due host in modo da rendere sicura la comunicazione su tutta la rete.

Chiediamo ad ssh di collegarsi al server VNC sulla porta 5902. Chiediamo inoltre ad ssh di mettersi in ascolto su un’altra porta, la 55902 e di fare in modo che il traffico criptato su quest’ultima finisca in chiaro sulla 5902 (forwarding)

ssh -f -L 55902:localhost:5902 remotehost

Il parametro -f istruisce il comando a liberare il prompt agendo come un comune demone.
Il paramtro -L si occupa invece del forwarding trasferendo i byte dalla porta 55902 del client sulla porta 5902 del server.

Per accedere al servizio possiamo eseguire vncviewer localmente

vncviewer localhost:55902:2

Per rendere le cose un tantino più semplici è possibile avvalersi del paramtro sleep con il quale specificare un tempo massimo di attesa (ad esempio 60 secondi) entro il quale creare una connessione. Questo garantisce che non restino appese sessioni inutili.

ssh -f -L 55902:localhost:5902 remotehost sleep 60; vncviewer localhost:55902:2

Nel caso ci fossero problemi è necessario verificare i parametri di ssh ed eventualmente di OpenSSL. Per maggiori informazioni prendere visione della miniguida riportata alla fine dell’articolo.

Sessioni sicure con Windows
Quanto detto in precedenza vale anche per i client Windows dato che ssh esiste anche per cygwin.

Volendo è possibile utilizzare PuTTY creando una sessione e specificando i parametri Source port (55902) e Destination (remotehost:5902) sotto Category -> SSH -> Tunnels e cliccando su “Add“.

Di seguito un esempio che replica quanto fatto in precedenza

Per il momento è tutto. Spero come al solito di non avervi annoiato.
Alla prossima.

Per saperne di più
VNC Mini-FAQ

ReadyNas Duo e LVM

Qualche giorno fa è nata la necessità di espandere un ReadyNas Duo della Netgear dotato di disco da 500GB. L’intenzione era quella di sostituire il disco esistente con due dischi da 1TB. Il risultato è stato la perdita di tutti i dati (vedi post).

A questo punto ho deciso di fare a modo mio resettando il NAS non prima di aver fatto un backup del disco esistente da 500gb.

Per fare questo mi sono collegato in remoto al NAS ed ho impartito i comandi:

tar cvpzf /myshare/nas_pre_dsk_upg.tgz –exclude=/shareX –exclude=/shareY –exclude=/proc –exclude=/lost+found –exclude=/c –exclude=/tmp –exclude=/sys –exclude=/home /

Nel comando precendete le cartelle shareX e shareY sono condivisioni di rete.

Come vedremo in seguito questo backup non è strettamente necessario ma io ho sempre l’abitudine di salvare i files che mi servono in caso di necessità. Il comando prececedente serve sostanzialmente a preservare i files del NAS ad esclusione delle condivisioni (che possono essere tranquillamente copiate da un computer remoto). tar è utile perchè sul NAS oggetto di aggiornamento sono presenti diverse add-on per le quali non ho voglia di procedere alla reinstallazione tramite frontview.

Fatto il backup sostituisco il drive da 500GB con due dischi da 1TB e provvedo a resettare il NAS riportandolo alle impostazioni di fabbrica.
Segue la creazione di un nuovo RAID e l’installazione dell’unica add-on necessaria: ToggleSSH disponibile qui.

Sono riuscito a fare il ripristino del backup eseguendo sul NAS i comandi:

cd /
tar xzvf /nas_pre_dsk_upg.tgz

Il restore è andato liscio come l’olio.

Come dicevo prima, il ripristino dei rimanenti files può essere portato a termine mediante l’uso delle condivisioni di rete ma io ho deciso di ripristinare i files usando il disco da 500GB originale tramite porta USB ed un comune convertitore SATA/USB.

Chi volesse impiegare il metodo descritto di seguito ma non ha un convertitore può:

- usare un case esterno;
- clonare il disco di orinine usando dd su un HD esterno di capacità uguale o maggiore di quello sorgente;
- utilizzare una distribuzione live di linux che supporti LVM (ad esempio il disco di ripristino che accompagna fedora) ed un altro computer.

Ho diciso di pubblicare questo metodo perchè potrebbe sorgere la necessità di recuperare i dati da un volume non più utile.

Nel mio caso ad esempio, l’espansione del RAID portato a termine dal ReadyNAS Duo non è andato a buon fine, di conseguenza tutti i dati presenti nel vecchio RAID sono stati cancellati nel nuovo.

Potrebbe inoltre capitare di dover recuperare i dati da un NAS defunto.

I comandi che seguono sono utili anche per chi non possiede un ReadyNas Duo ma vuole recuperare file presenti in partizioni LVM di linux.

Chi volesse cimentarsi nel ripristino tramite altro computer (cioè smontando il disco dal NAS e montandolo su un altro PC dotato di Linux con supporto LVM) avrà una vita più comoda perchè non bisogna considerare alcuni aspetti come ad esempio la duplicazione dei Volume Group (VG).

Riprendendo il filo del discorso, dopo aver resettato il NAS è possibile collegare tramite porta usb il vecchio disco esterno; il NAS provvederà in piena autonomia a montare le partizioni trovate nella directory /USB.

Il comando mount dovrebbe produrre un output del tutto simile al seguente:

mount


/dev/hdc1 on / type ext2 (rw,noatime)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw)
sysfs on /sys type sysfs (rw)
tmpfs on /ramfs type ramfs (rw)
tmpfs on /USB type tmpfs (rw,size=16k)
/dev/c/c on /c type ext2 (rw,noatime,acl,user_xattr,usrquota,grpquota)
/c/home on /home/ftp/homes type bind (rw,bind)
usbfs on /proc/bus/usb type usbfs (rw)
/dev/sda1 on /USB/USB_HDD_1_1 type ext3 (rw,noatime,acl)
/USB/USB_HDD_1_1 on /home/ftp/USB_HDD_1_1 type none (rw,bind)

Viene montata solo la partizione ext3 (USB_HDD_1_1) contenente tutti i files del NAS ad esclusione di quelli presenti nelle condivisioni di rete. Se non avere fatto il backup descritto in precedenza tramite tar, potete tranquillamente copiare i file presenti in /USB/USB_HDD_1_1 avendo l’accortezza di utilizzare il parametro -p (che preserva gli attributi dei files copiati).

Quello che però a noi interessa adesso è il recupero dei dati presenti nel LVM del disco che il NAS non ha montato. Quindi procediamo a verificare la tabella delle partizioni presenti sul disco:

fdisk -l /dev/sda


Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0×00000000


Device Boot Start End Blocks Id System
/dev/sda1 1 255 2048000 83 Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2 255 287 256000 82 Linux swap / Solaris
Partition 2 does not end on cylinder boundary.
/dev/sda3 287 60800 486064152 5 Extended
/dev/sda5 287 60800 486064151+ 8e Linux LVM

Con fdisk sappiamo che il disco presenta una partizione ext3 (già mondata su USB_HDD_1_1) una partizione di swap (non usata) ed una LVM (che contiene i dati a noi necessari).

Per visualizzare con maggior dettaglio le informazioni legate a LVM è possibile usare il comando pvscan:

pvscan


PV /dev/md2 VG c lvm2 [929.03 GB / 0 free]
Total: 2 [1.36 TB] / in use: 2 [1.36 TB] / in no VG: 0 [0 ]

Non ci sono tracce della partizione /dev/sda5. Questo perchè la scansione delle partizioni LVM da parte del ReadyNAS Duo è stata disabilitata. Basta dare una occhiata al file di configurazione presente in /etc/lvm/lvm.conf per capire che è stato attivato un filtro che evita la scansione di partizioni presenti su porta USB:

filter = [ "a|^/dev/hd[cegikmoq][5-9]$|”, “a|^/dev/hd[cegikmoq]1[0-5]$|”, “a|^/dev/md[2-9]$|”, “r|.*|” ]

Per risolvere il problema suppongo sia sufficiente commentare il filtro ma per essere più precisi è sufficiente apportare le dovute modifiche sostituendo la riga precedente con questa:

filter = [ "a|^/dev/sd[abcegikmoq][5-9]$|”,”a|^/dev/hd[cegikmoq][5-9]$|”, “a|^/dev/hd[cegikmoq]1[0-5]$|”, “a|^/dev/md[2-9]$|”, “r|.*|” ]

Dopo aver modificato il file, l’output del comando pvscan è diverso:

pvscan

PV /dev/sda5 VG c lvm2 [463.53 GB / 0 free]
PV /dev/md2 VG c lvm2 [929.03 GB / 0 free]
Total: 2 [1.36 TB] / in use: 2 [1.36 TB] / in no VG: 0 [0 ]

Adesso siamo in grado di vedere due VG invece che uno ma c’è un problema: entrambi hanno lo stesso nome: “c“. Questo vuol dire che non è possibile montare il volume senza mettere mano ai VG.

Per avere un maggior dettaglio sui VG presenti è possibile fare un controllo con vgdisplay:

vgdisplay

— Volume group —
VG Name c
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 4
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 1
Act PV 1
VG Size 463.53 GB
PE Size 32.00 MB
Total PE 14833
Alloc PE / Size 14833 / 463.53 GB
Free PE / Size 0 / 0
VG UUID q9L5G9-7Uuv-mg9m-9aqK-cOML-QziN-KzizYv

— Volume group —
VG Name c
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 2
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 1
Act PV 1
VG Size 929.03 GB
PE Size 32.00 MB
Total PE 29729
Alloc PE / Size 29729 / 929.03 GB
Free PE / Size 0 / 0
VG UUID fOsBiY-2J8W-d2tC-K0Xe-lRtz-ZRuZ-20IkVB

Montare il volume presente in /dev/sda5 comporta il riconoscimento del relativo VG. Per poter maneggiare il VG è necessario rinominarlo e per rinominarlo è necessario portarlo offline.

Il primo problema è quello di portare offline il VG perchè in caso di duplicazione dei nomi LVM darà la priorità agli array creati sul NAS e questo vanifica il tentativo. Ad esempio, eseguendo il comando vgchange il risultato sarà simile al seguente:

vgchange -a n c


WARNING: Duplicate VG name c: fOsBiY-2J8W-d2tC-K0Xe-lRtz-ZRuZ-20IkVB (created here) takes precedence over q9L5G9-7Uuv-mg9m-9aqK-cOML-QziN-KzizYv
Can’t deactivate volume group “c” with 1 open logical volume(s)
Can’t deactivate volume group “c” with 1 open logical volume(s)

Il comando precente tenta di portare offline il VG c ma poichè la precendeza viene data al volume con UUID fOsBiY-2J8W-d2tC-K0Xe-lRtz-ZRuZ-20IkVB il comando fallisce perchè attualmente il volume è usato dal sistema operativo (vedi comando mount eseguito in precedenza).

La cosa più veloce da fare è quella di smontare la partizione /c in modo da poter portare temporaneamente offline entrambi i VG:

/etc/init.d/frontview stop
/etc/init.d/samba stop
/etc/init.d/nis stop
/etc/init.d/proftpd stop

I comandi riportati in alto servono a fermare temporaneamente quei servizi che potrebbero utilizzare la partizione /c inibendo di fatto la possibilità di smondare la partizione /dev/c/c.

Adesso proseguiamo con lo smontaggio:

umount /c/home
umount /dev/c/c

Se lo smontaggio non dovesse funzionare è possibile verificare quali processi fanno uso della partizione tramite il comando fuser:

fuser -m /dev/c/c

Per ogni processo individuato da fuser è necessario procedere con:

kill -9 pid

dove pid è il numero segnalato da fuser. Prima di procedere accertarsi di non escludere un programma essenziale (come ad esempio la shell bash alla quale siamo collegati per impartire i comandi). A volte l’unità non viene smontata perchè il prompt attuale è in “/c” (o magari nella cartella home dell’utente anche essa montata sotto “/c”).

Fatto questo possiamo finalmente portare offile tutti i VG:

vgchange -a n

Se tutto è andato liscio è possibile ora rinominare il VG del vecchio disco specificando il corretto uuid che contraddistingue il gruppo:

vgrename q9L5G9-7Uuv-mg9m-9aqK-cOML-QziN-KzizYv d

Anche questo comando non dovrebbe creare problemi e con vgchange possiamo riportare i VG online:

vgchange -a y

Prima di riavviare il NAS facciamo una verifica finale sul lavoro con vgdisplay:

vgdisplay


— Volume group —
VG Name d
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 4
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 1
Act PV 1
VG Size 463.53 GB
PE Size 32.00 MB
Total PE 14833
Alloc PE / Size 14833 / 463.53 GB
Free PE / Size 0 / 0
VG UUID q9L5G9-7Uuv-mg9m-9aqK-cOML-QziN-KzizYv

— Volume group —
VG Name c
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 2
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 1
Act PV 1
VG Size 929.03 GB
PE Size 32.00 MB
Total PE 29729
Alloc PE / Size 29729 / 929.03 GB
Free PE / Size 0 / 0
VG UUID fOsBiY-2J8W-d2tC-K0Xe-lRtz-ZRuZ-20IkVB

Finalmente i gruppi hanno nomi differenti ed la loro gestione diventa possibile.

Dopo aver riavviato il NAS è possibile finalmente montare la partizione:

pvscan
mount /dev/d/c /USB/USB_HDD_1_1/c

Per ripristinare i files possiamo procedere con:

cd /USB/USB_HDD_1_1/c
cp -Rpv . /c/

Spero che questa piccola guida possa tornare utile a chi ha problemi di recupero dati da partizioni LVM. A volte le cose non sono complicate come sembrano.

Alla prossima.

SGCop ver 1.4.21

Nuova versione di SGCop disponibile sul sito.

Anche questa volta non ci sono sostanziali differenze con la relativa versione di originale. L’unica modifica apportata riguarda l’upload degli aggiornamenti.
Da questa versione infatti il firewall punterà ad una cartella di questo sito per fare gli aggiornamenti e non più sul server di IPCop. Resta comunque possibile caricare i files di IPCop perchè il relativo certificato GPG è ancora presente.
Da notare che l’indice dei nuovi upgrade è ancora prelevato dal sito di IPCop; questo per consentire all’amministratore di sapere se ci sono nuovi aggiornamenti per la piattaforma (Io purtroppo non sono molto veloce a mantenere il codice sorgente).

Per qualunque informazione lasciate un post.

Alla prox.