PHP 5.3, back to PHP 5.2

Comme vu dans l’article PHP 5.2 goto PHP 5.3, le passage de PHP 5.2 à PHP 5.3 lors d’un upgrade de Lenny à Squeeze peut poser des problèmes de compatibilité.

Il est possible de downgrader PHP 5.3 et de repasser (temporairement) à PHP 5.2 sur Squeeze en utilisant directement les paquets Lenny:

•  rajouter dans /etc/apt/sources.list :

deb http://ftp.fr.debian.org/debian/ lenny main contrib non-free

• modifier le fichier /etc/apt/preferences (ou /etc/apt/preferences.d/fichier) :

Package: libapache2-mod-php5 php5 php5-common php5-cli php5-mysql (…)
Pin: release a=oldstable
Pin-Priority: 1001

• désinstaller les packages PHP 5.3 :

aptitude update
aptitude remove `dpkg -l | grep php| awk '{print $2}' |tr "\n" " "`

• installer les packages PHP 5.2 en spécifiant la target lenny (oldstable) :

aptitude install -t oldstable `dpkg -l | grep php| awk '{print $2}' |tr "\n" " "`

On vérifie que les versions sont correctes et on peut redémarrer Apache.

La commande date

Commande plutôt simple et de base sur un système Unix, date a pas mal de petites options sympa.
Un petit exemple quand on construit une politique de sauvegarde sur un serveur Linux (réflexe de base à avoir quand on administre un serveur) avec par exemple l’idée de garder une archive par mois sur les deux derniers mois du répertoire de sauvegarde (nommé save).
L’idée étant en crontab par exemple d’avoir des commandes du style :

cp -al /home/save/ /home/archive/save`/bin/date +\%Y\%m\%d`
rm -rf /home/archive/save`/bin/date --date='2 months ago' +\%Y\%m\%d`

On note le date --date='2 months ago' bien pratique !

PHP 5.2 goto PHP 5.3

Passage de Debian Lenny à Debian Squeeze oblige pour tout serveur correctement infogéré, beaucoup de développeurs sont en train de valider leurs codes pour passer de PHP 5.2 à PHP 5.3.
Si vous rencontrez dans vos journaux d’erreur quelque chose comme :

