werk

Il arrive que j’ai besoin d’accéder à mon Mac Mini depuis le réseau local ou depuis l’extérieur, la plupart des tâches se faisant en ssh, il m’est de temps en temps utile, voir indispensable d’avoir accès à mon bureau. Pour se faire, j’utilise le serveur VNC Vine Server (OSXvnc). Bien qu’il possède un mode server qui permet de le faire tourner au démarrage du système, je ne veux le démarrer que lorsque j’ai vraiment besoin d’un accès GUI. La procédure est donc la suivante, je me connecte en ssh sur la machine, je lance le serveur VNC, je fais mon travail et j’arrête OSXvnc.
Ce petit tutoriel explique la démarche.

Après avoir installé Vine VNC, celui-ci se retrouve naturellement sous /Applications/Vine Server.app, ce répertoire contenant :

Contents
OSXvnc-server -> Contents/Resources/OSXvnc-server
storepasswd -> Contents/Resources/storepasswd

Nous allons créer un mot de passe (crypté) avec l’utilitaire storepasswd fourni :

# cd /Applications/Vine Server.app
# ./storepassword mot_de_passe nom_de_fichier

Voilà, un mot de passe est crée. Ne reste plus qu’à lancer OSXvnc comme ceci :

# ./OSXvnc-server -rfbauth nom_du_fichier -rfbport 5999

L’option -rfbauth va lire le fichier de mot de passe et -rfbport change le port standard.
En fin d’opération, il ne reste plus qu’à tuer le processus OSXvnc.

Sous GNU/Linux, j’utilisais assez les mount --bind pour monter un système de fichiers à un autre endroit de l’arborescence. Ceci étant une spécificité Linux, il n’existe pas sous FreeBSD. Mais il y a nullfs qui fait à peu près la même chose. Voici comment utiliser mount_nullfs pour – par exemple – monter une sous-arborescence music sous le home de toto :

# mkdir /usr/home/toto/music
# mount_nullfs /dataraid/zfsdata/music /usr/home/toto/music

L’arborescence /dataraid/zfsdata/music est désormais aliasée et ainsi disponible dans le home de toto. La grosse différence entre ceci et un lien symbolique est que le chemin de cette nouvelle arborescence est réellement vu à l’endroit indiqué /usr/home/toto/music. Ainsi :

# cd /usr/home/toto/music/
# realpath .
/usr/home/alex/music
# stat .
134283012 107 drwxr-xr-x 342 fabien wheel 0 345 "Dec 22 03:01:29 2009" "Dec 19 17:00:43 2009" "Dec 19 17:00:43 2009" "Dec  9 20:32:31 2009" 4096 27 0 .

Le realpath retourne bien notre système de fichiers et non celui d’origine sous /dataraid/zfsdata/music. stat quant à lui nous indique qu’il s’agit bien d’un répertoire et non d’un lien symbolique.

Pour faire ce montage (en lecture-écriture) automatiquement au démarrage dans le fstab, ajouter cette ligne :

/dataraid/zfsdata/music    /usr/home/toto/music nullfs  rw      0       0

Ce tutoriel explique comment ajouter un système de fichiers ZFS sous FreeBSD 8.0. Pour ce faire, deux disques SATA de 500Go vont être ajoutés pour fonctionner en mirroring (RAID 1).

Les manipulations suivantes ont été l’occasion pour moi de découvrir ZFS et je dois avouer que la simplicité de mise en œuvre est étonnante. Une seule ligne de commandes pour créer un volume RAID 1 exploitable. On est loin des longues suites de commandes sous GNU/Linux pour avoir un équivalent – par équivalent, j’entends ce que j’avais sous Fedora, du LVM2 formaté en ext3 sur un RAID 1 logiciel (mdadm).

Principes généraux

L’architecture de ZFS repose sur 3 niveaux : un ou des système(s) de fichiers sont contenus dans un pool qui lui-même est fait de device(s). Et ceci s’administre avec seulement deux commandes : zpool et zfs.

