K-Tux

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 !!

Linux : Mise en place de quota

KXan — Fri, 17 Jun 2011 11:24:52 +0000

Aujourd'hui, petit tip sur comment mettre en place des quotas sur un système Linux. Pour cela, il faut avoir quelques concepts de base que je vais définir vite fait, puis on passera à la pratique.

Les concepts en question

Limites

Hard limit

Une hard limit correspond à la limite maximale de blocs (disque ou d'inodes) étant autorisée et pouvant être utilisée même de manière temporaire par un utilisateur (ou par un groupe). Lorsqu'elle est atteinte, il est impossible d'allouer plus à l'utilisateur.

Soft Limit

Une soft limit correspond au nombre maximal de blocs de disque (ou d'inodes) pouvant être utilisé de manière temporaire par un utilisateur (ou par un groupe). Elle se situe logiquement au-dessous de la hard limit. Ainsi, ça permet aux utilisateurs d'y accéder temporairement (voir grace period) et de pouvoirêtre en mesure de finir toute tâche commencée ou de cleaner les données non utiles / non nécessaires afin de redescendre en-dessous de la soft limit.

Grace Period

Toute utilisation de disque au-dessus de la soft limit est par définition temporaire. C'est la grace period qui détermine la durée pendant laquelle un utilisateur (ou un groupe) peut pousser son utilisation au-delà de la soft tout en restant en dessous de la hard. Sous Linux, les quotas sont mis en place :

pour une parttion / un filesystem

pour un groupe ou pour un utilisateur.

Install et jeu

Pour l'installation, étant donné que les quotas sont intégrés sous Linux depuis belle lurette, il vous suffira d'utiliser votre package installer préféré et d'installer quota et quotatool. Je travaille sur une partition de sda, /dev/sda3 qui est montée sous /data. On commence par vérifier qu'il n'y a aucun quota de défini sur notre partition.

$ quotacheck -vgum /data/
quotacheck: Mountpoint (or device) /data not found or has no quota enabled.
quotacheck: Cannot find filesystem to check or filesystem not mounted with quota option.

Il faut ensuite éditer le fichier /etc/fstab pour ajouter usrquota,grpquota après les options standard de montage (default pour moi) :

LABEL=DATA             /data                   ext3    defaults,usrquota,grpquota        1 2

Remonter la partition, bien entendu, afin que les options soient prises en compte :

$ mount -o remount /data
$ mount /data
/dev/sda3 on /data type ext3 (rw,acl,usrquota,grpquota)

Et maintenant démarrer les quotas :

$ quotaon -v /data

En sachant que pour les stopper, ce n'est pas plus difficile :

$ quotaoff -v /data

Petit check sur /data, histoire de voir si des quotas sont déjà en jeu...

$ quotacheck -vgum /data/
quotacheck: Parcours de /dev/sda3 [/data] terminé
quotacheck: Vérifié 20164 répertoires et 142505 fichiers

Gestion des quotas

La gestion des quotas est on ne peut plus intuitive :

$ edquota k-tux

Quotas disque pour user k-tux (uid 11039) :
Système de fichiers           blocs       souple     stricte   inodes    souple   stricte
/dev/sda3                        32       6000       8000          8        0        0

On peut également faire jouer la grace period. Pour cela un petit :

# edquota -u -f /data -t

Sursis avant l'application des limites souples pour users :
Unités de temps peuvent être : days (jours), hours (heures), minutes, ou seconds
Système de fichiers  période de sursis bloc  période de sursis inode
/dev/sda3                     7days                  7days

Et enfin, résultat de notre boulot, affichons nos quotas:

$ repquota /data/
*** Rapport pour les quotas user sur le périphérique /dev/sda3
Période de sursis bloc : 7days ; période de sursis inode : 7days
Limites bloc               Limites fichier
Utilisateur     utilisé souple stricte sursis utilisé souple stricte sursis
----------------------------------------------------------------------
root      -- 8782860       0       0          81579     0     0
k-tux       --      32    6000    8000              8     0     0

Pour ceux que les unités dérangent, il suffit de demander bien poliment à repquota :

$ repquota -si /data/
*** Rapport pour les quotas user sur le périphérique /dev/sda3
Période de sursis bloc : 7days ; période de sursis inode : 7days
Limites bloc               Limites fichier
Utilisateur     utilisé souple stricte sursis utilisé souple stricte sursis
----------------------------------------------------------------------
root      --   8578M       0       0          81579     0     0
k-tux       --      32    6000    8000              8     0     0

Conclusion

En moins de temps qu'il n'en faut pour printer "Hello world", vous voilà avec une partition sous quota ! Enjoy !

Back To Basis : Torque & MAUI

KXan — Mon, 06 Jun 2011 11:44:36 +0000

Rapide tip pour sauver ce qui me reste de mémoire avec la mise en place et l'exploitation d'un cluster de calcul via Torque et MAUI.

Fonctionnement

Un cluster de calcul est composé de noeuds de calcul, plus ou moins riches en ressources, et à plus ou moins charger. Typiquement, ici, j'ai un cluster composé de 2 ensembles :

les noeuds de calcul 24/24 7/7
les noeuds de calcul cumulant 2 rôles et qui sont principalement des postes de travail

Pour info, je ne détaille pas l'installation ni du cluster en lui-même (réplication d'un noeud sur tous les autres, voir le tip sur SystemImager) ni celle des installations de Torque ni MAUI, qui sont triviales. Je n'attaquerais que la partie configuration. Le fonctionnement d'un cluster de calcul sous Torque / MAUI est le suivant. Les utilisateurs soumettent des travaux (on appellera ça des batchs) au master. Ce master a pour tâche d'enregistrer ces travaux dans une queue et de les soumettre à n noeuds en fonctions des ressources disponibles et demandées par le travail en question. Pour cela, il existe sur chacun des noeuds de calcul un daemon, pbs_mom, qui est chargé de la communication entre le master et le noeud. Pourquoi pbs_mom ? Et bien parce qu'avant de s'appeler Torque, l'outil portait le doux nom de PBS. Le master quant à lui fait tourner principalement 2 daemons : MAUI, l'ordonnanceur, et pbs_server, qui est notre serveur TORQUE. De plus, il gère toute une collection (enfin ça dépend de vous) de queue avec -de préférence- des priorités et des contraintes différentes.

Ces contraintes sont notamment liées au temps d'exécution qui est borné, et selon votre bon plaisir, le mien en tout cas, à un maximum de soumission et de jobs en cours d'exécution.

Comment faire ? Il suffit de continuer à lire :)

