Administrateur & Développeur système UNIX/Linux

Voici la nouvelle version de mon plugin de gestion des répondeurs pour RoundCube version 0.3. Elle s’appuie à présent sur l’API plugin de RoundCube, ce qui permet une installation en moins de cinq minutes. Au niveau des nouveautés, les drivers de stockage permettent une configuration sur mesure. Sont fournis le driver SQL et le driver LDAP qui couvrent entre autres l’utilisation de PostfixAdmin et Gnarwl. Si cela ne suffit pas, à vous de coder votre driver !

plugin-vacation-0.3-20091008.tar.gz

ChangeLog :
- support de l’API plugin RC.
- driver de stockage : SQL, LDAP.
- support des messages au format HTML.

Je vais vous guider dans la configuration d’un RAID1 logiciel avec RAIDFrame sous NetBSD. Cette procédure fonctionne également sous OpenBSD (votre noyau devant intégrer le support RAIDframe) ou encore FreeBSD 4/5. Le RAID peut être créé à chaud sans LiveCD et à distance, mais il est recommandé d’avoir un accès au BIOS setup. Si vous ne faites pas d’erreur de calcul ou de frappe, tout se passera bien sinon pensez d’emblée à faire une backup !

La procédure consiste à créer le RAID1 initialement sur le second disque, à y recopier le système et les données « live » du premier disque. Suite à cela, un redémarrage activera le RAID du second disque, auquel le premier disque sera ajouté.

Etape 1 : installation du système

Je débute par l’installation d’un système NetBSD 5.0.1/amd64. Le système est installé sur le premier disque dur SCSI (/dev/sd0) d’une capacité de 8 Go (l’exemple est ici réalisé sous VMware), dont l’ensemble est affecté au slice de NetBSD (partition DOS 0). Au niveau des partitions BSD, je crée le strict minimum par souci de simplification du présent guide : /, swap et  /home.

netbsd# grep sd0 dmesg.boot
sd0 at scsibus0 target 0 lun 0: <VMware,, VMware Virtual S, 1.0>
 disk fixed
sd0: 8192 MB, 1044 cyl, 255 head, 63 sec, 512 bytes/sect x 16777216
 sectors
netbsd# grep sd1 dmesg.boot
sd1 at scsibus0 target 1 lun 0: <VMware,, VMware Virtual S, 1.0>
 disk fixed
sd1: 8192 MB, 1044 cyl, 255 head, 63 sec, 512 bytes/sect x 16777216
 sectors

netbsd# fdisk /dev/sd0
Partition table:
0: NetBSD (sysid 169)
 start 63, size 16777153 (8192 MB, Cyls 0-1044/85/1), Active

netbsd# disklabel -r sd0
# /dev/rsd0d:
total sectors: 16777216

16 partitions:
#        size    offset     fstype [fsize bsize cpg/sgs]
 a:   8401995        63     4.2BSD   2048 16384     0
 b:    273105   8402058       swap
 c:  16777153        63     unused      0     0
 d:  16777216         0     unused      0     0
 e:   8102053   8675163     4.2BSD   2048 16384     0

La partition d est reservée et correspond au disque dur (la taille de 16777153 correspond bien à la taille du slice NetBSD). La partition c est aussi réservée et correspond au slice NetBSD, englobant toutes les partitions définies par l’utilisateur : a (point de montage /), b (swap) et e (/home). Comme j’utilise tout l’espace disque, la taille de c correspond à celle du disque moins les 63 blocs réservés par l’ID de slice. Ceci se matérialise au niveau de l’offset de c par rapport à d et également de a, qui débute fatalement au  63ème bloc.

A retenir :

• total sectors = size d
• size c = size d – 63
• offset c = offset a = 63
  

Etape 2 : partitionnement du 2ème disque dur (/dev/sd1)

Le slice NetBSD doit être reproduit à l’identique sur le second disque. Si  les disques ont des tailles différentes, il faut jouer avec fdisk pour créer un slice de la taille de celui du premier disque. Parfois, il est utile d’effacer la table des slices, si le disque a déjà été partitionné :

netbsd# dd if=/dev/zero of=/dev/rsd1d bs=8k count=1

