Why should a blog have a title ?

Comment configurer un virtual host sous apache et servir plusieurs sites web à la fois ?

Voici une page qui m’a bien servi :

http://fadace.developpez.com/oracle/nls/

Il suffit de mettre la bonne variable d’environnement. Dans les shell qui lancent mon zope (bin/runzope et bin/zopectl) , voici ce que j’ai ajouté pour régler le problème :

# Mon système et mon zope sont configurés en UTF-8. Je laisse american parce que la base est en American.

NLS_LANG=AMERICAN_AMERICA.AL32UTF8

export  NLS_LANG

I was looking for a standard function that does the same as strdup but for arbitrary memory chunks. The glibc, which is the library that gnu/linux systems are built upon, has no such function. Curious… So I googled for it a little and, guess what, only 4000 results for “memdup” query, mainly links to code of functions in Keberos, Samba and other softwares or libraries code.

Why everybody writes its own memdup ? why is not part of the standard C library ?

This can bring up some issues, because if you use multiple libraries that define their own memdup functions, you can have wired bahviors, as you expect to use lib1’s memdup but in reality you used lib2’s. Having a standard memdup function would tend to reduce such scenarios.

Take Solaris and OpenSolaris for instance, they have implemented it in the their C library , and I think it’s a good thing.

* http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libast/common/include/ast.h#192
* http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libast/common/string/memdup.c

(Curious…I would have used NULL instead of 0, because memdup returns a pointer, not an integer. But maybe there’s a reason why they used 0 here.)

AFAI’ve googled, Solaris and OpenSolaris are the only systems that implement memdup as part of the libc. Why other systems don’t ?

One possible reason is standardisation across platforms, as guys at freebsd pointed it out :

A memdup that is not string-oriented is a fine idea, but it
would not be something we would add to libc unless there were
a pre-existing reasonably standardized function somewhere that
did that sort of operation. It’s only a few lines of code but
the problem vis-a-vie putting things into libc is standardization.

Another reason would be that

the present interface between the heap and the rest of the
world consists of malloc(), realloc(), calloc(), and free(). Various
arguments were made for retaining this simplicity, and they won.

It turns out that before C99, they didn’t have strdup either ! but nowadays it is implemented in the standard GNU C library and . So why not memdup which is more generic ?

Simply create a file called allowed-hosts in your work_path (usually /var/lib/denyhosts/ in Debian|Ubuntu) with all the IPs and host names you would always allow to connect.

When slapd parses the configuration file and encounters the first “database” keyword, then it applies all the instructions that follow to the first database. When it encounters this keyword the second time, then all that follows is applied to the second database and so on…

So if you want to have, say, a second database for test purposes (to prevent you from messing with production database), just go to your config file (/etc/ldap/slapd.conf under debian or ubuntu) and :

1. go to the first occurrence of the database keyword and copy/paste all that is underneath
2. edit the config you just pasted, like the root dn (change your dc), the manager’s dn (change the dc) and the database files (directory instruction). Don’t forget to create your directory before restarting slapd (for example mkdir /var/lib/ldap-test/)
3. I suggest you not to restart slapd this way /etc/init.d/slapd restart, because sometimes slapd dosen’t restart properly and you are not notified about it. Instead, I would recommend :

This way you are notified about every error that may occur during startup.Now that you have created your second directory, you have to populate it. Let’s stay on the production vs test directory scheme. So you just want to populate your test database, which is database n°2, from your production directory, which is database n°1.

There you go ! you can check your test ldap database on phpldapadmin or your favorite tool.

Cool huh ? you can see at a glance where are the errors, the warnings etc.

Just install ccze (this is also the name of the Debian|Ubuntu software package) and type something like :

If you need to have only the most important log entries, then install and try logtool instead

This is how it looks like

Logcheck est un outil qui applique des filtre à tous (ou presque) les logs systeme pour en ressortir uniquement les informations les plus intéressantes qu’il envoi par mail.

Fichiers de configurations et régles de filtrage

Il existe une base de données de régles qui est fournie dans un paquetage séparé de logcheck. Sous Debian|Ubuntu, c’est le paquetage logcheck-databases.

Cette BDD est en fait une série de fichiers textes simples contenant une régle d’inclusion|exclusion (tout dépends de l’endroit où se trouve le fichier) par ligne.

Le fichier de configuration prinicipal est /etc/logcheck/logcheck.conf, où la seule chose à faire est de renseigner l’adresse email de notification et peut être le niveau de vigilence (serveur should do). Les autres options sont déjà configurés pour une utilisation normale de l’outil.

