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.

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 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

<?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

Ç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.

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.

# 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

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

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.