netbsd# fdisk -0ua /dev/rsd1d
Partition table:
0: NetBSD (sysid 169)
 start 63, size 16777153 (8192 MB, Cyls 0-1044/85/1), Active
 PBR is not bootable: All bytes are identical (0x00)

Au niveau des partitions, c’est différent : une unique partition dédiée au RAID est créée. Cette partition va devenir le pseudo-périphérique disque RAID. C’est sur celui-ci que nos partitions /, swap et /home seront créées. RAIDframe impose cette limitation de ne fonctionner que sur une seule partition par disque.

Sur /dev/sd1, on édite la table des partitions et on créé la partition a avec comme type RAID, de taille égale à l’espace disque total moins les 63 blocs d’identification. Pour faire simple, il suffit de dupliquer la ligne de la partition c pour le slice a et y changer le type.

netbsd# disklabel -r -e -I sd1
total sectors: 16777216

4 partitions:
#        size    offset     fstype [fsize bsize cpg/sgs]
 a:  16777153        63       RAID
 c:  16777153        63     unused      0     0
 d:  16777216         0     unused      0     0

Etape 3 : initialisation du RAID

Pour le moment, seul le second disque est intégrable au RAID. Il faut donc ruser et créer un faux disque /dev/sd9 qui sera retiré une fois /dev/sd0 intégré.

On établit le fichier de configuration du RAID entre /dev/sd9 et /dev/sd1 :

netbsd# more /root/raid0.conf
START array
1 2 0

START disk
/dev/sd9a
/dev/sd1a

START layout
128 1 1 1

START queue
fifo 100

Le faux disque est  créé :

netbsd# cd /dev/
netbsd# sh MAKEDEV sd9

L’initialisation du pseudo-périphérique RAID peut commencer. Il sera accessible par /dev/raid0. En retour, RAIDframe signale un élément manquant : ceci est normal. L’identifiant RAID est fixé à la date actuelle et le calcul de parité est lancé. La dernière commande affiche le statut du RAID :

netbsd# raidctl -C /root/raid0.conf raid0
netbsd# raidctl -I 200910 raid0
netbsd# raidctl -i raid0

netbsd# raidctl -s raid0

Les partitions /, swap et /home peuvent être créées :

netbsd# disklabel raid0 > /root/disklabel.raid0
netbsd# more /root/disklabel.raid0
netbsd# /dev/rraid0d:
total sectors: 16777088

4 partitions:
#        size    offset     fstype [fsize bsize cpg/sgs]
 a:  16777088         0     4.2BSD      0     0     0
 d:  16777088         0     unused      0     0

Comme avant, il faut se baser sur la taille du disque /dev/raid0 (16777088) pour calculer les tailles des partitions  :

• size a = 4 * 1024 * 1024 * 2 = 8388608 blocs
• offset a = 0
• size b = 1 * 1024 * 1024 * 2 = 2097152
• offset a  = size a = 2097152
• size e = size d – size a – size b = 16777088 – 8388608 – 2097152 = 6291328
• offset e = size a + size b = 10485760

Soit :

a:   8388608         0     4.2BSD      0     0     0
b:   2097152   8388608     swap        
d:  16777088         0     unused      0     0     0
e:   6291328  10485760     4.2BSD      0     0     0

La table de partitions peut être écrite et les systèmes de fichiers FFSv2 / et /home créés :

netbsd# disklabel -R -r raid0 disklabel.raid0
netbsd# newfs -O 2 /dev/rraid0a
netbsd# newfs -O 2 /dev/rraid0e

Une nouvelle limite doit être contourner : sur une version de NetBSD antérieure à la 5, les crash dumps du noyau ne peuvent être stockés que sur un périphérique disque réel. Ici, ce n’est pas nécessaire, mais la manipulation est à connaître. Si la swap /dev/raid0b ne peut être utilisée, rien ne nous interdit d’utiliser la swap « réelle » sur /dev/sd1 (et par la suite /dev/sd0). Il faut corriger la table de partitions du second disque :

netbsd# disklabel sd1 > /root/disklabel.sd1
netbsd# more /root/ disklabel.sd1
 a:  16777153        63       RAID
 c:  16777153        63     unused      0     0
 d:  16777216         0     unused      0     0