Mise en œuvre

Deux disques de 500Go sont donc ajoutés à la machine. Un dmesg montre qu’ils sont reconnus comme ad4 et ad6 :

# dmesg
ad4: 476940MB <WDC WD5000AAKS-65A7B0 01.03B01> at ata2-master SATA150
ad6: 476940MB <Seagate ST3500830AS 3.AFD> at ata3-master SATA150

On peut donc créer le pool ZFS – que je nommerai dataraid – comme ceci :

# zpool create dataraid raidz ad4 ad6

Et voilà. C’est fini :> Sérieusement, on peut s’arrêter là, le volume /dataraid monté à la racine est disponible et parfaitement exploitable. Voyons un peu son état avec l’option list de zpool qui permet de lister les pools :

# zpool list
NAME       SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
dataraid   931G   159K   931G     0%  ONLINE  -

C’est plutôt lisible. dataraid d’une taille de 931Go (capacité totale des devices et non pas capacité utile), utilisé pour 159Ko (il est encore vide), il reste donc 931Go et le pool est en ligne.
Un df confirme qu’il est monté :

# df -h
Filesystem               Size    Used   Avail Capacity  Mounted on
/dev/ad0s1a              496M    174M    282M    38%    /
/dev/ad0s1e              496M     16K    456M     0%    /tmp
/dev/ad0s1f               71G    7.4G     57G    11%    /usr
/dev/ad0s1d              1.4G    204M    1.1G    15%    /var
dataraid                 458G      0B    458G     0%    /dataraid

Pour plus d’informations :

# zpool status dataraid
  pool: dataraid
 state: ONLINE
 scrub: none requested
config:
 
	NAME        STATE     READ WRITE CKSUM
	dataraid    ONLINE       0     0     0
	  raidz1    ONLINE       0     0     0
	    ad4     ONLINE       0     0     0
	    ad6     ONLINE       0     0     0
 
errors: No known data errors

Encore des informations bien utiles. Le nom du pool, son statut en ligne. scrub indique la dernière vérification de l’état du pool qui se fait à chaque écriture/modification. Et on voit la hiérarchie de notre pile ZFS, le pool dataraid, en RAID constitué de 2 disques physiques. La dernière ligne renvoie les erreurs s’il y a lieu.

Essayons de passer ce pool en mode dégradé en débranchant un disque SATA à chaud tant qu’il n’y a pas trop de données dessus. Le système chez moi ne bronche pas. Normal. Lorsque c’est fait, on revoit le statut du pool :

# zpool status dataraid
  pool: dataraid
 state: DEGRADED
status: One or more devices could not be used because the label is missing or
	invalid.  Sufficient replicas exist for the pool to continue
	functioning in a degraded state.
action: Replace the device using 'zpool replace'.
   see: http://www.sun.com/msg/ZFS-8000-4J
 scrub: scrub in progress for 0h0m, 29.73% done, 0h0m to go
config:
 
	NAME        STATE     READ WRITE CKSUM
	dataraid    DEGRADED     0     0     0
	  raidz1    DEGRADED     0     0     0
	    ad4     ONLINE       0     0     0
	    ad6     UNAVAIL      3   212     0  experienced I/O failures
 
errors: No known data errors

Le statut est passé en mode dégradé, il nous indique qu’un disque est manquant (I/O failures). J’arrête la machine, je remets le disque :

$ sudo zpool status
  pool: dataraid
 state: ONLINE
 scrub: none requested
config:
 
	NAME        STATE     READ WRITE CKSUM
	dataraid    ONLINE       0     0     0
	  raidz1    ONLINE       0     0     0
	    ad4     ONLINE       0     0     0
	    ad6     ONLINE       0     0     0
 
errors: No known data errors

C’est reparti.
Le pool est en place, il faut maintenant le remplir avec un ou des systèmes de fichiers. Ceci s’opère avec la simple commande zfs. Dans l’exemple suivant, un système de fichiers zfsdata sera ajouté dans notre pool, on vérifiera sa disponibilité par un df :

