K-Tux » system

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

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 !

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 !

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

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

Back To Basis : tune2fs, réservation d’espace pour le système

K-TUX — Fri, 01 Apr 2011 13:59:51 +0000

Je me suis aperçue récemment d'une tout petite incohérence liée à l'estimation de l'espace disponible et occupé de mon disque dur.

# df -h /dev/sdb1
Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur
/dev/sdb1             459G  432G  3,8G 100% /data

Et oui : 432+3,8 = 435,8 or mon disque totalise une taille de 459G. Il faut dire que cela m'est complètement sorti de la tête, mais en fait la différence est à attribuer à la réservation d'espace pour le système. Cette réservation peut être utile par exemple lors d'une sur-utilisation mémoire, quand l'OS passe en swap. Vu qu'il s'agit d'un disque de données, donc non relié au système, ni une ni deux, je m'en vais te virer cette réservation qui est bien gourmande ! Petit aperçu de l'état du disque :

# tune2fs -l /dev/sdb1
tune2fs 1.41.9 (22-Aug-2009)
Filesystem volume name:   DATA
Last mounted on:          not available
Filesystem UUID:          9841e4fa-11cc-47a0-8e57-dd319c53ed37
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              30531584
Block count:              122096000
Reserved block count:     6104800
Free blocks:              7077533
Free inodes:              30060143
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      994
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Filesystem created:       Mon Oct  5 17:58:10 2009
Last mount time:          Wed Feb 16 10:02:40 2011
Last write time:          Wed Feb 16 10:02:40 2011
Mount count:              2
Maximum mount count:      37
Last checked:             Tue Jan  4 09:44:01 2011
Check interval:           15552000 (6 months)
Next check after:         Sun Jul  3 10:44:01 2011
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      c9cd057b-45a5-4b4b-999a-302e1fec3229
Journal backup:           inode blocks

Hop ! Mise à 0 du pourcentage disque réservé au système :

# tune2fs -m 0 /dev/sdb1
tune2fs 1.41.9 (22-Aug-2009)
Initialisation du pourcentage de blocs réservés à 0% (0 blocs)

De suite c'est beaucoup mieux :

# df -h /dev/sdb1
Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur
/dev/sdb1             459G  432G   27G  95% /data

Et pour les détails :

# tune2fs -l /dev/sdb1
tune2fs 1.41.9 (22-Aug-2009)
Filesystem volume name:   DATA
Last mounted on:          not available
Filesystem UUID:          9841e4fa-11cc-47a0-8e57-dd319c53ed37
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              30531584
Block count:              122096000
Reserved block count:     0
Free blocks:              7077533
Free inodes:              30060143
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      994
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Filesystem created:       Mon Oct  5 17:58:10 2009
Last mount time:          Wed Feb 16 10:02:40 2011
Last write time:          Wed Mar 30 10:18:28 2011
Mount count:              2
Maximum mount count:      37
Last checked:             Tue Jan  4 09:44:01 2011
Check interval:           15552000 (6 months)
Next check after:         Sun Jul  3 10:44:01 2011
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      c9cd057b-45a5-4b4b-999a-302e1fec3229
Journal backup:           inode blocks

Ca, c'est fait...

SystemImager : concepts d’une solution d’automatisation de déploiement

K-TUX — Sun, 04 Jul 2010 14:59:59 +0000

SystemImager est un projet très abouti qui permet de gérer l'installation et le déploiement de logiciel et de distribution Linux, tout en s'appuyant des outils standards comme SSH et rsync. Il se distingue très nettement des outils comme Fedora kickstart et Debian debootstrap dans la mesure où il est capable de gérer plusieurs architectures et distributions différentes. D'autre part, la finesse des petites customisations et tout ce qui pourrait sortir du standard des dépôts est directement prise en compte et appliquée, sans avoir à se confronter aux fameux scripts de post-installation. En ce sens, cela fait de lui l'outil incontournable pour une gestion de parc uniforme et automatisée. Son fonctionnement est simple : il aspire dans un premier temps tout ou partie d'un système de fichier (on peut spécifier des exclusions ou même en créer un viable, via les outils du package) qu'il stocke tel quel au sein d'un dépôt d'image. Il s'agit ensuite de rebalancer l'arborescence, soit pour une installation complète, soit pour un alignement des version. Du fait que le système de fichier soit stocké en l'état, il est alors très facile de modifier et contrôler le contenu de l'image avant déploiement. La seule contrainte concerne les clients et requiert une parfaite adéquation dans le nombre de disques durs des noeuds sous la juridiction de SystemImager. La capacité peut varier, mais attention aux disques plus petits que ceux du GoldenClient. En effet, si l'on venait à balancer une install qui ne tiendrait pas sur le disque, cela ferait désordre. Pour pouvoir entrer dans les détails, il est nécessaire de définir les notions sur lesquelles s'appuie SystemImager.

Les éléments

L'image server

SystemImager a besoin d'un maître d'orchestre, appelé le serveur d'image, afin de pouvoir centraliser toute la partie gestion des images et des noeuds. Notre serveur contiendra donc tous les packages et toute la configuration nécessaire à SystemImager. La racine de SystemImager se situe au niveau de /var/lib/systemimager, et est enrichie de plusieurs éléments :

# ll /var/lib/systemimager/
total 28
-rw-r--r--  1 root root 14361 2010-06-29 11:13 clients.xml
drwxr-xr-x  9 root root  4096 2010-06-23 10:21 images/
drwxr-xr-x 55 root root  4096 2010-06-23 10:21 overrides/
drwxr-xr-x  4 root root  4096 2010-06-23 10:21 scripts/