La taille de la swap réelle est identique à celle créé sur /dev/raid0. Il faut juste prendre en compte dans l’offset la taille réservée au bloc du RAID (64 blocs). Soit :

• size /dev/sd1b = size /dev/raid0b
• offset /dev/sd1b = 63 + 64 + offset /dev/raid0b

Soit :

a:  16777153        63       RAID
b:    273105   8402122       swap
c:  16777153        63     unused      0     0
d:  16777216         0     unused      0     0

Attention, un mauvais calcul de l’offset peut se manifester par un écrasement de vos données !

netbsd# disklabel -R -r /dev/sd1 disklabel.sd1

disklabel signale que la partition a écrase la partition b : ceci est tout à fait normal car b est située dans a.

Etape 4 : copie du système

Les partitions RAID sont montables et le dump des données depuis le premier disque est réalisable :

netbsd# mount /dev/raid0a /mnt
netbsd# dump -0 -f - / | (cd /mnt && restore -x -f -)

netbsd# mount /dev/raid0e /mnt/home
netbsd# dump -0 -f - /home | (cd /mnt/home && restore -x -f -)

Le fichier fstab du RAID doit à présent pointer sur les partitions RAID :

netbsd# vi /mnt/etc/fstab
/dev/raid0a     /       ffs     rw,log,noatime   1 1
/dev/raid0b     none    swap    sw               0 0
/dev/raid0e     /home   ffs     rw,log,noatime   1 2
kernfs          /kern   kernfs  rw
ptyfs           /dev/pts        ptyfs   rw
procfs          /proc   procfs  rw
/dev/cd0a       /cdrom  cd9660  ro,noauto

Avant de redémarrer, quelques modifications sont à effectuer. La swap doit être désactivée pour le prochain démarrage afin d’empêcher l’erreur de parité du RAID :

netbsd# cat >> /mnt/etc/rc.conf << EOF
swap_off=YES
EOF

Le MBR doit être écrit sur sd1, ce qui permettra de démarrer le système lorsque sd0 ne fonctionne plus :

netbsd# /usr/sbin/installboot -v /dev/rsd1a /usr/mdec/bootxx_ffsv2

Reste à activer le flag d’autoconfiguration du RAID pour son activation au prochain démarrage :

netbsd# raidctl -A -root raid0

A présent, le système peut être redémarré sur le RAID. Mais il ne faut plus utiliser la commande reboot qui démonte mal la swap, ce qui entrainerait une reconstruction du RAID au boot suivant. Il faut  utiliser à la place shutdown :

netbsd# shutdown -r now

Etape 5 : premier démarrage en RAID

Les partitions RAID doivent être utilisées :

netbsd# df -h
Filesystem        Size       Used      Avail %Cap Mounted on
/dev/raid0a       3.9G       175M       3.5G   4% /
/dev/raid0e       2.9G       2.9M       2.8G   0% /home
kernfs            1.0K       1.0K         0B 100% /kern
ptyfs             1.0K       1.0K         0B 100% /dev/pts
procfs            4.0K       4.0K         0B 100% /proc

netbsd# swapctl -l
Device      512-blocks     Used    Avail Capacity  Priority
/dev/raid0b    2097152        0  2097152     0%    0

netbsd# raidctl -s raid0
Components:
 component0: failed
 /dev/sd1a: optimal
No spares.
component0 status is: failed.  Skipping label.
Component label for /dev/sd1a:
 Row: 0, Column: 1, Num Rows: 1, Num Columns: 2
 Version: 2, Serial Number: 200910, Mod Counter: 60
 Clean: No, Status: 0
 sectPerSU: 128, SUsPerPU: 1, SUsPerRU: 1
 Queue size: 100, blocksize: 512, numBlocks: 16777088
 RAID Level: 1
 Autoconfig: Yes
 Root partition: Yes
 Last configured as: raid0
Parity status: DIRTY
Reconstruction is 100% complete.
Parity Re-write is 100% complete.
Copyback is 100% complete.

Le RAID est dégradé et le premier disque peut enfin être intégré. Il faut en premier lieu lui écrire sa table de partition RAID, identique à celle du second disque :

netbsd# disklabel -R -r /dev/sd0 /root/disklabel.sd1