Configuration

Maui

En réalité, MAUI n'a pas besoin, sauf cas particulier -du genre allouer telle ressources entre telle heure et telle heure à tel utilisateur- de configuration spécifique. Tout ce qu'il y a à savoir se trouve sous /var/spool/maui/maui.cfg, je vous ai même rajouté ce cas particulier dont je vous parlais :

$ cat /var/spool/maui/maui.cfg | grep -v "#"

SERVERHOST            master
ADMIN1                root

RMCFG[base] TYPE=PBS
AMCFG[bank]  TYPE=NONE

RMPOLLINTERVAL        00:00:30
SERVERPORT            50001
SERVERMODE            NORMAL

LOGDIR                /var/log/maui
LOGFILE               maui.log
LOGFILEMAXSIZE        1000000000
LOGLEVEL              3

QUEUETIMEWEIGHT       1

BACKFILLPOLICY        FIRSTFIT
RESERVATIONPOLICY     CURRENTHIGHEST
NODEALLOCATIONPOLICY  LASTAVAILABLE

SRCFG[prioritaire]          PERIOD=DAY
SRCFG[prioritaire]          STARTTIME=3:00:00
SRCFG[prioritaire]          ENDTIME=11:45:00
SRCFG[prioritaire]          HOSTLIST=ktux-w1,ktux-w2
SRCFG[prioritaire]          USERLIST=kuser

Torque

Par défaut, l'installation de Torque / PBS vous a crée un petit fichier de conf, destiné à paramétrer notamment le démarrage des services. Il nous indique également où est le home de Torque, c'est-à-dire où il range ses petites affaires. Ici, c'est sous /var/spool/pbs.

$ cat /etc/pbs.conf
#!/bin/sh
# init of some var needed bi pbs service
# config: /etc/pbs.conf

pbs_home=/var/spool/pbs
pbs_exec=/usr
# set 1 to start the service
start_server=1
start_sched=0
start_mom=0

/var/spool/pbs

Ce répertoire contient notamment les logs, mais aussi les données relatives aux queues et aux jobs

$ ll /var/spool/pbs/
total 112
drwxr-xr-x  2 root root  4096 2011-06-06 02:40 aux/
drwx------  2 root root  4096 2011-06-06 02:40 checkpoint/
drwxr-xr-x  2 root root  4096 2011-06-06 00:00 mom_logs/
drwxr-xr-x  3 root root  4096 2011-06-06 09:20 mom_priv/
-rw-r--r--  1 root root 56261 2011-06-06 12:46 nodes
-rwxr-xr-x  1 root root  2317 2011-06-06 02:41 pbs_config.sample*
-rw-r--r--  1 root root    26 2011-06-06 02:40 pbs_environment
drwxr-xr-x  2 root root  4096 2011-06-06 09:40 sched_logs/
drwxr-xr-x  3 root root  4096 2011-06-06 10:33 sched_priv/
drwxr-xr-x  2 root root  4096 2011-06-06 00:00 server_logs/
-rwxr-xr-x  1 root root    13 2011-06-06 16:39 server_name*
drwxr-xr-x 12 root root  4096 2011-06-06 15:10 server_priv/
drwxrwxrwt  2 root pbs   4096 2011-06-06 12:30 spool/
drwxrwxrwt  2 root pbs   4096 2011-06-06 02:40 undelivered/