PHP Parse error: syntax error, unexpected T_GOTO, expecting T_STRING or ‘(‘ in /arborescence/fichier.php on line 43

C’est que votre code PHP a été écrit avec une fonction prénommée goto ….
Or goto est un mot réservé en PHP >= 5.3.0 (car nouvelle méthode)
À vos grep/sed

crossdomain.xml pour du crossdomain en Flash

Le principe d’une animation Flash est de s’exécuter sur le navigateur du client et non pas sur votre serveur web (qui a une infogérance Evolix bien sûr ). Des restrictions sont donc en place sur les players Flash récents lorsque l’animation tente de charger des éléments extérieurs : par défaut, cela n’autorise que le chargement des images. En effet, une animation Flash malicieuse pourrait charger des éléments secrets sans ces restrictions de sécurité (par exemple, révéler le contenu d’un intranet sur un réseau interne d’entreprise) ! Néanmoins, on peut autoriser des éléments à être chargés par une animation Flash en créant un fichier crossdomain.xml du type :

<?xml version="1.0"?>
<cross-domain-policy>
        <allow-access-from domain="*"/>
</cross-domain-policy>

…que l’on placera à la racine du serveur avec les éléments à charger (et non pas sur le serveur web servant l’animation).

Prenons un exemple d’un site http://www.example.com/ contenant une animation foo.swf qui charge un fichier http://static.example.com/flux.rss : il faudra donc positionner un fichier http://static.example.com/crossdomain.xml

Pour plus de détails, voir sur http://kb2.adobe.com/cps/142/tn_14213.html

Ajouter un disque dans un volume RAID5 hardware

Prenons un serveur DELL avec un controlleur RAID et un volume RAID5 configuré. Vous l’utilisez (sous Linux bien sûr) et un jour vous avez besoin d’ajouter un disque pour avoir plus de place. Est-ce possible ?

Ça dépend du controlleur RAID !

La capacité d’étendre un volume RAID5 en recalculant l’ensemble du volume (la parité étant répartie sur tous les disques) dépend d’un controlleur RAID à un autre. Difficile de donner des proportions, mais forcément plus un controlleur sera cher plus il aura de chance de le supporter. Revenons à notre exemple d’un serveur DELL, équipé d’une classique carte RAID PERC 5/i. Après avoir rajouté un disque, si l’on va dans le BIOS de la carte RAID : aucune trace de la possibilité d’étendre un volume ! On peut le supprimer, modifier ses options, mais absolument pas rajouter un nouveau disque. En fait, cette fonctionnalité n’est pas accessible depuis le BIOS… mais elle est possible via un outil en ligne de commande ! Voici une ligne de commande permettant d’ajouter un disque dans un volume RAID5 existant :

# omconfig storage vdisk action=reconfigure controller=0 vdisk=0 raid=r5 \
 pdisk=0:0:0,0:0:1,0:0:2,0:0:3,1:0:5
Command successful!

Et au niveau système, ça se passe comment ?

Une fois cette commande lancée, on peut constater dans le BIOS que le volume RAID5 est en cours de reconstruction. On le voit aussi au niveau système (avec l’outil MegaCli) :

Reconstruction           : Completed 17%, Taken 99 min.

Cela va durer plusieurs heures où les accès au volume RAID sera très lent…

Tant que ce n’est pas terminé, le système verra toujours le volume avec son « ancienne » taille :

sd 0:2:0:0: [sda] 1754529792 512-byte logical blocks: (898 GB/836 GiB)

Une fois terminé, le système verra après un reboot la nouvelle taille :

sd 4:2:0:0: [sda] 2339373056 512-byte logical blocks: (1.19 TB/1.08 TiB)

On verra donc sans rien faire de plus la nouvelle taille via les outils fdisk/cfdisk/etc. et donc un espace supplémentaire en Free Space.

Il reste ensuite à gérer cela au niveau partitions et filesystem. Voici un exemple où l’on rajoute une partition LVM et l’on étend d’un LV existant :

# cfdisk /dev/sda
# partprobe
# pvcreate /dev/sda10
  Physical volume "/dev/sda10" successfully created
# vgextend group1 /dev/sda10
  Volume group "group1" successfully extended
# lvextend -L+250G /dev/mygroup/srv
  Extending logical volume srv to 550.00 GiB
  Logical volume srv successfully resized
# umount /srv
# resize2fs -p /dev/mygroup/srv
resize2fs 1.41.12 (17-May-2010)
Please run 'e2fsck -f /dev/mygroup/srv' first.
# e2fsck -f /dev/mygroup/srv
e2fsck 1.41.12 (17-May-2010)
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/mygroup/srv: 16/19660800 files (0.0% non-contiguous), 46720716/78643200 blocks
# resize2fs -p /dev/mygroup/srv
resize2fs 1.41.12 (17-May-2010)
Resizing the filesystem on /dev/mygroup/srv to 144179200 (4k) blocks.
Begin pass 1 (max = 2000)
Extending the inode table     XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/group1/srv is now 144179200 blocks long.
# mount /srv
# df -h /srv
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/group1-srv
                      542G  174G  341G  34% /srv

Et voilà, c’est donc possible dans certains cas.

mysql -o

Si vous avez une sauvegarde de base de données MySQL réalisée avec la commande mysqldump –all-databases il est souvent fastidieux de découper le fichier pour récupérer une base de données particulière. Une option de la commande mysql est faite pour cela : mysql -o

Vous pouvez donc restaurer une base de données ainsi :

mysql> create database foo
$ mysql -o foo < all-databases.sql

Note : la base de données foo doit déjà exister.

Connexion VPN PPTP sous Linux

Bien que le PPTP (Point-to-Point Tunneling Protocol) soit une technologie de VPN plutôt implantée dans le monde Microsoft, cela reste assez accessible sous Linux. Voici un résumé rapide de sa mise en place sous Debian :

# aptitude install ppp pptp-linux

Créer le fichier /etc/ppp/peers/<TUNNEL> :

name <LOGIN>
remotename PPTP
require-mppe-128
file /etc/ppp/options.pptp
ipparam <TUNNEL>

Ajouter la ligne suivante dans le fichier /etc/ppp/chap-secrets :

<LOGIN> PPTP <PASSWORD> *

Et, enfin, lancer le VPN ainsi :

# pppd call <TUNNEL>
# route add -net <RESEAU> dev ppp0

Nov 11 14:47:51 pppd[5648]: pppd 2.4.5 started by root, uid 0
Nov 11 14:47:51 pppd[5648]: Using interface ppp0
Nov 11 14:47:51 pppd[5648]: Connect: ppp0 <–> /dev/pts/9
Nov 11 14:47:51 pptp[5649]: anon log[main:pptp.c:314]: The synchronous pptp option is NOT activated
Nov 11 14:47:51 pptp[5656]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 ‘Start-Control-Connection-Request’
Nov 11 14:47:51 pptp[5656]: anon log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply
Nov 11 14:47:51 pptp[5656]: anon log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established.
Nov 11 14:47:52 pptp[5656]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 ‘Outgoing-Call-Request’
Nov 11 14:47:52 pptp[5656]: anon log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply.
Nov 11 14:47:52 pptp[5656]: anon log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer’s call ID 30866).
Nov 11 14:47:53 pppd[5648]: CHAP authentication succeeded
Nov 11 14:47:53 kernel: [16889.850222] PPP MPPE Compression module registered
Nov 11 14:47:53 pppd[5648]: MPPE 128-bit stateless compression enabled
Nov 11 14:47:56 pppd[5648]: local  IP address <IP1>
Nov 11 14:47:56 pppd[5648]: remote IP address <IP2>