L’ajout du disque au RAID s’effectue de cette façon :

netbsd# raidctl -a /dev/sd0a raid0
netbsd# raidctl -F component0 raid0

L’état de la reconstruction peut être affichée en temps réel :

netbsd# raidctl -S raid0
Reconstruction is 21% complete.
Parity Re-write is 100% complete.
Copyback is 100% complete.
Reconstruction status:
 91% |************************************   | ETA:    00:01

netbsd# raidctl -s raid0
Components:
 component0: spared
 /dev/sd1a: optimal
Spares:
 /dev/sd0a: used_spare
component0 status is: spared.  Skipping label.
Component label for /dev/sd1a:
 Row: 0, Column: 1, Num Rows: 1, Num Columns: 2
 Version: 2, Serial Number: 200910, Mod Counter: 61
 Clean: No, Status: 0
 sectPerSU: 128, SUsPerPU: 1, SUsPerRU: 1
 Queue size: 100, blocksize: 512, numBlocks: 16777088
 RAID Level: 1
 Autoconfig: Yes
 Root partition: Yes
 Last configured as: raid0
Component label for /dev/sd0a:
 Row: 0, Column: 0, Num Rows: 1, Num Columns: 2
 Version: 2, Serial Number: 200910, Mod Counter: 61
 Clean: No, Status: 0
 sectPerSU: 128, SUsPerPU: 1, SUsPerRU: 1
 Queue size: 100, blocksize: 512, numBlocks: 16777088
 RAID Level: 1
 Autoconfig: Yes
 Root partition: Yes
 Last configured as: raid0
Parity status: clean
Reconstruction is 100% complete.
Parity Re-write is 100% complete.
Copyback is 100% complete.

Une fois la reconstruction complète, le MBR est à regénérer sur le premier disque :

netbsd# /usr/sbin/installboot -v /dev/rsd0a /usr/mdec/bootxx_ffsv2

Le RAID1 est opérationnel.

Quelques commandes utiles pour nettoyer la mail queue d’un serveur de messagerie Exim.

• Obtenir le nombre de messages d’un expéditeur :

# exiqgrep -f '<user@domain.xyz>' -c

Cette commande permet de valider l’expression régulière acceptée par les options -f et -s.

• Supprimer tous les messages de l’expéditeur spécifié :

# exiqgrep -f '<user@domain.xyz>' -i | xargs exim -Mrm

• Supprimer tous les messages d’un destinataire spécifié :

# exiqgrep -s '<user@domain.xyz>' -i | xargs exim -Mrm

• Supprimer tous les messages vieux de plus de 2 heures (durée en secondes) :

# exiqgrep -o 7200 -i | xargs exim -Mrm

• Supprimer tous les messages gelés :

# exiqgrep -z -i | xargs exim -Mrm

J’ai réussi à faire fonctionner le CMS ezPublish sous Nginx. Rien de particulier au niveau des règles de réécriture, hormis la distinction de Nginx entre break et last, qui dans le premier cas empêche l’exécution de l’interpréteur PHP-CGI. Ma configuration permet d’exécuter tous les scripts PHP existants à la racine. Dans le cas d’un fichier inexistant, la page d’erreur 404 ezPublish est affichée.

N’oubliez pas de fixer l’option ForceVirtualHost à true dans votre fichier site.ini pour bénéficier de la réécriture simplifiée des URL.

