K-Tux

Nagios : configuration snmp sous Solaris 10

KXan — Wed, 09 May 2012 08:25:42 +0000

Comme pas mal d'équipements, les serveurs sous Solaris 10 peuvent utiliser snmp afin d'être monitorable via -au hasard- Nagios. Une petite particularité concerne la postinstall du client qui ne crée pas correctement le service. Voici une astuce pour remettre d'équerre. Premièrement, il vous faut récupérer les packages Product, SUNWsmagt, SUNWsmmgr et SUNWsmcmd, quelque part sous mettons /var/tmp/. Ces packages sont disponibles sur les medias d'installation, si vous avez un serveur Jumpstart (l'équivalent du couple PXE / Kickstart pour RedHat).

# pkgadd -d /var/tmp/snmp/solaris_10/Solaris_10/Product SUNWsmagt  SUNWsmmgr SUNWsmcmd

Le bug en question fait que les services ne sont pas enregistrés dans le système. La solution est triviale, il suffit de réimporter les xml concernés :

# pkill configd
# svccfg -v import /var/svc/manifest/application/management/seaport.xml 
# svccfg -v import /var/svc/manifest/application/management/sma.xml

La configuration des communautés snmp se fait sous /etc/sma/snmp/snmpd.conf :

rocommunity private 192.168.10.251 .1 # L'IP du serveur Nagios

Il ne reste plus qu'à réactiver le service via la commande :

# svcadm enable svc:/application/management/sma:default

Simple et concis. Il ne reste plus qu'à travailler les checks sur le serveur Nagios !

Tripwire : contrôle d’intégrité et monitoring

KXan — Mon, 16 Apr 2012 08:30:54 +0000

Il y a peu, je vous parlais d'une solution qui cherchait les différences entre le retour du ps et ce qui se trouve sous /proc/ -en bref, démasquer les processus cachés. Ce qui pose tout naturellement la question suivante : comment cacher un processus ? Plusieurs moyens sont à votre disposition, depuis l'encapsulation dans un autre processus plus passe partout jusqu'à la modification toute bête de votre ps. Et pourquoi pas de ses copains... Tripwire est une solution de monitoring d'intégrité de données. Dit comme ça, c'est pile poil ce qu'il nous faut et surtout c'est un peu le grand nom du milieu.

Principes

Rien de bien sorcier, Tripwire implémente l'évident : une installation suivie d'une initialisation de la base de données dans laquelle on stockera les infos des données. Une fois l'initialisation faite, on touche les configurations du service et celles visant à mentionner qui, et quoi faire en cas de changement. Un check doit suivre, afin d'initialiser les valeurs témoins pour chacune des data. Tripwire produit des rapports sur chacune de ses analyses, et si vous voyez un truc qui cloche, vous pouvez repousser une sauvegarde de ces données ou valider les modifications relevées par Tripwire et mettre à jour la database en conséquence.

Applications

L'installation se fait depuis les dépôts, car pour Debian ils sont plutôt à jour et que je ne souhaite pas avoir affaire à de possibles complications si update :)

# apt-get install tripwire

L'installation pose sous /etc/tripwire, sous /var/lib/tripwire et sous /usr/sbin pour les exécutables.

Configuration

De manière standard, vous trouverez les conf sous /etc/tripwire. Deux configurations sont à modeler selon les besoins. Elles ont chacune une version accessible en clair :

/etc/tripwire/twcfg.txt, qui est propre à la configuration du service en lui-même
/etc/tripwire/twpol.txt, qui concerne les politiques à mettre en place

Respectivement, une fois parsées, cela deviendra /etc/tripwire/tw.cfg pour la configuration du service et /etc/tripwire/tw.pol pour la spécification des policies. On commence par :

# /etc/tripwire/twinstall.sh

Le process pose alors pas mal de question, que l'on peut éviter en demandant le mode noprompt mais qui a le désavantage de demander explicitement les passphrases pour la génération des clés local et site. L'installation faite est une installation en mode standalone (c'est-à-dire que les checks ne sont pas centralisés, chacun des serveurs a sa propre base de données). 2 informations sont à fournir : la passphrase pour la clé locale et la passphrase pour la clé du site. Ces clés servent à signer les policies, les configurations et la base de données contenant les références sur lesquelles se base Tripwire.

# /etc/tripwire/twinstall.sh

----------------------------------------------
The Tripwire site and local passphrases are used to sign a variety of files, such as the configuration, policy, and database files.

Passphrases should be at least 8 characters in length and contain both letters and numbers.

See the Tripwire manual for more information.

----------------------------------------------
Creating key files...

(When selecting a passphrase, keep in mind that good passphrases typically have upper and lower case letters, digits and punctuation marks, and are at least 8 characters in length.)

Enter the site keyfile passphrase:
Verify the site keyfile passphrase:
Generating key (this may take several minutes)...
....Key generation complete.

----------------------------------------------
Signing configuration file...
Please enter your site passphrase:
Wrote configuration file: /etc/tripwire/tw.cfg

A clear-text version of the Tripwire configuration file /etc/tripwire/twcfg.txt has been preserved for your inspection. It is recommended that you delete this file manually after you have examined it.
----------------------------------------------
Signing policy file...
Please enter your site passphrase:
Wrote policy file: /etc/tripwire/tw.pol

A clear-text version of the Tripwire policy file /etc/tripwire/twpol.txt has been preserved for your inspection. This implements a minimal policy, intended only to test essential Tripwire functionality. You should edit the policy file to describe your system, and then use twadmin to generate a new signed copy of the Tripwire policy.

Ensuite ?

Attaquons la partie configurations. Comme dit un peu au dessus, il y a 2 configurations à valider : celle du service et celle des politiques à suivre. La configuration du service est stockée dans le fichier /etc/tripwire/tw.cfg, qui est une version parsée du /etc/tripwire/twcfg.txt. Cette dernière est à moduler selon vos besoins. Elle contient notamment le nom et l'emplacement de la base de données où Tripwire va stocker tout son bazar. La configuration des policies est plus tendue... Editons et voyons un peu sa tronche :

# vim /etc/tripwire/twpol.txt

C'est un fichier texte, à la syntaxe très particulière. Pas mal de policies sont déjà à votre disposition, implémentées ou commentées d'ailleurs, et cela permet de se familiariser avec la syntaxe. Si je veux faire dans le spécifique, je peux rajouter à la fin de la configuration :

(
rulename = "Application to monitor" ,
severity = 100,
emailto = rssi@k-tux.com

)

{
/APPS -> $(IgnoreNone)-MCHracm (recurse=true) ;
}

Pour les détails des options, je vous laisse consulter le man. Après avoir défini la politique de scellement dans le fichier twpol.txt, lancer la commande suivante :

# twadmin -m P -c /etc/tripwire/tw.cfg -S /etc/tripwire/site.key /etc/tripwire/twpol.txt
Please enter your site passphrase:
Wrote policy file: /etc/tripwire/tw.pol

-m P équivaut également à --create-polfile. Maintenant que nos conf sont parsées bien comme il faut, on doit créer la base des sceaux de référence. Très facile :

# tripwire --init -c /etc/tripwire/tw.cfg

Parsing policy file: /etc/tripwire/tw.pol
Generating the database...
*** Processing Unix File System ***
Wrote database file: /var/lib/tripwire/db.twd
The database was successfully generated.

La base de donnée créée, il ne reste plus qu'à rentrer les valeurs de référence en lançant le fameux check.

# tripwire --check

Parsing policy file: /etc/tripwire/tw.pol
*** Processing Unix File System ***
Performing integrity check...
Wrote report file: /var/lib/tripwire/report/kserv-20120412-210750.twr
... ... ...
Total objects scanned: 52397
Total violations found: 0

Les rapports produits par les check de Tripwire sont situés par défaut sous /var/lib/tripwire/report/ et ont une extension en .twr. Ce sont des data qui sont lisibles via la commande twprint. De là, il est facile de rediriger la sortie standard vers un fichier lisible via un less par exemple, c'est à votre convenance.

# twprint -m r -r /var/lib/tripwire/report/kserv-20120412-210750.twr

Evolution de la base et mise à jour des policies

Comme les filesystems évoluent vite rien que par les mises à jour, il est nécessaire de faire évoluer la base de données de Tripwire en conséquence. Tout d'abord, on doit mettre à jour la base de données de Tripwire à l'aide du rapport en question :

# tripwire -m u --twrfile /var/lib/tripwire/report/kserv-20120412-210750.twr

Please enter your local passphrase:
Wrote database file: /var/lib/tripwire/db.twd

Si besoin, vous pouvez encore revoir les policies. Pour cela, il faut regénérer le tw.pol après avoir modifier twpol.txt :

# twadmin -m P -c /etc/tripwire/tw.cfg -S /etc/tripwire/site.key /etc/tripwire/twpol.txt
Please enter your site passphrase:
Wrote policy file: /etc/tripwire/tw.pol

Il faut supprimer et recréer la database. C'est un peu brutal, mais c'est comme ça que ça marche.

# rm /var/lib/tripwire/db.twd
# tripwire --init -c /etc/tripwire/tw.cfg

Cronner le tout

Tripwire n'est pas un daemon, il est nécessaire de le lancer de façon récurrente. Crond s'impose donc :

00 03 * * * /usr/sbin/tripwire --check

And voilà ! Tout est prêt pour vous avertir dès qu'une modification est faite sur un des éléments sous surveillance.

Conclusion

Tripwire est, à mon sens, une réponse à un besoin élémentaire en terme de sécurité. Bien qu'elle nécessite un petit ajustement dans sa prise en main -mais minime alors- et une maintenance continue, elle reste plus que pertinente, surtout vu le niveau des joueurs. Et comme un système parfaitement sécurisé n'est que pure utopie, on se doit de checker un minimum nos bécanes :)

Back to Basis : clone d’un serveur OpenLDAP

KXan — Mon, 26 Mar 2012 08:39:31 +0000

C'est un tip très court, qui permet de refaire à l'identique votre serveur OpenLDAP et vous allez voir, c'est très rapide. Le but du jeu n'est pas de créer de la redondance de service ou du load balancing (auquel cas on préfèrera faire un peer et configurer slapd pour qu'il gère les 2 serveurs de manière cohérente) mais de créer une image fidèle de la production afin de travailler dessus et de mesurer les conséquences des modifications faites avant de les porter sur le serveur de référence. Je passe sur l'installation de l'OS. On commence juste après l'installation du package openldap (pour Debian, ce sera slapd) et on suppose que votre clone peut interroger votre serveur de référence. Petite sauvegarde au cas où de vos conf d'origine. Pour information, sous Debian, tout est sous /etc/ldap, ce qui n'est pas le cas par exemple sous Suse, où on sera sous /etc/openldap. Adaptez en conséquence :)

ldapserv2 # rsync -az /etc/ldap{,.org}

Récupérez vos enregistrements LDAP. A moduler selon que vous ayez autorisé ou pas le read en mode anonyme (-x). Si ce n'est pas le cas, utilisez un -D suivi du dn du compte autorisé (exemple : -D "cn=bofh,dc=k-tux, dc=com") et d'un -W qui vous permettra d'avoir un prompt pour rentrer le mot de passe du compte.

ldapserv2 # ldapsearch -x -H ldap://ldapserv1 -LLL > ldapserv1-dump.ldif

Dans la même optique, récupérez également les configurations du master, schémas compris, qu'il faut pousser au bon endroit sur votre clone.

ldapserv2 # rsync -avz ldapserv1:/etc/ldap/ /etc/ldap/

Et maintenant, sans rien faire de plus, balancez un slapadd pour pousser vos enregistrements sur le clone :

ldapserv2 # slapadd -f ldapserv1-dump.ldif

Redémarrez le service, le tour est joué !

ldapserv2 # /etc/init.d/slapd restart

High availability : drbd et heartbeat

KXan — Tue, 28 Feb 2012 09:16:48 +0000

La HA (acronyme pour High Availability, haute disponibilité) peut facilement se mettre en place en conjuguant une solution de mirroring de donnée par le réseau et une solution de détection de panne. Ces solutions existent et certaines ont fait leurs preuves depuis longtemps. C'est le cas pour DRBD et Heartbeat dont nous allons voir un exemple succinct.

DRBD

DRBD, c'est la version courte de Distributed Replicated Block Device. C'est une solution de réplication de données via un réseau dédié qui, somme toute, permet d'avoir, up to date, un mirroir de vos données tout prêt en cas de problème sur le nominal. L'installation se fera depuis les dépôts, pour la simple et bonne raison que cela permet de rester cohérent lors des updates du système et de ne pas avoir à tout recompiler après l'opération. Les packages à installer sont drbd et kmod-drbd, il ne vous reste plus qu'à faire appel à votre gestionnaire de package préféré. Après l'opération, on peut d'ores et déjà charger le module manuellement via un simple !

# modprobe -i drbd

Et, tant qu'à faire, rajouter la ligne du modprobe dans le fichier /sbin/rcdrbd.

Configuration

C'est à ce niveau que l'on peut admirer le génie de DRDB : deux modes existent :

la réplication de donnée Active / Passive implique que l'écriture est faite sur l'un des emplacements, le master, puis répliquée sur le slave.
la réplication de donnée Active / Active, qui gère l'écriture simultanée sur toutes les entités concernées

Malheureusement, on peut dire que la technologie sous-jacente limite les possibilités, car certains filesystems ont été conçus pour être les seuls à accéder aux volumes de données, comme ext3 par exemple. En conséquence, si vous utilisez -ou voulez utiliser- ext3, il faut opter pour une configuration drdb active / passive. En revanche, si vous souhaitez jouer avec active / active, vous pouvez vous orienter ver un cluster filesystem comme GFS ou OCFS. Nous sommes dans le cas le plus fréquent : on cherche l'ext3, donc une configuration active / passive. La configuration sera donc un peu comme suit :

# cat /etc/drbd.conf
global{ 
 dialog-refresh 1;
 minor-count 5;
} 

common{} 

resource drbd-dns{
 protocol C;
 disk{ on-io-error detach; }
 syncer{
  rate 640M;
  al-extents 257; 
} 

 handlers {
 # /usr/lib/drbd/notify-split-brain.sh est un script qui notifie l'utilisateur passé en paramètre du split brain et déconnecte le disque
 split-brain "/usr/lib/drbd/notify-split-brain.sh root"; }
 net{
  ping-int 10;
  timeout 60;
  connect-int 10;
  ping-timeout 5;

  # Après la détection du split brain, aucun primaire détecté, et un des serveurs n'a fait aucune modification : répliquer les modifications sur ce serveur
  after-sb-0pri discard-zero-changes; 

  # Après un split brain, un primaire détecté : le secondary est systématiquement la split brain victim
  after-sb-1pri discard-secondary; 

  # Après un split brain, 2 primary détectés : déconnexion
  after-sb-2pri disconnect; 

  # Si le rôle du serveur est incompatible avec la resynchronisation des ressources : déconnexion
  rr-conflict disconnect;
 } 

  startup{ degr-wfc-timeout 120; } 

  on dns1.k-tux.com{
   device      /dev/drbd0;
   address     192.168.1.52:7789; 
   # dns1 IP
   meta-disk /dev/sda6[1];
   disk /dev/sda5;
  } 

  on dns2.k-tux.com{
   device  /dev/drbd0;
   address 192.168.1.53:7789;
   # dns2 IP
   meta-disk /dev/sda6[1];
   disk /dev/sda5;
  } 
}

Si en revanche vous souhaitez monter une configuration en active / active, il suffit de mentionner l'option allow-two-primaries; dans la section net{} et de rajouter en dehors de net{} mais toujours dans la section resource data {} la section startup telle que :

startup {
become-primary-on both;
}

Cela permet de monter les 2 serveurs en rôle primaires au démarrage.

Création et synchronisation des metadonnées

La configuration vérifiée et carrée, il s'agit de créer et de connecter les metadata sur tous les serveurs impliqués :

# drbdadm create-md drbd-dns

Le retour doit vous donner :

New drbd meta data block successfully created

Il ne reste plus qu'à faire le lien entre les metadonnées, les ressources et les serveurs.

# drbdadm attach drbd-dns
# drbdadm syncer drbd-dns
# drbdadm connect drbd-dns

Pour information, l'option connect permet de monter la configuration réseau liée aux ressources. Dans le cas où on a plus de deux serveurs mentionnés dans la configuration drbd, il faut préciser l'option --peers afin de sélectionner les pairs sur lesquels vous voulez travailler. Redémarrez drbd :

# rcdrbd start

Vous pouvez monitorer la synchronisation des ressources en cattant /proc/drbd ou en interrogeant le service sur son status :

# cat /proc/drbd
# /etc/init.d/drbd status

Si l'on veut forcer la synchronisation, il suffit d'exécuter sur les 2 serveurs si on est en configuration active/active, ou sur le master uniquement si active/passive :

# drbdadm -- --overwrite-data-of-peer primary drbd-dns

Avant d'opérer le formattage, il faut s'assurer que la synchronisation est bien terminée :

# watch -n 1 cat /proc/drbd

Une fois la synchronisation finie, on peut formatter la partition /dev/drbd0 :

en ext3 dans mon cas # mkfs.ext3 /dev/drbd0

ou en autre chose, comme gfs par exemple # mkfs.gfs /dev/drbd0

Il ne reste plus qu'à finaliser :

# chkconfig --add drbd
# chkconfig --level 35 drbd on

Au quotidien, on peut obtenir l'état du mirroring DRBD grâce à la commande drbdadm-overview :

# drbdadm-overview

La commande doit renvoyer une sortie du genre :

1:drbd-dns   Connected Primary/Secondary UpToDate/UpToDate C r---

Failover / Failback

Lorsqu'il y a incident et que le master tombe, on peut forcer le serveur passif en primary :

dns2 # drbd primary drbd-dns
dns2 # drbdadm connect drbd-dns

Ne pas oublier, lors de la remise up du primary et une fois la synchronisation terminée, de remettre le slave en mode secondary :

dns2 # drbd secondary drbd-dns
dns2 # drbdadm connect drbd-dns

Split Brain

Un split brain est une situation où, suite à un souci, on se retrouve avec 2 serveurs qui se déclarent primary, d'où une haute probabilité de confusion des clients et pertes potentielles de données. DRBD détecte le split brain au moment où la connectivité est rétablie et quand les noeuds peer recommencent à négocier via le protocole DRBD. S'il y a détection de deux primary alors le daemon clôt la connexion et arrête toute réplication. Un split brain se lit dans les logs :

Split-Brain detected, dropping connection!

Après le split brain, un des noeuds se retrouve avec une connexion en état StandAlone. L'autre serveurs peut tout-à-fait être dans le même état de StandAlone, ou bien, s'il est monté après que le premier ait été déconnecté, être en attente de connexion (WFConnection). Même s'il est possible de configurer DRBD pour reprendre la main automatiquement et décider quelles données garder (les instructions after-sb-*pri dans la section net), il est préférable de trancher par vous-même quel est le noeud dont les données doivent être discréditées. Ce qui fera du noeud concerné le split brain victim. Dans mon cas, si je choisis de STONITH à l'ancienne le noeud dns2, il suffit de réattribuer le bon rôle sur le noeud et de discarder à la mano au moment de la synchronisation avec le volume :

dns2 # drbdadm secondary drbd-dns
dns2 # drbdadm connect --discard-my-data drbd-dns

Sur le noeud de référence (le split brain survivor), si sa connexion est aussi en StandAlone, alors il suffit de lancer un connect :

dns1 # drbdadm connect drbd-dns

Ce n'est pas nécessaire si le primary est dans l'état WFConnection. Le tour est joué, vous êtes revenu en situation nominal.

Heartbeat

C'est bien joli d'avoir un mirroir niveau block, encore faut-il détecter quand le neoud tombe. C'est le rôle de Heartbeat, qui est chargé, comme son nom l'indique, de prober les battements de coeur de l'autre serveur impliqué. Ce qui est bien, c'est que Heartbeat a été conçu pour se coupler comme un charme avec DRBD. Et ça mérite la démonstration. Même chose que pour DRBD, on part des packages présents sur les dépôts, histoire de ne rien casser à l'update.

Configuration

Il faut créer la configuration sous /etc/ha.d/ha.cf comme suit :

# /etc/ha.d/ha.cf

# Messages de debug
debugfile /var/log/ha-debug

# Autres messages
logfile /var/log/ha-log

# Alertes generes dans les logs en cas d'absence de battement
warntime 6

# Temps entre chaques battements "en sec"
keepalive 2

# Temps avant que le node soit declare arrete
deadtime 6

# port UDP utlise
udpport 694

# interface utilise
bcast eth0

# Recuperation auto des ressources quand celle-ci est a nouveau operationnel
auto_failback off

# Les nodes du cluster
node dns1.k-tux.com
node dns2.k-tux.com

Paramétrages des ressources

Une fois la configuration créée, il faut quand même lui donner les informations concernant les ressources de préférences, leur emplacement et les entités concernées. Le format peut sembler tricky, car tout est sur une ligne.

#!/bin/sh
# haresources
dns1.k-tux.com IPaddr::192.168.1.52/24/eth0:0 IPaddr::192.168.1.53/24/eth0:0 drbddisk::drbd-dns Filesystem::/dev/drbd0::/var/lib/named::ext3::acl

La configuration doit être identique sur tous les noeuds, et il faut respecter l'ordre qui est le suivant :

le nom du noeux préféré, qui doit avoir son entrée dans /etc/hosts
IPaddr mentionne les différentes adresses ip virtuelles
drbddisk pour préciser et pouvoir gérer les ressources drbd
Filesystem qui s'occupe de monter les partitions

Créer le fichier /etc/ha.d/authkeys :

# auth authentication
auth 1

# identifiant method used
1 md5 password

Il ne reste plus qu'à démarrer le daemon heartbeat :

# rchearcbeat start

Normalement, suite au démarrage du heartbeat, la virtual interface (eth0:0) devrait être activée et la ressource drbd /dev/drbd0 montée comme il faut bien, sous /var/lib/named dans mon cas.

dns1 # mount | grep drbd0
/dev/drbd0            9.7G  151M  9.1G   2% /var/lib/named

Heartbeat de configuré, DRBD prêt, tout est en place pour pour le pire des cas, si du moins il devait arriver.

Conclusion

Le couple DRBD / Heartbeat a fait ses preuves depuis pas mal de temps, et pourtant nous n'avons brossé que quelques options. L'un dans l'autre, ces solutions sont puissantes et bien employés, elles enlèvent une bonne partie du poids qui pèse sur les Sysadmins lorsque l'on parle critique, SLA et haute dispo.

Solaris : configuration d’un serveur NTP

KXan — Mon, 30 Jan 2012 08:30:32 +0000

Mine de rien, il existe pas mal de différences entre Solaris et notre bon vieux Linux. Bien que le set de commande est sensiblement le même, le nom mis à part (snoop pour tcpdump par exemple), l'arborescence a quelque chose... de dispersée. Enfin l'impression est vraie quand, comme moi, on est plutôt natif Nunux. Attaquons doucement avec un truc simple : la configuration d'un client NTP. Première subtilité : la conf n'est pas directement sous /etc/, mais sous /etc/inet/, et ça nous donne un /etc/inet/ntp.conf :

#
# Copyright 1996-2003 Sun Microsystems, Inc.  All rights reserved.
# Use is subject to license terms.
#
# /etc/inet/ntp.conf
#
# An example file that could be copied over to /etc/inet/ntp.conf and
# edited; it provides a configuration template for a server that
# listens to an external hardware clock, synchronizes the local clock,
# and announces itself on the NTP multicast net.
#

#
# Some of the devices benefit from "fudge" factors.  See the xntpd
# documentation.

# Either a peer or server.
# Servers to use to update

server ntpb1.k-tux.com prefer
server ntpb2.k-tux.com
# fudge 127.127.XType.0 stratum 0

broadcast 224.0.1.1 ttl 4

enable auth monitor
driftfile /var/ntp/ntp.drift
statsdir /var/ntp/ntpstats/
filegen peerstats file peerstats type day enable
filegen loopstats file loopstats type day enable
filegen clockstats file clockstats type day enable

keys /etc/inet/ntp.keys
trustedkey 0
requestkey 0
controlkey 0

Bien sûr, modifiez à votre convenance les statements commençant par le key word server afin que la conf soit carrée pour votre infrastructure. Il faut encore créer le drift s'il n'existe pas :

# touch /etc/inet/ntp.drift

Activez le service :

# svcadm enable svc:/network/ntp:default

Dans le cas où le service tourne déjà, on peut le restarter comme suit:

# /etc/init.d/xntpd stop
# /etc/init.d/xntpd start

Au niveau du client, c'est assez simple, il suffit de copier la conf libellée ntp.client qui ne doit, par défaut, contenir que :

# cat /etc/inet/ntp.client
multicastclient 224.0.1.1

Et d'activer le client NTP, de la même manière que pour le serveur :

# cp /etc/inet/ntp.client /etc/inet/ntp.conf
# svcadm enable svc:/network/ntp:default

Si vous voulez éviter le multicast, alors il suffit de retoucher le ntp.conf en conséquence. Il faut par contre mentionner le serveur par son ip. Par exemple :

# cat /etc/inet/ntp.client
server 192.168.16.2

Facile ! Au final, c'est une superbe claque quand on attaque un Solaris avec l'idée que c'est un type -mutant ?- de Linux. Mais quoi de meilleur que de tomber sur ce type de plateforme : un grand nom, une utilité certaine, et tout un terrain pour découvrir, exploiter et peaufiner une technologie à laquelle on n'est pas habitué ? Si vous avez la main sur ce type d'infra, n'hésitez pas à partager vos good practices et vos tips, vous êtes les bienvenus :)