Pour plus de détails, voir http://gcolpart.evolix.net/blog21/pptp-vpn-gateway-with-debian/ Et si vous voulez avoir un vrai serveur VPN, adressez-vous à Evolix

Augmenter le max open files

Un processus lancé sous Linux a une limite maximum de fichiers ouverts : en général c’est 1024. Parfois, certains processus manipulent beaucoup de fichiers et il est donc nécessaire d’augmenter cette limite.

Tout d’abord, voyons comment vérifier cette limite.

Dans un shell, on peut vérifier ce nombre :

$ ulimit -n
1024

Plus intéressant, on peut vérifier la limite d’un processus en fonctionnement :

# grep '^Max open files'  /proc/<pid>/limits
Max open files            2048                 2048                 files

Alors, comment modifier cette limite ?

Il faut bien avoir en tête que cette limite se change à la volée avec la commande ulimit. Tout processus lancé prendra la limite en cours dans le shell dans lequel il est lancé :

$ ulimit -n 512
$ <processus>

Néanmoins, on veut en général augmenter cette limite, et seul root peut augmenter cette limite.

Pour changer cette limite lors de l’identification d’un utilisateur via ssh, login, su, etc. on pourra utiliser le fichier /etc/security/limits.conf :

root                -       nofile          8192
jdoe                -       nofile          4096
*                   -       nofile          2048

Ainsi, lors du prochain login, un utilisateur « obtiendra » la limite indiquée.

Mais ATTENTION cela ne modifie PAS la limite des processus lancés au démarrage de la machine ! Cela peut être un vrai piège… Prenons un exemple concret : si j’augmente la limite du max open files à 8192 pour root via /etc/security/limits.conf j’ai donc cette valeur quand je me logue en root ! Si j’installe un logiciel qui se lance en daemon (ou si je redémarre un daemon déjà installé), celui se lancera  avec ma valeur courante soit 8192. MAIS si je redémarre ma machine, le logiciel se relancera cette fois avec la valeur 1024 ! J’espère que vous comprenez le piège que cela peut être !!

La meilleure solution sur un serveur destiné à lancer des daemons automatiquement (c’est souvent le cas sur un serveur )  est donc de positionner explicitement la limite avec la commande ulimit. Cela permet de positionner la bonne valeur au démarrage de la machine et pour chaque redémarrage du daemon. Sous Debian, on positionnera notamment ces valeurs dans les fichiers /etc/default/<daemon> :

# echo "ulimit -n 4096" >> /etc/default/tomcat6
# echo "ulimit -n 1337" >> /etc/default/ssh

Reverse DNS des adresses IP privées avec Bind