Principalement, ce qui nous intéressera sera situé sous server_priv :

$ ll /var/spool/pbs/server_priv/
total 328
drwxr-xr-x 2 root root  12288 2011-06-06 05:00 accounting/
drwxr-xr-x 2 root root   4096 2011-06-06 02:40 acl_groups/
drwxr-xr-x 2 root root   4096 2011-06-06 02:40 acl_hosts/
drwxr-xr-x 2 root root   4096 2011-06-06 10:40 acl_svr/
drwxr-xr-x 2 root root   4096 2011-06-06 10:23 acl_users/
drwxr-xr-x 2 root root   4096 2011-06-06 02:40 arrays/
drwxr-xr-x 2 root root   4096 2011-06-06 02:40 disallowed_types/
drwxr-xr-x 2 root root   4096 2011-06-06 02:40 hostlist/
drwxr-xr-x 2 root root 274432 2011-06-06 10:52 jobs/
-rw-r--r-- 1 root root   1058 2011-06-06 15:10 nodes
drwxr-xr-x 2 root root   4096 2011-06-06 06:55 queues/
-rw------- 1 root root   1351 2011-06-06 10:52 serverdb
-rw------- 1 root root      5 2011-06-06 09:41 server.lock
-rw------- 1 root root      0 2011-06-06 16:47 tracking
$ ll /var/spool/pbs/server_priv/queues/
total 36
-rw------- 1 root root 1319 2011-06-06 13:58 longday
-rw------- 1 root root 1321 2011-06-06 06:55 longnight
-rw------- 1 root root 1320 2011-06-06 13:58 shortday
-rw------- 1 root root 1321 2011-06-06 06:55 shortnight

$ file /var/spool/pbs/server_priv/queues/shortday
/var/spool/pbs/server_priv/queues/shortday: data

Et sous server_logs :

$ ll /var/spool/pbs/server_logs/ | head
-rw-r--r-- 1 root root 315447768 2011-06-06 00:00 20110606

Tout ça pour dire que c'est facile de retrouver une information.

Queues

Je vous parlais plus haut de queue. Une queue est exactement ce à quoi son nom fait penser : c'est une file type FIFO qui contient les travaux en attente. L'utilitaire par définition qui va s'occuper de créer et moduler nos queues comme bon nous semble répond au doux nom de qmgr. Ce qui est bien avec lui, c'est qu'il permet, juste en lançant une petite requête, de nous dumper l'essentiel des commandes nécessaires à créer et paramétrer les queues que nous nous sommes donné tant de mal à créer. Ca me permet de faire 2 manips en une : une, vous montrer comment interroger Torque, et deux, vous montrer comment créer une queue :)

$ qmgr -c "print queue @master"
#
# Create queues and set their attributes.
#
#
# Create and define queue longday
#
create queue longday
set queue longday queue_type = Execution
set queue longday Priority = 4
set queue longday max_user_queuable = 30
set queue longday from_route_only = False
set queue longday resources_default.neednodes = day
set queue longday resources_default.nodect = 1
set queue longday resources_default.nodes = 1:day
set queue longday resources_default.walltime = 100:00:00
set queue longday max_user_run = 6
set queue longday enabled = True
set queue longday started = True
#
# Create and define queue shortday
#
create queue shortday
set queue shortday queue_type = Execution
set queue shortday Priority = 2
set queue shortday max_user_queuable = 200
set queue shortday from_route_only = False
set queue shortday resources_max.walltime = 03:00:00
set queue shortday resources_default.neednodes = day
set queue shortday resources_default.nodect = 1
set queue shortday resources_default.nodes = 1:day
set queue shortday resources_default.walltime = 03:00:00
set queue shortday max_user_run = 12
set queue shortday enabled = True
set queue shortday started = True

#
# Create and define queue shortnight
#
create queue shortnight
set queue shortnight queue_type = Execution
set queue shortnight Priority = 2
set queue shortnight max_user_queuable = 400
set queue shortnight from_route_only = False
set queue shortnight resources_max.walltime = 04:00:00
set queue shortnight resources_default.neednodes = night
set queue shortnight resources_default.nodect = 1
set queue shortnight resources_default.nodes = 1:night
set queue shortnight resources_default.walltime = 04:00:00
set queue shortnight max_user_run = 70
set queue shortnight enabled = True
set queue shortnight started = False