# zfs create dataraid/zfsdata
# df -h
Filesystem               Size    Used   Avail Capacity  Mounted on
/dev/ad0s1a              496M    174M    282M    38%    /
devfs                    1.0K    1.0K      0B   100%    /dev
/dev/ad0s1e              496M     16K    456M     0%    /tmp
/dev/ad0s1f               71G    7.4G     57G    11%    /usr
/dev/ad0s1d              1.4G    204M    1.1G    15%    /var
dataraid                 458G    128K    458G     0%    /dataraid
devfs                    1.0K    1.0K      0B   100%    /var/named/dev
dataraid/backup          458G    128K    458G     0%    /dataraid/backup
dataraid/zfsdata         458G    128K    458G     0%    /dataraid/zfsdata

Voilà, par ce simple zfs create on a un système de fichiers exploitable. Celui-ci pourrait être supprimé avec zfs destroy dataraid/zfsdata. Cette commande zfs permet beaucoup plus, notament d’avoir des informations – très – détaillées sur le système de fichiers, grâce à zfs get all :

# zfs get all dataraid/zfsdata
NAME              PROPERTY              VALUE                  SOURCE
dataraid/zfsdata  type                  filesystem             -
dataraid/zfsdata  creation              Wed Dec  9 19:48 2009  -
dataraid/zfsdata  used                  18K                    -
dataraid/zfsdata  available             458G                   -
dataraid/zfsdata  referenced            18K                    -
dataraid/zfsdata  compressratio         1.00x                  -
dataraid/zfsdata  mounted               yes                    -
dataraid/zfsdata  quota                 none                   default
dataraid/zfsdata  reservation           none                   default
dataraid/zfsdata  recordsize            128K                   default
dataraid/zfsdata  mountpoint            /dataraid/zfsdata      default
dataraid/zfsdata  sharenfs              off                    default
dataraid/zfsdata  checksum              on                     default
dataraid/zfsdata  compression           off                    default
dataraid/zfsdata  atime                 on                     default
dataraid/zfsdata  devices               on                     default
dataraid/zfsdata  exec                  on                     default
dataraid/zfsdata  setuid                on                     default
dataraid/zfsdata  readonly              off                    default
dataraid/zfsdata  jailed                off                    default
dataraid/zfsdata  snapdir               hidden                 default
dataraid/zfsdata  aclmode               groupmask              default
dataraid/zfsdata  aclinherit            restricted             default
dataraid/zfsdata  canmount              on                     default
dataraid/zfsdata  shareiscsi            off                    default
dataraid/zfsdata  xattr                 off                    temporary
dataraid/zfsdata  copies                1                      default
dataraid/zfsdata  version               3                      -
dataraid/zfsdata  utf8only              off                    -
dataraid/zfsdata  normalization         none                   -
dataraid/zfsdata  casesensitivity       sensitive              -
dataraid/zfsdata  vscan                 off                    default
dataraid/zfsdata  nbmand                off                    default
dataraid/zfsdata  sharesmb              off                    default
dataraid/zfsdata  refquota              none                   default
dataraid/zfsdata  refreservation        none                   default
dataraid/zfsdata  primarycache          all                    default
dataraid/zfsdata  secondarycache        all                    default
dataraid/zfsdata  usedbysnapshots       0                      -
dataraid/zfsdata  usedbydataset         18K                    -
dataraid/zfsdata  usedbychildren        0                      -
dataraid/zfsdata  usedbyrefreservation  0                      -

Le détail de toutes ces informations peut être consulté à cette adresse chez Sun. A noter que les propriétés avec un tiret dans la colonne SOURCE, indiquent que celles-ci sont en lecture uniquement, alors que les autres peuvent être modifiées. Il y a trois types de SOURCE :

• default – la valeur ZFS par défaut
• local – la propriété a été modifiée localement pour ce système de fichiers
• inherited – la propriété est héritée d’un système de fichiers parent