Les explications relatives aux différents éléments seront fournies un peu plus loin. Afin de pouvoir distribuer les images correctement -et surtout lors du boot PXE-, le server devra regrouper le duo TFTP server et DHCP server. A noter que SystemImager permet de rapidement mettre en place une configuration complète de serveur de boot grâce à l'outil si_mkbootserver, intégré au package systemimager-server. Il existe plusieurs façons d'installer via SystemImager. PXE, comme nous l'avons mentionné un peu plus haut, Bittorent, ou par multicast. Ces variations sont à l'origine de certains packages qui ont été spécialement crée sur ces spécificités. A titre d'information, les packages intéressants sont :

systemimager-server : le core du serveur SystemImager,
systemimager-common : les outils qui vont avec,
systemimager-*boot-standard : les outils relatifs à la partie boot server, * regroupe i386 et x86_64

systemimager-server-flamethrower* : pour utiliser le mode multicast
systemimager-server-bittorrent : pour utiliser le mode BitTorrent.

Il va sans dire que, si vous projetez d'installer plusieurs distributions, il faudra assurer au niveau stockage des images. Même réflexion concernant la partie réseau, surtout si l'intention de virtualiser vous taraude. Le paramétrage fin de SystemImager se fait comme d'habitude, via un fichier de configuration : /etc/systemimager.conf, ou /etc/systemimager/systemimager.conf.

Les nodes

Les nodes sont les postes clients qui vont faire l'objet d'une installation automatisée par SystemImager. Ils sont rattachés préalablement à une image bien précise, et optionnellement à un ou plusieurs overrides. Accessoirement, ils disposent d'une entrée dans le fichier /etc/dhcpd.conf du serveur afin de pouvoir obtenir une adresse et pouvoir rapatrier, via TFTP par exemple, un noyau minimal qui se chargera de l'installation. Le paramétrage des clients et leur association à une image peut passer par si_addclients (c'est d'ailleurs historique)ou par si_clusterconfig. Je ne vous éplucherais pas toutes les options qui sont disponibles, sachez que vous pouvez absolument tout faire, grouper vos clients en liste FQDN, IP, avec un domainname qui leur pend, en interactif,... Bref, man est votre meilleur ami. On retrouve les informations relatives aux nodes dans le fichier /var/lib/systemimager/clients.xml. Point important, si_clusterconfig est un outil au-dessus de la gestion de node, c'est-à-dire qu'il définit l'ensemble de votre cluster en terme de groupe, de priorité, d'image, d'override, et de node.

Le GoldenClient

Le GoldenClient est un poste de même calibre que les nodes, et qui leur servira indirectement de référence. Il doit être installé et configuré manuellement et est à l'origine de l'image référente que vous déployerez. systemimager-common et systemimager-client devront être présents sur le GoldenClient.

Les images

Les images sont des répertoires chrootables qui contiennent l'intégralité du système de fichier à déployer sur les clients. Elles sont identifiées par un nom intelligible, fourni en entrée lors de leur récupération du GoldenClient. Toutes les images sont stockées sous la racine de SystemImager, c'est-à-dire sous /var/lib/systemimager/images. Gardez sous le coude si_lsimage pour les voir, si_rmimage pour les supprimer et surtout si_getimage pour en rapatrier une (oui, aussi si_mvimage et si_cpimage mais pas besoin de vous expliquer ce que ça vaut).

Les overrides

Parce qu'on ne va pas stocker plusieurs systèmes de fichiers juste pour une différence de configuration sur une poignée de fichiers, SystemImager a défini la notion d'override. Les overrides concernent les customisations appliquées à une image en particulier, il y peut donc y avoir plusieurs overrides pour une image. De la même façon que les images ont un nom, les overrides en disposent également d'un. Les overrides contiennent une portion de l'arborescence du système de fichier, qui diffère de celle proposée par l'image, et qui viendra écraser celle issue de l'image originale après que celle-ci ait été mise en place.

ls overrides/ide/
boot/  etc/

On retrouve les overrides sous /var/lib/systemimager/overrides, et pour les pousser sur les nodes, il vous suffit d'un si_pushoverrides.

Fonctionnement

Voila commence ça se passe... Premièrement, vous avez dû monter, à la sueur de votre front, votre petit serveur DHCP/TFTP/SystemImager. Deux-trois tips sympa qui vous permettront d'avancer rapidement : - si_mkdhcpserver / si_mkdhcpstatic, qui va vous arquer sur la configuration d'un DHCP opérationnel, - si_mkbootserver, pour l'aspect PXE / TFTP, - /etc/systemimager/systemimager.conf, pour la conf. Et puis on attaque le gros œuvre !

From Scratch ! L'installation automatisée

Le plus pénible d'abord. Prenez votre GoldenClient et, gentillement, patiemment, installez-le et configurez au poil toutes les options qui vont bien. Saupoudrez de systemimager-common et de systemimager-client, vos petits outils qui vous sauveront une énorme quantité de temps. N'oubliez pas de customiser le /etc/systemimager/client.conf pour tout ce qui est port d'adressage, exclude,... si_prepareclient va vous permettre de lancer tout ce qui va bien -rsync, fichiers,... afin que votre server SystemImager puisse récupérer l'image. En clair, il déduit de la conf actuelle toutes les informations utiles, dont le partitionnement des disques.

