J’ai eu récemment un problème sur un serveur de sauvegarde avec un chargeur de bandes LTO4 qui avait changé de nom après le reboot dudit serveur. Les fichiers de configuration qui comportaient une directive vers l’emplacement du chargeur de bandes n’ont pas apprécié…

J’ai donc décidé d’attribuer un nom immuable à mon périphérique, grâce à une règle UDEV. Après l’avoir identifié, cette règle va créer un lien symbolique vers le périphérique. Il est donc important d’être rigoureux pour fournir à udev une identification précise du matériel.

Pour procéder à cette identification, nous allons nous aider de udevadm info. Udev se basant sur sysfs (/sys) nous allons devoir au préalable trouver la correspondance entre le nom de mon périphérique dans /dev et celui dans /sys.

Dans /dev mon chargeur se nomme actuellement sg9, soit /dev/sg9. La commande suivante va me permettre de trouver sa correspondance dans /sys:

me donne:

Utilisons maintenant udevadm info afin de trouver des informations pertinentes pour l’identification du matériel:

Plein d’informations découpées en rubriques vont résulter de cette commande, le but étant de prendre celles qui permettent d’identifier simplement mais efficacement le périphérique.

Attention cependant à ne pas piocher les informations dans plusieurs rubriques différentes car udev considérant chaque rubrique comme un périphérique différent, votre règle ne fonctionnerait pas.

L’autre solution serait de séparer les informations dans votre règle udev en plusieurs lignes, mais rappelez vous que plus votre règle udev est simple, mieux c’est.

Une fois que vous avez trouvé votre bonheur, il ne reste plus qu’à créer la règle udev. Pour cela, il faut créer un fichier .rules dans /etc/udev/rules.d/ et, tout comme avec le fonctionnement des runlevels, spécifier l’ordre d’exécution de la règle.

Le mien s’appelle 55-chargeur-lto4.rules et contient uniquement la ligne suivante:

Vous noterez que j’ai rajouté aux informations trouvées grâce à udevinfo un attribut SYMLINK. Cet attribut correspond à un nom que j’ai donné à mon périphérique, sous forme de lien symbolique créé dans /dev/

Pour prendre en compte à chaud la modification on va lancer la commande:

Un ptit:

Et oh magie on a comme résultat:

Bookmark It

Changer un mot de passe root perdu (on va dire perdu hein…) sous Linux, ya vraiment rien de plus simple !

Il suffit pour cela d’un accès physique à la machine ou même d’un accès type KVM. La méthode décrite ci-dessous n’a été testée qu’avec le bootloader Grub, mais on ne doit pas être loin de la vérité avec Lilo.

Voici les différentes étapes:

- Démarrez ou redémarrez la machine

- Lorsque le menu de Grub apparaît, sélectionnez le kernel sur lequel vous souhaitez faire booter la machine et appuyez sur “a“

- Au prompt “grub append>“, rajoutez init=/bin/bash à la fin de la ligne et validez en appuyant sur “Entrée”

- Maintenant que vous avez la main en root, il va falloir remonter la partition racine en lecture/écriture afin de pouvoir changer le mot de passe. Pour cela, tapez:

- Yapuka changer le mot de passe avec la commande passwd

- Par mesure de sécurité, vous pouvez remonter la partition en lecture seule avant de redémarrer la machine avec:

- Au prochain boot n’oubliez pas de retirer les modifications effectuées sur grub afin de charger normalement le kernel.

Bookmark It

Un (des) moyen de sauvegarder proprement une base Mysql est d’utiliser la commande mysqldump.
Cette commande permet d’effectuer la sauvegarde à chaud et peut séparer les squelettes des tables de leurs données (pratique par exemple pour transférer une base vers un autre serveur qui ne serait pas forcément du Mysql).

Voici un script shell qui va parser l’ensemble de vos bases Mysql puis effectuer la sauvegarde:

Le script va ici aller mettre dans /usr/local/dumps/nomdelabase (le répertoire sera créé s’il n’existe pas) l’ensemble des squelettes des tables de chaque base au format .sql ainsi que les données au format .txt

