Introduction

La sauvegarde de la configuration des équipements réseaux (switch, routeurs, bornes Wi-Fi, etc) est un point souvent négligé. Pourtant, ces équipements jouent souvent un rôle clé, et l'incapacité de restaurer rapidement la configuration suite à un crash matériel peut provoquer la paralysie d'un réseau pendant de longues heures. Cette sauvegarde est parfois faite de façon manuelle après la phase initiale de configuration, avec le risque d'oublier de le faire lors des prochaines modifications. Il est donc préférable, lorsque l'équipement le permet, d'effectuer cette sauvegarde de façon automatique et récurrente vers une machine distante. Voyons comment faire cela sous Cisco IOS, en utilisant le planificateur de tâches Kron, semblable au programme Cron en environnement Unix.

Mise en place

Une fois connecté au Cisco avec Telnet ou SSH, on passe en mode administrateur, puis en mode configuration :

switch> enable
switch# conf t

On crée une nouvelle policy-list pour Kron, nommée backupConfig, qui sera composée d'une ou plusieurs commandes à exécuter :

switch(config)# kron policy-list backupConfig

On utilise la commande cli pour ajouter une commande dans notre policy. Cette commande utilisera show running-config afin d'écrire la configuration courante sur la sortie standard (on pourrait aussi utiliser show startup-config pour écrire la configuration stockée en mémoire flash). Ensuite, l'opérateur pipe (|) est utilisé pour rediriger cette sortie vers la commande redirect, qui permet de rediriger un flux vers un serveur FTP, HTTP, TFTP, etc. On utilise ici un stockage vers un serveur FTP :

switch(config-kron-policy)# cli show running-config | redirect ftp://<host>/<path>/cisco.txt
switch(config-kron-policy)# exit

On définit maintenant à quel moment exécuter cette policy. Pour cela on créé une occurrence nommée backupConfig_occurence. Dans cet exemple ce sera à 01h15, chaque jour (mot-clé recurring) :

switch(config)# kron occurrence backupConfig_occurence at 01:15 recurring
switch(config-kron-occurrence)# policy-list backupConfig
switch(config-kron-occurrence)# exit
switch(config)# exit

Pour vérifier la bonne prise en compte de notre tâche, et voir le délai avant son exécution :

switch# show kron schedule

Voilà, il ne reste plus qu'à attendre l'heure programmée, et vérifier la présence du fichier envoyé. Le bon fonctionnement de tout cela nécessitant que le Cisco soit pleinement configuré (date et heure, adresse IP, passerelle réseau, DNS, etc).

Enfin, tout cela ne dispense bien sûr pas de sauvegarder cette nouvelle configuration en mémoire flash en prévision d'un futur reboot :

switch# write mem

L'interpréteur Python dispose d'une fonctionnalité permettant de mettre en cache la phase de compilation d'un fichier source. Cela se traduit par la création de fichiers avec l'extension .pyc, placés au même niveau que les fichiers .py correspondant. Ceux-ci contiennent alors le bytecode résultant de la compilation. Cela permet d'améliorer la vitesse de chargement d'un module lors de sa prochaine invocation (mais non sa vitesse d'exécution).

Par défaut, Python effectue automatiquement cette opération pour les fichiers sources composant un module lors de son chargement. Il est nécessaire que le répertoire contenant les fichiers soit accessible en écriture par l'utilisateur invoquant Python, afin de pouvoir écrire les fichiers .pyc. Cela n'est pas forcément le cas pour les modules fournis par une distribution Linux par exemple, qui vont être installés dans une arborescence système, comme /usr/lib. Ou alors dans le cas d'une application web, où le serveur web n'a pas accès en écriture aux fichiers sources.

Afin de contourner cette limitation, il est possible de pre-créer les fichiers .pyc sans même exécuter le code correspondant. Cela nécessite d'utiliser le module compileall. Voici un exemple d'utilisation pour pré-compiler tous les fichiers du répertoire mymodule :

python -m compileall ./mymodule

A noter qu'il est possible d'obtenir un niveau d'optimisation supplémentaire en invoquant Python avec l'option -o. Les fichiers compilés auront alors l'extention .pyo.

Si vous obtenez une erreur de ce type, lors d'un mysqldump par exemple :

mysqldump: Got error: 1016: Can't open file: './db/table.frm' (errno: 24) when using LOCK TABLES

C'est que votre serveur MySQL tente d'ouvrir trop de fichiers simultanément.

Pour augmenter le nombre maximal de fichiers pouvant être ouverts, vous pouvez ajuster le paramètre suivant dans la section [mysqld] du fichier my.cnf, dans la limite permise par votre système d'exploitation :

open_files_limit = 2048

La valeur par défaut étant de 1024.