$ si_prepareclient  --server kaster
Welcome to the SystemImager si_prepareclient command.  This command may modify
the following files to prepare your golden client for having it's image
retrieved by the imageserver.  It will also create the /etc/systemimager
directory and fill it with information about your golden client.  All modified
files will be backed up with the .before_systemimager-4.1.6 extension.

/etc/services:
This file defines the port numbers used by certain software on your system.
Entries for rsync will be added if necessary.

/tmp/filerNi0f5:
This is a temporary configuration file that rsync needs on your golden client
in order to make your filesystem available to your SystemImager server.

inetd configuration:
SystemImager needs to run rsync as a standalone daemon on your golden client
until it's image is retrieved by your SystemImager server.  If rsyncd is
configured to run as a service started by inetd, it will be temporarily
disabled, and any running rsync daemons or commands will be stopped.  Then,
an rsync daemon will be started using the temporary configuration file
mentioned above.

See "si_prepareclient --help" for command line options.

Continue? (y/[n]): y
*********************************** WARNING ***********************************
This utility starts an rsync daemon that makes all of your files accessible
by anyone who can connect to the rsync port of this machine.  This is the
case until you reboot, or kill the 'rsync --daemon' process by hand.  By
default, once you use si_getimage to retrieve this image on your imageserver,
these contents will become accessible to anyone who can connect to the rsync
port on your imageserver.  See rsyncd.conf(5) for details on restricting
access to these files on the imageserver.  See the systemimager-ssh package
for a more secure method of making images available to clients.
*********************************** WARNING ***********************************

Continue? (y/[n]): y

Signaling xinetd to restart...
...
Using "sfdisk" to gather information about disk:
/dev/sda

[...]
>>> Choosing filesystem for new initrd:  cpio
>>> Creating new initrd from staging dir:  /tmp/.systemimager.0
>> cd /tmp/.systemimager.0 && find . ! -name "*~" | cpio -H newc --create | gzip -9 > /etc/systemimager/boot/initrd.img
123093 blocks
>> ls -l /etc/systemimager/boot/initrd.img
-rw-r--r-- 1 root root 44150730 Jul  1 16:02 /etc/systemimager/boot/initrd.img

>> Evaluating initrd size to be added in the kernel boot options
>> (e.g. /etc/systemimager/pxelinux.cfg/syslinux.cfg):
>>     suggested value -> ramdisk_size=71786.5

>>> Using kernel from:          /boot/vmlinuz-2.6.31.13-server-1mnb
>> ls -l /etc/systemimager/boot/kernel
-rw-r--r-- 1 root root 2748752 Jul  1 16:02 /etc/systemimager/boot/kernel

Starting or re-starting rsync as a daemon.....
done!

This client is ready to have its image retrieved.  You must now run
the "si_getimage" command on your imageserver.

Your client has been successfully prepared.  Boot kernel (copied from
this Linux distribution) and an initrd.img (generated by the
initrd_template package) can be found in /etc/systemimager/boot.

Automatically create configuration file for systemconfigurator:
>> /etc/systemconfig/systemconfig.conf

Ici, le transport se fera par rsync, mais il est possible d'utiliser rsync over SSH, BitTorrent, multicast,... Switchez sur votre serveur SystemImager et lancez le si_getimage qui va bien, avec -golden-client et image en entrée. En optionnel, des options sur des exclusions, les assignements IP, le comportement postinstallation (reboot, beep, shutdown,...), bref, de quoi bien jouer. Une fois l'image rapatriée, et mise au frais, si_clusterconfig -e pour organiser votre cluster -tel node va avec telle image, tel overrides,... Pour la petite idée de ce à quoi ça ressemble :



kaster
absolutely_all_nodes
override_for_absolutely_all_nodes

kluster.knBSD.overBSD
1
knBSD
overBSD
knod1


kluster.kDeb.overDeb
2
kDeb
overDeb
knod2,knod3,knod4

Tous vos nodes paramétrés bien comme il faut dans votre SystemImager, il ne vous reste plus qu'à forcer leur boot réseau avec si_mkclientnetboot...

si_mkclientnetboot --client=knod2 --netboot
[netboot] using the kernel and initrd.img for architecture: i386
[netboot] using the flavor: standard

...Et de les rebooter en PXE. si_pushinstall prend alors le contrôle des choses et le server va tout simplement redescendre par SSH, brute de force, l'image sur le node.

Les synchronisations

Evidemment, je vous avais parlé de SystemImager en tant qu'outil de déploiement d'OS, oui, mais de logiciel également. En soi, le processus est le même, il s'agit d'une synchronisation -initiée par le serveur SystemImager à destination des nodes- entre l'image assignée au node et le système de fichier du node en lui-même. Ce qui diffère, ce sont les outils.

si_pushupdate

L'outil adapté à tout ce qui doit découler d'une mise à jour de l'image référente. si_pushupdate va, ici via rsync, transférer tout ce qui manque du server aux nodes. Vu que c'est du rsync, la gestion de la bande passante est optimisée -on ne redescend pas absolument toute l'image-, malgré tout, le multicast est, à mon avis, beaucoup plus adapté à ce genre de redescente, surtout si vous avez beaucoup de node à mettre à jour.