Conclusion

Voilà une introduction à ZFS qui permet tout de même de commencer à le découvrir et l’exploiter rapidement. Une documentation complète peut être consultée ou téléchargée sur le site de Sun.

Sources :

• http://docs.sun.com/app/docs/doc/817-2271
• http://flux.org.uk/howto/solaris/zfs_tutorial_01

Petite astuce intéressante sous FreeBSD pour avoir un accès rapide à un système de fichiers distant via NFS avec le daemon amd.

En effet, amd permet de monter un système de fichiers à la demande en s’attachant aux répertoires /net et /host. Dès qu’un accès est demandé à l’intérieur de ces deux répertoires, le montage est réalisé de façon automatique. La ressource est ensuite libérée après un certain temps d’inactivité.
/int permet d’utiliser un système de fichiers exporté à partir d’une IP et /host à partir d’un nom d’hôte.

Exemple :

Supposons une machine monserveur exporte (partage) deux systèmes de fichiers NFS /home et /mnt/data. Depuis notre machine – ici FreeBSD – il est possible de lister ces partages avec la commande showmount :

# showmount -e monserveur
Exports list on monserveur :
/home		192.168.1.100
/mnt/data		192.168.1.100

Maintenant pour accéder par exemple à /mnt/data de monserveur, il suffit de se rendre sous :

# cd /host/monserveur/mnt/data

amd va résoudre le nom d’hôte monserveur et monter le système de fichiers demandé.

Le daemon amd peut être démarré avec la machine en ajoutant ceci au rc.conf :

amd_enable="YES"

Et la commande rc pour le démarrer est simplement :

# /etc/rc.d/amd start

Pages de manuels d’amd(8) et d’amd.conf(5).

Depuis hier edoras ma vieille config qui me sert de serveur fourre-tout sous Fedora 11 ne démarrait plus. J’avais depuis un certains temps un disque qui jouait du grattoir à faire un bruit pas possible qui normalement devrait alerter n’importe qui qu’il faut s’en occuper. Mais bon, j’ai laissé courir en me disant que ça allait bien tenir et que je regarderais plus tard. J’ai attendu trop longtemps.

Je passe sur les détails du comment du pourquoi je m’en suis dépatouillé pour récupérer mes données (229Go de photos et de musique) sur du LVM réparti sur 2 disques avec un disque marqué inexistant. Mais j’ai réussi.
Edoras est d’une part un vieux coucou (Sempron 2400+ avec 1Go de RAM), mais très bien pour un petit serveur qui démarre en niveau 3. Mais c’est aussi une usine à gaz qui comporte 5 disques : un disque système avec 2 partitions /boot et l’autre en LVM (swap, root et home), un VGdata de 380Go sur 2 disques et un VGraid qui comme son l’indique est un RAID1 sur deux disques SATA de 500Go. Non seulement, j’ai eu ce problème d’inconsistance du VGdata, mais j’avais un des disques du RAID déconnecté. Et ne me demandez pas pourquoi, ce deuxième disque avec un identifiant de partition de type Linux LVM (8e) et non pas Linux RAID auto (fd). Je l’ai donc ré-attribué l’id du système de fichiers comme étant fd. Et j’ai du ré-ajouter le disque au RAID pour le resynchroniser.

Ajout du disque à la pile raid md127 :

# mdadm --add /dev/md127 /dev/sde1
mdadm: added /dev/sde1

Voilà, la synchronisation doit commencer toute seule :

[edoras@edoras ~]# cat /proc/mdstat 
Personalities : [raid1] 
md127 : active raid1 sde1[2] sdd1[0]
      488383936 blocks [2/1] [U_]
      [>....................]  recovery =  2.7% (13261248/488383936) finish=137.9min speed=57399K/sec
 
unused devices: <none>

Plus qu’une bonne 130aine de minutes à attendre pour avoir ses données sécurisées de nouveau.