Unhide : découverte des processus et ports cachés

KXan — Thu, 24 Nov 2011 13:53:42 +0000

Unhide est un outil simple de détection de process et de ports cachés qui n'apparaîtraient pas avec les outils classiques. Il a le bon goût d'être Open Source et disponible également pour les plateformes sous Windows. Commençons dans un premier temps par rapatrier et détarer l'archive de l'outil. La dernière version en date à l'heure de la manip est estampillée du 13 Janvier 2011. L'installation est très simple, mais rompt complètement avec la routine des ./configure; make && make install à laquel on est habitué. Ici, il s'agit simplement de compiler le code c qui va bien afin d'utiliser les outils. Encore une fois, le README.txt est à disposition et nous donne les bonnes inforamtions.

$ wget http://downloads.sourceforge.net/project/unhide/unhide-20110113.tgz
$ tar xzvf unhide-20110113.tgz
$ cd unhide-20110113
$ gcc --static unhide.c -o unhide
$ gcc --static unhide-tcp.c -o unhide-tcp
$ gcc -Wall -O2 --static -pthread unhide-linux26.c -o unhide-linux26

On se retrouve directement les exécutables sous la main. Ils sont 3 : unhide, unhide-linux26 et unhide-tcp. Commençons par unhide tout court. Cet outil est destiné à démasquer les processus cachés. Un premier run nous renvoie les options à fournir pour que cela fonctionne :

# unhide
Unhide 20110113
http://www.unhide-forensics.info

usage: unhide proc | sys

Très succint, n'est-ce pas ? Clair aussi : proc pour lister les processus cachés en utilisant la comparaison entre ps et /proc, et sys pour comparer ps avec les informations issues des appels système.

# unhide proc
Unhide 20110113
http://www.unhide-forensics.info

[*]Searching for Hidden processes through /proc scanning

Found HIDDEN PID: 762
Command: /usr/sbin/console-kit-daemon

Found HIDDEN PID: 763
Command: /usr/sbin/console-kit-daemon

Found HIDDEN PID: 764
Command: /usr/sbin/console-kit-daemon

Found HIDDEN PID: 1749
Command: auditd

Found HIDDEN PID: 3199
Command: dsmcad

Found HIDDEN PID: 3200
Command: dsmcad
[...]

Voyons ce que ça donne pour sys. Personnellement, j'ai complète correspondance pour sys et pour proc.

# unhide sys
Unhide 20110113
http://www.unhide-forensics.info

[*]Searching for Hidden processes through getpriority() scanning

Found HIDDEN PID: 762
Command: /usr/sbin/console-kit-daemon

Found HIDDEN PID: 763
Command: /usr/sbin/console-kit-daemon

Found HIDDEN PID: 764
Command: /usr/sbin/console-kit-daemon
[...]

[*]Searching for Hidden processes through getpgid() scanning

Found HIDDEN PID: 762
Command: /usr/sbin/console-kit-daemon

Found HIDDEN PID: 763
Command: /usr/sbin/console-kit-daemon

Found HIDDEN PID: 764
Command: /usr/sbin/console-kit-daemon
[...]

Pour les modes plus intensifs, il faut utiliser unhide-linux26 avec l'option adéquate. La liste des modes et des options est tout de suite plus conséquente comme on peut le voir.

# unhide-linux26
Unhide 20110113
http://www.unhide-forensics.info
Usage: unhide-linux26 [options] test_list

Option :
-V          Show version and exit
-v          verbose
-h          display this help
-m          more checks (available only with procfs command)
-r          use alternate sysinfo test in meta-test
-f          log result into unhide.log file
Test_list :
Test_list is one or more of the following
Standard tests :
brute
proc
procall
procfs
quick
reverse
sys
Elementary tests :
checkbrute
checkchdir
checkgetaffinity
checkgetparam
checkgetpgid
checkgetprio
checkRRgetinterval
checkgetsched
checkgetsid
checkkill
checknoprocps
checkopendir
checkproc
checkquick
checkreaddir
checkreverse
checksysinfo
checksysinfo2

Par exemple, avec l'option brute :

# unhide-linux26 brute
Unhide 20110113
http://www.unhide-forensics.info
[*]Starting scanning using brute force against PIDS with fork()

[*]Starting scanning using brute force against PIDS with pthread functions
Found HIDDEN PID: 21443 "  ... maybe a transitory process"

Autre exemple avec reverse :

# unhide-linux26 reverse
Unhide 20110113
http://www.unhide-forensics.info
[*]Searching for Fake processes by verifying that all threads seen by ps are also seen by others

Un bon compromis est de tourner unhide proc et si problème ou résultats étranges, lancer sa version approfondie agrémentée de la liste de tests qui va bien :

# unhide-linux26 procall checkbrute checkchdir checkgetaffinity checkgetparam checkgetpgid checkgetprio checkRRgetinterval  checkgetsched checkgetsid checkkill checknoprocps checkopendir checkproc checkquick checkreaddir checkreverse checksysinfo checksysinfo2
Unhide 20110113
http://www.unhide-forensics.info
[*]Searching for Hidden processes through /proc stat scanning

[*]Searching for Hidden processes through /proc chdir scanning

[*]Searching for Hidden processes through /proc opendir scanning

[*]Searching for Hidden thread through /proc/pid/task readdir scanning

[*]Searching for Hidden processes through getpriority() scanning

[*]Searching for Hidden processes through getpgid() scanning

[*]Searching for Hidden processes through getsid() scanning

[*]Searching for Hidden processes through sched_getaffinity() scanning

[*]Searching for Hidden processes through sched_getparam() scanning

[*]Searching for Hidden processes through sched_getscheduler() scanning

[*]Searching for Hidden processes through sched_rr_get_interval() scanning

[*]Searching for Hidden processes through kill(..,0) scanning

[*]Searching for Hidden processes through  comparison of results of system calls

[*]Starting scanning using brute force against PIDS with fork()

Found HIDDEN PID: 28354 "  ... maybe a transitory process"
Found HIDDEN PID: 28604 "  ... maybe a transitory process"
Found HIDDEN PID: 28610 "  ... maybe a transitory process"
[*]Starting scanning using brute force against PIDS with pthread functions
Found HIDDEN PID: 24819 "  ... maybe a transitory process"
[*]Searching for Fake processes by verifying that all threads seen by ps are also seen by others

[*]Searching for Hidden processes through  comparison of results of system calls, proc, dir and ps

[*]Searching for Hidden processes through sysinfo() scanning

[*]Searching for Hidden processes through sysinfo() scanning

L'outil unhide-tcp, quant à lui, s'attache plus à découvrir quels sont les ports TCP et UDP qui auraient été "oubliés" par netstat.

# unhide-tcp

Starting TCP checking

Starting UDP checking

Dans le cas où vous avez un peu quelques ports qui sont ouverts mais cachés à netstat, vous aurez quelque chose du genre : Bien entendu, si vous tournez en user simple, tous les ports seront listés vu que netstat ne vous permet pas de tout voir :)

Starting TCP checking
Found Hidden port that not appears in netstat: 1021
Found Hidden port that not appears in netstat: 1022

Starting UDP checking
Found Hidden port that not appears in netstat: 1021
Found Hidden port that not appears in netstat: 1022

Au final, unhide est un set complet qui trouve facilement une place dans les outils. Bien pour les paranoïaques mais également pour ceux qui veulent vérifier ce qu'il en est exactement. A conjuguer avec temps, outils complémentaires, skills et à volonté !

DNScap : debug et trace DNS

KXan — Thu, 17 Nov 2011 11:15:34 +0000