#
# Create and define queue longnight
#
create queue longnight
set queue longnight queue_type = Execution
set queue longnight Priority = 4
set queue longnight max_user_queuable = 180
set queue longnight from_route_only = False
set queue longnight resources_default.neednodes = night
set queue longnight resources_default.nodect = 1
set queue longnight resources_default.nodes = 1:night
set queue longnight resources_default.walltime = 100:00:00
set queue longnight max_user_run = 30
set queue longnight enabled = True
set queue longnight started = False

Comme vous pouvez le voir, les priorités entre queues sont tranchées au couteau : les queues de priorité moindre seront plus prioritaire que celles ayant une valeur plus grandes. Pour modifier un de ces paramètres, il suffit de les modifier avec par exemple un :

$ qmgr -c "set queue longnight max_user_run = 20"

Noeuds de calcul

Pour rajouter des noeuds de calcul, il faut être un peu plus sournois : il faut jouer avec les propriétés du noeud. Même principe, je print, mais pour le créer, soit on passe par un qmgr -c, soit qmgr tout court, qui nous renvoie un prompt :

$ qmgr -c "print node ktux-1"

#
# Create and define node ktux-1
#
create node ktux-1
set node ktux-1 np = 2
set node ktux-1 properties = night
set node ktux-1 ntype = cluster

Ici, je dis que mon noeud ktux-1 a 2 CPUs, de type cluster et doit faire jouer uniquement les travaux en mode night. Pour un noeud de calcul 24/24, 7/7, ça donnera plus du genre : Via qmgr -c :

$ qmgr -c 'create node ktux-w1 np=4,ntype=cluster'
$ qmgr -c 'set node ktux-w1 properties=day'

Ce qui nous donne :

$ qmgr -c "print node ktux-w1"
#
# Create nodes and set their properties.
#
#
# Create and define node ktux-w1
#
create node ktux-w1
set node ktux-w1 state = free
set node ktux-w1 np = 4
set node ktux-w1 properties = day
set node ktux-w1 ntype = cluster

Au fur et à mesure que les noeuds communiqueront avec le master, tout un tas d'autres infos vont être remontées, comme l'état actuel, les jobs en cours sur ce noeud, ...

$ qmgr -c "print node ktux-w1"
#
# Create nodes and set their properties.
#
#
# Create and define node ktux-w1
#
create node ktux-w1
set node ktux-w1 state = busy
set node ktux-w1 np = 4
set node ktux-w1 properties = day
set node ktux-w1 ntype = cluster
set node ktux-w1 status = opsys=linux
set node ktux-w1 status += uname=Linux ktux-w1 2.6.31.14-server-1mnb
set node ktux-w1 status += sessions=23566 23591 23629 23680
set node ktux-w1 status += nsessions=4
set node ktux-w1status += nusers=1
set node ktux-w1 status += idletime=8968185
set node ktux-w1 status += totmem=9009420kb
set node ktux-w1 status += availmem=8458932kb
set node ktux-w1 status += physmem=8143220kb
set node ktux-w1 status += ncpus=4
set node ktux-w1 status += loadave=1.36
set node ktux-w1 status += netload=2067207052
set node ktux-w1 status += state=free
set node ktux-w1 status += jobs=65605 65606 65607 65608
set node ktux-w1 status += varattr=
set node ktux-w1 status += rectime=1307353529

En réalité, le lien entre properties et queue est fait via l'instruction resources_default.neednodes :

set queue longnight resources_default.neednodes = night

et qmgr mentionne explicitement, pour chaque noeud, à quelle queue il se rattache. Le tout est sous /var/spool/pbs/server_priv/nodes :

$ cat /var/spool/pbs/server_priv/nodes

ktux-1 np=2 night
ktux-2 np=2 night
ktux-3 np=2 night
ktux-w1 np=4 day
ktux-w2 np=4 day

Sans ces instructions, on aurait une erreur du genre :

$ qmgr -c "print node ktux-2"
qmgr obj=ktux-2 svr=default: Unknown node  MSG=cannot located specified node

Évidemment, toute modification doit être ponctuée par un restart de pbs_server pour être effective.

Job

Toute soumission de travail passe par un qsub et doit mentionner le job à faire, la queue sur laquelle on désire travailler et optionnellement si l'on souhaite être averti en allocation des ressources, run et fin du travail. En retour, on obtient un identifiant de travail.

$ qsub -q shortday -o /home/kuser/date.res -e /home/kuser/date.err -m  abe -N  date -M ktux@ktux.com  /home/kuser/date.sh

