automysqlbackup ou l'art de ne pas réinventer la roue

Rédigé par jdrien - - aucun commentaire
On trouve très souvent des personnes qui publient sur leur blog des scripts qui leur permettent de sauvegarder leurs bases de données avec MySQL. Ces scripts faits maison sont nombreux et tentent de répondre précisément aux besoins des rédacteurs.

En fait, la sauvegarde à chaud des bases de données simples est tellement évidente sous MySQL (un bête mysqldump suffit a priori) que l'on est vite tenté de réinventer la roue et de repartir de zéro. On arrivera certainement à un résultat satisfaisant, mais on sera sans doute passé à côté de fonctionnalités ou de problèmes importants (externalisation des sauvegardes, nettoyage, sécurité etc).

C'est suite à la publication sur le Planet Debian d'un énième script de ce type que j'ai appris qu'un outil intégré dans les dépôts de Debian existait : automysqlbackup.

Sous Debian donc, un simple sudo apt-get install automysqlbackup suffit à mettre en place une solution rapide de sauvegarde des bases sous MySQL.

D'origine, on arrive à un résultat très satisfaisant :
 - toutes les bases sont sauvegardées dans des répertoires bien ordonnés ;
 - les sauvegardes sont quotidiennes, hebdomadaires et mensuelles ;
 - les sauvegardes sont gérées par cron ;
 - pas d'utilisateur à renseigner : on utilise le mécanisme interne de debian (utilisateur MySQL debian-sys-maint) ;
 - les sauvegardes sont compressées ;
 - les sauvegardes sont nettoyées au fur et à mesure selon la durée de rétention définie.
 
Avec un peu de configuration on peut (fichier /etc/default/automysqlbackup) :
 - compresser les données avec bzip2 au lieu de gzip ;
 - exclure certaines bases ;
 - transmettre les logs de la sauvegarde par mail ;
 - effectuer des pre-traitements ainsi que des post-traitements : ainsi on peut facilement faire un rsync vers un autre serveur.