Parfois, logcheck va vous remonter des informations qui ne vous intéresse pas. Par exemple, si vous l’installer sur votre portable et que le wifi ne marche pas dessus, vous aurez certainement des remontées de type :

 Security Events
 =-=-=-=-=-=-=-=
 Apr 24 11:14:16 bughunter kernel: [264869.628000] bcm43xx: Error: Microcode "bcm43xx_microcode5.fw" not available or load failed.
 Apr 24 11:16:18 bughunter kernel: [264991.684000] bcm43xx: Error: Microcode "bcm43xx_microcode5.fw" not available or load failed.
 Apr 24 11:18:20 bughunter kernel: [265113.752000] bcm43xx: Error: Microcode "bcm43xx_microcode5.fw" not available or load failed.
 Apr 24 11:20:23 bughunter kernel: [265235.808000] bcm43xx: Error: Microcode "bcm43xx_microcode5.fw" not available or load failed.
 Apr 24 11:22:25 bughunter kernel: [265357.860000] bcm43xx: Error: Microcode "bcm43xx_microcode5.fw" not available or load failed.

 System Events
 =-=-=-=-=-=-=
 Apr 24 11:14:16 bughunter firmware_helper[10249]: main: error loading '/lib/firmware/bcm43xx_microcode5.fw' for device '/class/firmware/0000:05:00.0' with driver 'bcm43xx'
 Apr 24 11:14:18 bughunter NetworkManager: <WARN>  nm_device_802_11_wireless_scan(): could not trigger wireless scan on device eth1: No such device
 Apr 24 11:16:18 bughunter firmware_helper[10328]: main: error loading '/lib/firmware/bcm43xx_microcode5.fw' for device '/class/firmware/0000:05:00.0' with driver 'bcm43xx'
 Apr 24 11:16:20 bughunter NetworkManager: <WARN>  nm_device_802_11_wireless_scan(): could not trigger wireless scan on device eth1: No such device
 Apr 24 11:18:20 bughunter firmware_helper[10382]: main: error loading '/lib/firmware/bcm43xx_microcode5.fw' for device '/class/firmware/0000:05:00.0' with driver 'bcm43xx'
 Apr 24 11:18:23 bughunter NetworkManager: <WARN>  nm_device_802_11_wireless_scan(): could not trigger wireless scan on device eth1: No such device
 Apr 24 11:20:23 bughunter firmware_helper[10408]: main: error loading '/lib/firmware/bcm43xx_microcode5.fw' for device '/class/firmware/0000:05:00.0' with driver 'bcm43xx'
 Apr 24 11:20:25 bughunter NetworkManager: <WARN>  nm_device_802_11_wireless_scan(): could not trigger wireless scan on device eth1: No such device
 Apr 24 11:22:25 bughunter firmware_helper[10628]: main: error loading '/lib/firmware/bcm43xx_microcode5.fw' for device '/class/firmware/0000:05:00.0' with driver 'bcm43xx'

Ce qu’on souhaite bien évidemment éviter. Il suffit alors d’ajouter un fichier logcheckdans le répertoire /etc/logcheck/violations.ignore.d/ et d’y écrire la régle de filtrage d’exclusion qui convient (ici à la barbare…)

 ^.*kernel.*Microcode.*$

En ayant pris soin de la tester avec egrep auparavant.

Je ne maîtrise pas bien encore l’outil mais si cela ne suffit pas pour filtrer vos messages indésirables c’est que logcheck se base sur un autre fichier de conf pour message dont vous voulez vous débarasser et le fichier de log qui l’a produit.

Vous pouvez alors essayer d’écrire votre règle dans les autres répertoires :

 root@bughunter:/etc/logcheck# alias lsdir
 alias lsdir='ls -d */'
 root@bughunter:/etc/logcheck# lsdir
 drwxr-s--- 2 root logcheck 4,0K 2008-04-24 11:07 cracking.d/
 drwxr-s--- 2 root logcheck 4,0K 2008-04-24 12:26 cracking.ignore.d/
 drwxr-s--- 2 root logcheck 4,0K 2008-04-24 11:07 ignore.d.paranoid/
 drwxr-s--- 2 root logcheck 4,0K 2008-04-24 12:27 ignore.d.server/
 drwxr-s--- 2 root logcheck 4,0K 2008-04-24 11:07 ignore.d.workstation/
 drwxr-s--- 2 root logcheck 4,0K 2008-04-24 11:07 violations.d/
 drwxr-s--- 2 root logcheck 4,0K 2008-04-24 12:11 violations.ignore.d/
 root@bughunter:/etc/logcheck#