Ici, -q attend une queue spécifique, -o précède l'emplacement de l'output désiré, -e celui de l'erreur renvoyée si il y a, -m abe désigne l'instruction de mailing en cas de a(borted) b(egin) e(nd). -N donne un nom au travail, -M précise le mail en question et en dernier, le script à exécuter. A noter qu'ici, le /home de kuser est un partage NFS, qui fonctionnera quelque soit le noeud de calcul choisi. Autrement, il aurait fallu désigner un espace accessible avec les droits de kuser par le noeud de calcul en question. Sur le master, on peut alors suivre le job et son évolution :

$ qstat -u kuser

master :
Req'd  Req'd   Elap
Job ID               Username Queue    Jobname          SessID NDS   TSK Memory Time  S Time
-------------------- -------- -------- ---------------- ------ ----- --- ------ ----- - -----
656969            kuser           shortday date                --      1  --    --  00:45 Q   --

Q : le job est enqueue. R : running. Sur le client aussi, et ce en étant loggé en tant que kuser :

$ qstat
Job id                    Name             User            Time Use S Queue
------------------------- ---------------- --------------- -------- - -----
656969              date                 kuser              0 Q shortday

Un affichage plus complet passe par un qstat -f, d'où on extrait facilement l'exec host, c'est à dire l'hôte qui a pris en charge le calcul dès que celui-ci passe en mode Running. Cet exec host peut être composé de plusieurs noeuds de calcul, en fonction des ressources nécessaires au run du travail. Lorsque l'on souhaite investiguer sur un batch qui ne s'est pas passé comme on l'attendait, deux options s'offrent à nous pour mettre le doigt sur les noeuds ayant participé à sa résolution :

une analyse classique de log
tracejob

L'analyse classique de log va vous amener à grepper votre jobID sur les logs de /var/spool/pbs/server_logs/ et à remonter jusqu'à l'attribution d'un noeud au batch. C'est sympa, mais manuellement, et sur beaucoup de batch, ça devient un peu long. Tracejob permet de parser justement un ensemble de logs et de vous retourner automatiquement tout ce qui a, de près ou de loin, participé à votre batch. La petite faiblesse étant que, par défaut, il ne prend que les logs du jour même. Tracejob est à lancer sur le master, qui sait et qui voit tout. En gros, pour aujourd'hui le lundi 06 Juin, il va chercher : /var/spool/pbs/server_priv/accounting/20110606 /var/spool/pbs/server_logs/20110606 /var/spool/pbs/mom_logs/20110606 /var/spool/pbs/sched_logs/20110606 Ca nous donne ça :

$ tracejob 656969
/var/spool/pbs/mom_logs/20110606: No matching job records located
/var/spool/pbs/sched_logs/20110606: No such file or directory

Job: 656969

06/06/2011 12:29:22  S    ready to commit job
06/06/2011 12:29:22  S    ready to commit job completed
06/06/2011 12:29:22  S    committing job
06/06/2011 12:29:22  S    enqueuing into veryshortjour, state 1 hop 1
06/06/2011 12:29:22  S    Job Queued at request of kuser@ktux-1, owner = kuser@ktux-1, job name = date, queue = shortday
06/06/2011 12:29:22  A    queue=shortday
06/06/2011 12:35:25  S    attr Resource_List modified
06/06/2011 12:35:25  S    Job Modified at request of root@master