si_pushupdate --server kaster --hosts="knod2"
knod2 : ======================= WARNING =================================
knod2 :  This command will update this host with the image: kDeb
knod2 :  and overrides (in order of importance):
knod2 :
knod2 :  overDeb, override_for_absolutely_all_nodes
knod2 :
knod2 :  Some files could be deleted or overwritten, so probably it is a
knod2 :  good idea to run this command with --dry-run before and stop the
knod2 :  production on this host.
knod2 : ======================= WARNING =================================
knod2 :
knod2 : Are you sure to continue? (y / N)? y
knod2 : [...]
knod2 : Excluding (filesystem ext2): /tmp
knod2 : >> Updating image from module kDeb...
knod2 : receiving incremental file list
knod2 : deleting .readahead_collect
knod2 : sent 86986 bytes  received 23829894 bytes  621217.66 bytes/sec
knod2 : total size is 10895198915  speedup is 455.54
knod2 : >> Updating image from module overrides/override_for_absolutely_all_nodes...
knod2 : Running bootloader...Kernel /boot/...

si_pushoverrides

Comme son nom l'indique, il s'agit en réalité non pas d'aligner le node avec son image mais avec ses overrides.

si_pushoverrides -v knod2
Building clients list...
Grouping clients by common overrides...
WARNING: in case of file overlaps the overrides will be distributed using the following order (first hit wins):
WARNING: -->
Performing the updates...
>> si_pcp -v    -n knod2 /var/lib/systemimager/overrides/overDeb/ /
knod2 :/: sending incremental file list
[...]
knod2 :/: sent 898 bytes  received 203 bytes  734.00 bytes/sec
knod2 :/: total size is 2510  speedup is 2.28

Le monitoring

Monitorer un node revient, sous SystemImager, à se faire une idée d'où il en est au niveau de l'installation. Pour cela, SystemImager exploite grandement /var/lib/systemimager/clients.xml et met à disposition 2 outils, l'un étant la version graphique de l'autre, il s'agit de si_monitor et si_monitortk.

Conclusion

SystemImager apporte donc une réponse simple, complète et très satisfaisante aux besoins d'automatisation d'installation et de déploiement. De par ce fait, il est tout-à-fait dans la ligne de mire des exploitation en cluster, et se marie très bien avec des systèmes de répartition de charge dans des environnements de calcul, comme c'est le cas pour OSCAR, Torque, MAUI, et autres. Attention toutefois, car même s'il correspond également au besoin d'uniformisation dans un parc constitué de postes de travail, il peut s'avérer que la synchronisation provoque des problèmes d'incohérence et d'instabilité au niveau de l'environnement graphique ou du noyau, selon ce qui a été mis à jour. Il est donc sage de l'utiliser avec parcimonie quand vous êtes en première ligne face à vos utilisateurs. Il ne vous reste plus qu'à vous en faire une idée par vous-même, et, pourquoi pas, l'adopter !

TSM : Petite mise en bouche

K-TUX — Thu, 08 Apr 2010 11:08:11 +0000

Tivoli Storage Manager, de son petit nom TSM, compte parmi les plus puissantes architectures dédiées aux sauvegardes / stockage / restauration de données. Seulement voilà, non content d'être une technologie propriétaire, c'est en plus un gros morceau à gérer... Enfin du moins au début. Ce billet a donc pour vocation de découvrir les premiers concepts qui se cachent sous TSM et de vous lancer dans l'apprivoisement de ce géant bourru.

Fonctionnement général

TSM fonctionne sur un mode Client/Serveur, c'est-à-dire que le serveur TSM se tient à la disposition des Clients, nos nodes, afin que les sauvegardes soient faites. Selon la manière dont la sauvegarde est effectuée, les rôles varient. En effet, sur une sauvegarde faite manuellement, le node sollicite le serveur TSM et lui demande d'effectuer une tâche bien précise (sauvegarde ou restauration). Lorsque la sauvegarde est automatisée, c'est le serveur TSM qui sollicite le node -via un scheduler- et qui va lui demander les données à sauvegarder. Le node endosse ainsi la fonction de serveur (en perpétuelle écoute de requête en provenance du serveur TSM). Au sein de l'architecture TSM, un node se définit par rapport à d'autres entités, qui permettent notamment d'organiser et de paramétrer au plus fin les détails liés aux sauvegardes à faire. Logiquement, on a :