dnscap fait parti de ces outils d'analyse de flux et de troubleshooting basé sur le sniff des échanges. Il pourrait se rapprocher du célèbre tcpdump, à ceci près qu'il est, comme son nom l'indique, entièrement dédié aux flux concernant le DNS. L'installation est simple, concise, et l'outil est directement utilisable en l'état. Comme d'habitude, on récupère les sources, un coup de ./configure, un coup de make install.

$ wget http://dnscap.dns-oarc.net/dnscap-134.tar.gz
$ tar zxvf dnscap-134.tar.gz && cd dnscap-134
$ ./configure
$ make install
mkdir -p /usr/local/bin /usr/local/share/man
if [ -f /usr/local/bin/dnscap ]; then \
mv -f /usr/local/bin/dnscap /usr/local/bin/dnscap.old; fi
cp dnscap /usr/local/bin
cp dnscap.cat1 /usr/local/man/cat1/dnscap.1
cp: ne peut créer le fichier régulier `/usr/local/man/cat1/dnscap.1': Aucun fichier ou dossier de ce type
make: *** [install] Erreur 1

Ce que je vais faire n'est pas très beau, mais comme c'est d'un man dont on parle, ça rentre dans l'acceptable.

$ ln -s /usr/local/man/man1 /usr/local/man/cat1
$ make install
mkdir -p /usr/local/bin /usr/local/share/man
if [ -f /usr/local/bin/dnscap ]; then \
mv -f /usr/local/bin/dnscap /usr/local/bin/dnscap.old; fi
cp dnscap /usr/local/bin
cp dnscap.cat1 /usr/local/man/cat1/dnscap.1

Jetons un oeil aux options disponibles, ça peut aider :

$ dnscap -help
dnscap: usage error: -h takes only [ir]
dnscap: version V1.0-OARC-r124 (2011-03-09)

usage: dnscap
[-?pd1g6fT] [-i ]+ [-r ]+ [-l ]+
[-u ] [-m [qun]] [-e [nytfsxir]]
[-h [ir]] [-s [ir]]
[-a ]+ [-z ]+ [-A ]+ [-Z ]+
[-w  [-k ]] [-t ] [-c ]
[-x ]+ [-X ]+
[-B ]+ [-E ]+

note: the -? or -\? option will display full help text

Et comme on est curieux, voyons ce que ça donne. Bien entendu, pour les besoins, j'ai pingué une machine qui n'était pas dans mon cache ARP et qui porte le doux nom de arctic. Les flux sont donc directement affichés, formatés en mode dig-like, et ça donne ça :

$ dnscap -i eth0 -g
[61] 2011-11-16 13:38:51.505423 [#0 eth0 0] \
[192.168.16.145].46889 [192.168.10.2].53  \
dns QUERY,NOERROR,20694,rd \
1 arctic.k-tux.com,IN,A 0 0 0
[153] 2011-11-16 13:38:51.505824 [#1 eth0 0] \
[192.168.10.2].53 [192.168.16.145].46889  \
dns QUERY,NOERROR,20694,qr|aa|rd|ra \
1 arctic.k-tux.com,IN,A \
1 arctic.k-tux.com,IN,A,86400,192.168.20.43 \
2 k-tux.com,IN,NS,86400,dns1.k-tux.com \
k-tux.com,IN,NS,86400,dns2.k-tux.com \
2 dns1.k-tux.com,IN,A,86400,192.168.10.2 \
dns2.k-tux.com,IN,A,86400,192.168.10.3
[69] 2011-11-16 13:38:51.513186 [#2 eth0 0] \
[192.168.16.145].41402 [192.168.10.2].53  \
dns QUERY,NOERROR,59669,rd \
1 43.21.168.192.in-addr.arpa,IN,PTR 0 0 0
[174] 2011-11-16 13:38:51.513522 [#3 eth0 0] \
[192.168.10.2].53 [192.168.16.145].41402  \
dns QUERY,NOERROR,59669,qr|aa|rd|ra \
1 43.21.168.192.in-addr.arpa,IN,PTR \
1 43.21.168.192.in-addr.arpa,IN,PTR,86400,arctic.k-tux.com \
2 168.192.in-addr.arpa,IN,NS,86400,dns2.k-tux.com \
168.192.in-addr.arpa,IN,NS,86400,dns1.k-tux.com \
2 dns1.k-tux.com,IN,A,86400,192.168.10.2 \
dns2.k-tux.com,IN,A,86400,192.168.10.3
^Cdnscap: signalled break

Le principal intérêt est de vérifier que vous n'avez pas de pépin sur vos serveurs DNS, et notamment avec ce qu'ils répondent, cela va de soit. Il existe un joli éventail d'outils dédiés aux checks du DNS signés de la même entité (OARC, comme vous pouvez le voir lors du run de dnscap) et qui sont à votre totale disposition. Il peut être bon d'y jeter un oeil et de les garder sous le coude au besoin :)

Shutdown accidentel : molly-guard

KXan — Fri, 04 Nov 2011 13:05:15 +0000

Il y a un ancien dicton qui dit que seuls 2 types d'admin existent en ce bas monde : ceux qui ont déjà fait un shutdown / reboot sur le mauvais serveur, et ceux qui ne vont pas tarder à le faire. Molly-guard est un tout petit outil qui permet de déroger à la règle en demandant simplement le nom du serveur sur lequel vous êtes loggué, histoire de vérifier que c'est bien sur lui que vous voulez lancer l'opération. Pour cela, rien de plus simple qu'une installation classique depuis les dépôts, puis d'un peu de conf, mais vraiment minime dans /etc/molly-guard/rc : décommenter la directive qui suit.

ALWAYS_QUERY_HOSTNAME=true

Le test est facile :

k-serv $ sudo reboot
W: molly-guard: SSH session detected!
Please type in hostname of the machine to reboot: k-ldap
Good thing I asked; I won’t reboot k-serv …
W: aborting reboot due to 30-query-hostname exiting with code 1.

En pratique, molly-guard vous protègera donc des halt, shutdown et reboot intempestifs. Bon à savoir quand on est débordé et qu'on a plus de 5 terminaux d'ouverts :)

OSSEC : Surveillance du système et réponse active

KXan — Mon, 10 Oct 2011 13:00:59 +0000

Le dernier post était axé sur la surveillance de certaines données via auditd. Et bien cette fois, câblons plus efficace, et englobons dans un joli package surveillance du système ET réponse active ! C'est le rôle d'OSSEC.

OSSEC

OSSEC est un HIDS (Host-based Intrusion Detection System). Il s'agit en quelque sorte d'une sonde qui travaille sur une machine en particulier et analyse les éléments propres à cette machine. OSSEC dispose de fonctionnalités adaptées à son utilisation, comme l'analyse de logs, la détection de rootkit, les alertes en temps réel et les réponses actives. OSSEC fonctionne sur la plupart des OS communément rencontrés : Windows, Linux, Mac OS, HP-UX, solaris, ... Il s'appuie sur un schéma client / Serveur :

d'une part le Manager, qui met à disposition les éléments permettant d'évaluer les clients et stocke les informations renvoyées par ces clients
d'autre part un agent, qui se charge de récupérer les éléments nécessaires aux analyses et pousse le tout au Manager

Cependant, OSSEC peut très bien se passer de l'agent, par exemple pour le cas où les systèmes à monitorer seraient plus de l'ordre des équipements réseaux. Ce mode ne sera pas testé ici, mais sachez qu'il est tout-à-fait envisageable.

Installation et configuration en standalone

Comme d'habitude, l'installation se fera depuis les sources, non pas que l'outil ne soit pas disponible sur les dépôts, mais il se peut qu'il date un peu par rapport à la fraiche mouture du site référent. L'installation est on ne peut plus simple : ./install

$ wget http://www.ossec.net/files/ossec-hids-2.6.tar.gz
$ tar zxvf ossec-hids-2.6.tar.gz
$ cd ossec-hids-2.6
$ sudo "./install.sh "
Password:

** Pour une installation en français, choisissez [fr]
(en/br/cn/de/el/es/fr/it/jp/nl/pl/ru/sr/tr) [en]: fr

OSSEC HIDS v2.6 Script d'installation - http://www.ossec.net

Vous êtes sur le point d'installer OSSEC HIDS.
Vous devez avoir une compilateur C préinstallé sur votre système.
Si vous avez des questions ou des commentaires, envoyez un email
à dcid@ossec.net (ou daniel.cid@gmail.com).

- Système: Linux ossec-server.k-tux Debian
- Utilisateur: root
- Hôte: ossec-server.k-tux

-- Appuyez sur Entrée pour continuer ou Ctrl-C pour annuler. --

1- Quel type d'installation voulez-vous (serveur, agent, local ou aide) ? serveur
- Installation du serveur choisie.

2- Définition de l'environnement d'installation.
- Choisissez votre répertoire d'installation de OSSEC HIDS [/var/ossec]:
- L'installation sera faite sur  /var/ossec .

3- Configuration de OSSEC HIDS.
3.1- Voulez-vous une alerte par email ? (o/n) [o]: o
- Quel est votre adresse email ? k-tux@k-tux.com
- Quel est l'adresse IP ou le nom d'hôte de votre serveur SMTP ? smtp.k-tux.com

3.2- Voulez-vous démarrer le démon de vérification d'intégrité ? (o/n) [o]: o
- Lancement de syscheck (démon de vérification d'intégrité).

3.3- Voulez-vous démarrer le moteur de détection de rootkit ? (o/n) [o]: o
- Lancement de rootcheck (détection de rootkit).

3.4- La réponse active vous permet d'éxécuter des commandes  spécifiques en fonction d'évènement. Par exemple, vous pouvez bloquer une adresse IP ou interdire l'accès à un utilisateur spécifique. Plus d'information sur : http://www.ossec.net/en/manual.html#active-response
- voulez-vous démarrer la réponse active ? (o/n) [o]: o
- Réponse active activée.

- Par défaut, nous pouvons activer le contrôle d'hôte
et le pare-feu (firewall-drop). Le premier ajoute un hôte dans /etc/hosts.deny et le second bloquera l'hôte dans iptables (sous linux) ou dans ipfilter (sous Solaris, FreeBSD ou NetSBD).
- Ils peuvent aussi être utilisés pour arrêter les scans en force brute de SSHD, les scans de ports ou d'autres formes d'attaques. Vous pouvez aussi les bloquer par rapport à des évènements snort, par exemple.
- Voulez-vous activer la réponse pare-feu (firewall-drop) ? (o/n) [o]:
- pare-feu (firewall-drop) activé (local) pour les levels >= 6
- liste blanche (white list) par défaut pour la réponse active :
- Voulez-vous d'autres adresses IP dans votre liste (white list) ? (o/n)? [n]:

3.5- Voulez-vous activer fonctionnalité syslog (port udp 514) ? (o/n) [o]:
- Fonctionnalité syslog activé.

3.6- Mise en place de la configuration pour analyser les logs suivants :
-- /var/log/messages
-- /var/log/auth.log
-- /var/log/secure
-- /var/log/syslog
-- /var/log/security
-- /var/log/maillog
-- /var/log/proftpd/proftpd.log
-- /var/log/httpd/error_log (apache log)
-- /var/log/httpd/access_log (apache log)

- Si vous voulez surveiller d'autres fichiers, changez le fichier ossec.conf en ajoutant une nouvelle valeur de nom de fichier local. Pour toutes vos questions sur la configuration, consultez notre site web http://www.ossec.net
--- Appuyez sur Entrée pour continuer ---

5- Installation du système
- Exécution du Makefile INFO: Little endian set.
[...]
- Le Système est Debian Linux.
- Script d'initialisation modifié pour démarrer OSSEC HIDS pendant le boot.
- Configuration correctement terminée.
- Pour démarrer OSSEC HIDS:
/var/ossec/bin/ossec-control start
- Pour arrêter OSSEC HIDS:
/var/ossec/bin/ossec-control stop
- La configuration peut être visualisée ou modifiée dans /var/ossec/etc/ossec.conf

Merci d'utiliser OSSEC HIDS.
Si vous avez des questions, suggestions ou si vous trouvez un bug, contactez nous sur contact@ossec.net ou en utilisant la liste de diffusion publique sur ossec-list@ossec.net ( http://www.ossec.net/en/mailing_lists.html ).
Plus d'information peut être trouver sur http://www.ossec.net

- Vous devez ajouter le(s) agent(s) avant qu'ils aient un accés autorisé. Lancez 'manage_agent' pour les ajouter ou les supprimer:
/var/ossec/bin/manage_agents

Plus d'information sur http://www.ossec.net/en/manual.html

C'est plutôt verbeux, ce qui nous permet de bien maîtriser ce qui est fourni à OSSEC et de savoir par où commencer. Allons faire un tour sur le basedir d'OSSEC : /var/ossec.

$ cd /var/ossec/
$ ll
total 76
4 dr-xr-x--- 15 root  ossec 4096 2011-08-25 15:28 .
4 drwxr-xr-x 21 root  root  4096 2011-08-25 15:28 ..
4 dr-xr-x---  3 root  ossec 4096 2011-08-25 15:28 active-response
4 dr-xr-x---  2 root  ossec 4096 2011-08-25 15:28 agentless
4 -r-xr-x---  1 root  ossec   24 2011-08-25 15:28 .bash_logout
4 -r-xr-x---  1 root  ossec  191 2011-08-25 15:28 .bash_profile
4 -r-xr-x---  1 root  ossec  124 2011-08-25 15:28 .bashrc
4 dr-xr-x---  2 root  ossec 4096 2011-08-25 15:28 bin
4 dr-xr-x---  3 root  ossec 4096 2011-08-25 15:28 etc
4 dr-xr-x---  2 root  ossec 4096 2011-08-25 15:28 .gnome2
4 drwxr-x---  5 ossec ossec 4096 2011-08-25 15:28 logs
4 dr-xr-x---  2 root  ossec 4096 2011-08-25 15:28 .mozilla
4 dr-xr-x--- 11 root  ossec 4096 2011-08-25 15:28 queue
4 dr-xr-x---  3 root  ossec 4096 2011-08-25 15:28 rules
4 -r-xr-x---  1 root  ossec 3793 2011-08-25 15:28 .screenrc
4 drwx------  2 ossec ossec 4096 2011-08-25 15:28 .ssh
4 drwxr-x---  2 ossec ossec 4096 2011-08-25 15:28 stats
4 dr-xr-x---  2 root  ossec 4096 2011-08-25 15:28 tmp
4 dr-xr-x---  3 root  ossec 4096 2011-08-25 15:28 var

Comme on peut le voir, toute une arborescence a été créée et remplie avec les informations données à l'installation.

La configuration se trouve sous etc, profitons-en pour jeter un oeil dessus :

$ cat etc/ossec.conf


yes
k-tux@k-tux.com
smtp.k-tux.com
ossecm@ossec-server.k-tux



rules_config.xml
pam_rules.xml
sshd_rules.xml
telnetd_rules.xml
syslog_rules.xml
arpwatch_rules.xml
symantec-av_rules.xml
symantec-ws_rules.xml
pix_rules.xml
named_rules.xml
smbd_rules.xml
vsftpd_rules.xml
pure-ftpd_rules.xml
proftpd_rules.xml
ms_ftpd_rules.xml
ftpd_rules.xml
hordeimp_rules.xml
roundcube_rules.xml
wordpress_rules.xml
cimserver_rules.xml
vpopmail_rules.xml
vmpop3d_rules.xml
courier_rules.xml
web_rules.xml
apache_rules.xml
nginx_rules.xml
php_rules.xml
mysql_rules.xml
postgresql_rules.xml
ids_rules.xml
squid_rules.xml
firewall_rules.xml
cisco-ios_rules.xml
netscreenfw_rules.xml
sonicwall_rules.xml
postfix_rules.xml
sendmail_rules.xml
imapd_rules.xml
mailscanner_rules.xml
dovecot_rules.xml
ms-exchange_rules.xml
racoon_rules.xml
vpn_concentrator_rules.xml
spamd_rules.xml
msauth_rules.xml
mcafee_av_rules.xml
trend-osce_rules.xml
ms-se_rules.xml

zeus_rules.xml
solaris_bsm_rules.xml
vmware_rules.xml
ms_dhcp_rules.xml
asterisk_rules.xml
ossec_rules.xml
attack_rules.xml
openbsd_rules.xml
clam_av_rules.xml
bro-ids_rules.xml
dropbear_rules.xml
local_rules.xml




79200


/etc,/usr/bin,/usr/sbin
/bin,/sbin


/etc/mtab
/etc/mnttab
/etc/hosts.deny
/etc/mail/statistics
/etc/random-seed
/etc/adjtime
/etc/httpd/logs
/etc/utmpx
/etc/wtmpx
/etc/cups/certs
/etc/dumpdates
/etc/svc/volatile


C:\WINDOWS/System32/LogFiles
C:\WINDOWS/Debug
C:\WINDOWS/WindowsUpdate.log
C:\WINDOWS/iis6.log
C:\WINDOWS/system32/wbem/Logs
C:\WINDOWS/system32/wbem/Repository
C:\WINDOWS/Prefetch
C:\WINDOWS/PCHEALTH/HELPCTR/DataColl
C:\WINDOWS/SoftwareDistribution
C:\WINDOWS/Temp
C:\WINDOWS/system32/config
C:\WINDOWS/system32/spool
C:\WINDOWS/system32/CatRoot



/var/ossec/etc/shared/rootkit_files.txt
/var/ossec/etc/shared/rootkit_trojans.txt
/var/ossec/etc/shared/system_audit_rcl.txt
/var/ossec/etc/shared/cis_debian_linux_rcl.txt
/var/ossec/etc/shared/cis_rhel_linux_rcl.txt
/var/ossec/etc/shared/cis_rhel5_linux_rcl.txt



127.0.0.1
^localhost.localdomain$



syslog



secure



1
7



host-deny
host-deny.sh
srcip
yes



firewall-drop
firewall-drop.sh
srcip
yes



disable-account
disable-account.sh
user
yes



restart-ossec
restart-ossec.sh




route-null
route-null.sh
srcip
yes





host-deny
local
6
600




firewall-drop
local
6
600





syslog
/var/log/messages



syslog
/var/log/auth.log



syslog
/var/log/secure



syslog
/var/log/syslog



syslog
/var/log/security



syslog
/var/log/maillog



syslog
/var/log/proftpd/proftpd.log



apache
/var/log/httpd/error_log



apache
/var/log/httpd/access_log

Par défaut telle quelle, la configuration est tout-à-fait viable. On recevra alors des mails du genre :

[...]Received: from notify.ossec.net (ossec-server.k-tux.com)[...]
To: 
From: "OSSEC HIDS" 
Date: Wed, 21 Sep 2011 14:23:41 +0200
Subject: OSSEC Notification - ossec-server.k-tux - Alert level 4

OSSEC HIDS Notification.
2011 Sep 21 14:23:28

Received From: ossec-server.k-tux->/var/log/messages
Rule: 10100 fired (level 4) -> "First time user logged in."
Portion of the log(s):

Sep 21 14:23:26 ossec-server.k-tux sshd[3185]: Accepted password for k-user1 from 192.168.10.105 port 62205 ssh2

 --END OF NOTIFICATION

C'est pratique, notamment pour garder un oeil sur ce qui se passe sur votre infrastructure, cela s'inscrit notamment dans la même veine que le monitoring via Nagios, à ceci près qu'il n'a besoin que des logs de la cible. D'ailleurs, on pourrait mettre également en place la centralisation de logs, afin de pouvoir sécuriser les éléments sur lesquels OSSEC s'appuie.

Active responses

Les actives responses -ou réponses actives en français- sont une des principales fonctionnalités d'OSSEC. Ce sont des actions qui, selon certaines conditions, permettent d'agir immédiatement et de prendre les mesures qui s'imposent. Comme on peut s'en douter, il est facile de mesurer les avantages et inconvénients de ces mécanismes : rapidité de réponse, efficacité (trop parfois), faux positifs, ... Tout est contenu dans la définition : il s'agit d'une part de paramétrer une action / une commande, et de l'autre, de spécifier les conditions déclenchant l'action. Comme vous pouvez le constater, la cnfiguration par défuat en contient déjà quelques unes, comme par exemple :


firewall-drop
firewall-drop.sh
srcip
yes

[...]


firewall-drop
local
6
600

En ce qui concerne la définition de la commande, on a principalement :

le nom de la commande
l'exécutable auquel OSSEC doit se référer pour l'action, situé sous /var/ossec/active-response/bin/
expect, qui contient l'argument nécessaire pour effectuer l'action
la possibilité d'autoriser un timeout

Pour ce qui est de la définition de la réponse active, on doit spécifier :

le nom de la commande
location : où la commande doit être exécutée. 4 choix s'offrent à vous :

local ; c'est-à-dire sur la machine cliente, où l'agent s'est exécuté
server ; donc sur le serveur OSSEC lui-même
defined-agent ; sur un agent spécifique, il faut alors renseigner un champ agent_id pour que cela soit fait correctement
all : partout

agent_id : le fameux agent sur lequel l'action sera faite si on a mentionné defined-agent dans les balises de location
level : la réponse sera exécutée sur chaque évènement ayant un niveau supérieur ou égal à celui spécifié
timeout : combien de temps avant que la réponse soit défaite (par exemple, ici, l'ip débloquée)

Voyons ce que cela donne dans le cadre d'une installation d'un client seulement...

Clients / Serveur

L'installation d'un client distinct fonctionne à peu près pareil que pour l'installation du serveur, à ceci près que l'on mention agent au lieu de server.

# cd /usr/lcoal/src/ossec-hids-2.6
-bash-4.0# ls
active-response/  BUGS  CONFIG  contrib/  CONTRIBUTORS  doc/  etc/  INSTALL  install.sh*  LICENSE  README  src/
-bash-4.0# ./install.sh
** Pour une installation en français, choisissez [fr]
(en/br/cn/de/el/es/fr/it/jp/nl/pl/ru/sr/tr) [en]: fr

OSSEC HIDS v2.6 Script d'installation - http://www.ossec.net
[...]

- Système: Linux Debian
- Utilisateur: root
- Hôte: ossec-agent.k-tux.com

1- Quel type d'installation voulez-vous (serveur, agent, local ou aide) ? agent
- Installation de l'agent (client) choisie.
2- Définition de l'environnement d'installation.
- Choisissez votre répertoire d'installation de OSSEC HIDS [/var/ossec]:
- L'installation sera faite sur  /var/ossec .
3- Configuration de OSSEC HIDS.
3.1- Quelle est l'adresse IP de votre serveur OSSEC HIDS ?: 192.168.206.145
- Ajout de l'IP du Serveur 192.168.206.145
3.2- Voulez-vous démarrer le démon de vérification d'intégrité ? (o/n) [o]: o
- Lancement de syscheck (démon de vérification d'intégrité).
3.3- Voulez-vous démarrer le moteur de détection de rootkit ? (o/n) [o]:
- Lancement de rootcheck (détection de rootkit).
3.4 - voulez-vous démarrer la réponse active ? (o/n) [o]:
3.5- Mise en place de la configuration pour analyser les logs suivants :
-- /var/log/messages
-- /var/log/auth.log
-- /var/log/secure
-- /var/log/syslog
-- /var/log/security
-- /var/log/maillog
-- /var/log/proftpd/proftpd.log
-- /var/log/httpd/error_log (apache log)
-- /var/log/httpd/access_log (apache log)

5- Installation du système
- Exécution du Makefile [...]
- Le Système est Debian Linux.
- Script d'initialisation modifié pour démarrer OSSEC HIDS pendant le boot.
- Configuration correctement terminée.
- Pour démarrer OSSEC HIDS:
/var/ossec/bin/ossec-control start
- Pour arrêter OSSEC HIDS:
/var/ossec/bin/ossec-control stop
- La configuration peut être visualisée ou modifiée dans /var/ossec/etc/ossec.conf
- Vous devez d'abord ajouter cet agent sur le serveur pour
qu'ils communiquent entre eux. Quand cela sera fait,
vous pourrez lancer l'outil 'manage_agents' pour
importer la clef d'authentification depuis le serveur.

/var/ossec/bin/manage_agent

Comme mentionné, il faut ajouter manuellement l'agent sur le serveur, car sinon, il ne voit que lui-même. Pour cela il faut utiliser manage_agent, qui, sur mon serveur, se situe sous /var/ossec/bin. Quant à agent_control, il permet d'avoir la main sur la liste des agents référencés et de leur faire subir quelques contrôles.

 ossec-server.k-tux# agent_control -l

OSSEC HIDS agent_control. List of available agents:
ID: 000, Name: ossec-serv.k-tux (server), IP: 127.0.0.1, Active/Local

# manage_agents
****************************************
* OSSEC HIDS v2.6 Agent manager.     *
* The following options are available: *
****************************************
(A)dd an agent (A).
(E)xtract key for an agent (E).
(L)ist already added agents (L).
(R)emove an agent (R).
(Q)uit.
Choose your action: A,E,L,R or Q: A

- Adding a new agent (use '\q' to return to the main menu).
Please provide the following:
* A name for the new agent: ossec-agent.k-tux
* The IP Address of the new agent: 192.168.206.151
* An ID for the new agent[001]:
Agent information:
ID:001
Name:ossec-agent.k-tux
IP Address:192.168.206.151
Confirm adding it?(y/n): y
Agent added.

****************************************
* OSSEC HIDS v2.6 Agent manager.     *
* The following options are available: *
****************************************
(A)dd an agent (A).
(E)xtract key for an agent (E).
(L)ist already added agents (L).
(R)emove an agent (R).
(Q)uit.
Choose your action: A,E,L,R or Q: Q

** You must restart the server for your changes to have effect.
manage_agents: Exiting ..

Et de redémarrer le serveur ossec :

# ossec-control restart
Deleting PID file '/var/ossec/var/run/ossec-remoted-7684.pid' not used...
Killing ossec-monitord ..
Killing ossec-logcollector ..
ossec-remoted not running ..
Killing ossec-syscheckd ..
Killing ossec-analysisd ..
Killing ossec-maild ..
Killing ossec-execd ..
OSSEC HIDS v2.6 Stopped
Starting OSSEC HIDS v2.6 (by Trend Micro Inc.)...
OSSEC analysisd: Testing rules failed. Configuration error. Exiting.
Started ossec-maild...
Started ossec-execd...
Started ossec-analysisd...
Started ossec-logcollector...
Started ossec-remoted...
Started ossec-syscheckd...
Started ossec-monitord...
Completed.

Du client, si rien de plus n'est fait, on part tout de même en erreur sur une histoire de clé :

 ossec-agent.k-tux # /var/ossec/bin/ossec-control start
Starting OSSEC HIDS v2.6 (by Trend Micro Inc.)...
Started ossec-execd...
2011/10/05 13:21:39 ossec-agentd(1402): ERROR: Authentication key file '/var/ossec/etc/client.keys' not found.
2011/10/05 13:21:39 ossec-agentd(1750): ERROR: No remote connection configured. Exiting.
2011/10/05 13:21:39 ossec-agentd(4109): ERROR: Unable to start without auth keys. Exiting.

Pour récupérer la clé du client, il faut créer un fichier /var/ossec/etc/client.keys qui contiendra la clé du client que le serveur garde sous son /var/ossec/etc/clients.keys (attention, il y a bien un s à clients, contrairement à celui du client).

ossec-agent.k-tux # cat /var/ossec/etc/client.keys
001 ossec-agent.k-tux 192.168.206.151 3ba007429eb3f283e85cc18eefcf4e01e64604e82757723db94c23fd1026df88

Une autre méthode, mais qui n'a pas fonctionné pour moi, est, depuis le client, de passer par manage_agent avec un bon cut/paste de la clé :

ossec-agent.k-tux # ./manage_agents

****************************************
* OSSEC HIDS v2.6 Agent manager.     *
* The following options are available: *
****************************************
(I)mport key from the server (I).
(Q)uit.
Choose your action: I or Q: I

* Provide the Key generated by the server.
* The best approach is to cut and paste it.
*** OBS: Do not include spaces or new lines.

Paste it here (or '\q' to quit): 3ba007429eb3f283e85cc18eefcf4e01e64604e82757723db94c23fd1026df88

** Invalid authentication key. Starting over again.
** Press ENTER to return to the main menu.

Dans un cas comme dans l'autre -du moins si votre manage_agent fonctionne sur l'import-, vous pouvez dès que cela est réglé, lancer ossec-agent sur le client :

ossec-agent.k-tux # /var/ossec/bin/ossec-control start
Starting OSSEC HIDS v2.6 (by Trend Micro Inc.)...
ossec-execd already running...
Started ossec-agentd...
Started ossec-logcollector...
Started ossec-syscheckd...
Completed.

A partir de là, votre agent fonctionne tout comme votre serveur, notifications et réponses actives !

Conclusion

Il est indéniable qu'OSSEC dispose de fonctionnalités clé qui permettent d'avoir un état en temps réel de votre infrastructure. En cela, il devient un des outils nécessaires à tout administrateur voulant contrôler un peu plus ce qui se passe sur son parc. Cependant, comme pour tous les outils puissants, il reste maintenant à faire un peu de tri dans les informations renvoyées, afin de distinguer celles qui sont vraiment importantes de celles qui relèvent plus de l'anecdote. Car c'est un risque identifié : plus il y a de bruit, et moins on voit le problème...

Auditd : monitoring de données en temps réel

KXan — Mon, 05 Sep 2011 16:45:14 +0000

Auditd

Auditd est un outil qui permet de monitorer les accès aux données et de pouvoir offrir un support stable pour l'exploitation des logs. Auditd fait partie d'un ensemble de composants qui ont pour fonctionnalités de gérer les règles de surveillance et d'afficher les rapports. Auditd est le daemon qui tourne en fond, en userspace, et qui est au coeur de la récupération des informations.

Prise en main

L'installation est très facile, et comme l'outil a fait ses preuves, on peut l'installer directement depuis les dépôts officiels.

$ apt-get install audit

Et oui, cela suffit...

Configuration

La configuration d'audit se trouve sous /etc/audit/. On y trouve auditd.conf, qui est la conf à proprement parler du daemon auditd et audit.rules qui est destiné à contenir vos règles en dur.

# ls -asl /etc/audit/
total 24
4 drwxr-x--- 2 root root 4096 2011-09-02 15:13 ./
12 drwxr-xr-x 140 root root 12288 2011-09-05 15:23 ../
4 -rw-r----- 1 root root 680 2009-07-27 21:07 auditd.conf
4 -rw-r----- 1 root root 373 2009-07-27 21:07 audit.rules

La conf ressemble à ça :

#
# This file controls the configuration of the audit daemon
#

log_file = /var/log/audit/audit.log
log_format = RAW
log_group = root
priority_boost = 4
flush = INCREMENTAL
freq = 20
num_logs = 4
disp_qos = lossy
dispatcher = /sbin/audispd
name_format = NONE
##name = mydomain
max_log_file = 5
max_log_file_action = ROTATE
space_left = 75
space_left_action = SYSLOG
action_mail_acct = root
admin_space_left = 50
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND
##tcp_listen_port =
tcp_listen_queue = 5
##tcp_client_ports = 1024-65535
tcp_client_max_idle = 0
enable_krb5 = no
krb5_principal = auditd
##krb5_key_file = /etc/audit/audit.key

Cette conf nous apprend notamment l'emplacement du log généré par le daemon, ce qui nous permettra d'y jeter un œil plus tard, pour extraction. Quant à audit.rules, à la base, il est un peu vide, comme vous pouvez le constater : un -D pour tout flusher, une instruction d'augmentation de buffer, en dehors de cela, tout reste à faire.

$ cat /etc/audit/audit.rules

# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.

# First rule - delete all
-D

# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 320

# Feel free to add below this line. See auditctl man page

Il y a donc 2 manières différentes de faire des règles : en statique dans le fichier de conf /etc/audit/audit.rules, ou à la volée. Bien sûr, les seules différences entre statique et à la volée sont que :

la volée ne survit pas à un reboot, alors que statique se lancera avec le daemon auditd
la syntaxe des règles statiques est la même que celles à la volée, mis à part l'invocation de auditctl.

Création et gestions des règles

Comme c'est plus facile, et que c'est pratique, nous allons créer quelques règles à la volée. Pour information, voici les options que j'ai renseigné :

w : watch, activer la surveillance
p war : fixer le filtre concernant les permissions pour la surveillance d'un fichier. Ici, r pour read, w pour write, x pour execute, a pour append.
k passwd-file : clé unique permettant d'identifier l'objet de la requête

k-root # auditctl -w /etc/passwd -p war -k password-file
k-root # ausearch -f /etc/passwd

J'ai crée un watch sur le fichier /etc/passwd, qui relèvera toute tentative en read, write ou append sur le fichier. Comme on peut le voir, pour le moment, aucun évènement n'a eu lieu... Mais c'est sans compter sur k-user, qui va grepper root sur ledit fichier...

k-user $ grep root /etc/passwd
root:x:0:0:root:/root:/bin/bash

Immédiatement, la tentative -fructueuse- est journalisée et vue par auditd :

k-root # ausearch -f /etc/passwd
----
time->Fri Sep 2 15:16:50 2011
type=PATH msg=audit(1314969410.095:9): item=0 name="/etc/passwd" inode=1982554 dev=08:01 mode=0100644 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1314969410.095:9): cwd="/home/k-user/Documents"
type=SYSCALL msg=audit(1314969410.095:9): arch=40000003 syscall=5 success=yes exit=4 a0=b763b078 a1=80000 a2=1b6 a3=8295090 items=1 ppid=6893 pid=28672 auid=4294967295 uid=3100 gid=3000 euid=3100 suid=3100 fsuid=3100 egid=3000 sgid=3000 fsgid=3000 tty=(none) ses=4294967295 comm="ps" exe="/bin/ps" key="password-file"
----
time->Fri Sep 2 15:16:52 2011
type=PATH msg=audit(1314969412.095:10): item=0 name="/etc/passwd" inode=1982554 dev=08:01 mode=0100644 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1314969412.095:10): cwd="/home/k-user/Documents"
type=SYSCALL msg=audit(1314969412.095:10): arch=40000003 syscall=5 success=yes exit=4 a0=b7669078 a1=80000 a2=1b6 a3=86c6090 items=1 ppid=6893 pid=28673 auid=4294967295 uid=3100 gid=3000 euid=3100 suid=3100 fsuid=3100 egid=3000 sgid=3000 fsgid=3000 tty=(none) ses=4294967295 comm="ps" exe="/bin/ps" key="password-file"
---- [...]

On peut faire aussi un peu plus lisible, grâce à l'option -i qui interprètera les id (uid, guid, date, ...). Plus facile pour le coup d’œil, n'est-ce pas ?

k-root # ausearch -f /etc/passwd -i
----
type=PATH msg=audit(02/09/2011 15:16:50.095:9) : item=0 name=/etc/passwd inode=1982554 dev=08:01 mode=file,644 ouid=root ogid=root rdev=00:00
type=CWD msg=audit(02/09/2011 15:16:50.095:9) : cwd=/home/k-user/Documents
type=SYSCALL msg=audit(02/09/2011 15:16:50.095:9) : arch=i386 syscall=open success=yes exit=4 a0=b763b078 a1=80000 a2=1b6 a3=8295090 items=1 ppid=6893 pid=28672 auid=unset uid=k-user gid=k-user euid=k-user suid=k-user fsuid=k-user egid=k-user sgid=k-user fsgid=k-user tty=(none) ses=4294967295 comm=ps exe=/bin/ps key=password-file
----
type=PATH msg=audit(02/09/2011 15:16:52.095:10) : item=0 name=/etc/passwd inode=1982554 dev=08:01 mode=file,644 ouid=root ogid=root rdev=00:00
type=CWD msg=audit(02/09/2011 15:16:52.095:10) : cwd=/home/k-user/Documents
type=SYSCALL msg=audit(02/09/2011 15:16:52.095:10) : arch=i386 syscall=open success=yes exit=4 a0=b7669078 a1=80000 a2=1b6 a3=86c6090 items=1 ppid=6893 pid=28673 auid=unset uid=k-user gid=k-user euid=k-user suid=k-user fsuid=k-user egid=k-user sgid=k-user fsgid=k-user tty=(none) ses=4294967295 comm=ps exe=/bin/ps key=password-file
----

Les commandes de base sont intuitives, par exemple, le listing des règles en place :

k-root # auditctl -l
LIST_RULES: exit,always watch=/etc/passwd perm=rwa key=password-file
LIST_RULES: exit,always watch=/etc/shadow perm=rwax key=shadow-file

La suppression d'une règle (attention, une, et autant vous dire que les doublons ne sont pas conseillés). En parlant de doublon, étant donné que l'évaluation d'une règle est parfois coûteuse, comme par exemple l'évaluation de tous les syscall, la factorisation d'expression est préconisée.

k-root # auditctl -l
LIST_RULES: exit,always watch=/etc/shadow perm=rwxa key=shadow-file
LIST_RULES: exit,always watch=/etc/passwd perm=rwa key=passwd-file

k-root # auditctl -d exit,never -W /etc/shadow -k shadow-file

k-root # auditctl -l
LIST_RULES: exit,always watch=/etc/passwd perm=rwa key=passwd-file

A titre d'information, le delete all a déjà été vu dans le fichier de règles : l'option en question est -D. Bon à savoir quand on veut resetter notre daemon :)

Reporting

Pour ce qui est du reporting, pas de problème non plus, un tas d'options permettant en plus de mettre le focus sur ce que vous avez vraiment envie de consulter. Pour savoir un peu ce qui tourne, on appellera auditctl.

k-root # auditctl -s
AUDIT_STATUS: enabled=1 flag=1 pid=28521 rate_limit=0 backlog_limit=64 lost=0 backlog=0

Alors que pour le reporting à proprement parler, on passera par aureport : ici pour les évènements...

k-root # aureport -e
1840. 02/09/2011 16:14:25 1846 USER_AUTH -1 yes
1841. 02/09/2011 16:14:25 1847 CRED_REFR -1 yes
1842. 02/09/2011 16:14:23 1840 SYSCALL -1 yes

Et là pour lister les authentifications, réussi ou pas d'ailleurs :)

k-root # aureport --auth

Authentication Report
============================================
# date time acct host term exe success event
============================================
1. 02/09/2011 15:16:46 root ? pts/26 /bin/su yes 4
2. 02/09/2011 16:14:25 k-user ? :0 /usr/lib/kde4/libexec/kcheckpass yes 1846

Et enfin, vue d'ensemble, à la logwatch :

# aureport --summary

Summary Report
======================
Range of time in logs: 02/09/2011 15:14:10.327 - 02/09/2011 16:17:06.165
Selected time for report: 02/09/2011 15:14:10 - 02/09/2011 16:17:06.165
Number of changes in configuration: 4
Number of changes to accounts, groups, or roles: 0
Number of logins: 0
Number of failed logins: 0
Number of authentications: 2
Number of failed authentications: 0
Number of users: 1
Number of terminals: 8
Number of host names: 1
Number of executables: 23
Number of files: 2
Number of AVC's: 0
Number of MAC events: 0
Number of failed syscalls: 1
Number of anomaly events: 0
Number of responses to anomaly events: 0
Number of crypto events: 0
Number of keys: 2
Number of process IDs: 1847
Number of events: 1930

A titre d'indication, voila ce que renvoie le help de aureport.

k-root # aureport --help
usage: aureport [options]
-a,--avc Avc report
--auth Authentication report
-c,--config Config change report
-cr,--crypto Crypto report
-e,--event Event report
-f,--file File name report
--failed only failed events in report
-h,--host Remote Host name report
--help help
-i,--interpret Interpretive mode
-if,--input
 use this file as input
--input-logs Use the logs even if stdin is a pipe
-l,--login Login report
-k,--key Key report
-m,--mods Modification to accounts report
-ma,--mac Mandatory Access Control (MAC) report
--node Only events from a specific node
-n,--anomaly aNomaly report
-p,--pid Pid report
-r,--response Response to anomaly report
-s,--syscall Syscall report
--success only success events in report
--summary sorted totals for main object in report
-t,--log Log time range report
-te,--end [end date] [end time] ending date & time for reports
-tm,--terminal TerMinal name report
-ts,--start [start date] [start time] starting data & time for reports
-u,--user User name report
-v,--version Version
-x,--executable eXecutable name report
If no report is given, the summary report will be displayed

Auditd et Prelude

Ce qui est bien avec auditd, c'est qu'il ne fait pas sa soupe dans son coin, il peut aussi très bien échanger avec, mettons, des IDS... Malheureusement, comme je souhaite me garder encore quelques tips pour plus tard, je n'ai pas joué avec, mais sachez qu'il existe un plugin, audisp-prelude, qui, utilisant la librairie de Prelude, permet d'envoyer des IDMEF (Intrusion Detection Message Exchange Format). Ceci étant, il est nécessaire d'avoir un prelude-manager de disponible pour pouvoir agréger et corréler les données. D'ailleurs, si certains l'utilisent, je les encourage à donner de la voix sur leurs ressentis du produit :)

Conclusion

Auditd est un outil bien pratique, à porter de main, qui peut être appliqué dans un contexet de sécurisation et de monitoring comme de reporting sur des modifications effectuées sur les données du système. Il permet d'avoir un état des lieux concis et indiscutable et de pouvoir remonter le fil des évènements sans devoir dépendre totalement des informations fournies (ou pas) par les auteurs des modifs. Bien entendu, même s'il s'agit d'un outil très puissant et pouvant être redoutable d'efficacité, rien ne pourra remplacer une bonne com au sein de l'équipe :)

Wipe : suppression de données irréductibles

KXan — Fri, 02 Sep 2011 09:56:38 +0000

Ce tip est issu d'une situation fort désagréable et inconfortable qui m'a été donnée de rencontrer : un rm qui ne fonctionne mais alors pas du tout ! Le pire, c'est que le fichier en question -car c'est bien un fichier (?!!!?) qui bloque un rm -rf (pourtant, syntaxe ok) semble être un fichier vide. Le fait est que :

le récalcitrant se trouve sur un partage NFS
le rm -rf n'a pas eu plus de succès en direct sur le serveur qu'en montage nfs.
mv ne fonctionne pas, cela va sans dire
... C'est un fichier vide...

Dans ce cas de figure, pas mal d'alternatives fourmillent, et la première étant de supprimer le fichier par son inode :

k-srv:/export/beta $ stat HOME/Documents/LaTeX/Rapport4-b4/qt_temp.vM6596
File: `HOME/Documents/LaTeX/Rapport4-b4/qt_temp.vM6596'
Size: 0               Blocks: 0          IO Block: 32768  fichier régulier vide
Device: 1ah/26d Inode: 247409165   Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 3132/ UNKNOWN)   Gid: ( 3000/  k-user)
Access: 2011-09-02 09:43:04.000000000 +0200
Modify: 2011-09-01 16:33:48.000000000 +0200
Change: 2011-09-01 16:33:48.000000000 +0200