server {
   listen 80;
   server_name  ezpublish.bhuisgen.my.domain;
   root /Users/bhuisgen/Sites/ezpublish/www/html;
   index index.php;

   if (!-f $request_filename) {
       rewrite ^(.*)$ /404;
   }

   location ~ "^/[^/]*\.php$" {
      set $script "index.php";

      if ( $uri ~ "^/(.*\.php)" ) {
         set $script $1;
      }

      fastcgi_pass   unix:/opt/local/var/run/nginx/fcgi-php.sock;
      fastcgi_index  index.php;
      fastcgi_param  SCRIPT_FILENAME /Users/bhuisgen/Sites/ezpublish/www/html/$script;
      include        fastcgi_params;
   }

   location / {
      rewrite "^/var/storage/(.*)$" "/var/storage/$1" break;
      rewrite "^/var/([^/]+)/storage/(.*)$" "/var/$1/storage/$2" break;
      rewrite "^/var/cache/texttoimage/(.*)$" "/var/cache/texttoimage/$1" break;
      rewrite "^/var/([^/]+)/cache/texttoimage/(.*)$" "/var/$1/cache/texttoimage/$2" break;
      rewrite "^/design/([^/]+)/(stylesheets|images|javascript)/(.*)$" "/design/$1/$2/$3" break;
      rewrite "^/share/icons/(.*)$" "/share/icons/$1" break;
      rewrite "^/extension/([^/]+)/design/([^/]+)/(stylesheets|images|javascripts|javascript|flash?)/(.*)$" "/extension/$1/design/$2/$3/$4" break;
      rewrite "^/packages/styles/(.+)/(stylesheets|images|javascript)/([^/]+)/(.*)$" "/packages/styles/$1/$2/$3/$4" break;
      rewrite "^/packages/styles/(.+)/thumbnail/(.*)$" "/packages/styles/$1/thumbnail/$2" break;
      rewrite "^/favicon\.ico$" "/favicon.ico" break;
      rewrite "^/robots\.txt$" "/robots.txt" break;
      rewrite "^/var/cache/debug.html(.*)$" "/var/cache/debug.html$1" break;
      rewrite "^/var/([^/]+)/cache/public/(.*)$" "/var/$1/cache/public/$2" break;
      rewrite "^/var/([^/]+)/cache/debug\.html(.*)$" "/var/$1/cache/debug.html$2" break;
      rewrite "^/crossdomain\.xml$"  "/crossdomain.xml" break;
      rewrite "^/content/treemenu/?$" "/index_treemenu.php" last;
      rewrite "^(.*)$" "/index.php?$1" last;
   }
}

En cas de mise à jour d’une version majeure d’OpenLDAP, voici la procédure à respecter pour reconstruire votre base LDAP.

Etape 1 : export de votre base LDAP :

# /etc/init.d/slurpd stop
# /etc/init.d/slapd stop
# slapcat -l /root/ldapdump.raw
# egrep -v '^entryCSN:' < /root/ldapdump.raw > /root/ldapdump
# mv /var/lib/openldap-data/ /root/openldap-data-backup/

Etape 2 : mise à jour et configuration de la nouvelle version d’OpenLDAP.

Etape 3 : import du dump :

# slapadd -l /root/ldapdump
# chown <ldap_user>:<ldap_user> /var/lib/openldap-data/*
# /etc/init.d/slapd start

Pour activer et démarrer définitivement sous le noyau 64 bits de Snow Leopard, la commande à exécuter est la suivante :

$ sudo nvram boot-args="arch=x86_64"

Votre machine doit évidemment supporter le 64 bits (noyau + EFI64 + CPU), mais aussi vos drivers qui doivent être 64 bits (ce qui n’est pas le cas de tous les constructeurs actuellement…). Si tout se passe bien un uname -a doit vous indiquer le mode x86_64.

Pour basculer sur le noyau 32 bits par défaut, la commande suivante sera nécessaire :

$ sudo nvram boot-args=""

Parfois, j’avoue hésiter entre tout réinstaller et mettre les mains dans le cambouis… alors autant faire ceci :

Inutile de préciser qu’il faut être adulte !

Source : http://www.commandlinefu.com/commands/view/3786/better-russian-roulette

Pour utiliser Mailman avec Nginx, il n’y a aucunement besoin d’un serveur externe pour l’exécution CGI. Une configuration adaptée permet de se passer du serveur THTTPD, utilisé dans ce tutorial.

En premier lieu, lisez mon article traitant de l’exécution CGI/Perl sous Nginx et installez y le wrapper. Il reste  ensuite à configurer les deux logiciels.

Côté Nginx, toute la difficulté se situe dans le passage des arguments aux scripts CGI. Par ex :

URL : http://127.0.0.1/mailman/listinfo/my_mailing_list
URI pour Mailman : listinfo/my_mailing_list

Le script CGI listinfo est exécuté avec la variable d’environnement PATH_INFO utilisée pour passer les arguments, égale ici à /my_mailing_list. Bref, des rewrites rules bien conçues et une variable spécifique pour le module FastCGI et Mailman peut ensuite fonctionner à 100 %  grâce à Nginx.