Policy
- Domain
  - CLOptSet (jeu d'options pour le domaine (INCLEXCL), optionnel)
    - Schedule (planification des sauvegarde)
      - Node (noeud à sauvegarder)

Les mains dans le cambouillis

Sur de l'opérationnel

L'appel du terminal se fait par dsmadmc, qui, par défaut, ouvre une interface de commande avec le serveur TSM. Il est également possible de stipuler la commande sur la même ligne que dsmadm. Ainsi, dsmadm exécutera la commande, fermera l'invite de commande tsm et rendra le terminal à l'utilisateur. Dans un système qui fonctionne, on peut interroger l'existant grâce à la commande QUERY -abrégée en q- QUERY sert à rapporter un état précis du système, par exemple, l'état des processes qui tournent et s'il y en a (q proc), les associations existantes (q association)...

tsm: TSMSERVER>q policy

Policy        Policy        Default       Description
Domain        Set Name      Mgmt
Name                        Class
Name
---------     ---------     ---------     ------------------------
NDMP          ACTIVE        STANDARD
[...]

tsm: TSMSERVER>q domain

Policy        Activated     Activated      Number of     Description
Domain        Policy        Default       Registered
Name          Set           Mgmt               Nodes
Class
---------     ---------     ---------     ----------     ------------------------
NIX          STANDARD      STANDARD             205     serveurs UNIX
[...]
tsm: TSMSERVER>q sched
Domain           *     Schedule Name        Action     Start Date/Time          Duration     Period     Day
--
NIX                   Schedbux             Inc Bk     27-05-2008 00:00:00          8 H        1 D      Any
[...]

Ce qui revient à dire que, lorsque l'on arrive sur un système TSM tout frais, prêt à être installé, il faut donc créer et paramétrer tout le système.

Sur du tout neuf

Et bien, allons-y, recréons tout ça ! L'invite dsmadmc lancée, vous pouvez d'ores et déjà vous essayer à créer tout ce bazard. Et si vous bloquez sur une option, il existe une commande help qui, invoquée seule, vous énumérera l'ensemble des catégories qu'elle détient, et sinon, si vous savez sur quelle commande vous bloquez, il suffit de lancer help pour avoir accès à tout le descriptif, illustré d'exemple, de ladite commande. Alors pas de panique !

Petit aperçu de comment faire...

1. Créer un domaine, avec ou non son set d'option :

define domain domainname [...]
define cloptset cloptsetname [...]
define clientopt cloptsetname inclexcl "exclude.dir /tmp*"
[...]

2. Définir une policyset :

define policyset domainname policysetname [...]

3. Définir sa mgmtclass ou utiliser celle par défaut (STANDARD)

define mgmtclass domainname policysetname classname [...]

4. Assigner la mgmtclass définie (on peut utiliser celle par défaut en mentionnant STANDARD en lieu et place de classname) :

assign defmgmtclass domainname policysetname classname [...]

5. Valider la policyset (il n'existe qu'une et une seule policyset activée à un instant donné) :

validate policyset policysetname [...]
activate policyset policysetname [...]

6. Créer un schedule et fixer le schedule et les paramètres de sauvegarde pour le node :

define sched domainname schedname nodename action=Incremental|[...voir help define sched] desc=\\\"description\\\" type=client scheds=classic startDate=11/25/2005 startTime=20:00:00 period=1 perunits=days priority=1 duration=8 durUnits=hours

7. Enregistrer le node dans le domaine, ainsi que ses paramètres de connexion au service :

register node nodename nodepasswd passexp=0 contact=contact\@bux.fr domain=domainname cloptset=optionsetname forcepwreset=no url=http://nodename:1581

8. Définir l'association entre le domain, le schedule et le node :

define association domainname schedulename nodename

9. Customiser le node :

update node nodename [...]

Et lorsqu'on veut supprimer des nodes... D'abord supprimer ses data :

delete filespace nodename *

Et enfin supprimer le node :

remove node nodename

En cas, supprimer le schedule, si on lui a attribué un schedule rien que pour lui :

delete schedule domainname schedulename

Et oui, ce n'est pas de tout repos...

La config

Les fichiers de configuration se situent généralement aux emplacements mentionnés, à savoir dans /opt/tivoli, mais il peut arriver que ce ne soit pas le cas. Si vous êtes dans ce genre de situation, un petit find vous fixera de suite sur la localisation de votre configuration.

Le client

Le client dispose de 2 fichiers relatifs à sa configuration : dsm.opt et dsm.sys, tous les 2 disponibles à l'emplacement /opt/tivoli/tsm/client/ba/bin/. dsm.opt, comme son extension laisse le supposer, précise les options utilisateur du client, tandis que dsm.sys, quant à lui, définit les options système du client. Par défaut, à l'installation, TSM met à disposition des samples permettant de comprendre et de paufiner les réglages client. Voici quelques exemples :

# cat /opt/tivoli/tsm/client/ba/bin/dsm.opt
SERVERNAME              TSMSERVER
DOMAIN                  /home
DATEFORMAT              3
ARCHSYMLINKASFILE       no

# cat /opt/tivoli/tsm/client/ba/bin/dsm.sys
SERVERNAME          TSMSERVER
NODENAME            tsmcli
COMMMETHOD          TCPIP
TCPPORT             1500
HTTPPORT            1581
TCPSERVERADDRESS    192.168.1.252
TCPNODELAY          YES
PASSWORDACCESS      GENERATE
COMMRESTARTDURATION 0
SCHEDLOGRETENTION   7 D
ERRORLOGRETENTION   7 D
SCHEDLOGNAME        /var/log/dsmsched.log
ERRORLOGNAME        /var/log/dsmerror.log
MAXCMDRETRIES       10
RETRYPERIOD         5
REVOKEREMOTEACCESS      ACCESS
SCHEDMODE           PROMPTED
MANAGEDSERVICES     schedule webclient
INCLUDE             /home/.../* DONNEES
EXCLUDE.DIR         /tmp

Il est possible d'avoir un bref aperçu de la configuration client en lançant en superutilisateur, la commande dsmc query session, qui vous rendra un output qui ressemble à peu près à ça :

# dsmc query session
IBM Tivoli Storage Manager
Interface du client de sauvegarde/archivage en ligne de commande
Version client 5, Edition 5, Niveau 2.2
Date/heure client : 2010-04-10 11:00:19
(c) Copyright by IBM Corporation and other(s) 1990, 2009. All Rights Reserved.

Nom du poste : TSMClient
Session etablie avec le serveur SERVER1 : Linux/i386
Version serveur 5, edition 5, niveau 4.1
Date/heure serveur : 2010-04-10 10:57:37    Dernier acces : 2010-04-10 10:55:55

Informations sur la connexion au serveur TSM

Nom du serveur...........................: TSMSERVER
Type de serveur..........................: Linux/i386
Proteger la conservation de l'archivage..: "Non"
Version du serveur.......................: Ver. 5, Edi. 5, Niv. 4.1
Date du dernier acces....................: 2010-04-10 10:55:55
Supprimer les fichiers sauvegardes.......: "Non"
Supprimer les fichiers archives..........: "Oui"

Nom du poste client......................: TSMClient
Nom d'utilisateur........................: root

Le server

Le serveur dispose, de la même manière, d'un dsmserver.opt, par contre, pas de dsmserv.sys, tout du moins, dans mon installation. Du coup, tout le paramétrage du serveur se concentre dans un et un seul fichier de conf, dont voici un aperçu.

# cat /opt/tivoli/tsm/server/bin/dsmserv.opt
* dsmserv.opt
COMMmethod TCPIP
COMMmethod HTTP
TCPPort 1500
TCPWindowsize 64
TCPNODELAY         YES
HTTPPort 1580
MSGINTerval 1
MAXSessions 400
LOGPoolsize 3072
TXNGroupmax 256
COMMTimeout 300
IDLETimeout 30
LANGuage en_US
DATEformat 1
TIMEformat 1
NUMberformat 1
EXPInterval  0
MIRRORREAD LOG NORMAL
MIRRORREAD DB  NORMAL
MIRRORWRITE LOG PARALLEL
MIRRORWRITE DB  SEQUENTIAL
VOLUMEHistory volhist.out
DEVCONFIG devconfig.out
MOVEBatchsize 1000
MOVESizethresh 500
USELARGEBUFFERS    YES
EVENTSERVer        YES
DISABLESCHEDS no
REQSYS Yes
ASSISTVCRRECOVERY  YES
QUERYAUTH NONE
DBPAGEShadow Yes
DBPAGESHADOWFILE dbpgshdw.bdt
DNSLOOKUP       NO
ALIASHALT bye
NOMIGRRECL
DIRECTIO YES

TXNGROUPMAX 1024
BUFPOOLSIZE 786432

IDLETIMEOUT 60
COMMTIMEOUT 300

MAXSESSIONS 400
* EOF

Votre premier choc : les commentaires sont marqués par une *. Dur. Enfin, vous êtes habitués, maintenant...

La WebI

Selon que l'on ait paramétré comme il faut son serveur TSM -flagez le paramètre COMMmethod et HTTPPort-, il est possible de faire en sorte que l'utilisateur puisse accéder facilement à ses sauvegardes TSM sans avoir à se débattre avec dsmadmc, et ceci, en passant par l'interface Web du node. Ainsi, les données engrangées par notre serveur seront disponibles simplement à l'adresse http://nodename:1581. Petit bémol, pensez que c'est une applet JAVA, par conséquent, vérifiez tout de même que vous faites bien tourner le JDK de Sun avant de vous lancer dans la grande aventure.

Conclusion

Voila ! Fin de l'introduction, qui, quoiqu'un peu massive, donne un aperçu bien ciselé de TSM. Pour les plus curieux, la documentation est très présente, et il vaut mieux, car TSM est un produit propriétaire bien coûteux, mais qui peut valoir l'investissement, s'il est couplé avec la IBM Tape Library. Ce point rajoute d'ailleurs encore aux commandes à savoir manier, car la gestion des bandes est plus rapide via un terminal type dsmadmc que via une interface web. Enfin, à ce niveau-là, nous ne sommes plus en introduction. Les aides officielles / non officielles qui aident bien :

Troubleshooting : UUID + Initrd + publication de noyau = Timeout

K-TUX — Wed, 24 Mar 2010 12:49:27 +0000

Pour certains systèmes d'installation automatisée, comme SystemImager , il est possible de mettre à jour absolument tout et n'importe quoi, simplement par rsync ou en utilisant le mode de transport multicast . Et parfois, suite à cette mise à jour, et surtout quand elle touche le contenu du /boot, on peut être amené à constater, lors du reboot, l'apparition de messages concernant des timeout sur les disques supportant le système. Petites pistes pour traquer l'origine du problème -qui n'en est pas vraiment un, vu que le timeout passé, le boot se fait normalement-.

UUID

Avant toute chose, un petit précis s'impose. Un UUID, comme Universal Unique Identifier, sert à identifier de manière formelle et catégorique un device, que ce soit un disque dur, un device USB, bref, tout ce qui touche au matériel. Il est facile de les retrouver ou de les intégrer dans la fstab et dans le menu.lst de GRUB. Beaucoup de filesystems reconnaissent ces UUIDs, y compris le NTFS de Windows. Il existe également un autre moyen d'identifier ses partitions (en plus de celui de les appeler directement par leur petit nom), le Labelling, qui consiste à attribuer un LABEL à la partition. La grande différence avec l'UUID, mise à part sa compréhension plus intuitive, est que ce Label n'est unique que localement, tandis que l'UUID est censé (je dis bien censé, puisque ce sont les mêmes algorithmes de génération qui jouent, il y a forcément des intersections) être universellement unique.

Investigation !

Initrd.img

Pour savoir ce qu'il se cache dans votre initrd.img, rien ne vaut un lsinitrd ! Un peu d'exploration, et dans les dernières lignes, par exemple, on peut trouver :

# lsinitrd /boot/initrd.img

echo waiting for device sda1 to appear (timeout 1min)
waitdev --timeout=60000000 UUID=0d4af533-85cf-4a81-a378-172ac9143140
echo waiting for device sda2 to appear (timeout 1min)
waitdev --timeout=60000000 UUID=ce132640-34f0-43bd-b256-250ef6c369f6

Et là, vous avez cerné le problème !

Dans les faits...

Donc, d'après ce que l'on a pu tirer de notre lsinitrd, on peut facilement déduire que ce qui provoque le timeout vient justement des UUIDs qui sont appelé en dur. Voyons ce que l'on a à disposition... La méthode simple :

# ll /dev/disk/by-uuid/
total 0
drwxr-xr-x 2 root root 100 2010-03-11 16:32 .
drwxr-xr-x 6 root root 120 2010-03-11 16:32 ..
lrwxrwxrwx 1 root root  10 2010-03-11 16:32 1a3808ca-c81c-416f-9109-2ebc9c635722 -> ../../sda2
lrwxrwxrwx 1 root root  10 2010-03-11 16:32 97a38b84-b2a2-4970-b593-8f561b827fda -> ../../sda1
lrwxrwxrwx 1 root root  10 2010-03-11 16:32 c999ed94-737b-4a5a-8945-519e07c27610 -> ../../sda3

La méthode spécifique :

# /sbin/blkid
/dev/sda1: LABEL="ROOT" UUID="97a38b84-b2a2-4970-b593-8f561b827fda" TYPE="ext3"
/dev/sda2: LABEL="SWAP" UUID="1a3808ca-c81c-416f-9109-2ebc9c635722" TYPE="swap"
/dev/sda3: LABEL="HOMELOCAL" UUID="c999ed94-737b-4a5a-8945-519e07c27610" TYPE="ext3"

Divergence d'UUID

Le constat est simple. L'appel du initrd se base sur son UUID, et ici, les UUIDs entre l'appelé et le réel diffèrent. Pour fixer le souci, un simple mkinitrd remet à jour ces informations. Plus de timeout au boot, malheureusement, le problème reviendra avec d'autre mises à jour du initrd. Alors, aux vues de toutes les manips à faire, Reconsidérez bien l'affaire. Après tout, quelques minutes de timeout ne font pas de mal à vos utilisateurs !

Alternatives : ménagez-vous des options !

K-TUX — Fri, 19 Mar 2010 18:00:19 +0000

Salut à tous, et en avant pour un tout petit post sur une astuce de configuration. On a tous dû endurer, un jour, un souci entre le package proposé par l'éditeur et celui fourni par défaut dans la distribution. Cruel dilemme d'en choisir un et d'effacer totalement l'autre, dépendances entremêlés, cauchemar de manipulation des liens, bref, une expérience atroce lorsqu'elle est faite à la main. Heureusement, depuis maintenant un petit moment, il existe un package qui permet de faire ça, en plus propre et en plus rapide, sans pour autant vous priver des 2 systèmes. Cet outil, c'est alternatives. Un tour sur le site officiel nous apprend tout ce qu'il faut, et la mise en place est plus que facile, puisque le package est inclu dans la majorité des distributions. Pour ce qui est de la config, rien de plus simple ! Prenons, par exemple, le cas du jdk. Nous listons la configuration actuelle avec l'option qui va bien :

/usr/sbin/alternatives --list java
/usr/lib/jvm/jre-1.6.0-sun/bin/java
/usr/lib/jvm/jre-1.6.0-openjdk/bin/java

Et puis, nous la modifions.

/usr/sbin/alternatives --config java
There are 2 programs which provide `java'.

Selection    Command
-----------------------------------------------
1        /usr/lib/jvm/jre-1.6.0-sun/bin/java
*+    2        /usr/lib/jvm/jre-1.6.0-openjdk/bin/java

Enter to keep the default[*], or type selection number: 1
Using `/usr/lib/jvm/jre-1.6.0-sun/bin/java' to provide `java'.

Choisissez, c'est réglé !

4 lignes pour RSyslog

K-TUX — Wed, 17 Mar 2010 11:48:10 +0000

Il n'y a pas si longtemps que ça, je vous parlais très vaguement de RSyslog. Intuitif, vite déployé, avantages multiples, toussa toussa... Bref, ça sentait le faux, le lu, le commercial, et malgrè tous les véritables avantages que le daemon représentait, vous ne m'avez pas crue. Ah c'est comme ça ! Voilà en concis 4 lignes qui vous feront basculer du côté obscure de la RsysForce !

RSyslog en UDP sur le port 514

Une fois rsyslog installé, et donc syslog viré automatiquement, vous pouvez aller taper directement sur /etc/rsyslog.d/. Un truc bien pratique existe par défaut sur votre /etc/rsyslog.d/, un fichier de type 00-common. Il contient déjà les quelques informations utiles pour pouvoir monter un trafic Rsyslog, alors pourquoi s'en priver ? Copiez, renommez, et roule ! D'ailleurs, ce qui est bien avec RSyslog, c'est justement qu'il va parser tout ce qu'il trouvera dans son /etc/rsyslog.d/.

La partie Serveur

#### GLOBAL DIRECTIVES ####
# Use default timestamp format
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

# File syncing capability is disabled by default. This feature is usually not required,
# not useful and an extreme performance hit
#$ActionFileEnableSync on

# An "In-Memory Queue" is created for remote logging.
$WorkDirectory /var/spool/rsyslog       # where to place spool files
$ActionQueueFileName queue              # unique name prefix for spool files
$ActionQueueMaxDiskSpace 1g     # 1gb space limit (use as much as possible)
$ActionQueueSaveOnShutdown on   # save messages to disk on shutdown
$ActionQueueType LinkedList     # run asynchronously
$ActionResumeRetryCount -1      # infinety retries if host is down

#### MODULES ####

$ModLoad imuxsock.so    # provides support for local system logging (e.g. via logger command)
$ModLoad imklog.so      # provides kernel logging support (previously done by rklogd)
#$ModLoad immark.so     # provides --MARK-- message capability

# Provides UDP syslog reception
$ModLoad imudp.so             # Nos fameuses sockets UDP
$UDPServerRun 514              # Le truc qui dit que c'est en UDP sur le port 514

# EOF /etc/rsyslog/server.conf

Redémarrez rsyslogd, qui doit alors abreuver votre /var/log/syslog de message. Et oui, la nature est bien faite, rsyslog est compliant syslog. Il ne détruit pas, il réutilise ! D'ailleurs, si ce mode rétrocompatible est bien pratique en phase de transition, il convient quand même de rebasculer pour profiter à fond des fonctionnalités de RSyslog. Cette bascule dépend en réalité de la présence d'un fichier de conf de syslog dans /etc/. Petit mv et on n'en parle plus. Enfin, pour savoir, en mode lancement manuel, c'est l'option -c4 qui passera en full rsyslogd et non plus en syslog compliant.

La partie Client

Même scénario, mais sur le client, qui a auparavant installé rsyslog. Tentez le vim /etc/rsyslog.d/client.conf

#### GLOBAL DIRECTIVES ####
# Use default timestamp format
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

# File syncing capability is disabled by default. This feature is usually not required,
# not useful and an extreme performance hit
#$ActionFileEnableSync on

# An "In-Memory Queue" is created for remote logging.
$WorkDirectory /var/spool/rsyslog       # where to place spool files
$ActionQueueFileName rsyslogclient    # unique name prefix for spool files
$ActionQueueMaxDiskSpace 1g     # 1gb space limit (use as much as possible)
$ActionQueueSaveOnShutdown on   # save messages to disk on shutdown
$ActionQueueType LinkedList     # run asynchronously
$ActionResumeRetryCount -1      # infinety retries if host is down

#### MODULES ####

$ModLoad imuxsock.so    # provides support for local system logging (e.g. via logger command)
$ModLoad imklog.so      # provides kernel logging support (previously done by rklogd)
#$ModLoad immark.so     # provides --MARK-- message capability

# Provides UDP syslog reception
# UDP sockets
$ModLoad imudp.so
$UDPServerRun 514

*.*     @Rsyslogserver:514

# EOF /etc/rsyslog/client.conf

Petite astuce très simple, pour tester l'ouverture du port, il suffit de lancer un NetCat sur le port concerné, en mode UDP.

echo "bux" | ncat -u Rsyslogserver 514

Une entrée "bux" en provenance du client doit apparaitre dans le log du Server

RSyslog en TCP sur le port 514

Oui mais UDP, son mode non connecté, insecure,... Et si on essayait en TCP ? Bon, notez au passage tout ce que cela peut comporter comme trafic, contrôle des pertes, retransmissions, acquittements...

La partie Serveur

On réitère, mais en veillant à indiquer à notre Rsyslogserver le bon type de socket dans notre /etc/rsyslog.d/server.conf.

#### GLOBAL DIRECTIVES ####
# Use default timestamp format
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

# File syncing capability is disabled by default. This feature is usually not required,
# not useful and an extreme performance hit
#$ActionFileEnableSync on

# An "In-Memory Queue" is created for remote logging.
$WorkDirectory /var/spool/rsyslog       # where to place spool files
$ActionQueueFileName queue              # unique name prefix for spool files
$ActionQueueMaxDiskSpace 1g     # 1gb space limit (use as much as possible)
$ActionQueueSaveOnShutdown on   # save messages to disk on shutdown
$ActionQueueType LinkedList     # run asynchronously
$ActionResumeRetryCount -1      # infinety retries if host is down

#### MODULES ####

$ModLoad imuxsock.so    # provides support for local system logging (e.g. via logger command)
$ModLoad imklog.so      # provides kernel logging support (previously done by rklogd)
#$ModLoad immark.so     # provides --MARK-- message capability

# Provides TCP syslog reception
$ModLoad imtcp.so
$InputTCPServerRun 514
# EOF /etc/rsyslog.d/server.conf

Et sur le Client...

Ca donne ça.

### GLOBAL DIRECTIVES ####
# Use default timestamp format
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

# File syncing capability is disabled by default. This feature is usually not required,
# not useful and an extreme performance hit
#$ActionFileEnableSync on

# An "In-Memory Queue" is created for remote logging.
$WorkDirectory /var/spool/rsyslog       # where to place spool files
$ActionQueueFileName rsyslogclient   # unique name prefix for spool files
$ActionQueueMaxDiskSpace 1g     # 1gb space limit (use as much as possible)
$ActionQueueSaveOnShutdown on   # save messages to disk on shutdown
$ActionQueueType LinkedList     # run asynchronously
$ActionResumeRetryCount -1      # infinety retries if host is down

#### MODULES ####

$ModLoad imuxsock.so    # provides support for local system logging (e.g. via logger command)
$ModLoad imklog.so      # provides kernel logging support (previously done by rklogd)
#$ModLoad immark.so     # provides --MARK-- message capability

# Provides TCP syslog reception
$ModLoad imtcp.so
$InputTCPServerRun 514
*.*     @@Rsyslogserver:514
# EOF /etc/rsyslog.d/client.conf

Notez que l'on a une double @ pour le mode TCP.

Conclusion

Testez. Déployez. Je vous l'avais dit ! Un jeu d'enfant ! Enjoy !