k-srv:/export $ ls -il HOME/Documents/LaTeX/Rapport4-b4/qt_temp.vM6596
247409165 -rw-r--r-- 1 3132 k-user 0 2011-09-01 16:33 HOME/Documents/LaTeX/Rapport4-b4/qt_temp.vM6596
k-srv:/export $ su -c "find . -inum 247409165 -exec rm -i {} \;"
Password:
rm: détruire fichier régulier vide `./HOME/Documents/LaTeX/Rapport4-b4/qt_temp.vM6596'? y
rm: ne peut enlever `./HOME/Documents/LaTeX/Rapport4-b4/qt_temp.vM6596': Aucun fichier ou dossier de ce type
k-srv:/export $ ls -il HOME/Documents/LaTeX/Rapport4-b4/qt_temp.vM6596
247409165 -rw-r--r-- 1 3132 k-user 0 2011-09-01 16:33 HOME/Documents/LaTeX/Rapport4-b4/qt_temp.vM6596

Comme vous pouvez le constater, cela ne fonctionne pas mieux que notre bon vieux rm -rf. En farfouillant sur le Wired, j'ai pu trouver 2 outils ma foi bien sympa : Wipe et Schred. Le second étant plutôt orienté "je te dd plusieurs fois avant de te supprimer", aka sécurité, je me suis penchée sur le premier : Wipe. Et là, bonne surprise, il est dans les dépôts !