Voici la directive de l’hôte :

server {
listen          80;
server_name     localhost;
root            /var/www/localhost/htdocs;

location /mailman/ {
 rewrite "^/mailman/$" http://$host/mailman/listinfo;

 set $script $fastcgi_script_name;
 set $args /;

 if ($request_uri ~ "^/mailman/(.[^\/]*){1}(.*)$" ) {
  set $script /$1;                             
  set $args $2;
 }

 fastcgi_pass   unix:/tmp/fcgi-perl.sock;
 fastcgi_param  SCRIPT_FILENAME /usr/lib/mailman/cgi-bin$script;
 fastcgi_param  PATH_INFO $args;
 include        fastcgi_params;
}

location /images/mailman/ {
 alias   /usr/lib/mailman/icons/;
}

eau de Mailman, les scripts CGI doivent être exécutés par l’utilisateur déclaré lors de sa compilation (option –with-cgi-gid du script configure). Si vous ne pouvez pas modifier cette valeur (ce qui est le cas avec une installation d’un package binaire), il faut modifier les droits sur la socket UNIX fcgi-perl.sock et ajouter l’utilisateur au groupe utilisé par Nginx.

Par exemple, sous Gentoo, je fixe le propriétaire de la socket à apache:nginx et j’ajoute l’utilisateur apache (mailman) au groupe nginx :

# ls -l fcgi-perl.sock
srw-rw---- 1 apache nginx 0 2009-10-06 11:53 fcgi-perl.sock

Rendez-vous ensuite sur http://127.0.0.1/mailman et cliquez sur une mailing list pour valider la configuration.

Encore une petite boulette de la team Gentoo pour mod_suphp en version 0.7.1  : le port installe un fichier de configuration non valide, ce qui provoque une inexécution de tous les scripts PHP ! C’est très fâcheux pour un module qui justement  sécurise l’exécution PHP…

Il faut donc corriger le bloc suivant dans /etc/suphp.conf :

[handlers]
;Handler for php-scripts
x-httpd-php=php:/usr/lib/php5/bin/php-cgi
x-httpd-php5=php:/usr/lib/php5/bin/php-cgi
x-httpd-phtml=php:/usr/lib/php5/bin/php-cgi

;Handler for CGI-scripts
x-suphp-cgi=execute:!self

par celui-ci :

[handlers]
;Handler for php-scripts
x-httpd-php="php:/usr/lib/php5/bin/php-cgi"
x-httpd-php5="php:/usr/lib/php5/bin/php-cgi"
x-httpd-phtml="php:/usr/lib/php5/bin/php-cgi"

;Handler for CGI-scripts
x-suphp-cgi="execute:!self"

Vous noterez donc les doubles quotes en plus.

Sous Windows et Linux, VMWare 6 intègre un serveur VNC et permet un accès console VNC aux machines virtuelles. Toutefois sur Mac, VMWare Fusion ne propose pas cette option dans l’interface graphique de configuration. Cela demeure possible, en l’activant manuellement :

- fermer VMWare Fusion.
- placez-vous dans le répertoire de stockage de vos VM (fichiers  .vmwarevm).
- cliquez droit sur votre VM et sélectionnez « Afficher le contenu du paquet ».
- ouvrez le fichier à l’extension .vmx avec un éditeur de texte.
- ajoutez-y les lignes suivantes :

RemoteDisplay.vnc.enabled = "TRUE"
RemoteDisplay.vnc.port = "5901"
RemoteDisplay.vnc.password = "mot_de_passe"

Les options sont explicites, assurez-vous que le port d’écoute soit disponible.

Pour finir, lancez la VM et votre client VNC sur vnc://127.0.0.1:5901. Pour ce qui est de l’accès distant, SSH restera comme toujours votre ami.

Remarque : deux options en plus pour faciliter l’accès au BIOS setup :

bios.forceSetupOnce = "TRUE"
bios.bootDelay = "1500"

La première option ne marche que pour le boot suivant (le flag est désactivé ensuite). BootDelay est alors utile pour augmenter le délai en millisecondes de bascule par Fn + F2.