06/06/2011 12:35:25  S    Job Run at request of root@master
06/06/2011 12:35:25  S    forking in send_job                                                                                                      06/06/2011 12:35:25  S    send_job child job pid is 30568
06/06/2011 12:35:25  S    entering post_sendmom
06/06/2011 12:35:25  S    child reported success for job after 0 seconds (dest=ktux-w1), rc=0
06/06/2011 12:35:25  S    attr Resource_List modified
06/06/2011 12:35:25  S    Job Modified at request of root@master
06/06/2011 12:35:25  S    attr session_id modified
06/06/2011 12:35:25  S    sending 'b' mail for job 656969 to kuser@ktux-1 (---)
06/06/2011 12:35:25  A    user=kuser group=kuser jobname=date queue=shortday ctime=1307356162 qtime=1307356162 etime=1307356162 start=1307356525
owner=kuser@ktux-1 exec_host=ktux-w1/0 Resource_List.neednodes=ktux-w1 Resource_List.nodect=1 Resource_List.nodes=1:day
Resource_List.walltime=00:45:00
06/06/2011 12:35:29  S    obit received
06/06/2011 12:35:29  S    obit received - updating final job usage info
06/06/2011 12:35:29  S    attr resources_used modified
06/06/2011 12:35:29  S    job exit status 0 handled
06/06/2011 12:35:29  S    sending 'e' mail for job 656969 to kuser@ktux-1 (Exit_status=0
06/06/2011 12:35:29  S    Exit_status=0 resources_used.cput=00:00:00 resources_used.mem=0kb resources_used.vmem=0kb resources_used.walltime=00:00:04
06/06/2011 12:35:29  S    on_job_exit task assigned to job
06/06/2011 12:35:29  S    req_jobobit completed
06/06/2011 12:35:29  S    JOB_SUBSTATE_EXITING
06/06/2011 12:35:29  S    JOB_SUBSTATE_STAGEOUT
06/06/2011 12:35:29  S    about to copy stdout/stderr/stageout files
06/06/2011 12:35:29  S    JOB_SUBSTATE_STAGEOUT
06/06/2011 12:35:29  S    JOB_SUBSTATE_STAGEDEL
06/06/2011 12:35:29  S    JOB_SUBSTATE_EXITED
06/06/2011 12:35:29  S    JOB_SUBSTATE_COMPLETE
06/06/2011 12:35:29  S    dequeuing from shortday, state COMPLETE
06/06/2011 12:35:29  S    removed job script
06/06/2011 12:35:29  S    removed job file
06/06/2011 12:35:29  S    freeing job
06/06/2011 12:35:29  A    user=kuser group=kuser jobname=date queue=shortday ctime=1307356162 qtime=1307356162 etime=1307356162 start=1307356525
owner=kuser@ktux-1 exec_host=ktux-w1/0 Resource_List.neednodes=1:day Resource_List.nodect=1 Resource_List.nodes=1:day
Resource_List.walltime=00:45:00 session=24524 end=1307356529 Exit_status=0 resources_used.cput=00:00:00 resources_used.mem=0kb
resources_used.vmem=0kb resources_used.walltime=00:00:04

Manipulations de jobs

Bien entendu, on peut manipuler comme bon nous semble les batches ! Pour cela, nous avons tout un éventail de commandes en q.

qdel : suppression du jobID
qrun : forçage du run du batch, avec options possibles, comme de le faire tourner sur tel et tel noeuds,...
qalter : modifier les attributs du job : queue, mailing, ...
qhold : mettre en suspens un job
qenable/qdisable : activer/désactiver la destination, typiquement une queue particulière
qstart/qstop : démarrer/arrêter les queues dans le sens où on peut soumettre, mais les jobs enqueued ne sont pas distribués
...

Conclusion

En fait, monter un cluster de calcul est beaucoup plus contraignant au moment de la conception matérielle (installation, câblage, mise dans un VLAN, homogénéisation des configurations) et lors de sa maintenance quotidienne que dans la configuration. D'autant plus que le couple Torque/MAUI est vraiment opérationnel ! Que dire, maintenant que d'autres moyens, plus abstraits comme le Cloud Computing existent ? Car malgré tout, un cluster de calcul, ce n'est rien que pour parser des données. A vous de voir si celles-ci méritent un peu de temps et de moyens pour garder le tout sous contrôle ou si ce besoin de sécurité n'est pas du tout pertinent...

Manipulation de paramètres de carte réseaux : mii-tool, ethtool

KXan — Mon, 30 May 2011 13:54:46 +0000

Petit tip plus pour reminder, et qui tourne autour de la problématique d'affichage et de modification des paramètres d'une carte réseau, le tout en ligne de commande (vu qu'il n'est pas forcément désirable d'avoir sur chaque type de machine, un X11 qui tourne). Il existe historiquement 2 anciens packages qui font tous les deux presque exactement la même chose : mii-tool et ethtool. Selon l'âge de la carte et la durabilité voulue des manips, il faut se tourner soit vers l'un soit vers l'autre.

Mii-Tool

Mii-Tool est un outil déprécié, qui a laissé sa place à ethtool, mais comme celui-ci date, il est facilement supporté par d'anciennes cartes :

$ mii-tool
eth0: 100 Mbit, half duplex, link ok
SIOCGMIIPHY on 'eth1' failed: Operation not supported

Attention, normalement, sur les machines jeunes, le mode est auto-négocié. Il se peut que la liaison soit coupée si l'on force dans un mode qui n'est pas compris/opérationnel sur le switch. Modification en ligne de commande du paramétrage pour eth0 pour l'exemple, en 100 base Tx, full duplex :

# mii-tool -F 100baseTx-FD eth0

Ce paramétrage ne peut pas être permanent, sauf si, brute que l'on est, on force un run de la modification dans le /etc/rc.local, en tout dernier des initiations. Plus d'info ? Rendez-vous sur le man de Mii-Tool !

Ethtool

$ ethtool
ethtool version 6
Usage:
ethtool DEVNAME Display standard information about device
ethtool -s|--change DEVNAME     Change generic options
[ speed 10|100|1000|2500|10000 ]
[ duplex half|full ]
[ port tp|aui|bnc|mii|fibre ]
[ autoneg on|off ]
[ advertise %%x ]
[ phyad %%d ]
[ xcvr internal|external ]
[ wol p|u|m|b|a|g|s|d... ]
[ sopass %%x:%%x:%%x:%%x:%%x:%%x ]
[ msglvl %%d ]
ethtool -a|--show-pause DEVNAME Show pause options
ethtool -A|--pause DEVNAME      Set pause options
[ autoneg on|off ]
[ rx on|off ]
[ tx on|off ]
ethtool -c|--show-coalesce DEVNAME      Show coalesce options
ethtool -C|--coalesce DEVNAME   Set coalesce options
[adaptive-rx on|off]
[adaptive-tx on|off]
[rx-usecs N]
[rx-frames N]
[rx-usecs-irq N]
[rx-frames-irq N]
[tx-usecs N]
[tx-frames N]
[tx-usecs-irq N]
[tx-frames-irq N]
[stats-block-usecs N]
[pkt-rate-low N]
[rx-usecs-low N]
[rx-frames-low N]
[tx-usecs-low N]
[tx-frames-low N]
[pkt-rate-high N]
[rx-usecs-high N]
[rx-frames-high N]
[tx-usecs-high N]
[tx-frames-high N]
[sample-interval N]
ethtool -g|--show-ring DEVNAME  Query RX/TX ring parameters
ethtool -G|--set-ring DEVNAME   Set RX/TX ring parameters
[ rx N ]
[ rx-mini N ]
[ rx-jumbo N ]
[ tx N ]
ethtool -k|--show-offload DEVNAME       Get protocol offload information
ethtool -K|--offload DEVNAME    Set protocol offload
[ rx on|off ]
[ tx on|off ]
[ sg on|off ]
[ tso on|off ]
[ ufo on|off ]
[ gso on|off ]
ethtool -i|--driver DEVNAME     Show driver information
ethtool -d|--register-dump DEVNAME      Do a register dump
[ raw on|off ]
[ file FILENAME ]
ethtool -e|--eeprom-dump DEVNAME        Do a EEPROM dump
[ raw on|off ]
[ offset N ]
[ length N ]
ethtool -E|--change-eeprom DEVNAME      Change bytes in device EEPROM
[ magic N ]
[ offset N ]
[ value N ]
ethtool -r|--negotiate DEVNAME  Restart N-WAY negotation
ethtool -p|--identify DEVNAME   Show visible port identification (e.g. blinking)
[ TIME-IN-SECONDS ]
ethtool -t|--test DEVNAME       Execute adapter self test
[ online | offline ]
ethtool -S|--statistics DEVNAME Show adapter statistics
ethtool -h|--help DEVNAME       Show this help

Illustration avec ma petite eth0 :

$ ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes:   10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes:  10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
Link detected: yes

La modification des paramétrages en ligne de commande se fait comme suit :

ethtool -s eth0 speed 100 duplex full autoneg off

Là, j'ai désactivé l'autonégociation et forcé en 100 full duplex. Par rapport à mii-tool, les modifications peuvent être appliquées systématiquement au démarrage de la carte réseau en modifiant notre /etc/sysconfig/network-scripts/ifcfg-eth0, grâce à la spécification d'un champ ETHTOOL_OPTS :

#
# File: /etc/sysconfig/network-scripts/ifcfg-eth0
#
DEVICE=eth0
IPADDR=192.168.12.11
NETMASK=255.255.255.0
BOOTPROTO=static
ONBOOT=yes
ETHTOOL_OPTS="speed 100 duplex full autoneg off"

Pour info, le man d'ethtool. Et voilà ! Ca de moins à faire !

Back To Basis : Bash tips

K-TUX — Fri, 06 May 2011 13:43:53 +0000

Bonjour à tous ! Un petit retour sur un outil qui sert tous les jours, j'ai nommé : Bash ! Et notamment, tout ce qui tourne autour de son historique, histoire de ne pas se répéter plein de fois :)

History et manips en ligne de commande

Qui ne connait pas la commande history ! Elle vous affiche ce que vous avez rentré en ligne de commande. Et malgré les apparences, cela permet d'appeler ces commandes sans avoir à -totalement- se les retaper (et non, je ne parle pas du click molette :). Mais vous allez voir, on peut faire beaucoup plus de choses !

Manips usuelles

!cmd : rappelle la dernière instance de cmd que vous avez appelé. Exemple : !mou me rappelera mon dernier mount. Et oui, c'est une recherche de chaine de caractère donc pas la peine de tout taper !
!2 : rappelle la seconde commande, celle inventoriée avec le numéro d'index 2 lorsque que l'on lance un history.
!-2 : avant dernière commande cette fois.
sudo !! : sudo est concaténé avec la commande précédente. Bon, ça fonctionne aussi avec d'autres instructions :)
ctrl -r : permet de rechercher un motif dans notre historique
!!:$ : désigne le dernier argument de la dernière commande. Equivalent à !$.

Manips sur l'history

history -c : clear de l'history
history -d offset : clear de l'history à partir de l'offset spécifié
history -r filename : récupère l'historique de filename et le stocke afin qu'il soit accessible en ligne de commande. Si filename n'est pas donné, c'est le contenu de la variable d'environnement HISTFILE qui est utilisé.
history -w filename : écrit l'historique actuel dans filename. Même comportement que -r si filename n'est pas mentionné.
history -s cmd : va mettre cmd enqueue dans l'history sans l'exécuter réellement,

History et config

L'historique du bash est stocké sous ~/.bash_history. D'où 2 problématiques :

la confidentialité de l'historique, puisque par défaut au moins accessible à tous les root,
la redondance inutile d'infos : par exemple on peut rentrer 20 fois la commande ls, sans pour autant que celle-ci n'ait d'intérêt à être enregistrée 20 fois telle quelle.

Pour régler ces 2 problèmes, il suffit de faire appel à la variable d'environnement HISTCONTROL qui peut exclure certaines commandes en fonction du pattern stipulé. Cette variable peut être exportée en ligne de commande, mais le mieux c'est tout de même de la définir dans le ~/.bashrc, afin qu'elle soit initialisée à chaque reconnexion :

export HISTCONTROL=ignorespace:ignoredups

ignorespace va ignorer toute commande invoquée mais derrière un espace, tandis qu'ignoredups va ignorer tout duplicata de commande déjà enregistrée. Un truc sympa aussi, c'est d'ignorer les mises en foreground/background (&:[bf]g), les ls et les exit (ls:exit) :

export HISTIGNORE="&:ls:[bf]g:exit"

Stockage des commandes multilignes sur une seule

Une autre option du Bash qui n'est pas forcément activée par défaut et cmdhist. Ça permet notamment quand elle est activée de stocker sur une ligne les commandes s'étalant sur plusieurs. Activation de l'option :

shopt -s cmdhist

Et désactivation :

shopt -u cmdhist

Vérification avant passage au bash

Encore une option qui peut potentiellement vous sauver de la catastrophe : histverify. Cela permet de ne pas passer tout de suite la commande à Bash mais de passer par un print et donc de pouvoir corriger si la commande n'est pas correcte ou pire, dangereuse :) Un rm -rf par exemple... Idem que cmdhist, pour lactiver, il faut passer par shopt.

Retouches

Il est possible de sélectionner et de retoucher un panel de commande de l'historique grâce à fc (Fix Command).

fc [-e ename] [-lnr] [first] [last] : sur un éventail de commande allant de [first] à [last], tout deux pouvant être la commande écrite ou son index de l'historique, faire un listing :
- -l : normal,
- -n : sans le numéro d'index, histoire de récupérer la suite d'instruction et de la rejouer automatiquement par exemple,
- -r : inversé par rapport à l'ordre originel d'invocation de ces commandes
- -e ename : stipule explicitement quel éditeur utiliser, vi étant le défaut.

fc -s [command] : réexecute la commande stipulée, à défaut la dernière effectuée.

Paramétrage de l'historique

Evidemment, l'historique est soumis à des contraintes de taille au niveau des commandes mais aussi au niveau du fichier contenant le tout. Et bien entendu, ceci est modifiable : Bienvenue sous Linux !

HISTSIZE : le nombre de commandes retenues, par défaut 500.
HISTFILESIZE : nombre maximum de ligne contenue dans le ~/.bash_history. Defaut : 500.
HISTCONTROL : vu précédemment, module l'enregistrement des commandes
HISTTIMEFORMAT : si définie, permet de stipuler le format du timestamp associé à chaque commande, qui sera du coup affiché lors de l'invocation d'history. Très pratique pour tracer les manips, et surtout quand elles ont été faites ! Exemple, dans le ~/.bashrc :
```
CYAN=$(echo -e '\e[0;36m')
NORMAL=$(echo -e '\e[0m')
HISTTIMEFORMAT="${CYAN}[ %d/%m/%Y %H:%M:%S ]${NORMAL}    "
```

En bref

On vient juste de brosser un premier plan de Bash et déjà on peut quasiment refaire le monde ! Car oui, si c'est l'outil qui vous permet de manipuler d'autres outils et qui date tout de même, il n'empêche qu'il est puissant et regorge de multiples fonctionnalités. En tout cas, si vous voulez aller plus loin, rien ne vaut le man ! Après, il n'y a pas que bash : zsh, ksh, csh, bref de quoi jouer ! Enjoy !