Documents à lire

• Des explications plus détaillées se trouvent dans /usr/share/doc/logcheck-database/README.logcheck-database.gz sur votre machine ou directement ici sur le site officiel

Nagios est un outil de supervision. Il permet d’avoir des alertes emails quand un service ou une machine ne réponds plus et nous préviens qu’il faut intervenir pour rétablir la situation.

En configurant des event_handler, on peut aussi spécifier des actions à exécuter (comme le redémarrage d’un serveur d’application ou l’exécution d’une commande shell) quand on s’aperçoit qu’un service ou qu’une machine ne répond plus.

Cet article vise à donner un bref apperçu du fonctionnement de Nagios et de la manière de la configurer, mais reste très (trop ?) concis pour en apprecier sa réelle capacité et l’étendu de ses fonctionnalitées. C’est pourquoi des liens seront donnés en bas de page pour approfondir ses connaissances sur le sujet.

Principe de fonctionnement général

Nagios scane tous les fichiers .cfg qu’il trouve dans son répertoire de configuration. Les répertoires de configurations usuels sont :

• Pour un Nagios compilé -fedora- : /usr/local/nagios/etc
• Pour un Nagios dépaqueté -debian- : /etc/nagios/
• Sur certaines distributions -Ubuntu-: /etc/nagios2

En particulier, il commence par lire le fichier de configuration principal, nagios.cfg, puis lis le reste des fichiers de configurations qu’on lui demande de charger avec les directives suivantes (placées dans ce même fichier):

• cfg_file = chemin/vers/fichier/de/conf
• cfg_dir = chemin/vers/repertoire/de/fichiers/de/conf

En fonction de votre système, les fichiers de configurations sont mis sur un ou deux niveaux :

• Le premier niveau contient les fichiers de configurations principaux (nagios.cfg,commands.cfg…)
• Le deuxième niveau contient les fichiers de configurations secondaires (mis dans un répertoire conf.d ou objects selon le système)

Comment superviser des machines

Pour dire à Nagios quelles sont les machines qu’on souhaite superviser, on lui indique les informations nécessaires dans un fichier hosts.cfg. En réalité, le nom du fichier importe peu, c’est par convention qu’on nomme le fichier hosts.cfg mais il aurait tout aussi bien pu s’appeler toto.cfg ou jeveuxuneporsche.cfg. Nagios ne se base pas sur les noms de fichiers mais sur les instructions qu’il trouve dans ces fichiers.

Voici comment dire à Nagios de superviser la machine PC-salon par exemple

     # Definition du hote PC-salon
     define host {
            host_name	PC-salon
            display_name	PC du salon
            address     	84.14.3.154
            use         	generic-host
     }

• Nagios utilise ce que vous avez mis dans host_name comme identifiant pour se référer à cette machine (dans les autres fichiers de confs par ex.)

• display_name est le libéllé que vous voulez voir dans l’interface graphique pour representer cette machine. Ce nom ne sert pas à Nagios pour l’identifier.

• la ligne use generic-host dit à Nagios d’utiliser la template generic-host pour remplir les autres options. C’est une sorte d’heritage (au sens programmation objet).

Pour connaître les autres options, veuillez vous référer à la documentation officielle sur les hosts

Comment superviser un service ?

Avant de parler de la supervision des services, il est utile de noter certains points :

2 types de services, 2 façons de faire

Il y a deux types de services que l’on peut superviser :

• Les services qui peuvent être testés à distance, tels que SSH, HTTP, TELNET, SMTP, PING etc.
• Les services qui ne peuvent pas être testés à distance, tels que la supervision du materiel (CPU, Disque, Mémoire…), le nombre d’utilisateurs connectés etc. Il n’y a aucun moyen de connaître ces informations là depuis le serveur hôte (qui fait tourner Nagios), car il faut être connecté sur la machine supervisée (par SSH par exemple) pour avoir accès à ces informations là.

Dans le premier cas on parle de “client passif” :

Les commandes de verification partent du serveur Nagios vers le client et retournent un résultat. Le client ne joue aucun rôle.

Dans le deuxième cas on parle de “client actif” :

