Les Fourmis Acidulées en concert
October 2nd, 2009 by nono
C’est le mercredi 28 octobre prochain à la cantine de Belleville.
Tags: concert, fourmis acidulées
Posted in musique | Comments (0)
Choisir le bon /usr/sbin/sendmail avec puppet
September 2nd, 2009 by nono
Un peu de contexte
J’utilise linux-vserver sur une poignée de machines qui hébergent chacune quelques dizaines d’instances d’OS. Dans mon installation de base (CentOS), chaque isolateur fait tourner sendmail pour envoyer le mail local vers l’extérieur ; je parle essentiellement des rapports de logwatch et autres cronneries. Avec tous les problèmes habituels en cas de forte charge, ce qui arrive assez facilement dans ce genre de configuration.
Solution : installer un /usr/sbin/sendmail un peu plus léger, en l’occurrence ssmtp, sur toutes les machines sauf les vrais serveurs SMTP, qui eux font tourner Postfix.
La configuration puppet
Un petit extrait de ma config (nettement plus complète mais pas publiable en l’état) :
class mail{
}
class mail::smtp inherits mail {
package { "ssmtp": ensure => installed, }
file { "/etc/ssmtp/ssmtp.conf":
source => [
"puppet:///files/mail/ssmtp.conf.$hostname",
"puppet:///mail/ssmtp.conf",
],
owner => root,
group => root,
mode => 0644,
require => Package["ssmtp"],
}
exec { "setup_mta":
command => "/usr/sbin/update-alternatives --set mta /usr/sbin/sendmail.ssmtp",
subscribe => Package["ssmtp"],
refreshonly => true,
}
}
class mail::postfix inherits mail::smtp {
package { ["postfix", "postfix-pflogsumm"]: ensure => installed }
service { "postfix":
enable => true,
ensure => running,
hasstatus => true,
subscribe => Package["postfix"],
}
Exec["setup_mta"] {
command => "/usr/sbin/update-alternatives --set mta /usr/sbin/sendmail.postfix",
subscribe => Package["postfix"],
}
}
L’intérêt de la chose : toutes les machines sont dans la classe mail::smtp, et Postfix est installé uniquement là où il faut, et surtout une même machine peut cumuler les rôles « serveur SMTP » et « autre chose » et tout se passera comme il faut.
Pour le moment, ça installe ssmtp même sur les machines où il n’est pas nécessaire, on verra à corriger ça dans la prochaine version. 
Tags: postfix, puppet, ssmtp
Posted in geekeries | Comments (0)
Nagios et LDAP, partie 2
August 27th, 2009 by nono
Une petite mise à jour du stockage de la configuration LDAP dans Nagios, puisque j’ai eu besoin de différencier les périodes de surveillance : nous avons une application web qui est arrêtée pendant la nuit pour des opérations de maintenance genre sauvegarde et nettoyage des logs.
Le schéma LDAP
J’ai ajouté un attribut optionnel timePeriod à la classe nagiosHost. Il doit contenir le nom d’une période définie ailleurs dans la config (chez moi elles sont en dur dans localhost.cfg, ça vient de la configuration d’origine de Nagios) ; s’il n’est pas renseigné, on conviendra qu’il vaut 24×7 par défaut.
En langage schéma LDAP, ça se dit comme ça :
attributetype ( 1.3.6.1.4.1.7568.1.1.33 NAME ( 'timePeriod' ) SUP name )
objectclass ( 1.3.6.1.4.1.7568.1.2.12 NAME 'nagiosHost' SUP top AUXILIARY
DESC ''
MAY ( nagiosService $ nagiosName $ timePeriod ) )
Notez que je ne fais pas de différence entre les différents services associés à un hôte, ils sont tous surveillés ou pas en même temps. Dans mon cas ça se justifie, puisque je n’installe qu’une seule application par machine (virtuelle). Si vous avez besoin de surveiller plusieurs services sur la même machine de façon différenciée, je suppose que vous pouvez créer plusieurs fiches LDAP pour la machine en question, mais ça me semble un peu compliqué et ça risque d’avoir des effets de bord pour les autres applications qui s’appuient sur le même annuaire.
Les scripts
Le script gen-nagios-services-hosts de la dernière fois demande quelques modifications minimes pour s’adapter au nouveau schéma. Le patch étant presque aussi long que le script lui-même, voici la nouvelle version directement en ligne.
Tags: LDAP, Nagios
Posted in geekeries | Comments (0)
Stocker la configuration de Nagios dans un annuaire LDAP
August 25th, 2009 by nono
À ma gauche, un serveur Nagios. À ma droite, un annuaire LDAP. Le but de la manoeuvre est de générer automatiquement la configuration du premier à partir du deuxième. L’intérêt de la chose : s’assurer que le serveur Nagios est toujours à jour et surveille bien ce qu’il doit (étant entendu que l’annuaire LDAP est lui-même tenu à jour, ce qui devrait être le cas).
Tout ça s’applique à Nagios 2.x ; je l’utilise simplement parce que c’est la version immédiatement installable sur mon OS de prédilection (CentOS 5 avec EPEL). Je n’ai pas regardé à quoi ressemblait Nagios 3 mais j’imagine que les principes sont facilement adaptables.
Vue d’ensemble
Je suis parti de la configuration par défaut dont j’ai gardé trois fichiers : nagios.cfg, localhost.cfg et cgi.cfg, auxquels j’ai juste apporté les quelques modifications nécessaires pour les adapter à mon installation locale. La seule partie que je vais détailler est la liste des inclusions au début du fichier nagios.cfg, qui ressemble à ça :
# host and service definitions for monitoring this machine
cfg_file=/etc/nagios/localhost.cfg
# human-maintained parts, if any
cfg_dir=/etc/nagios/admin
cfg_dir=/etc/nagios/hosts
cfg_dir=/etc/nagios/services
# script-generated parts
cfg_file=/etc/nagios/commands.cfg
cfg_file=/etc/nagios/hosts.cfg
cfg_file=/etc/nagios/services.cfg
Le premier fichier, localhost.cfg, provient tel quel de la distribution Nagios. Les répertoires admin, hosts et services sont là au cas où je voudrais ajouter des bouts de config à la main. Les trois derniers fichiers sont générés par les scripts dont on va parler dans la suite.
Les commandes
Définitions
Une commande, au sens Nagios, se compose d’un nom (le paramètre command_name dans le fichier de config) et d’une ligne de commande (le paramètre command_line). J’ai donc ajouté une classe regroupant ces deux attributs à mon schéma LDAP. J’ai aussi crée un attribut command qui n’existait pas. Au final, ça donne ça :
attributetype ( 1.3.6.1.4.1.7568.1.1.32 NAME ( 'command' ) SUP name )
objectclass ( 1.3.6.1.4.1.7568.1.2.15 NAME 'nagiosCommand' SUP top STRUCTURAL
DESC 'Nagios command definition'
MUST ( cn $ command )
MAY ( description ) )
Données
Une fois le schéma à jour, une commande se définit comme ça :
dn: cn=check_ldap,ou=commands,ou=nagios,ou=tools,dc=ircam,dc=fr
objectClass: nagiosCommand
objectClass: top
cn: check_ldap
command: $USER1$/check_ldap -H $HOSTADDRESS$ -b dc=ircam,dc=fr -3
Pour ceux que ça intéresse, j’ai bricolé un bout de script Perl pour convertir le fichier commands.cfg d’origine au format LDIF ; il est disponible ici. Attention, il ne fonctionnera pas sur un fichier qui n’est pas écrit comme le commands.cfg d’origine de Nagios (disposition différente des espaces ou autres variantes du genre).
Génération
Maintenant qu’on a nos commandes dans l’annuaire, il suffit de les relire pour générer le fichier commands.cfg. Je fais ça avec ce script Python.
Le serveur et le DN de base LDAP y sont codés en dur, promis, dans la prochaine version, je mets des options.
Les machines et les services
Dans mon esprit, les machines et les services « vont ensemble » ; je génère donc les fichiers hosts.cfg et services.cfg en même temps.
Définitions
Un service Nagios, tout comme une commande, est défini avant tout par un nom et une commande à exécuter (la commande en question n’a rien à voir avec celles du paragraphe précédent, mais peu importe, on n’a pas besoin de définir un attribut LDAP différent). Il doit aussi avoir une description (pas peut, doit, sinon Nagios râle très fort). Dans mon cas, les autres options (contacts, périodicités et autres) sont communes à tous les services et codées en dur dans le script de génération. Encore une fois, on verra dans la prochaine version pour une approche plus propre.
Une machine, quant à elle, est définie par un nom d’hôte, une adresse IP (tous deux définis dans la classe d’objet ipHost), une liste de services et éventuellement un alias qui apparaîtra dans l’interface web. Tout comme pour les services, tout le reste est pour le moment défini en dur dans le script de génération.
En termes de schéma LDAP, ça nous donne ça :
attributetype ( 1.3.6.1.4.1.7568.1.1.28 NAME ( 'nagiosService' ) SUP name )
attributetype ( 1.3.6.1.4.1.7568.1.1.29 NAME ( 'nagiosName' ) SUP name )
objectclass ( 1.3.6.1.4.1.7568.1.2.14 NAME 'nagiosServiceType' SUP top STRUCTURAL
DESC 'Nagios service definition'
MUST ( cn $ command $ description ) )
objectclass ( 1.3.6.1.4.1.7568.1.2.12 NAME 'nagiosHost' SUP top AUXILIARY
DESC ''
MAY ( nagiosService $ nagiosName ) )
Données
Maintenant qu’on sait ce que sont un service et une machine, on peut en ajouter dans l’annuaire. Il y a quelques bricoles pas strictement indispensables pour nous dans ce qui suit ; l’annuaire LDAP ne sert pas que pour Nagios.
dn: cn=ldap,ou=services,ou=nagios,ou=tools,dc=ircam,dc=fr
objectClass: nagiosServiceType
objectClass: top
cn: ldap
command: check_ldap
description: LDAP
dn: cn=ldap4.ircam.fr,ou=virtuels,ou=Hosts,dc=ircam,dc=fr
cn: ldap4.ircam.fr
ipHostNumber: 129.102.6.196
objectClass: top
objectClass: device
objectClass: ircamDevice
objectClass: ieee802Device
objectClass: bootableDevice
objectClass: ipHost
objectClass: nagiosHost
nagiosService: ldap
Génération
On utilise le petit frère du script précédent. Il crée deux fichiers hosts.cfg et services.cfg dans le répertoire courant sans se poser de questions ; attention à ne pas effacer de données importantes !
Servez chaud !
En cadeau puisque vous êtes sages, le bout de Makefile qui va bien pour utiliser tout ça :
all:
/usr/local/sbin/gen-nagios-hosts-services
/usr/local/sbin/gen-nagios-commands > commands.cfg
/bin/chmod 0644 hosts.cfg services.cfg commands.cfg
/sbin/service nagios restart
La semaine prochaine, si j’ai le temps, vous aurez la classe puppet qui va avec.
Edit 26/08/2009 : la description des services est obligatoire.
Tags: LDAP, Nagios
Posted in geekeries | Comments (1)
Une nouvelle salle machines
July 10th, 2009 by nono
Des nouvelles baies, un bon paquet de câbles et des jours de boulot.
Avant
Après
Ça a de la gueule, non ?
Tags: baies, photos, salle machines
Posted in geekeries | Comments (0)
Je suis une rock star !
July 7th, 2009 by nono
Pour ceux qui ont un lecteur flash propriétaire installé :
http://www.dailymotion.com/Fourmis_acidulees09
Pour les autres, il y a moyen de voir quand même ce dont il est question en passant par exemple par http://clipnabber.com/.
Le type qui fait le kéké avec la basse à lumières, c’est moi.
Tags: concert, fourmis acidulées
Posted in musique | Comments (0)
Fuckin’ Bruges
February 27th, 2009 by nono
Hier, expédition à Bruges.
Tags: bruges, photos, tourisme
Posted in photos | Comments (0)
Paris by night : Notre-Dame et ses environs
February 13th, 2009 by nono
Une petite balade en soirée dans Paris avec mon vieux Sony en main.
Aucune retouche si ce n’est un recadrage, pas mal du tout pour un compact de 2003.
Tags: paris, photos
Posted in photos | Comments (0)
Le Louvre by night
January 28th, 2009 by nono
Juste une paire de photos prises avec mon vieux compact et un minimum de retouches.
Tags: paris, photos
Posted in photos | Comments (0)
Transformer un NAS NeutralNAS NE52PRO en Thecus N5200PRO
January 8th, 2009 by nono
Transtec nous a envoyé un N5200PRO avec un firmware modifié qui s’identifiait comme un NeutralNAS NE52PRO. Du coup, les modules refusent de s’installer parce que « c’est pas la bonne machine ».
Pour contourner, il faut modifier les modules SYSUSER et SSHD pour qu’ils acceptent de s’installer ; ça veut dire passer les patches suivants et les recompiler :
diff -urN N5200_SYSUSER_2.00.02/SYSUSER/Configure/install.rdf N5200_SYSUSER_2.00.02.ne52pro/SYSUSER/Configure/install.rdf
--- N5200_SYSUSER_2.00.02/SYSUSER/Configure/install.rdf 2007-01-31 18:11:44.000000000 +0100
+++ N5200_SYSUSER_2.00.02.ne52pro/SYSUSER/Configure/install.rdf 2009-01-08 14:17:40.846560965 +0100
@@ -18,8 +18,8 @@
<md:UI>Thecus</md:UI>
</md:Install>
<md:NAS>
- <md:TargetNas>Thecus</md:TargetNas>
- <md:NasType>n5200</md:NasType>
+ <md:TargetNas></md:TargetNas>
+ <md:NasType>NE52</md:NasType>
<md:NasVersion>1.00.06.5</md:NasVersion>
</md:NAS>
</rdf:RDF>
diff -urN N5200_SSHD_2.00.00/SSHD/Configure/install.rdf N5200_SSHD_2.00.00.ne52pro/SSHD/Configure/install.rdf
--- N5200_SSHD_2.00.00/SSHD/Configure/install.rdf 2007-01-17 18:17:57.000000000 +0100
+++ N5200_SSHD_2.00.00.ne52pro/SSHD/Configure/install.rdf 2009-01-08 14:18:15.080559781 +0100
@@ -18,8 +18,8 @@
<md:UI>Thecus</md:UI>
</md:Install>
<md:NAS>
- <md:TargetNas>Thecus</md:TargetNas>
- <md:NasType>n5200</md:NasType>
+ <md:TargetNas></md:TargetNas>
+ <md:NasType>NE52</md:NasType>
<md:NasVersion>1.00.06.5</md:NasVersion>
</md:NAS>
</rdf:RDF>
Les modules acceptent maintenant de s’installer ; une fois que c’est fait, on peut se connecter en ssh sur la machine et modifier le fichier /app/manifest.txt. Il doit ressembler à ça :
type n5200 producer THECUS
Voilà, la boîboîte est maintenant une « vraie » Thecus N5200PRO. On peut maintenant mettre le firmware à jour et tout marche comme il faut.
Les modules et les firmwares sont téléchargeables depuis le wiki Thecus.
Tags: Linux, NAS, Thecus
Posted in geekeries | Comments (0)