Tout administrateur d’un réseau d’adresses IP se doit de configurer des reverses DNS pour l’ensemble des adresses IP de son réseau. En effet, de nombreux services comme MySQL, Postfix, OpenSSH, CUPS… se servent des reverses DNS pour leur fonctionnement. Ceci est d’autant plus important si il s’agit d’adresses IP privés (10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16) car la tentative de résolution DNS se propagera sur Internet ce qui est théoriquement interdit. Plus grave, la résolution DNS échouera grâce aux réponses NXDOMAIN des serveurs blackhole d’IANA (qui sont là pour limiter ce genre de requêtes grâce au cache DNS) et le problème ne sera donc pas apparent ! Sauf qu’aller faire des requêtes DNS à l’autre bout du monde sur des serveurs plus ou moins fiables à chaque requête MySQL (exemple volontairement exagéré) n’est évidemment pas la meilleure idée. Cela peut dégrader les performances mais surtout cela provoquer de lourds dysfonctionnements (un serveur MySQL complètement hors-service par exemple…) si ces requêtes DNS ne fonctionnent pas (et ça n’est pas rare que cela arrive). Pour éviter cela, la réponse est donc de configurer une résolution DNS avec un logiciel comme Bind. L’idée est même de configurer systématiquement les reverses DNS de chaque bloc d’IP non routables. On ajoutera donc dans la configuration de Bind les blocs suivants :

zone "10.in-addr.arpa" {
        type master;
        file "/etc/bind/db.nxdomain";
};

zone "168.192.in-addr.arpa" {
        type master;
        file "/etc/bind/db.nxdomain";
};

zone "16.172.in-addr.arpa" {
        type master;
        file "/etc/bind/db.nxdomain";
};

zone "17.172.in-addr.arpa" {
        type master;
        file "/etc/bind/db.nxdomain";
};

zone "18.172.in-addr.arpa" {
        type master;
        file "/etc/bind/db.nxdomain";
};

zone "19.172.in-addr.arpa" {
        type master;
        file "/etc/bind/db.nxdomain";
};

zone "20.172.in-addr.arpa" {
        type master;
        file "/etc/bind/db.nxdomain";
};

zone "21.172.in-addr.arpa" {
        type master;
        file "/etc/bind/db.nxdomain";
};

zone "22.172.in-addr.arpa" {
        type master;
        file "/etc/bind/db.nxdomain";
};

zone "23.172.in-addr.arpa" {
        type master;
        file "/etc/bind/db.nxdomain";
};

zone "24.172.in-addr.arpa" {
        type master;
        file "/etc/bind/db.nxdomain";
};

zone "25.172.in-addr.arpa" {
        type master;
        file "/etc/bind/db.nxdomain";
};

zone "26.172.in-addr.arpa" {
        type master;
        file "/etc/bind/db.nxdomain";
};

zone "27.172.in-addr.arpa" {
        type master;
        file "/etc/bind/db.nxdomain";
};

zone "28.172.in-addr.arpa" {
        type master;
        file "/etc/bind/db.nxdomain";
};

zone "29.172.in-addr.arpa" {
        type master;
        file "/etc/bind/db.nxdomain";
};

zone "30.172.in-addr.arpa" {
        type master;
        file "/etc/bind/db.nxdomain";
};

zone "31.172.in-addr.arpa" {
        type master;
        file "/etc/bind/db.nxdomain";
};

Avec un fichier db.nxdomain quasiment vide :

$TTL 1800
@ IN    SOA     ns.example.com. dnsmaster.example.com. (
                2011111111      ;serial
                3h              ;refresh
                1h              ;retry
                1w              ;expire
                1h )            ;minimum

        IN      NS      localhost.

Ainsi, toute demande de reverse DNS sur une adresse IP privée restera en « local » et obtiendra immédiatement une réponse NXDOMAIN :

% dig -x 10.42.51.21

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 53753
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;21.51.42.10.in-addr.arpa.      IN      PTR

;; AUTHORITY SECTION:
10.in-addr.arpa.  1800 IN SOA  ns.example.com. dnsmaster.example.com. 2011111111 10800 3600 604800 3600

;; Query time: 1 msec

Indispensable sur les réseaux avec des milliers de machines mais aussi les petits réseaux de quelques machines.

Sortie d’OpenBSD 5.0

Comme chaque 1er mai et 1er novembre, une nouvelle version d’OpenBSD est sortie ce 1er novembre 2011 !  La version OpenBSD 5.0 n’est pas une version particulièrement « majeure » (elle vient simplement après la version 4.9) mais elle apporte son lot de changements et d’améliorations. Pour rappel, OpenBSD est un système BSD ultra-sécurisé, particulièrement adapté pour fonctionner comme routeur et comme firewall grâce à PF (firewalling), isakmpd (IPSEC), OpenBGP (service BGP), CARP/pfsync (redondance), OpenSSH, etc.