k-srv:/export $ apt-get install wipe

Le premier test, lancé en interactif (histoire de contrôler un minimum ce qui est fait) ne semble pas satisfaisant :

k-srv:/export/beta $ su -c "wipe -r -i /export/beta/HOME/"
Password:
wipe: destroy files in `/export/beta/HOME/'? y
wipe: destroy files in `Documents'? y
wipe: destroy files in `LaTeX'? y
wipe: destroy files in `Rapport4-b4'? y
wipe: destroy file `qt_temp.vM6596'? y
wipe: cannot rename `qt_temp.vM6596': Invalid argument
wipe: remove directory `Rapport4-b4'? y
wipe: Directory not empty: unable to remove directory: `Rapport4-b4'
wipe: remove directory `LaTeX'? y
wipe: Directory not empty: unable to remove directory: `LaTeX'
wipe: remove directory `Documents'? y
wipe: Directory not empty: unable to remove directory: `Documents'
wipe: remove directory `/export/beta/HOME'? y
wipe: Directory not empty: unable to remove directory: `HOME'

Mais en fait si, quoique pas tout-à-fait propre : une arborescence a été créée par le run de wipe, pas très joli, un peu incompréhensible :

k-srv:/export/beta $ ll
total 20
4 drwxr-xr-x  3 root root    4096 2011-09-02 09:54 .
12 drwxr-xr-x  3 3132 k-user 12288 2011-09-02 09:54 3s%@elQFgjxuX+YZ...
4 drwxr-xr-x 25 root root    4096 2011-09-01 04:42 ..

Le retry d'un peu plus haut, en revanche, paie, mais toujours avec ce faux-négatif. Attention, ici, c'est la suppression COMPLETE du répertoire que je lance, car c'était dans mon intention de tout supprimer concernant beta ! Cela n'a pas résolu directement la suppression du fichier fautif ! Et surtout, gare si vous faites un copier/coller, les conséquences sont difficilement réparables...