Bref, rien ne sert de réinventer la roue ! Et comme l'écrit Thomas Goirand, mainteneur du paquet pour Debian dans son commentaire à propos d'un script de sauvegarde :
Hi,
I'm the maintainer of automysqlbackup. Actually, you should really have a look into automysqlbackup. You thought about few of the problems you may have when doing backups, like the umask, and some others, but you forgot lots of them, and your script is missing many features of automysqlbackup (like daily, weekly, and monthly backups, which covers absolutely all needs). The nice part of automysqlbackup is also that it lived inside Debian for a large amount of time, and gathered feedback from users, which means that many, many, many small problems have been fixed in it. Over the years, I can even say that it's now a fork from the original code (it's unfortunate, and happened because of many things that I added in the package, plus upstream not adding them and releasing a new version which was really different and impossible to merge back).

I would strongly suggest to not work on your own, that's always less good than working as a team. If there's something that is missing in automysqlbackup (actually, I don't think there is), then it can be added, and I would welcome you to contribute patches.
PS : bien sûr, l'expérience de l'écriture de sa propre solution de sauvegarde peut être bénéfique sur le plan des connaissances. On comprend alors vraiment les choses. Et quand on voit des outils comme automysqlbackup on comprend justement qu'il est illusoire de croire que l'on peut penser à tout tout seul...

2001, odyssée de l'uptime

Rédigé par jdrien - - aucun commentaire


Plus de 2 000 jours d'uptime pour un serveur, c'est pas mal. Et c'est suffisamment rare pour que celui puisse être noté. Typiquement le type de machine qui prend la poussière dans un coin et que l'on oublie... Il est vrai aussi qu'elle ne fait pas grand chose (juste un serveur de rebond pour administrer d'autres composants de temps en temps).

Pour les curieux : il s'agit d'un serveur IBM x336 (type 8837), mono-alimenté de surcroît. Jamais eu un seul problème avec cette machine.

Pour les grincheux : oui, je sais... Un uptime de 2001 jours c'est pas top au niveau des mises à jour des composants. On se traîne des vieilleries à tous les étages : firmwares bogués, outils systèmes inexistants, obsolètes ou bogués. Et pas de mise à jour de sécurité, en tout cas pour le noyau.

Mais la performance matérielle est tout de même belle !

Comment modifier les informations produits d'une lame IBM BladeCenter HS22

Rédigé par jdrien - - aucun commentaire
Il m'est arrivé de voir que certains serveurs IBM BladeCenter HS 22 perdaient un peu la tête de temps à autre : lors d'une simple interrogation des registres DMI via la commande dmidecode j'obtenais ceci
Product Name: IBM System x -[7870TH4]-
alors que j'attendais
Product Name: BladeCenter HS22 -[7870TH4]-

Il est possible de changer ce comportement via l'utilitaire asu fourni par IBM : en effet en lançant la commande asu show all on constate que l'on a les éléments suivants :
SYSTEM_PROD_DATA.SysInfoProdName=7870TH4
SYSTEM_PROD_DATA.SysInfoProdIdentifier=
SYSTEM_PROD_DATA.SysInfoSerialNum=1234567
Le champ SYSTEM_PROD_DATA.SysInfoProdIdentifier est vide ; si on compare avec un serveur HS22 qui répond correctement on observe que ce champ contient normalement l'information qui va bien :
SYSTEM_PROD_DATA.SysInfoProdName=7870TH4
SYSTEM_PROD_DATA.SysInfoProdIdentifier=BladeCenter HS22
SYSTEM_PROD_DATA.SysInfoSerialNum=1234567

Pour changer cette valeur on lance la commande suivante :
# asu set SYSTEM_PROD_DATA.SysInfoProdIdentifier 'BladeCenter HS22'
Après un reboot de la machine, la commande dmidecode répond correctement.
À noter que cette commande peut servir aussi à changer le numéro de série ou le type de machine ; utile lors du remplacement de la carte-mère.

Connaître la version du firmware des cartes fibres QLogic

Rédigé par jdrien - - aucun commentaire
Aide-mémoire : connaître la version des pilotes et des firmwares utilisés pour les cartes QLogic.

Nous devions mettre à jour un serveur IBM x3650 M3 sous CentOS 5.4 64 bits (noyau : 2.6.18-164.15.1.el5) avec 2 cartes bi-ports QLogic en utilisant le paquet qlgc_fw_fc_4g-mb1.90-2-sysx_linux_32-64.bin. Ce paquet, selon le changelog, devait apporter les versions suivantes :
* BIOS version 2.16
* EFI version 2.27
* FCode version 3.13
* Firmware version 5.03.06
Problème : nous ne savions pas où vérifier les versions des éléments qui devaient être mis à jour. En effet, nous utilisions, à tort, la commande systool qui nous indiquait une versions de fimrware qui nous semblait pertinente :
# systool -c fc_host -v
Class = "fc_host"
  Class Device = "host5"
  Class Device path = "/sys/class/fc_host/host5"
[...]
    supported_speeds    = "1 Gbit, 2 Gbit, 4 Gbit"
    symbolic_name       = "QLE2462 FW:v4.04.09 DVR:v8.03.00.1.05.05-k"
[...]
Sous Linux, on trouve dans le répertoire /sys/class/fc_host/host?/device/scsi_host:host? on trouve des fichiers optrom_* :
# cat optrom_bios_version
2.16
# cat optrom_efi_version
2.27
# cat optrom_fcode_version
3.13
# cat optrom_fw_version
5.03.06 1154
On trouve également deux autres fichiers qui correspondent au pilote utilisé :
# cat fw_version
4.04.09 (486)
# cat driver_version
8.03.00.1.05.05-k
Pour résumer, nous avons donc une carte avec deux firmwares bien distincts :
 - le firmware embarqué sur la carte (partie matérielle) ;
 - le firmware utilisé et chargé par le pilote (partie système).

Graphes MRTG pour Apache

Rédigé par jdrien - - aucun commentaire

Script PERL apache2 :


#!/usr/bin/perl
# can return hits or bytes (counters)
@res = `GET http://localhost:80/server-status`;
foreach $res (@res) {
    if ($res =~ /Server uptime: (.*)$/) { $up = $1; last } else { next }
    if ($res =~ /Server at/) { $server = $res; last } else { next }
}

@res = `GET http://localhost:80/server-status?auto`;

foreach $res (@res) {
    if ($res =~ /Total Accesses: (\d+)/) { $d1 = $1; next }
    if ($res =~ /Total kBytes: (\d+)/) { $d2 = $1 * 1024; next }
}
$d1 = int($d1);
$d2 = int($d2);
if ($ARGV[0] eq "hits") {
    print "$d1\n";
    print "$d1\n";
} elsif ($ARGV[0] eq "bytes") {
    print "$d2\n";
    print "$d2\n";
}

print "$up\n";
$server = "mon_serveur";
print "$server\n";

que l'on lance par ./apache2 hits ou ./apache2 bytes

Partie du fichier de configuration MRTG :

## Apache2 hits ##
Target[apache2_hits]: `/etc/mrtg-sys/apache2 hits`
Colours[apache2_hits]: LIGHT BLUE#7AAFFF,BLUE#1000FF,DARK GREEN#006000,VIOLET#FF00FF
Options[apache2_hits]: perhour, nopercent, growright, noinfo, nobanner
PageTop[apache2_hits]: <h1>Hits Apache2</h1>
MaxBytes[apache2_hits]: 1000000
YLegend[apache2_hits]: hits/heure
ShortLegend[apache2_hits]: par heure   
LegendO[apache2_hits]: Hits:
Legend2[apache2_hits]: Hits horaires
Legend4[apache2_hits]: Hits Horaires max
Title[apache2_hits]: Hits horaires du serveur Apache
WithPeak[apache2_hits]: wmy

## Apache2 Traffic ##
Target[apache2_traffic]: `/etc/mrtg-sys/apache2 bytes`
Colours[apache2_traffic]: LIGHT BLUE#7AAFFF,BLUE#1000FF,DARK GREEN#006000,VIOLET#FF00FF
Options[apache2_traffic]: nopercent, growright, noinfo, nobanner
PageTop[apache2_traffic]: <h1>Traffic Apache</h1>
MaxBytes[apache2_traffic]:16000
AbsMax[apache2_traffic]:20000
YLegend[apache2_traffic]: octets/s
ShortLegend[apache2_traffic]: o/s
LegendO[apache2_traffic]: Traffic Apache:
Legend2[apache2_traffic]: Traffic Apache
Title[apache2_traffic]: Traffic du serveur Apache
WithPeak[apache2_traffic]: wmy
Legend4[apache2_traffic]: Traffic max Apache

Pour que cela fonctionne il faut bien sûr que le mod_status soit activé pour Apache.

Auto-hébergement - Recherche d'un outil de gestion d'un outil de gestion de photos en ligne

Rédigé par jdrien - - aucun commentaire

Afin de gérer notamment les diverses images collectées sur le Net, je suis à la recherche d'un outil de gestion de photos / images. Cet outil doit répondre aux critères de l'auto-hébergement, puisque je ne désire pas être tributaire d'un service centralisé Web 2.0 comme imgurl.

J'ai finalement trouvé deux prétendants :
- photoshow (http://www.photoshow-gallery.com/);
- piwigo (http://fr.piwigo.org/).

Photoshow est très léger et ne nécessite pas de BDD pour fonctionner. Tout se passe au niveau du système de fichiers. Pour l'instant, j'ai effectivement réussi à uploader des images, que je retrouve sur le disque, mais Photoshow ne me permet pas de les visualiser (embêtant).

piwigo est lui une grosse machine, qui nécessite une BDD MySQL. L'installation est très simple. Inutilisable pour l'instant, n'ayant pas la bibliothèque GD sur mon serveur.

Fichiers m3u

Rédigé par jdrien - - aucun commentaire

Les fichiers qui portent l'extension m3u sont des playlists. Ce format est apparu avec WinAMP sous Windows et est resté très simple : une URI vers un fichier musical par ligne. Son édition est donc facile et rapide, un simple éditeur de texte suffit. De plus ces playlists sont universelles, la plupart des lecteurs audio actuels permettent de lire ce type de fichier.

Il est possible de faire des scripts qui à partir de la liste des fichiers musicaux d'un répertoire génère une playlist :

find <mon_repertoire_de_musique> -type f -iname "*.mp3" | grep -v m3u > <ma_playlist>.m3u

D'autres ressources :
http://www.fmbv.nu/playlist-generator-bash
http://ubuntuforums.org/showthread.php?t=1570713
http://www.biazed.com/blog/blogs/index.php?blog=2&title=quickly_generate_your_m3u_playlist_in_a_&more=1&c=1&tb=1&pb=1

Recherche d'un lecteur audio, simple, rapide et winamp-like

Rédigé par jdrien - - aucun commentaire

J'étais à la recherche d'un lecteur audio simple, rapide, sans gestion de base de données. Bref un lecteur audio à l'ancienne, style winamp 2.X. Le fameux xmms n'est plus disponible dans les dépôts officiels debian / ubuntu, la compilation peut se faire mais bon...
La page consacrée au sujet sur le wiki d'Ubuntu est très fournie, c'est le moins que l'on puisse dire : http://doc.ubuntu-fr.org/lecteur_audio

Une alternative qui pour l'instant est plaisante à utiliser : qmmp (voir le wiki d'Ubuntu : http://wiki.ubuntu-fr.org/qmmp)

Fil Rss des articles de ce mot clé