A noter que vous pouvez très bien ne pas séparer les squelettes des données en supprimant l’argument –tab. Je vous invite à vous reporter à la doc de mysqldump pour voir l’ensemble des possibilités que vous offre cette commande.

Pour restaurer tout cela, on va utiliser les commandes suivantes (et pourquoi pas les scripter elles aussi):

Bookmark It

Kixtart ( à ne pas confondre avec Kickstart de RedHat ) est un langage de script utilisé principalement pour effectuer les ouvertures de sessions sous Windows. Il est gratos ( et pourtant développé par un mec de chez Krosoft, c’est dire ! ) et super simple à utiliser. Il parait qu’il permet aussi une exécution plus rapide de l’ouverture de session que ne le ferait un vbscript…

Pour ma part, je l’ai intégré dans un contrôleur de domaine Samba à la place du bon vieux logon.bat en place.

Le principe est donc sensiblement le même, à savoir un script ( lancé avec les droits de l’utilisateur courant ) qui va parser vos droits et groupe(s) d’appartenance et mapper votre ou vos lecteurs réseaux en fonction de cela.

Je vous invite à vous rendre sur le helpdesk Kixtart http://helpdesk.kixtart.org avant de parcourir mon script afin de voir à quoi correspondent les macros et fonctions utilisées.
Votre script devra porter l’extension .kix et en fonction de votre parc clients (98 ?!, XP, Vista), vous aurez à placer ou non dans votre répertoire de logon ( genre //pdc/netlogon ) des .dll et .exe requis par Kixtart. Encore une fois, RTFM sur http://www.kixtart.org ou sur le helpdesk.

Notez le truc con, l’exécution de votre script se fera par l’intermédiaire d’un batch.

Voici dans les grandes lignes à quoi peut ressembler un script de connexion:

Vous voyez, c’est vraiment pas sorcier. Ca m’a aussi permis de réduire de moitié la taille de mon script de connexion par rapport à mon ancien logon.bat.

Je vous ai présenté une utilisation assez basique de Kixtart, cependant il ne faut pas le réduire à une simple fonction de mappage réseau. Vous pouvez vous en servir pour effectuer des opération bien plus puissantes telles que des installations et mises à jour d’applicatifs (ex: antivirus), des interactions avec des fichiers Words ou Excel, des interfaces graphiques, etc.

Bookmark It

Lors de l’installation de Zimbra, la configuration de SpamAssassin se résume au minimum.

Pour optimiser le filtrage des spams, vous pouvez configurer et activer des RBL (Realtime Blackhole List). Ces fameuses RBL vont permettre de lister les serveurs connus pour être de gros spammeurs et de catégoriser en spam les mails reçus de ces serveurs. On pourrait donc résumer ça à une grosse liste noire.

Attention cependant à ne pas utiliser n’importe quelle RBL, certaines étant plus ou moins efficaces… Je vous conseille donc d’utiliser uniquement celles répertoriées sur le site officiel de Zimbra.

Voici comment configurer et activer l’utilisation des RBL avec Zimbra:

- Connectons-nous en tant qu’utilisateur zimbra:

- Listons tout d’abord les RBL actuellement utilisées par SpamAssassin:

qui me donne:

- Récupérons les RBL en cours et ajoutons à celles-ci les RBL listées sur le site de Zimbra dans la commande suivante:

Voilà, ça devrait être déjà mieux !

Bookmark It

L’utilitaire Amrestore permet tout comme Amrecover de restaurer les fichiers sauvegardés par Amanda, mais de manière moins “fine”. En effet, si les données à sauvegarder sont trop volumineuses, Amanda effectue la sauvegarde en découpant en plusieurs morceaux les disques déclarés dans votre fichier disklist. Cela permet d’effectuer la sauvegarde plus rapidement.

Amrestore se base sur ces morceaux (chunks) pour établir une restauration. Il ne peut restaurer qu’au minimum un morceau. Pour restaurer un seul fichier, vous êtes obligé de restaurer l’intégralité du morceau dans lequel il se trouve.

Quel est alors l’intérêt d’utiliser un outil “moins puissant” ? C’est simple, contrairement à Amrecover, Amrestore n’a pas besoin des fichiers d’index pour effectuer une restauration. Si vos index sont perdus, vous pouvez donc quand même effectuer une restauration de vos fichiers.

Voici la méthode

Rembobiner la bande:

Lancer la commande pour lister le contenu de la bande:

Voici un exemple de listing qu’amrestore va vous générer:

Puis rembobiner la bande à nouveau:

Pour restaurer l’ensemble des données du serveur “pdc” présentes sur la bande nous allons faire:

Pour ne restaurer par exemple que le disque “etc” du serveur “pdc” nous allons faire:

Il y a un petit truc pour aller plus rapidement, si au préalable vous aviez lancé le listing de la bande (cf commande correspondante). Amrestore lance la recherche de l’emplacement des données sur la bande avant d’effectuer la restauration et ce processus peut prendre énormément de temps si vous avez beaucoup de données sauvegardées. Le truc consiste alors à se placer directement à l’endroit des données à restaurer, pour cela il suffit d’avoir le numéro du morceau correspondant à cet emplacement sur la bande (n° de chunk).

Exemple avec mon disque “etc” du serveur “pdc”:

4 correspondant donc au morceau où se trouve “etc”

Il ne reste alors plus qu’à décompresser l’archive restaurée pdc._etc.20080917.3.1 avec tar -xzvf

A noter, Amanda n’utilise pas de format propriétaire pour la sauvegarde de vos fichiers. Si votre serveur de sauvegarde est en rade et que vous devez faire une restauration en urgence, vous pouvez tout simplement utiliser les outils Linux pour restaurer vos bandes. Certes, ça va être du “tout ou rien” mais ce n’est pas le moment de chipoter !

En utilisant dd on va pouvoir restaurer tout une bande en un seul coup:

Bookmark It

Je n’ai jamais compris pourquoi cette option n’était pas activée par défaut, m’enfin voici comment l’activer dès l’invit de connexion de GDM:

Dans le fichier /etc/gdm/Init/Default, placer les lignes suivantes:

It works !

Bookmark It

Sous Linux, il existe plusieurs outils afin de tester les performances de votre disque dur voire même de les améliorer:

- HDPARM: J’ai pu lire un peu partout que hdparm ne fonctionne qu’avec les disques IDE. Pourtant le man est formel: “hdparm provides a command line interface to various hard disk ioctls supported by the Linux SATA/PATA/SAS “libata” subsystem and the older IDE driver subsystem.“

En gros ça fonctionne aussi avec les disques SATA (sauf condition citée plus bas…) et il suffit de tester pour s’en convaincre ! La preuve avec une tripotée d’informations sur mon disque SATA:

Effectuons maintenant un test de rapidité en lecture sur ce disque (-t) ainsi que sur son cache (-T):

hdparm vous permet aussi d’effectuer des modifications de configuration de votre disque dur, dont certaines plus ou moins risquées. Vous pouvez par exemple:

- Activer , modifier ou désactiver le DMA (Direct Memory Access) avec -d.

- Modifier le paramètrage de l’AAM (Automatic Acoustic Management) avec -M afin d’améliorer les temps d’accès disque ou à l’inverse d’avoir un disque plus silencieux mais des temps d’accès plus important.

- Démonter un disque à chaud avec -Y.

- Réinitialiser un disque avec -w (à bien réfléchir avant).

- Modifier l’APM (Advanced Power Management) avec -B.

Il est également possible de modifier la vitesse de votre lecteur CD avec l’option -E bien que je ne vois pas réellement l’intérêt d’une telle option…après tout les lecteurs sont censés gérer automatiquement cela.

NB: pour rendre vos modifications définitives, vous devrez les paramétrer dans le fichier /etc/hdparm.conf

A noter que si vous disposez d’un disque SATA et qu’il n’apparaît pas en tant que disque IDE, l’utilisation de sdparm plutôt que de hdparm va plus ou moins s’imposer. Le problème c’est que cet utilitaire pour disque SCSl est moins complet que l’autre, essayez donc de déterminer la vitesse de votre disque…

- BONNIE++: Un programme centré sur le benchmark de vos disques. Il n’est pas possible comme avec hdparm de modifier quoi que ce soit dans la configuration de votre disque.

Bonnie++ fonctionne sur tous les types de disques durs et fourni des résultats plus poussés, mais vraiment barbare à décoder !

Voyez par vous même les résultats par défaut de lecture / écriture sur le même disque SATA que précédemment:

Quelques petites explications sur cette sortie, le benchmark étant décomposé en plusieurs parties:

- sequential output et sequential input: débit en lecture / écriture octet par octet ou bloc par bloc d’un fichier de 4Go. Affichage de la consommation CPU.

- random seek: temps d’accès et charge CPU.

- sequential create: écriture séquentielle de n fichiers et charge CPU.

- random create: écriture aléatoire de n fichiers et charge CPU.

Il est bien évidemment possible d’affiner votre benchmark en modifiant par exemple la taille du fichier généré pour le test avec -s, la taille de la RAM à utiliser avec -r ou encore la désactivation du buffer avec -b.

Pour mettre en forme vos résultats, vous pouvez utilisez deux scripts perl fournis avec bonnie++: bon_csv2html afin d’exporter les résultats en html et bon_csv2txt afin d’exporter les résultats en …

Voici comment l’utiliser:

Il ne reste plus qu’à ouvrir bonnie_results.html dans un navigateur pour voir s’afficher les résultats de vos différents benchmarks dans un “joli” tableau.

Bookmark It

Sauvegarder sa base openLDAP ? Rien de plus simple si l’on prend un minimum de précautions.

Bien que vous puissiez faire cela à chaud, il est quand même conseillé de couper le service avant d’effectuer la sauvegarde. Si vous ne pouvez vous le permettre, vous pouvez également passer le démon slapd en lecture seule afin de ne pas corrompre la base sur une mauvaise manip.
Pour cela il suffit de rajouter dans le fichier de configuration slapd.conf la directive “readonly on” et de relancer le démon slapd.

Sauvegarde de la base:
- Couper le démon slapd (et vérifier qu’il se soit bien arrêté…).

- Ouvrir le fichier de configuration slapd.conf et noter le chemin indiqué par la directive “directory“: c’est le chemin d’accès à votre base LDAP.

- Dans ce répertoire, sauvegarder la totalité des fichiers .bdb qui vous permettront en cas de mauvaise manipulation de retrouver votre base dans son ancien état (il suffira alors de replacer ces fichiers dans le répertoire et de relancer le démon slapd).

- Lancer la commande:

Où -n spécifie le nombre de base LDAP dont vous disposez (correspond au nombre de directives “directory” de votre slapd.conf) et -c faisant abstraction des erreurs potentiellement rencontrées.

- Relancer le démon slapd et vérifier que tout fonctionne correctement.

Importation de la sauvegarde:

- Couper le démon slapd (et vérifier qu’il se soit bien arrêté…).

- Dans le répertoire indiqué par “directory“, sauvegarder les fichiers .bdb puis supprimer la totalité des fichiers contenu dans ce répertoire.

- Lancer la commande:

- Vérifier que les fichiers .bdb aient bien été reconstruits dans le répertoire indiqué par “directory” et qu’ils aient les bons droits d’accès (lecture et écriture seulement pour le propriétaire de la base).

- Relancer le démon slapd et vérifier que tout fonctionne correctement.

Bookmark It

Il est erroné de penser que sous Linux, une machine va utiliser toute la RAM disponible avant de commencer à swapper.

La variable swappiness permet de faire varier l’utilisation de la mémoire vive par rapport à la swap. Par défaut, cette variable est fixée à 60 sur une échelle qui va de 0 à 100.

Plus cette valeur est élevée plus le système va avoir tendance à swapper au détriment de l’utilisation de la mémoire vive.

Réduire cette valeur peut améliorer considérablement les performances du système, je vous laisse le soin de tester cela avec les commandes suivantes:

ou:

vous permettra de voir quelle est la valeur en cours de swappiness.

va par exemple fixer la valeur de 10 à swappiness.

Si vous voulez que cette modification soit conservée même après un redémarrage de la machine, il vous faudra la renseigner dans le fichier /etc/sysctl.conf en y insérant la directive suivante:

photo: jscreationzs/FreeDigitalPhotos.net

Bookmark It