Giochiamo con Label e UUID

Mettiamo il caso che si stia lavorando su un server, un lavoro delicato, eh, e che la fuckup fairy decida proprio in quel momento di venire a trovarvi…

Mettiamo il caso che per una botta incredibile di fortuna, vi interrompano mentre state eseguendo un echo su /etc/fstab e invece di un bel >> vi ritroviate con >.

Ok, in questo caso fate ciao ciao con la manina a /etc/fstab e pensate intensamente al fatto che, genialmente, chi si occupa dei backup se n’è andato in vacanza una settimana prima di voi.

Ora, proprio per non rendere le cose facili, tenete conto che il vostro /etc/fstab monti i filesystem indicandoli con una volume label che, ovviamente, ora non ricordate, del tipo :

LABEL=SW-cciss/c0d0p2   swap                    swap    defaults        0 0

Questo è un caso classico, una swap referenziata da label, e cancellata la riga chi si ricorda più dove, come, quando, perché? Volendo ripristinare un mount via label, una via semplice per recuperare l’etichetta mancante consiste nell’utilizzare bklid:

#: blkid /dev/cciss/c0d0p2
/dev/cciss/c0d0p2: TYPE="swap" LABEL="SW-cciss/c0d0p2" UUID="1b2e35d0-8321-4d5b-bed0-647b862cbc88"

Fatto. La label è

SW-cciss/c0d0p2

Incidentalmente, ma nemmeno troppo, blkid vi mostra anche la UUID del filesystem. Infatti, potreste volere montare il filesystem usando il suo UUID e quindi la precedente istruzione in /etc/fstab potrebbe essere riscritta come:

UUID=1b2e35d0-8321-4d5b-bed0-647b862cbc88 swap swap defaults 0 0

Ciò vale per qualsiasi filesystem. Per esempio, questa regola di mount per il filesystem contenente i database di MySQL, da così

/dev/VolGroup00/LogVol03 /var/lib/mysql ext3 defaults 1 2

passando per

#: blkid /dev/VolGroup00/LogVol03
/dev/VolGroup00/LogVol03: UUID="fb5050a9-6641-4ec8-a1dc-5365b326d9bd" TYPE="ext3"

Può essere riscritta come:

UUID=fb5050a9-6641-4ec8-a1dc-5365b326d9bd /var/lib/mysql ext3 defaults 1 2

Avete notato nulla? Il filesystem è sprovvisto di una volume label. Rimediamo applicando una etichetta che ci consenta di capire al volo la funzione del filesystem montato:

tune2fs -L "MySQL DB" /dev/VolGroup00/LogVol03

Controlliamo che il filesystem abbia preso l’etichetta in maniera corretta:


#: blkid /dev/VolGroup00/LogVol03
/dev/VolGroup00/LogVol03: UUID="fb5050a9-6641-4ec8-a1dc-5365b326d9bd" TYPE="ext3" LABEL="MySQL DB"

Ora non rimane che modificare /etc/fstab per rimontare il filesystem usando la nuova label:

LABEL=MySQL\040DB /var/lib/mysql ext3 defaults 1 2

Notato qualcosa? Forse quello

\040

messo fra MySQL e DB? Esatto. Serve per eseguire l’escape dello spazio fra le due parole che compongono la label. Se date un’occhiata al man 5 di fstab noterete che gli spazi vanno sottoposti a escape se si trovano all’interno di una etichetta o nel percorso del mount point. Quindi, corollario molto semplice, potete anche creare dei mount point il cui percorso sia composto da più termni separati da uno spazio.

Proviamoci:

mkdir "/Spazio per i file database di MySQL"

Quindi modifichiamo in questo modo /etc/fstab:

LABEL=MySQL\040DB /Spazio\040per\040i\040file\040database\040di\040MySQL ext3 defaults 1 2

Ora non rimane che smontare e rimontare il filesystem:

umount /var/lib/mysql/ ; mount -a

e infine, verifichiamo la buona riuscita dell’operazione:

#: mount | grep Spazio
/dev/mapper/VolGroup00-LogVol03 on /Spazio per i file database di MySQL type ext3 (rw)

e poi:

ls /Spazio\ per\ i\ file\ database\ di\ MySQL/
controllo ib_logfile0 ib_logfile1 ibdata1 lost+found mysql nagios_data

Bene, direi che tutto è a posto. Non vi rimane che fare qualche esperimento, giusto?

P.S.

Nel caso aveste giocato con la directory dei db di MySQL (ma siete pazzi come me?), rimettete tutto a posto, oppure modificate il puntamento in my.cnf.