Commes les commandes ne peuvent être appelées depuis l’exterieur, on installe ces commandes sur la machine cliente sous forme de plugins Nagios, avec un programme spéciale qui permet à Nagios de les appeler à distance et de récuperer les informations : c’est le logiciel NRPE (Nagios Remote Plug-Ins Executor).

Les commandes de verification sont toujours à l’initiative du serveur Nagios vers les clients, mais cette fois-ci, à l’aide de NRPE, les commandes s’executent sur le client, et les infos remontent au serveur Nagios.

Ok, maintenant je veux savoir comment superviser un service

Par convention, nous écrivons un fichier nommé services.cfg que nous mettons dans le répertoir de configuration de Nagios, et nous y écrivons les actions que l’on souhaite effectuer.

Voici un exemple pour superviser le service SSH sur la machine du salon définie plus haut

       # check SSH sur le PC du salon
       define service {
         host_name			 PC-salon
         service_description             SSH sur PC-salon
         check_command                   check_ssh
         use                             generic-service
         notification_interval           0 ; set > 0 if you want to be renotified
       }

• host_name et service_description sont respectivement le nom de la machine sur laquelle effectuer le test et le nom du test
• check_command contient le nom de la commande que l’on veut executer pour tester ce service. check_ssh est en fait une commande sous forme de plugins (binaire executable) disponible (selon votre O.S) dans :
  • /usr/lib/nagios/plugins/ (Ubuntu)
  • /usr/local/nagios/libexec/

On peut également écrire sa propre commande en la spécifiant avec la directive “define command”, usuellement dans un fichier commands.cfg, comme suit :

 define command{
   command_name	check_pop
   command_line	/usr/local/nagios/libexec/check_pop -H $HOSTADDRESS$
 }

Ici, nous définissions la commande check_pop (commande_name), qui executera la ligne commande_line après avoir remplacé toutes les macros éventuelles (comme $HOSTADDRESS$ ici). Cette commande pourra être appelée dans les instructions de configuration de votre service (directive define service) de la sorte :

 # check mail pop sur PC-salon
 define service {
      host_name			      PC-salon
      service_description             Pop sur PC-salon
      check_command                   check_pop
      use                             generic-service
      notification_interval           0 ; set > 0 if you want to be renotified
 }

Vous pouvez également faire en sorte de passer des arguments supplémentaires à votre commande. Voici comment l’appeler dans votre service :

 define service{
   use			generic-service		; Inherit default values from a template
   host_name		remotehost
   service_description	SSH Version Check
   check_command		check_ssh!-t 5 -r "OpenSSH_4.2"
  }

Pour spécifier des arguments, utiliser ! comme séparateur

Et voici comment définir la commande pour qu’elle prennent en compte vos arguments

 define command{
  command_name	check_ssh
  command_line	$USER1$/check_ssh $ARG1$ $HOSTADDRESS$
 }

Dans notre exemple, $ARG1$ sera remplacé par le premier agument (ici -t 5 -r “OpenSSH_4.2″).

• Pour connaître les autres options de l’instruction define service, veuillez vous référer à la documentation officielle sur les services

• La directive define command ne possède pas d’options supplémentaires

• Pour en savoir plus sur les macros, veuillez vous référer à la documentation officielle sur les macros

Et pour les services s’executant à distance ??

Après avoir installé NRPE, il suffit d’écrire la définition de votre service ainsi :

 define service{
      use                     generic-service
      host_name               machine_avec_un_petit_disque
      service_description     Disque 2 machine 4
      check_command           check_nrpe!check_disk
      contact_groups  admins
 }

Comme on le voit, ici on appelle la commande check_nrpe, qui est donc le programme qui appelle les plugins à distance, et on lui passe en argument check_disk, c’est la commande qui sera appelée sur le client. Voilà :) !

Super, maintenant un mot sur l’interface graphique

Sur Ubuntu (et debian ?) on doit invoquer les commandes suivantes pour exectuer les commandes externes (depuis le navigateur web) pour par exemple relancer un service manuellement (au lieu d’attendre sa prochaine heure d’execution programmée) :

 /etc/nagios2#/etc/init.d/nagios2 stop
 /etc/nagios2# dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios2/rw
 /etc/nagios2# dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios2
 /etc/nagios2# /etc/init.d/nagios2 start

Trouvé sur les forums d’aide Ubuntu

Articles à lire

• Supervision des services publics (HTTP,SMTP,SSH,PING etc.)
• TOC de la doc officielle