k-srv:/export $ wipe -r -v -f -i /export/beta/
wipe: destroy files in `/export/beta/'? y
wipe: destroy files in `j9E0tfoEivctXXg2Slx_MEYofK#cq...'? y
wipe: cannot rename `qt_temp.vM6596': Invalid argument
wipe: remove directory `LSmlfyE5s1@LTquaetz#%w2...'? y
wipe: Directory not empty: unable to remove directory: `LSmlfyE5s1@LTquaetz#%w...'
wipe: remove directory `74UAnCRudHzgJyZP1ydU1N08D%DNY3t3x5Q0N_HD...'? y
wipe: Directory not empty: unable to remove directory: `74UAnCRudJyZP1ydU1N08D%DN...'
wipe: remove directory `gP6Mw2SssTzzeWBAx7akfCZHw2jN8pMSZqM#qe8n%fc1FMWOAbklWObxvU...'? y
wipe: Directory not empty: unable to remove directory: `gP6Mw2SssTzzeWBAx7R3zakfCZHw2...'
wipe: remove directory `j9E0tfoEivctXXg2Slx_MEYofK#cq.kCGR9jpnAPR4C@xcRKiUJXB8uow...'? y
wipe: Directory not empty: unable to remove directory: `j9E0tfoEivctXXg2Slx_MEYofK#cq...'
wipe: remove directory `/export/beta'? y
wipe: Directory not empty: unable to remove directory: `beta'

k-srv:/export $ ls /export/beta
ls: ne peut accéder /export/beta : Aucun fichier ou dossier de ce type

Notez que :

mon problème est résolu,
j'ai dit que les conséquences d'un wipe étaient difficilement réparables.

En effet, car comme on trouve des utilitaires de suppression, on en trouve de restauration. Ca fera d'ailleurs l'objet d'un autre tip :) Sur ce, have a nice day !

Mutt : client mail en ligne de commande

KXan — Mon, 29 Aug 2011 11:45:44 +0000

Bonjour à tous ! Parlons peu, parlons bien, j'ai été confrontée il y a peu au besoin d'envoyer de manière récurrence un backup de configurations. J'ai donc été amenée à jouer avec Mutt. Mutt est un client mail en ligne de commande qui permet, entre autre, de pouvoir faire toutes les opérations du client mail natif de Linux, avec des options non négligeables en plus, comme, au hasard, la prise en charge des pièces jointes.

Mutt : Installation et... Utilisation

L'installation n'est pas plus difficile que ça, le maniement encore moins :

$ apt-get install mutt
$ mutt
q:Quitter  d:Effacer  u:RM-CM-)cup  s:Sauver  m:Message  r:RM-CM-)pondre  g:Groupe  ?:Aide
1 N F Aug 29 To k-tux@192.168.1.105 (   2) test



---Mutt: /var/spool/mail/k-tux [Msgs:1 New:1 0,6K]---(date/date)-------------------(all)---

Au premier lancement, il vous demande où stocker les préférences, etc... Et l'emplacement par défaut de la mailbox sera très classique : sous /var/spool/mail/. Mutt se présente un peu comme iftop, avec une interface directement faite en ligne de commande. Comme vous pouvez le constater, les principales commandes sont renseignées en haut de l'écran Mutt, qui permettent d'interagir tout-à-fait comme un client mail graphique, comme Thunderbird. Mais il peut également s'utiliser en ligne de commande sans passer par l'interface, ce qui est tout de même mieux pour le scripting :) Ici, pour l'exemple, test est un fichier contenant la chaine de caractère "Testing Mutt" :

$ mutt -s "k-tux test" k-tux@k-tux.com < test

Les mails envoyés seront stockés sous ~/sent, qui est un fichier text :

$ cat sent
From k-tux@192.168.1.105 Mon Aug 29 10:50:34 2011
Date: Mon, 29 Aug 2011 10:50:34 +0200
From: k-tux 
To: k-tux@k-tux.com
Subject: k-tux test
Message-ID: <20110829085034.GA14010@192.168.1.105>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Status: RO
Content-Length: 13
Lines: 1

Testing Mutt

Et maintenant, test d'envoi de pièce jointes :

$ mutt -s "k-tux test" k-tux@k-tux.com -a /data/k-tux/backup.tar.gz < test

Le ~/sent a rajouté :
From k-tux@192.168.1.105 Mon Aug 29 10:56:51 2011
Date: Mon, 29 Aug 2011 10:56:51 +0200
From: k-tux 
To: k-tux@k-tux.com
Subject: k-tux test
Message-ID: <20110829085651.GA14297@192.168.1.105>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="ZGiS0Q5IWpPtfppv"
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Status: RO
Content-Length: 6256
Lines: 96


--ZGiS0Q5IWpPtfppv
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

Mutt : Testing enclosed data

--ZGiS0Q5IWpPtfppv
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="backup.tar.gz"
Content-Transfer-Encoding: base64

H4sIAJATVk4AA+1dbZPbthH2V9+vYC8fnIxLHUmRVOpxPJMmbuMZx/bEdjqdTKeFSIhCRBI0
AOpO/vVdAJROOgOk7sVMbOOZxDphl3hb7GIXL9Q8WxTRhGO2xmwSJcG3YXh2744RAGZJoj4B
Vz/V32GYRkkchtM0uheEURrE97zkritiQssFYp53j1Eq+viG6J8o5gb5q7Q7HAVHyj8MgSmK
YpD/NJlFTv5jwC7/V6uiKthdDIOj5Z+ABYinIP8kCFMn/zHQI3+UrVCB+e1HwLHynyZROotn
Uv7TKHDyHwNHyD9D2RLfZhRcZ/5PppAeptM4cfIfA8fIn9YLUkwuqvKGZUgBp3FslX8SR1v7
H0aR9P9m0Qz0P7jTllrwhcv/8WvasgzzJyf3Pe/x96/e6O/66z8ZbZsnOZ4TVPv8XYvxe/z4
TKcqhre/PH+yFKJ5dHa2EM0kxxPNPKGsONN/nj0+k1ySXeLxr5hxQusnu+y2CTuOH2jV0BrX
4kmFSP347PK7iaUtBYGxy/EAI8NcMJIJnA8wtnVPft+zbPkEVXkaPz5Tf594HeD7Zec9Ptt1
[...]

PGP

Il est possible d'utiliser PGP pour signer le mail, le chiffrer ou les deux. Pour cela, en interface, il suffit de taper "p" lors du récapitulatif du mail à envoyer :

y:Envoyer  q:Abandonner  t:To  c:CC  s:Subj  a:Attacher fichier  d:Description  ?:Aide
From: K-Tux 
To: k-tux@k-tux.com
Cc:
Bcc:
Subject: Mutt : Test PGP
Reply-To:
Fcc: ~/sent
Security: Clair


-- Attachements
- I     1 /tmp/mutt-192.168.1.105-3100-15158-0      [text/plain, 7bit, iso-8859-1, 0,1K]
-- Mutt: Compose  [Approx. msg size: 0,1K   Atts: 1]---------------------------------------
(c)hiffrer PGP, (s)igner, (e)n tant que, les (d)eux, en l(i)gne, en clai(r)M-BM- ?

Ici, on veut chiffrer, donc "c". Cela provoque la mise à jour du champ Security :

y:Envoyer  q:Abandonner  t:To  c:CC  s:Subj  a:Attacher fichier  d:Description  ?:Aide
From: K-Tux 
To: k-tux@k-tux.com
Cc:
Bcc:
Subject: Mutt : Test PGP
Reply-To:
Fcc: ~/sent
PGP: Chiffrer (PGP/MIME)


-- Attachements
- I     1 /tmp/mutt-192.168.1.105-3100-15158-0   [text/plain, 7bit, iso-8859-1, 0,1K]
-- Mutt: Compose  [Approx. msg size: 0,1K   Atts: 1]---

Mutt demandera alors la clé PGP avant d'envoyer le mail. Et avec ça, mon besoin est totalement comblé -du moins pour l'usage que je voulais en faire :). Il existe pas mal d'option et de fonctionnalités dans Mutt, que je ne détaillerais pas car à la fois la doc en ligne et le man -voire pour le reste, mutt -h- renvoient de manière concise les options et les fonctionnalités qu'il est possible d'utiliser :) En bref, pourquoi se priver ?

Rsnapshot : utilisataire de prise de cliché

KXan — Tue, 23 Aug 2011 12:06:32 +0000

Aujourd'hui, petit tip sur un utilitaire de sauvegarde / restauration : rsnapshot.

Principes

Rsnapshot est un outil système qui permet de prendre des clichés de répertoire. Cela permet notamment de sauvegarder localement ou de manière distante les données. Les transferts de données s'appuient sur rsync : les snapshots de données locales sont effectués via rsync, tandis que pour ceux de données distantes, rsync à travers ssh est utilisé. Le principal intérêt de rsnapshot est le cron, et le fait que tout s'appuie sur un fichier de configuration situé sous /etc/rsnapshot.conf.

Pratique

Pour commencer, nous allons installer -ce serait difficile de s'abstenir- rsnapshot depuis ces sources. A l'heure où j'écris ces lignes, la dernière version stable est la 1.3.1, aussi, si celle-ci venait à évoluer, il vous faudra alors adapter ces lignes en conséquence. Alors, comme d'habitude, hein, pas de grande difficulté ici :

$ wget http://rsnapshot.org/downloads/rsnapshot-1.3.1.tar.gz
$ tar zxvf rsnapshot-1.3.1.tar.gz
$ cd rsnapshot-1.3.1
rsnapshot-1.3.1 $ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make sets $(MAKE)... (cached) yes
checking for a BSD-compatible install... /usr/bin/install -c
checking for perl... /usr/bin/perl
checking for rsync... /usr/bin/rsync
checking for cp... /bin/cp
checking for rm... /bin/rm
checking for ssh... /usr/bin/ssh
checking for logger... /bin/logger
checking for du... /usr/bin/du
configure: creating ./config.status
config.status: creating Makefile
config.status: creating rsnapshot
config.status: creating rsnapshot-diff
config.status: creating rsnapshot.conf.default
config.status: creating t/support/etc/configtest.conf
config.status: creating t/support/etc/rsync.conf
config.status: creating t/support/etc/gnu_cp.conf
config.status: creating t/support/etc/relative_delete_bugfix.conf
config.status: creating t/configtest.t
config.status: creating t/rsync.t
config.status: creating t/gnu_cp.t
config.status: creating t/relative_delete_bugfix.t

Now type  "make test"    to run the regression test suite.
Then type "make install" to install the program.

After rsnapshot is installed, don't forget to copy
/usr/local/etc/rsnapshot.conf.default to /usr/local/etc/rsnapshot.conf

Puisque c'est si bien dit, c'est parti pour la séquence make && make install.

rsnapshot-1.3.1 $ make
/usr/bin/pod2man -c '' -n 'rsnapshot' -r '' rsnapshot > rsnapshot.1
/usr/bin/pod2man -c '' -n 'rsnapshot-diff' -r '' rsnapshot-diff > rsnapshot-diff.1

rsnapshot-1.3.1 $ make test
/usr/bin/perl -MTest::Harness -e 'runtests(glob "t/*.t")';
t/configtest.t .............. ok
t/gnu_cp.t .................. ok
t/relative_delete_bugfix.t .. ok
t/rsync.t ................... ok
All tests successful.
Files=4, Tests=5,  1 wallclock secs ( 0.02 usr  0.02 sys +  0.38 cusr  0.10 csys =  0.52 CPU)
Result: PASS

rsnapshot-1.3.1 $ su -c "make install"
Password:
make[1]: entrant dans le répertoire « /usr/local/src/rsnapshot/rsnapshot-1.3.1 »
test -z "/usr/local/bin" || mkdir -p -- "/usr/local/bin"
/usr/bin/install -c 'rsnapshot' '/usr/local/bin/rsnapshot'
/usr/bin/install -c 'rsnapshot-diff' '/usr/local/bin/rsnapshot-diff'
test -z "/usr/local/etc" || mkdir -p -- "/usr/local/etc"
/usr/bin/install -c -m 644 'rsnapshot.conf.default' '/usr/local/etc/rsnapshot.conf.default'
test -z "/usr/local/man/man1" || mkdir -p -- "/usr/local/man/man1"
/usr/bin/install -c -m 644 './rsnapshot.1' '/usr/local/man/man1/rsnapshot.1'
/usr/bin/install -c -m 644 './rsnapshot-diff.1' '/usr/local/man/man1/rsnapshot-diff.1'
make[1]: quittant le répertoire « /usr/local/src/rsnapshot/rsnapshot-1.3.1

Configuration

Au niveau configuration, 2 fichiers ont été crées, qui ne sont, somme toute, pas si différent l'un de l'autre :

$ diff /etc/rsnapshot.conf /etc/rsnapshot.conf.default
27c27
< #snapshot_root        /home/.snapshots/
---
> snapshot_root /.snapshots/
57c57
< cmd_ssh       /usr/bin/ssh
---
> #cmd_ssh      /usr/bin/ssh
167c167
< link_dest     1
---
> #link_dest    0

Nous allons nous baser sur le .conf et voir un peu de quoi il en retourne.

$ cat /etc/rsnapshot.conf
Password:
#################################################
# rsnapshot.conf - rsnapshot configuration file #
#################################################
# PLEASE BE AWARE OF THE FOLLOWING RULES:
# This file requires tabs between elements
# Directories require a trailing slash:
#   right: /home/                               #
#   wrong: /home                                #
#################################################

#######################
# CONFIG FILE VERSION #
#######################

config_version  1.2

###########################
# SNAPSHOT ROOT DIRECTORY #
###########################

# All snapshots will be stored under this root directory.
#
#snapshot_root  /home/.snapshots/

# If no_create_root is enabled, rsnapshot will not automatically create the
# snapshot_root directory. This is particularly useful if you are backing
# up to removable media, such as a FireWire or USB drive.
#
#no_create_root 1

#################################
# EXTERNAL PROGRAM DEPENDENCIES #
#################################

# LINUX USERS:   Be sure to uncomment "cmd_cp". This gives you extra features.
# EVERYONE ELSE: Leave "cmd_cp" commented out for compatibility.
#
# See the README file or the man page for more details.
#
cmd_cp          /bin/cp

# uncomment this to use the rm program instead of the built-in perl routine.
#
cmd_rm          /bin/rm

# rsync must be enabled for anything to work. This is the only command that
# must be enabled.
#
cmd_rsync       /usr/bin/rsync

# Uncomment this to enable remote ssh backups over rsync.
#
cmd_ssh /usr/bin/ssh

# Comment this out to disable syslog support.
#
cmd_logger      /bin/logger

# Uncomment this to specify the path to "du" for disk usage checks.
# If you have an older version of "du", you may also want to check the
# "du_args" parameter below.
#
cmd_du          /usr/bin/du

# Uncomment this to specify the path to rsnapshot-diff.
#
cmd_rsnapshot_diff      /usr/bin/rsnapshot-diff

# Specify the path to a script (and any optional arguments) to run right
# before rsnapshot syncs files
#
#cmd_preexec    /path/to/preexec/script

# Specify the path to a script (and any optional arguments) to run right
# after rsnapshot syncs files
#
#cmd_postexec   /path/to/postexec/script

#########################################
#           BACKUP INTERVALS            #
# Must be unique and in ascending order #
# i.e. hourly, daily, weekly, etc.      #
#########################################

interval        hourly  6
interval        daily   7
interval        weekly  4
#interval       monthly 3

############################################
#              GLOBAL OPTIONS              #
# All are optional, with sensible defaults #
############################################

# Verbose level, 1 through 5.
# 1     Quiet           Print fatal errors only
# 2     Default         Print errors and warnings only
# 3     Verbose         Show equivalent shell commands being executed
# 4     Extra Verbose   Show extra verbose information
# 5     Debug mode      Everything
#
verbose         2

# Same as "verbose" above, but controls the amount of data sent to the
# logfile, if one is being used. The default is 3.
#
loglevel        3

# If you enable this, data will be written to the file you specify. The
# amount of data written is controlled by the "loglevel" parameter.
#
logfile /var/log/rsnapshot

# If enabled, rsnapshot will write a lockfile to prevent two instances
# from running simultaneously (and messing up the snapshot_root).
# If you enable this, make sure the lockfile directory is not world
# writable. Otherwise anyone can prevent the program from running.
#
lockfile        /var/run/rsnapshot.pid

# Default rsync args. All rsync commands have at least these options set.
#
#rsync_short_args       -a
#rsync_long_args        --delete --numeric-ids --relative --delete-excluded

# ssh has no args passed by default, but you can specify some here.
#
#ssh_args       -p 22

# Default arguments for the "du" program (for disk space reporting).
# The GNU version of "du" is preferred. See the man page for more details.
# If your version of "du" doesn't support the -h flag, try -k flag instead.
#
#du_args        -csh

# If this is enabled, rsync won't span filesystem partitions within a
# backup point. This essentially passes the -x option to rsync.
# The default is 0 (off).
#
#one_fs         0

# The include and exclude parameters, if enabled, simply get passed directly
# to rsync. If you have multiple include/exclude patterns, put each one on a
# separate line. Please look up the --include and --exclude options in the
# rsync man page for more details on how to specify file name patterns.
#
#include        ???
#include        ???
#exclude        ???
#exclude        ???

# The include_file and exclude_file parameters, if enabled, simply get
# passed directly to rsync. Please look up the --include-from and
# --exclude-from options in the rsync man page for more details.
#
#include_file   /path/to/include/file
#exclude_file   /path/to/exclude/file

# If your version of rsync supports --link-dest, consider enable this.
# This is the best way to support special files (FIFOs, etc) cross-platform.
# The default is 0 (off).
#
link_dest       1

# When sync_first is enabled, it changes the default behaviour of rsnapshot.
# Normally, when rsnapshot is called with its lowest interval
# (i.e.: "rsnapshot hourly"), it will sync files AND rotate the lowest
# intervals. With sync_first enabled, "rsnapshot sync" handles the file sync,
# and all interval calls simply rotate files. See the man page for more
# details. The default is 0 (off).
#
#sync_first     0

# If enabled, rsnapshot will move the oldest directory for each interval
# to [interval_name].delete, then it will remove the lockfile and delete
# that directory just before it exits. The default is 0 (off).
#
#use_lazy_deletes       0

# Number of rsync re-tries. If you experience any network problems or
# network card issues that tend to cause ssh to crap-out with
# "Corrupted MAC on input" errors, for example, set this to a non-zero
# value to have the rsync operation re-tried
#
#rsync_numtries 0

###############################
### BACKUP POINTS / SCRIPTS ###
###############################

# LOCALHOST
backup  /home/          localhost/
backup  /etc/           localhost/
backup  /usr/   localhost/
#backup /var/log/rsnapshot              localhost/
#backup /etc/passwd     localhost/
#backup /home/foo/My Documents/         localhost/
#backup /foo/bar/       localhost/      one_fs=1, rsync_short_args=-urltvpog
#backup_script  /usr/bin/backup_pgsql.sh        localhost/postgres/

# EXAMPLE.COM
#backup_script  /bin/date "+ backup of example.com started at %c"       unused1
#backup root@example.com:/home/ example.com/    +rsync_long_args=--bwlimit=16,exclude=core
#backup root@example.com:/etc/  example.com/    exclude=mtab,exclude=core
#backup_script  ssh root@example.com "mysqldump -A > /var/db/dump/mysql.sql"    unused2
#backup root@example.com:/var/db/dump/  example.com/
#backup_script  /bin/date       "+ backup of example.com ended at %c"   unused9

# CVS.SOURCEFORGE.NET
#backup_script  /usr/bin/backup_rsnapshot_cvsroot.sh    rsnapshot.cvs.sourceforge.net/

# RSYNC.SAMBA.ORG
#backup rsync://rsync.samba.org/rsyncftp/       rsync.samba.org/rsyncftp/

Telle quelle, la configuration créée n'est pas utilisable, et le test de celle-ci ne tarde pas à sortir en erreur :

rsnapshot-1.3.1 $ rsnapshot configtest
1823: priorité précédente 0, nouvelle priorité 19
----------------------------------------------------------------------------
rsnapshot encountered an error! The program was invoked with these options:
/usr/bin/rsnapshot configtest
----------------------------------------------------------------------------
ERROR: /etc/rsnapshot.conf on line 196:
ERROR: backup /home/ localhost/ - snapshot_root needs to be \
defined before backup points
ERROR: /etc/rsnapshot.conf on line 197:
ERROR: backup /etc/ localhost/ - snapshot_root needs to be defined before \
backup points
ERROR: /etc/rsnapshot.conf on line 198:
ERROR: backup /usr/ localhost/ - snapshot_root needs to be defined before \
backup points
ERROR: ---------------------------------------------------------------------
ERROR: Errors were found in /etc/rsnapshot.conf,
ERROR: rsnapshot can not continue. If you think an entry looks right, make
ERROR: sure you don't have spaces where only tabs should be.

En fait, au lieu d'une erreur, il s'agit surtout de la non prise en compte des défauts, notamment, comme c'est explicitement dit, le snapshot_root. Pour le coup, il faut donc décommenter le paramètre et, tant qu'à faire, le customiser. La partie en question est située au tout début du fichier de conf.

# All snapshots will be stored under this root directory.
#
snapshot_root  /home/.snapshots/

Même chose pour vos backups, car sauvegarder /etc et /usr n'est parfois pas essentiel / suffisant. On travaillera donc sur la partie qui parle de :

backup  /home/          localhost/
backup  /etc/           localhost/
backup  /usr/   localhost/

Pour test, j'ai commenté le backup de /etc et /usr. Vérifions notre configuration à nouveau :

$ rsnapshot configtest
1880: priorité précédente 0, nouvelle priorité 19
Syntax OK

Un test rapide (-t) renverra les lignes de commandes qui seront exécutées si on relance sans l'option -t, option qui représente une sorte de dry run.

$ rsnapshot -t hourly
1936: priorité précédente 0, nouvelle priorité 19
echo 1936 > /var/run/rsnapshot.pid
mkdir -m 0700 -p /home/.snapshots/
mkdir -m 0755 -p /home/.snapshots/hourly.0/
/usr/bin/rsync -a --delete --numeric-ids --relative --delete-excluded \
/home/k-tux /home/.snapshots/hourly.0/localhost/
mkdir -m 0755 -p /home/.snapshots/hourly.0/
/usr/bin/rsync -a --delete --numeric-ids --relative --delete-excluded /etc \
/home/.snapshots/hourly.0/localhost/
mkdir -m 0755 -p /home/.snapshots/hourly.0/
/usr/bin/rsync -a --delete --numeric-ids --relative --delete-excluded /usr \
/home/.snapshots/hourly.0/localhost/
touch /home/.snapshots/hourly.0/

Sauvegarde

Puisqu'après tout il ne faut jamais craindre la sauvegarde, qu'à cela ne tienne, lançons le comme dans la vraie vie :

$ rsnapshot hourly
2187: priorité précédente 0, nouvelle priorité 19

Et vérifions ce qui a été crée :

$ ll /home/.snapshots/hourly.0/localhost/home/
total 12
4 drwxr-xr-x  3 root      root   4096 2011-08-21 20:03 .
4 drwxr-xr-x  3 root      root   4096 2011-08-22 11:09 ..
4 drwxr-xr-x 83 k-tux k-tux 4096 2011-08-22 10:31 k-tux

Ce qui est bien, c'est qu'on n'a pas vraiment besoin de tout faire soi-même. Par exemple, Rsnapshot dispose d'une option bien nommée "du" qui renvoie la taille des données sauvegardées.

$ rsnapshot du
2540: priorité précédente 0, nouvelle priorité 19
720M    /home/.snapshots/hourly.0/
720M    total

La relance du hourly crée un autre répertoire :

$ rsnapshot hourly
3019: priorité précédente 0, nouvelle priorité 19

$ ll /home/.snapshots/hourly*
hourly.0/ hourly.1/

En réalité, ici, hourly.0 est toujours l'image la plus récente. En pratique, rsnapshot crée le répertoire et copie l'image précédente dedans avant d'effectuer la sauvegarde des données dans hourly.0, comme nous l'a précédemment indiqué le dry-run :

$ rsnapshot -t hourly
4732: priorité précédente 0, nouvelle priorité 19
echo 4732 > /var/run/rsnapshot.pid
mv /home/.snapshots/hourly.1/ /home/.snapshots/hourly.2/
mv /home/.snapshots/hourly.0/ /home/.snapshots/hourly.1/
/usr/bin/rsync -a --delete --numeric-ids --relative --delete-excluded \
--link-dest=/home/.snapshots/hourly.1/localhost/ /home/ \
/home/.snapshots/hourly.0/localhost/
touch /home/.snapshots/hourly.0/

Il s'agit donc bien de rotation des sauvegardes. A l'image de rsnapshot du, il existe également une version du diff, par contre, pas très pratique, il faut mentionner les répertoires en eux-mêmes. La version de base n'est pas très exploitable...

$ rsnapshot-diff /home/.snapshots/hourly.0 /home/.snapshots/hourly.1
Comparing /home/.snapshots/hourly.1 to /home/.snapshots/hourly.0
Between /home/.snapshots/hourly.1 and /home/.snapshots/hourly.0:
17 were added, taking 1006442932 bytes;
17 were removed, saving 446593057 bytes;

Oui, mais !!! En réalité, rsnapshot permet d'être plus précis (-v) ou encore plus précis que précis (-V). Et là, effectivement, c'est tout de suite mieux :)

$ rsnapshot-diff -v /home/.snapshots/hourly.0 /home/.snapshots/hourly.1
Comparing /home/.snapshots/hourly.1 to /home/.snapshots/hourly.0
+ /home/.snapshots/hourly.0/localhost/home/k-tux/.viminfo
+ /home/.snapshots/hourly.0/localhost/home/k-tux/.recently-used.xbel
+ /home/.snapshots/hourly.0/localhost/home/k-tux/.xsession-errors
- /home/.snapshots/hourly.1/localhost/home/k-tux/.viminfo
- /home/.snapshots/hourly.1/localhost/home/k-tux/.recently-used.xbel
[...]
Between /home/.snapshots/hourly.1 and /home/.snapshots/hourly.0:
17 were added, taking 1006442932 bytes;
17 were removed, saving 446593057 bytes;

Voilà, il ne reste plus qu'à se concocter son cron, qui ressemblera à un truc du genre : 0 */4 * * * /usr/local/bin/rsnapshot hourly Il est important de noter que si un fichier ne change pas d'une version à l'autre, il ne sera pas dupliqué mais sera dans les faits un hard link sur la donnée. Ce n'est que lorsque la donnée est modifiée que le lien est supprimé et la donnée mise à jour et sauvegardée. Du coup, il n'y a pas de consommation inutile de place.

Hourly, Daily, Weekly

C'est bien joli tout ça, mais lorsque l'on met notre hourly, de quoi il en retourne ? En fait, rsnapshot propose 3 modes de sauvegarde : hourly, daily et weekly. Ces noms sont assez évocateurs, mais le fonctionnement de rsnapshot mérite d'être explicité. Pour expliquer le fonctionnement, il faut expliquer le paramètre interval qui est mentionné dans la configuration.

interval        hourly  6
interval        daily   7
interval        weekly  4

Par exemple, prenons la première ligne mentionnant hourly : l'intervalle définit hourly tel que 6 sauvegardes par jour sont faites. Ce qui signifie que faire tourner 7 fois hourly revient à prendre 6 snapshots hourly et de passer le 7ème, le plus récent en daily. Il est important -et souligné- que les paramétrages d'interval doivent être mentionnés du plus petit au plus grand dans le fichier de conf. Cela vient du fait que c'ets la première occurrence d'interval qui va récupérer les données du filesystem, tandis que les autres utiliseront celles de la première occurrence.

Restauration

Les restaurations ne sont pas plus compliquées qu'un rsync : il suffit de récupérer la dernière des sauvegardes effectuées -ou du moins celle qui correspond au besoin-, et d'en récupérer les données, de façon classique. Étrangement, et cela contraste par ailleurs avec la version du et diff, rsnapshot ne fournit pas d'option pour faire la restauration en elle-même. Mais qu'importe, puisque vous pouvez :)

Conclusion

Un petit outil somme toute bien pratique qu'est rsnapshot : gain de place, de lisibilité, conf aux petits oignons... Il ne vous reste plus qu'à l'utiliser en fait :) Enjoy !

Bcfg2 : la gestion de conf du bout des doigts

KXan — Thu, 21 Jul 2011 13:49:18 +0000

Il n'y a pas si longtemps que ça, je vous avais parlé d'un gestionnaire de conf, Puppet, qui s'appuyait sur son propre langage descriptif et jouait avec du Ruby. Après quelques essais ma foi assez pertinents, je me suis aperçue que Puppet était somme toute un peu lent : pour 3 packages (certes, il y avait du java dans le tas) et 2 conf, plus de 20 minutes étaient nécessaires pour mettre à niveau les nodes. Un autre fâcheux défaut est que, par défaut, il agrège toutes les instructions dans un même espace, sans tenir compte de la séquence selon laquelle ils sont définis. Pour le coup, les résultats sont pour le moins inattendus, surtout si on est dans un cas de figure où l'on doit passer une instruction (exemple : définition des dépôts officiels) avant une autre (installation de package). Au final, l'organisation des manifests finit, par défaut en un gigantesque mashup d'instructions. Pas trop sympa quand, naif, on n'y a pas pensé et passé des heures à tout bien organiser. Le seul moyen d'échapper à ce mécanisme est de passer par de lourdes définitions de dépendances. Il était temps de faire jouer AlternativeTo... Et de tomber sur bcfg2, un gestionnaire de conf s'appuyant sur du python ! Retour sur une conf aux petits oignons !

Principes de fonctionnement

Dans l'absolu, le fonctionnement de bcfg2 est assez similaire à celui de Puppet : on a un agent qui interroge le serveur, et exécute -ou pas- les modifications. Après, étant un peu flemmarde et n'étant pas trop pour la copie illégitime de contenu, je vous renvoie sur le fonctionnement détaillé au poil du projet !

Un peu de technique

Installation

Comme d'habitude, on partira des sources : fraîches, dispo, et surtout dernière version :)

$ cd /usr/local/src
$ wget ftp://ftp.mcs.anl.gov/pub/bcfg/bcfg2-1.1.2.tar.gz
$ tar zxvf bcfg2-1.1.2.tar.gz
$ python setup.py build
$ python setup.py install

$ bcfg2-admin init
Store bcfg2 configuration in [/etc/bcfg2.conf]:
Location of bcfg2 repository [/var/lib/bcfg2]:
Input password used for communication verification (without echoing; leave blank for a random):
What is the server's hostname [bcfg2-server]:
Input the server location [https://bcfg2-server:6789]:
Input base Operating System for clients:
1: Redhat/Fedora/RHEL/RHAS/Centos
2: SUSE/SLES
3: Mandrake
4: Debian
5: Ubuntu
6: Gentoo
7: FreeBSD
: 5
Generating a 2048 bit RSA private key
.......+++
........+++
writing new private key to '/etc/bcfg2.key'
-----
Signature ok
subject=/C=US/ST=Illinois/L=Argonne/CN=bcfg2-server.k-tux.com
Getting Private key
Repository created successfuly in /var/lib/bcfg2

Bon, certificat un peu faussé parce que K-Tux, dans l'Illinois, c'est un peu tiré par les cheveux, mais bon, en s'en contentera :)

Configuration du service

La configuration du serveur en lui-même (je veux dire par là, le paramétrage du service, hein, pas celui concernant les nodes qui vont le solliciter) se situe tout simplement sous /etc et se compose de 3 éléments : la conf, la clé et le certificat en lui-même.

bcfg2-server $ ls /etc/bc*
bcfg2.conf  bcfg2.crt   bcfg2.key

Un petit start du service pour se rendre compte du truc :

bcfg2-server $ bcfg2-server start
Handled 14 events in 0.017s
service available at https://bcfg2-server.k-tux.com:6789
serving bcfg2-server at https://bcfg2-server.k-tux.com:6789
serve_forever() [start]

...Qui reste en foreground, mais c'est pas plus mal pour voir ce qui se passe ! La première conf est celle du Hello World : tester le service en local. Notre serveur sera donc, pour cette fois-ci du moins, également notre node. On lance donc la partie cliente, avec les options qui vont bien : -q (query) -v (verbose) -n (dry-run mode)

bcfg2-server $ bcfg2 -q -v -n
Loaded tool drivers:
Action     Chkconfig  POSIX      RPMng

Phase: initial
Correct entries:        0
Incorrect entries:      0
Total managed entries:  0
Unmanaged entries:      2754

Phase: final
Correct entries:        0
Incorrect entries:      0
Total managed entries:  0
Unmanaged entries:      2754

C'est un peu violent de se prendre 2754 Unmanaged entries dans la tronche, mais pas d'erreur, le serveur nous renvoie tout simplement un :

Generated config for bcfg2-server.k-tux.com in 0.001s
Client bcfg2-server.k-tux.com reported state clean

En clair, il nous reste 2754 packages à configurer.

Configuration du client en local

Il faut savoir, et c'est intéressant car c'est là que vous allez bosser, que la configuration des paramétrages pour les nodes tapant sur votre bcfg2-server se situe par défaut sous /var/lib/bcfg2. Là-dedans, vous avez tout une arborescence qui a été mise en place lors de l'installation :

bcfg2-server $ ls -lsaR  /var/lib/bcfg2
/var/lib/bcfg2:
total 40
4 drwxr-xr-x 10 root root 4096 2011-07-06 16:14 .
4 drwxr-xr-x 48 root root 4096 2011-07-06 16:14 ..
4 drwxr-xr-x  2 root root 4096 2011-07-06 16:14 Base
4 drwxr-xr-x  2 root root 4096 2011-07-06 16:14 Bundler
4 drwxr-xr-x  2 root root 4096 2011-07-06 16:14 Cfg
4 drwxr-xr-x  2 root root 4096 2011-07-06 16:14 etc
4 drwxr-xr-x  2 root root 4096 2011-07-06 16:14 Metadata
4 drwxr-xr-x  2 root root 4096 2011-07-06 16:14 Pkgmgr
4 drwxr-xr-x  2 root root 4096 2011-07-06 16:14 Rules
4 drwxr-xr-x  2 root root 4096 2011-07-06 16:14 SSHbase

/var/lib/bcfg2/Base:
total 8
4 drwxr-xr-x  2 root root 4096 2011-07-06 16:14 .
4 drwxr-xr-x 10 root root 4096 2011-07-06 16:14 ..

/var/lib/bcfg2/Bundler:
total 8
4 drwxr-xr-x  2 root root 4096 2011-07-06 16:14 .
4 drwxr-xr-x 10 root root 4096 2011-07-06 16:14 ..

/var/lib/bcfg2/Cfg:
total 8
4 drwxr-xr-x  2 root root 4096 2011-07-06 16:14 .
4 drwxr-xr-x 10 root root 4096 2011-07-06 16:14 ..

/var/lib/bcfg2/etc:
total 8
4 drwxr-xr-x  2 root root 4096 2011-07-06 16:14 .
4 drwxr-xr-x 10 root root 4096 2011-07-06 16:14 ..

/var/lib/bcfg2/Metadata:
total 16
4 drwxr-xr-x  2 root root 4096 2011-07-06 16:14 .
4 drwxr-xr-x 10 root root 4096 2011-07-06 16:14 ..
4 -rw-r--r--  1 root root  111 2011-07-06 16:14 clients.xml
4 -rw-r--r--  1 root root  354 2011-07-06 16:14 groups.xml

/var/lib/bcfg2/Pkgmgr:
total 8
4 drwxr-xr-x  2 root root 4096 2011-07-06 16:14 .
4 drwxr-xr-x 10 root root 4096 2011-07-06 16:14 ..

/var/lib/bcfg2/Rules:
total 8
4 drwxr-xr-x  2 root root 4096 2011-07-06 16:14 .
4 drwxr-xr-x 10 root root 4096 2011-07-06 16:14 ..

/var/lib/bcfg2/SSHbase:
total 8
4 drwxr-xr-x  2 root root 4096 2011-07-06 16:14 .
4 drwxr-xr-x 10 root root 4096 2011-07-06 16:14 ..

Et par défaut, et bien vous avez vraiment peu de choses :) En fait, seuls /var/lib/bcfg2/Metadata/clients.xml et groups.xml sont définis. Soit dit en passant, ce sont ces fichiers qui vont permettre d'associer un profil à un node, le profil pouvant ensuite se moduler à l'infini, par le biais de Bundle et d'autres subtilités. Jetons-y un oeil, pour le coup :

bcfg2-server $ cat /var/lib/bcfg2/Metadata/clients.xml

Ici, notre client (qui est aussi le serveur) est associé au profil par défaut; "basic". pinguable et pingtime parlent d'eux même. Pour ce qui est de groups.xml, c'est la même trame : une série de sont définis, par défaut vides et fonction de la distribution du client.

bcfg2-server $ cat /var/lib/bcfg2/Metadata/groups.xml

A noter que 2 types de groupes existent : les publics, qui sont en fait les entrées par lesquelles les clients accèdent à leur catalogue, et les autres, qui ne sont pas directement visibles par les clients mais servent à mieux organiser les catégories.

Jouer avec les conf

Le premier jeu va consister à mettre à jour une conf sur un client.Les conf, les fichiers texte e, général sont toujours stockés dans /var/lib/bcfg2/Cfg. Pour jouer donc, tapons et modifions d'abord nos jolis xml :

bcfg2-server:/var/lib/bcfg2 $ cat Metadata/groups.xml










/var/lib/bcfg2 $ cat Bundler/release.xml

Bien sûr, il faut tout de même mettre la conf dans un endroit précis, distinct du système (que se passerait-il si ce ne sont pas les mêmes OS ?). Pour cela, il suffit de créer un dir portant le path et le nom de la conf sous /var/lib/bcfg2/Cfg/. Par exemple, ici, on va :

bcfg2-server $ mkdir -p /var/lib/bcfg2/Cfg/etc/ubuntu-release/
bcfg2-server $ cp /etc/ubuntu-release /var/lib/bcfg2/Cfg/etc/ubuntu-release/

Enfantin, n'est-ce pas ? Le plus embêtant, c'est que j'ai dû redémarrer le service pour qu'il prenne en compte les changements.

bcfg2-server $ bcfg2-server start
service available at https://bcfg2.k-tux.com:6789
serving bcfg2-server at https://bcfg2.k-tux.com:6789
serve_forever() [start]
Handled 30 events in 0.020s

Lançons le client,qui dispose de son ubuntu-release correctement paramétré :

bcfg2-server $ bcfg2 -q -v -n
Loaded tool drivers:
Action     Chkconfig  POSIX      RPMng

Phase: initial
Correct entries:        1
Incorrect entries:      0
Total managed entries:  1
Unmanaged entries:      2754

Phase: final
Correct entries:        1
Incorrect entries:      0
Total managed entries:  1
Unmanaged entries:      2754

Et cette fois, qui a volontairement le ubuntu-release tronqué :

bcfg2-server $ bcfg2 -q -v -n
Loaded tool drivers:
Action     Chkconfig  POSIX      RPMng

Phase: initial
Correct entries:        0
Incorrect entries:      1
Total managed entries:  1
Unmanaged entries:      2759

Le dry-run mode ne faisant rien de spécial sur le système, il se contente de nous broncher une Incorrect entry. Virons le dry-run et voyons si la conf redescend bien comme il faut !

bcfg2-server $ bcfg2 -q -v
Loaded tool drivers:
Action     Chkconfig  POSIX      RPMng

Phase: initial
Correct entries:        0
Incorrect entries:      1
Total managed entries:  1
Unmanaged entries:      2759

Installing ConfigFile /etc/ubuntu-release
The Following Bundles have been modified:
release

Phase: final
Correct entries:        1
Incorrect entries:      0
Total managed entries:  1
Unmanaged entries:      2759

Clair, net, concis : notre conf est bien redescendue ! C'est bien joli tout ça, mais tant qu'à y être, autant voir les choses en grand :) Passons donc en multi clients !

Client - Serveur distincts

Notre client, lui, n'est plus sous ubuntu comme le serveur mais sur une autre machine , en Debian 6.0.1. En réalité, que se passe-t-il qui est différent de notre mode client=serveur ? Et bien, rien de spécial, si ce n'est qu'on a rajouté une entrée dans le clients.xml.

bcfg2-server $ /var/lib/bcfg2 $ cat Metadata/clients.xml

Notre groups.xml est aussi enrichi, puisque l'OS est différent et qu'il existe pile poil la bonne catégorie pour ce type de machine : bcfg2-server Au niveau du client, c'est un peu plus palpable :

bcfg2cli-deb $ apt-get update && apt-get upgrade
bcfg2cli-deb $ apt-get install bcfg2
Creating config file /etc/bcfg2.conf with new version

Forcément, la conf par défaut n'est pas valide, puisque pour fonctionner doit d'ailleurs directement taper sur le serveur (logique). Avant, on avait donc ça :

bcfg2cli-deb $ cat /etc/bcfg2.conf
[communication]
protocol = xmlrpc/ssl
password = foobat
# certificate = /etc/bcfg2.key
# key = /etc/bcfg2.key

[components]
bcfg2 = https://localhost:6789

Et après modification du general password et du serveur sur lequel taper :

bcfg2cli-deb $ cat /etc/bcfg2.conf
[communication]
protocol = xmlrpc/ssl
password = sF9Xlpuv
# certificate = /etc/bcfg2.key
# key = /etc/bcfg2.key

[components]
bcfg2 = https://bcfg2-server.k-tux.com:6789

On lance le client :

bcfg2cli-deb $ bcfg2 -qvn
No ca is specified. Cannot authenticate the server with SSL.
No ca is specified. Cannot authenticate the server with SSL.
Loaded tool drivers:
APT      Action   DebInit  POSIX

Phase: initial
Correct entries:        0
Incorrect entries:      0
Total managed entries:  0
Unmanaged entries:      365

Phase: final
Correct entries:        0
Incorrect entries:      0
Total managed entries:  0
Unmanaged entries:      365

No ca is specified. Cannot authenticate the server with SSL.

Au niveau du serveur, il existe des outils permettant de bien visualiser ce que l'on a, sans forcément rentrer dans le xml. Un peu comme... bcfg2-info :

bcfg2-server $ bcfg2-info "clients"
Handled 31 events in 0.012s
cli Client          | Profile
============================
bcfg2cli-deb   | deb
bcfg2-server  | basic

Installer des packages via bcfg2

Forcément, la conf ne fait pas tout, et on aimerait -moi en tout cas- pouvoir monter un noeud qui aurait été victime d'une installation très basique pour en faire un noeud fonctionnel, prêt à brasser du code. Contrairement à son petit nom qui sonne un peu restrictif somme toute, bcfg2 peut, comme Puppet, prendre en charge cette opération, aussi facilement que pour la partie configuration. Attaquons de suite par un exemple on ne peut plus simple ! Je rappelle que le noeud en question rentre dans le profil deb qui fait appel au group debian. Pour pouvoir accéder à la fonctionnalité installation / gestion des packages, il faut retoucher la conf de bcfg2 et rajouter le plugin Packages au bon endroit. Votre conf deviendra donc :

bcfg2-server $ cat /etc/bcfg2.conf

[server]
repository = /var/lib/bcfg2
plugins = Base,Bundler,Cfg,Metadata,Pkgmgr,Packages,Rules,SSHbase

[statistics]
sendmailpath = /usr/lib/sendmail
database_engine = sqlite3
# 'postgresql', 'mysql', 'mysql_old', 'sqlite3' or 'ado_mssql'.
database_name =
# Or path to database file if using sqlite3.
#/etc/brpt.sqlite is default path if left empty
database_user =
# Not used with sqlite3.
database_password =
# Not used with sqlite3.
database_host =
# Not used with sqlite3.
database_port =
# Set to empty string for default. Not used with sqlite3.
web_debug = True

[communication]
protocol = xmlrpc/ssl
password = sF9Xlpuv
certificate = /etc/bcfg2.crt
key = /etc/bcfg2.key
ca = /etc/bcfg2.crt

[components]
bcfg2 = https://bcfg2-server.k-tux.com:6789

Il faut également créer le répertoire et la configuration qu'il contiendra et qui permettra d'indiquer les dépôts sur lesquels chercher les packages. Dans ma config.xml, comme c'est une Debian Squeeze à qui je m'adresse, les dépôts sont spécifiques. Donc à modifier pour aligner sur vos noeuds.

bcfg2-server:/var/lib/bcfg2 $ mkdir /var/lib/bcfg2/Packages
bcfg2-server:/var/lib/bcfg2 $ vim Packages/config.xml



debian-squeeze
http://ftp.de.debian.org/debian/
squeeze
main
multiverse
restricted
universe
amd64

A présent, il faut indiquer quels packages, et pour qui.

bcfg2-server $ cat /var/lib/bcfg2/Metadata/groups.xml

Voila pour qui. Maintenant, le quoi en question. Pour les packages, on utilise ce que bcfg2 appelle des Bundles, qui permettent de grouper plusieurs définitions pour actions. Le tout étant, bien entendu, stocké à sa place dans /var/lib/bcfg2/Bundler/. Nous avons indiqué un Bundle nommé python, nous allons le mettre en forme :

bcfg2-server $ cat /var/lib/bcfg2/Bundler/python.xml

Le restart du service n'est pas très rassurant :

bcfg2-server:/var/lib/bcfg2 $ bcfg2-server start
Failed to read file /var/lib/bcfg2/Packages/cache/http:@@ftp.de.debian.org@debian@dists@squeeze@multiverse@binary-amd64@Packages.gz
Packages: File read failed; falling back to file download
Packages: Updating http://ftp.de.debian.org/debian/dists/squeeze/main/binary-amd64/Packages.gz
Packages: Updating http://ftp.de.debian.org/debian/dists/squeeze/multiverse/binary-amd64/Packages.gz
Packages: Failed to fetch url http://ftp.de.debian.org/debian/dists/squeeze/multiverse/binary-amd64/Packages.gz. code=404
Packages: Updating http://ftp.de.debian.org/debian/dists/squeeze/restricted/binary-amd64/Packages.gz
Packages: Failed to fetch url http://ftp.de.debian.org/debian/dists/squeeze/restricted/binary-amd64/Packages.gz. code=404
Packages: Updating http://ftp.de.debian.org/debian/dists/squeeze/universe/binary-amd64/Packages.gz
Packages: Failed to fetch url http://ftp.de.debian.org/debian/dists/squeeze/universe/binary-amd64/Packages.gz. code=404
Failed to read file /var/lib/bcfg2/Packages/cache/http:@@ftp.de.debian.org@debian@dists@squeeze@multiverse@binary-amd64@Packages.gz
Failed to update source
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/Bcfg2/Server/Plugins/Packages.py", line 120, in setup_data
self.read_files()
File "/usr/lib/python2.6/site-packages/Bcfg2/Server/Plugins/Packages.py", line 406, in read_files
raise
File "/usr/lib/python2.6/site-packages/Bcfg2/Server/Plugins/Packages.py", line 403, in read_files
reader = gzip.GzipFile(fname)
File "/usr/lib/python2.6/gzip.py", line 79, in __init__
fileobj = self.myfileobj = __builtin__.open(filename, mode or 'rb')
IOError: [Errno 2] No such file or directory: '/var/lib/bcfg2/Packages/cache/http:@@ftp.de.debian.org@debian@dists@squeeze@multiverse@binary-amd64@Packages.gz'
The following plugins conflict with Packages;Unloading ['Pkgmgr']
Loading experimental plugin(s): Packages
NOTE: Interfaces subject to change
Handled 32 events in 0.012s
service available at https://bcfg2-server.k-tux.com:6789
serving bcfg2-server at https://bcfg2-server.k-tux.com:6789
serve_forever() [start]

Par contre, le service est opérationel ! Le client en dry-run, nous renvoie :

bcfg2cli-deb $ bcfg2 -qvn
No ca is specified. Cannot authenticate the server with SSL.
No ca is specified. Cannot authenticate the server with SSL.
Loaded tool drivers:
APT      Action   DebInit  POSIX
Package python-openssl not installed
Package python-pytools not installed
Package python-setuptools not installed

Phase: initial
Correct entries:        0
Incorrect entries:      3
Total managed entries:  3
Unmanaged entries:      364

In dryrun mode: suppressing entry installation for:
Package:python-openssl     Package:python-pytools     Package:python-setuptools

Phase: final
Correct entries:        0
Incorrect entries:      3
Package:python-openssl     Package:python-pytools     Package:python-setuptools
Total managed entries:  3
Unmanaged entries:      364

No ca is specified. Cannot authenticate the server with SSL.

Et en mode non dry-run, on a effectivement les installations qui se déroulent comme prévu :

bcfg2cli-deb $ bcfg2 -qv
No ca is specified. Cannot authenticate the server with SSL.
No ca is specified. Cannot authenticate the server with SSL.
Loaded tool drivers:
APT      Action   DebInit  POSIX
Package python-openssl not installed
Package python-pytools not installed
Package python-setuptools not installed

Phase: initial
Correct entries:        0
Incorrect entries:      3
Total managed entries:  3
Unmanaged entries:      364

The Following Bundles have been modified:
python

Phase: final
Correct entries:        3
Incorrect entries:      0
Total managed entries:  3
Unmanaged entries:      364

No ca is specified. Cannot authenticate the server with SSL.

bcfg2cli-deb $ dpkg -s python-openssl
Package: python-openssl
Status: install ok installed [...]

Et voilà ! Il ne reste plus qu'à gérer les 364 entrées restantes, plus celles que vous allez rajouter pour enrichir vos nodes :) Pour ma part, je dois encore paufiner la conf sur la partie authentification par certificat SSL et tant qu'à faire résoudre le pourquoi-qu'il-me-crache-des-erreurs-python-au-start. Mais tout ceci est une autre histoire ! Ah ! Et à toujours garder en tête : garder la conf par défaut est trèèèèèèèèèèèès dangereux (je pense au port 6789 en question) !!! Enjoy !!!

Ubuntu Server 11.04 i686 sur plus de 8 CPU

KXan — Fri, 08 Jul 2011 09:02:32 +0000

Récemment, j'ai pu tester l'installation d'un Ubuntu Server 11.04 i686 sur un serveur contenant 2 CPU Intel® Xeon® Processor X5650, ce qui fait pas moins de 24 CPUs visibles sous nunux. La demande était expresse : OS 32 bits imposé, donc aucune discussion possible. Et là surprise : à la fin de l'install, on ne voit plus que 8 CPU. Alors forcément, on se pose des questions... Enfin, on pose des questions à dmesg, qui nous renvoie un joli : WARNING: NR_CPUS limit of 8 reached. Pour cela, il existe une solution : recompiler le noyau avec les bonnes options :) Pas de panique ni de make menuconfig, sous Ubuntu, la procédure est standardisée. Au cas où le lien n'est plus valide :

sudo apt-get install fakeroot build-essential crash kexec-tools makedumpfile kernel-wedge
sudo apt-get build-dep linux
sudo apt-get install git-core libncurses5 libncurses5-dev libelf-dev asciidoc binutils-dev

fakeroot debian/rules clean
sudo apt-get build-dep --no-install-recommends linux-image-$(uname -r)
apt-get source linux-image-$(uname -r)

A partir de là, il suffit juste d'éditer linux-2.6.38/debian.master/config/i386/config.flavour.generic-pae (enfin pour moi, à modifier pour votre cas de figure), et de stipuler en plus 2 options :

CONFIG_NR_CPUS=32
CONFIG_X86_BIGSMP=y

Pourquoi 32 ? D'une, il s'agit en fait d'une limite, donc pas besoin de mettre 24 dans la mesure où Ubuntu va lui-même détecter le bon nombre de CPU présent. Et de deux, pour l'avoir testé avec 24, j'ai pu constater qu'en fait, il pouvait voir 32 slots possibles -sûrement la capacité d'accueil de la carte mère-, donc au cas où je décide de rajouter des processeurs (on ne sait jamais), autant la fixer au max :) Ne pas oublier le chmod des scripts :

chmod -R u+x debian/scripts/*

Update de la config :

debian/rules updateconfigs

On recompile en adoptant l'option skipabi (car pour moi ça partait en erreur):

DEB_BUILD_OPTIONS=parallel=2 AUTOBUILD=1 NOEXTRAS=1 skipabi=true fakeroot debian/rules binary-generic-pae

Si vous tombez sur une question vous demandant de choisir entre Sparse et Discontinious Memory et que vous ne savez absolument pas de quoi il en retourne, mieux vaut choisir la Discontinuous Memory, car la Sparse est à titre expérimentale. Toute l'information est ici. Et c'est parti pour la génération des .deb ! Il ne restera plus qu'à dpkg -i les .deb, rebooter et vous avez un serveur prêt, frais et dispo !!