Je dois avouer que la configuration de Bacula m'a fait passer plusieurs soirées seul devant mon écran à crier sur quiconque passé derrière moi.
Ayant déjà subit les ravages de Bacula, j'espère pouvoir vous éviter la crise.

Les fichiers de configuration de Bacula se trouvent dans le répertoire “/etc/bacula/”, en listant le contenu de ce répertoire vous trouverez quatre fichiers de configuration qui nous intéresse (ainsi qu'un répertoire est deux autres fichiers) :

1. bacula-dir.conf = Fichier de configuration du “Bacula Director”.
2. bacula-fd.conf = Fichier de configuration du “Bacula Client”.
3. bacula-sd.conf = Fichier de configuration du “Bacula Storage”.
4. bconsole.conf = Fichier de configuration de la “Bacula Console”.

• Il gère les tâches (job)
• Il gère les planifications des tâches (schedule)
• Il gère les serveurs à sauvegarder (client)
• Il gère les médias ou seront sauvegarder les fichiers (pool, storage)
• Il gère les fichiers à sauvegarder (fileset)
• Il gère les messages (message)
• Il gère les catalogues (catalog)

Les liens indiqués dans cette liste peuvent devenir obsolètes.

• Le daemon “bacula-sd” stocke et récupère les fichiers sur le support physique (Doc sur le Storage).

• Le daemon “bacula-fd” est installé sur les serveurs à sauvegarder (Doc sur le Filer.
• Il sauvegarde les fichiers et se charge de les envoyer sur le “Director”.

Pour des questions de lisibilité, j'ai décidé de découper le fichier de configuration principale (bacula-dir.conf) en plusieurs parties comme ci-dessous :

• “clients.conf” : Contient les machines distantes à sauvegarder.
• “filesets.conf” : Contient les directives sur les fichiers à sauvegarder ou à exclure.
• “jobs.conf” : Contient la liste des jobs à déclencher.
• “messages.conf” : Contient la forme des messages qui seront envoyés ainsi que leurs destinataires.
• “pools.conf” : Contient la liste des volumes à utiliser lors de la sauvegarde
• “schedules.conf” : Contient les planifications qui seront utilisées par les jobs.
• “storages.conf” : Contient la liste des storages à utiliser.

Pour résumé :

Le FileSet = "Que sauvegarder ?", Le Client = "Qui sauvegarder ?", Le Schedule = "Quand sauvegarder ?", Le Pool = "Sur quel volume sauvegarder ?"

Tous ces fichiers se trouvent dans “/etc/bacula/conf.d/”; “conf.d” est un répertoire que j'ai créé. Donc :

# mkdir /etc/bacula/conf.d/

Maintenant que nous avons décrit l'environnement dans lequel nous allons effectuer la configuration de Bacula, nous pouvons passer à la configuration du Director.
Cette dernière s'effectue dans le fichier “/etc/bacula/bacula-dir.conf”.

#
# Informations relatives au Director.
#
Director {
	# Nom du Director. "localhost" peut poser problème.
	Name = thales.0pb.org-dir
 
	# Port utilisé par le Director.
	DIRport = 9101
 
	# Fichier contenant des requêtes SQL pouvant être utilisées.
	# Par défaut ce fichier est vide mais cette directive doit-être présente.
	QueryFile = "/etc/bacula/scripts/query.sql"
 
	# Répertoire ou seront stockés les fichiers de travail de Bacula entre autre le catalogue.
	WorkingDirectory = "/var/lib/bacula"
 
	# Répertoire ou seront créés les ID des processus daemon Bacula (director, storage, filer).
	PidDirectory = "/var/run/bacula"
 
	# Nombre de jobs pouvant-être exécutés simultanément.
	Maximum Concurrent Jobs = 20
 
	# Mot de passe qui sera utilisé par le storage et par le filer (client) pour se connecter au director.
	Password = "S8jSXrIaGjucBQlFuEhmbp2jVEXf3r1v"
 
	# Redirection des messages vers le director.
	Messages = Daemon
}
 
# Inclusion de tous les fichiers de configuration présents dans "/etc/bacula/conf.d/"
@|"sh -c 'for FILE in /etc/bacula/conf.d/*.conf ; do echo @${FILE} ; done'"
 
#
# Le catalogue contient le nom de tous les fichiers sauvegardés.
#
Catalog {
	# Nom du catalogue (ici rien de bien original). :)
	Name = Catalogue
 
	# A décommenter si vous souhaitez utiliser le module DBI pour vous connecter à la base de données.
	#dbdriver = "dbi:mysql"; dbaddress = 127.0.0.1; dbport = 3306
 
	# Informations de connexion à la base de données "bacula".
	dbname = bacula; DB Address = "sql.goldzoneweb.info"; dbuser = "bacula"; dbpassword = "*****"
}
 
#
# Console restreinte utilisée par le "tray-monitor" afin d'obtenir des informations sur l'état du Director.
#
Console {
	# Nom de la console.
	Name = thales.0pb.org-mon
 
	# Mot de passe qui sera utilisé pour se connecter à cette console.
	Password = "OISF_enTkinz5ZCOXQm_Mev6DYeRkGkbF"
 
	# La console a uniquement le droit le lancer la commande "status".
	CommandACL = status, .status
}

La liste des options pour le Director est disponible à cette adresse : http://www.bacula.org/fr/dev-manual/Configurer_Director.html

Passons à la configuration du Storage, comme dit au début de ce document, le fichier qui nous intéresse est “/etc/bacula/bacula-sd.conf”.

#
# Informations relatives au Storage.
#
Storage {
	# Nom du Storage. "localhost" peut poser problème.
	Name = backup01.goldzoneweb.info-sd
 
	# Port utilisé par le Storage.
	SDPort = 9103
 
	# Répertoire ou seront stockés les fichiers de travail de Bacula entre autre le catalogue.
	WorkingDirectory = "/var/lib/bacula"
 
	# Répertoire ou seront créés les ID des processus daemon Bacula (director, storage, filer).
	Pid Directory = "/var/run/bacula"
 
	# Nombre de jobs pouvant-être exécutés simultanément.
	Maximum Concurrent Jobs = 20
}
 
#
# Liste des Directors qui sont autorisés à se connecter au Storage.
#
Director {
	# Nom du Director. "localhost" peut poser problème.
	Name = backup01.goldzoneweb.info-dir
 
	# Mot de passe qui sera utilisé par le storage et par le filer (client) pour se connecter au Director.
	Password = "44kjMmUSo-a9nnL_RhbZgYxwEQ7bLmjX6"
}
 
#
# Director restreint utilisée par le "tray-monitor" afin d'obtenir des informations sur l'état du Storage.
#
Director {
	# Nom du Director. "localhost" peut poser problème.
	Name = backup01.goldzoneweb.info-mon
 
	# Mot de passe qui sera utilisé se pour connecter à ce Director.
	Password = "JNxhVmxe9RJqtqlFEPTxlt0LRTqBeZl6F"
 
	# Activation du monitoring.
	Monitor = yes
}
 
#
# Support ou seront stocker les fichiers sauvegardés.
#
Device {
	# Nom du stockage qui sera utilisé dans la directive Storage de chaque job.
	Name = File
 
	# Type de media qui sera utilisé, "File" n'est pas une obligation.
	# Il est tout à fait possible de mettre "DisqueDur", cependant "File" est représentatif du type \
	# de media utilisé à savoir un disque dur.
	Media Type = File
 
	# Répertoire ou seront stockés les fichiers et répertoires sauvegardés sous forme de volume.
	Archive Device = /home/bacula/
 
	# Cette directive permet d'étiqueter automatiquement un média (à savoir notre disque dur).
	# Sans cela, l'administrateur devra se connecter à la console pour ensuite lancer la commande "label".
	# Il est recommandé de l'activer pour les médias de type disque dur.
	LabelMedia = yes;
 
	# Support de la commodité lseek() permettant de lire les informations d'un fichier.
	Random Access = Yes;
 
	# Autorise Bacula à accéder automatiquement au volume.
	AutomaticMount = yes;
 
	# Dans notre cas cette option doit restée à "no". Cette dernière n'est a utiliser \
	# uniquement pour des médias amovibles (disquette, cdrom, bande, etc...).
	RemovableMedia = no;
 
	# Comme pour "RemovableMedia", cette directive est surtout appréciée pour les médias amovibles \
	# elle évite par exemple qu'une bande soit rembobinée dès que Bacula n'en a plus besoin.
	AlwaysOpen = no;
}
 
#
# Envoie tous les messages au Director.
#
Messages {
	Name = Daemon
	director = backup01.goldzoneweb.info-dir = all
}

La liste des options pour le Storage est disponible à cette adresse : http://www.bacula.org/fr/dev-manual/Configuratio_Storage_Daemon.html

La configuration du Storage étant finalisée, il nous reste à finir de configurer le Director. En effet si vous vous souvenez, nous avons vu plus haut que la configuration du Director avait été découpée pour facilité la compréhension.

#
# Fichiers qui seront à sauvegarder lors de la sauveagrde totale du serveur.
#
FileSet {
	# Nom de notre FileSet qui sera appelé dans les jobs.
	Name = "Totale"
 
	# Fichiers à sauvegarder ainsi que quelques options.
	Include {
		Options {
			# Tous les fichiers seront chiffrés en SHA1.
			signature = SHA1
 
			# Compression des fichiers.
			compression = GZIP9
 
			# Permet de sauvegarder plusieurs systèmes de fichiers.
			onefs = no
 
			# Sauvegarde des ACL.
			aclsupport = yes
		}
 
		# Tous les fichiers depuis "/" (la racine) seront sauvegardés.
		File = /
	}
 
	# Fichier qui seront exclus de la sauvegarde.
	Exclude {
		File = /proc
		File = /sys
		File = /tmp
		File = /dev
		File = /.journal
		File = /.fsck
		File = /var/www/tmp
		File = /var/www/logs_apache2
		File = /var/www/logs_proftpd
	}
}
 
#
# Fichiers qui seront à sauvegarder lors de la sauveagrde incrémentale du serveur.
#
FileSet {
	# Nom de notre FileSet qui sera appelé dans les jobs.
	Name = "Incrementale"
 
	# Fichiers à sauvegarder ainsi que quelques options.
	Include {
		Options {
			# Tous les fichiers seront chiffrés en SHA1.
			signature = SHA1
 
			# Compression des fichiers.
			compression = GZIP9
 
			# Permet de sauvegarder plusieurs systèmes de fichiers.
			onefs = no
 
			# Sauvegarde des ACL.
			aclsupport = yes
		}
 
		# Tous les fichiers depuis "/var/www/" seront sauvegardés.
		File = /var/www/
	}
 
	# Fichier qui seront exclus de la sauvegarde.
	Exclude {
		File = /var/www/tmp
		File = /var/www/logs_apache2
		File = /var/www/logs_proftpd
	}
}
 
#
# Sauvegarde du catalogue Bacula.
#
FileSet {
	# Nom de notre FileSet qui sera appelé dans les jobs.
	Name = "Catalogue"
 
	# Fichier SQL à sauvegarder ainsi que quelques options.
	Include {
		Options {
			# Le fichier sera chiffré en SHA1.
			signature = SHA1
		}
 
		# Fichier qui sera sauvegardé.
		File = "/var/lib/bacula/bacula.sql"
	}
}

La liste des options pour le FileSet est disponible à cette adresse : http://www.bacula.org/fr/dev-manual/Configurer_Director.html#SECTION00467000000000000000

#
# Envoi des messages en rapport avec les jobs.
#
Messages {
	# Nom de la ressource "Message" qui sera utilisé par le Filer, Director, etc...
	Name = Standard
 
	# Commande utilisée par Bacula pour envoyer un mail.
	# Si cette dernière n'est pas présente alors la commande "mail" de Linux sera utilisée.
	# Les arguments "%r, %t, %c, etc..." sont indiqués dans la documentation.
	# L'option -h permet de spécifier le serveur SMTP, dans notre cas nous passerons par NullMailer (cf. sur le Wiki GoldZone Web).
	mailcommand = "/usr/lib/bacula/bsmtp -h localhost -f \"\(Bacula\) \<%r\>\" -s \"Bacula: %t %e of %c %l\" %r"
 
	# Identique à la commande ci-dessus mais destinée aux administrateurs de sauvegardes.
	operatorcommand = "/usr/lib/bacula/bsmtp -h localhost -f \"\(Bacula\) \<%r\>\" -s \"Bacula: Intervention needed for %j\" %r"
 
	# Adresse ou seront envoyés les messages exceptés les fichiers exclus dans notre FileSet.
	mail = administrateur@goldzoneweb.info = all, !skipped
 
	# Adresse email ou seront envoyés les messages en relation avec le montage d'un volume.
	operator = administrateur@goldzoneweb.info = mount
 
	# Les messages sont envoyés à la console Bacula, une fois que l'administrateur aura tapé "message" \
	# dans la console, ces derniers ne seront plus disponibles depuis la console.
	console = all, !skipped, !saved
 
	# Envoi les informations dans le fichier de log bacula excépté les fichiers exclus dans le FileSet.
	append = "/var/lib/bacula/log" = all, !skipped
 
	# Insert les événements dans le catalogue Bacula et plus précisement dans la table "Log".
	# Un log relatif à un job est supprimé lorsque le job référant est supprimé.
	catalog = all
}
 
#
# Envoi des messages en rapport avec les daemons Bacula.
#
Messages {
	# Nom de la ressource "Message" qui sera utilisé par le Filer, Director, etc...
	Name = Daemon
 
	# Commande utilisée par Bacula pour envoyer un mail.
	mailcommand = "/usr/lib/bacula/bsmtp -h localhost -f \"\(Bacula\) \<%r\>\" -s \"Bacula daemon message\" %r"
 
	# Adresse ou seront envoyés les messages exceptés les fichiers exclus dans notre FileSet.
	mail = administrateur@goldzoneweb.info = all, !skipped
 
	# Les messages sont envoyés à la console Bacula, une fois que l'administrateur aura tapé "message" \
	# dans la console, ces derniers ne seront plus disponibles depuis la console.
	console = all, !skipped, !saved
 
	# Envoi les informations dans le fichier de log bacula excépté les fichiers exclus dans le FileSet.
	append = "/var/lib/bacula/log" = all, !skipped
}

Description des ”options” utilisées dans la directive “mailcommand” :

• %% = %
• %c = Le nom du client
• %d = Le nom du Director
• %e = Le code de sortie du job (OK, Error, …)
• %i = L'Id du Job
• %j = Le nom unique du job
• %l = Le niveau (Full, Differential, …) du job
• %n = Le nom du job
• %r = Les destinataires
• %t = Le type du job (Backup, Verify, …)

La liste des options pour la directive Messages est disponible à cette adresse : http://www.bacula.org/fr/dev-manual/ressource_Messages.html#_ChapterStart15

#
# Planification des sauvegardes.
#
Schedule {
	# Nom de la planification qui sera appelée dans le job.
	Name = "WeeklyCycle"
 
	# La sauvegarde totale se déroulera le premier dimanche du mois à 04h05 du matin.
	Run = Full 1st sun at 04:05
 
	# La sauvegarde différentielle se déroulera le seconde et cinquième dimanche du mois à 23h05.
	Run = Differential 2nd-5th sun at 23:05
 
	# La sauvegarde incrémentale se déroulera tous les soirs à partir de 23h05.
	Run = Incremental sun-sat at 23:05
}
 
#
# Sauvegarde du catalogue après le schedules "WeeklyCycle".
#
Schedule {
	# Nom de la planification qui sera appelée dans le job.
	Name = "WeeklyCycleAfterBackup"
 
	# Sauvegarde totale du catalogue tous les soirs à 23h10.
	Run = Full sun-sat at 23:10
}

#
# Pool destiné à la sauvegarde totale.
#
Pool {
	# Nom du pool qui sera utilisé par les jobs.
	Name = SauvegardeTotale
 
	# Type de pool correspondant au job qui y sera exécuté.
	# Il peut y avoir plusieurs (un seul à la fois), Backup, Archive, Copy, etc...
	Pool Type = Backup
 
	# Permet à Bacula de ré-utiliser les volumes n'étant plus dans le catalogue.
	Recycle = yes
 
	# Fait le ménage dans le catalogue de Bacula en supprimant les jobs anciens.
	# Suite à cela ils pourront être recyclés (voir la directive précédente).
	AutoPrune = yes
 
	# Temps pendant lequel les jobs seront conservés dans les catalogues.
	# Arrivés à expération, il sera supprimé par la directive "AutoPrune" et ré-utilisés grace à la directive "Recycle".
	Volume Retention = 365 days
 
	# Nombre de volume autorisés par Pool, ci la valeur est à 0 alors il n'y a aucune limite.
	Maximum Volumes = 100
 
	# Format des noms des volumes.
	# Par exemple : GZW-Full-2010-07-03_23:20
	# La liste des variables sont disponibles ici : http://www.bacula.org/fr/dev-manual/Variable_Expansion.html#_ChapterStart50
	Label Format = "GZW-Full-${Year}-${Month:p/2/0/r}-${Day:p/2/0/r}_${Hour:p/2/0/r}:${Minute:p/2/0/r}"
}
 
#
# Pool destiné à la sauvegarde différencielle.
#
Pool {
	# Nom du pool qui sera utilisé par les jobs.
	Name = SauvegardeDifferencielle
 
	# Type de pool correspondant au job qui y sera exécuté.
	# Il peut y avoir plusieurs (un seul à la fois), Backup, Archive, Copy, etc...
	Pool Type = Backup
 
	# Permet à Bacula de ré-utiliser les volumes n'étant plus dans le catalogue.
	Recycle = yes
 
	# Fait le ménage dans le catalogue de Bacula en supprimant les jobs anciens.
	# Suite à cela ils pourront être recyclés (voir la directive précédente).
	AutoPrune = yes
 
	# Temps pendant lequel les jobs seront conservés dans les catalogues.
	# Arrivés à expération, il sera supprimé par la directive "AutoPrune" et ré-utilisés grace à la directive "Recycle".
	Volume Retention =  40 days
 
	# Format des noms des volumes.
	# Par exemple : GZW-Diff-2010-07-03_23:20
	# La liste des variables sont disponibles ici : http://www.bacula.org/fr/dev-manual/Variable_Expansion.html#_ChapterStart50
	Label Format = "GZW-Diff-${Year}-${Month:p/2/0/r}-${Day:p/2/0/r}_${Hour:p/2/0/r}:${Minute:p/2/0/r}"
}
 
#
# Pool destiné à la sauvegarde incrémentale.
#
Pool {
	# Nom du pool qui sera utilisé par les jobs.
	Name = SauvegardeIncrementale
 
	# Type de pool correspondant au job qui y sera exécuté.
	# Il peut y avoir plusieurs (un seul à la fois), Backup, Archive, Copy, etc...
	Pool Type = Backup
 
	# Permet à Bacula de ré-utiliser les volumes n'étant plus dans le catalogue.
	Recycle = yes
 
	# Fait le ménage dans le catalogue de Bacula en supprimant les jobs anciens.
	# Suite à cela ils pourront être recyclés (voir la directive précédente).
	AutoPrune = yes
 
	# Temps pendant lequel les jobs seront conservés dans les catalogues.
	# Arrivés à expération, il sera supprimé par la directive "AutoPrune" et ré-utilisés grace à la directive "Recycle".
	Volume Retention =  10 days
 
	# Format des noms des volumes.
	# Par exemple : GZW-Incr-2010-07-03_23:20
	# La liste des variables sont disponibles ici : http://www.bacula.org/fr/dev-manual/Variable_Expansion.html#_ChapterStart50
	Label Format = "GZW-Incr-${Year}-${Month:p/2/0/r}-${Day:p/2/0/r}_${Hour:p/2/0/r}:${Minute:p/2/0/r}"
}
 
#
# Pool destiné à la sauvegarde du catalogue.
#
Pool {
	# Nom du pool qui sera utilisé par les jobs.
	Name = SauvegardeCatalogue
 
 
	# Type de pool correspondant au job qui y sera exécuté.
	# Il peut y avoir plusieurs (un seul à la fois), Backup, Archive, Copy, etc...
	Pool Type = Backup
 
	# Permet à Bacula de ré-utiliser les volumes n'étant plus dans le catalogue.
	Recycle = yes
 
	# Fait le ménage dans le catalogue de Bacula en supprimant les jobs anciens.
	# Suite à cela ils pourront être recyclés (voir la directive précédente).
	AutoPrune = yes
 
	# Temps pendant lequel les jobs seront conservés dans les catalogues.
	# Arrivés à expération, il sera supprimé par la directive "AutoPrune" et ré-utilisés grace à la directive "Recycle".
	Volume Retention = 365 days
 
	# Nombre de volume autorisés par Pool, ci la valeur est à 0 alors il n'y a aucune limite.
	Maximum Volumes = 100 
 
	# Format des noms des volumes.
	# Par exemple : GZW-Catalogue-2010-07-03_23:20
	# La liste des variables sont disponibles ici : http://www.bacula.org/fr/dev-manual/Variable_Expansion.html#_ChapterStart50
	Label Format = "GZW-Catalogue-${Year}-${Month:p/2/0/r}-${Day:p/2/0/r}_${Hour:p/2/0/r}:${Minute:p/2/0/r}"
}
 
#
# Pool de secours.
#
Pool {
	# Nom du pool qui sera utilisé par les jobs.
	Name = Scratch
 
	# Type de pool correspondant au job qui y sera exécuté.
	# Il peut y avoir plusieurs (un seul à la fois), Backup, Archive, Copy, etc...
	Pool Type = Backup
}

La liste des options relatives à la ressource Pool est disponible à cette adresse : http://www.bacula.org/fr/dev-manual/Configurer_Director.html#SECTION004615000000000000000
Une définition complète du pool “Scratch” est disponible ici : http://www.bacula.org/fr/dev-manual/Configurer_Director.html#SECTION004615100000000000000

#
# Serveur N°1 à sauvegarder.
#
Client {
	# Nom du serveur qui sera utilisé dans les jobs.
	Name = Cartman
 
	# Adresse du serveur (IP ou DNS).
	Address = 192.168.0.2
 
	# Port d'écoute du Filer (par défaut).
	FDPort = 9102
 
	# Catalogue à utiliser pour ce serveur.
	Catalog = Catalogue
 
	# Mot de passe du Director (obligatoire pour que le Filer puisse se connecter au Director).
	Password = "ukHDHtRJ2MF7ZuEdwI0ynsnuS3DhRck6"
 
	# Durée pendant laquelle les fichiers resteront renseignés dans le catalogue.
	File Retention = 30 days
 
	# Durée pendant laquelle les jobs resteront renseignés dans le catalogue.
	Job Retention = 6 months
 
	# Fait le ménage dans le catalogue de Bacula en supprimant les jobs anciens.
	AutoPrune = yes
}

La liste des directives pour la ressource Client est disponible à cette adresse : http://www.bacula.org/fr/dev-manual/Configurer_Director.html#SECTION004613000000000000000

#
# Storages disponibles
#
Storage {
	# Nom du Storage qui sera appelé dans le job.
	Name = File
 
	# Adresse du Storage à utiliser, il est tout à fait possible d'avoir plusieurs serveurs \
	# ayant le daemon "bacula-sd" actif. Il est donc possible d'avoir un serveur n'ayant \
	# que des disques, un autre gérant un lecteur LTO, etc...
	# Il est préférable de ne pas mettre "localhost" si le "bacula-sd" tourne en local (ce qui est notre cas).
	Address = 192.168.0.3
 
	# Port d'écoute du storage.
	SDPort = 9103
 
	# Mot de passe pour se connecter au Director.
	Password = "ukHDHtRJ2MF7ZuEdwI0ynsnuS3DhRck6"
 
	# Nom du Storage qui a été défini dans le fichier "bacula-sd.conf"
	Device = FileStorage
 
	# Comme pour la directive du dessus il est nécessaire d'indiquer la même valeur \
	# que celle présente dans le fichier "bacula-sd.conf".
	Media Type = File
}

#
# Template pour la sauvegarde incrémentale.
#
JobDefs {
	# Nom du template qui sera appelé dans le job.
	Name = "Incrementale"
 
	# Type du job (Backup, Restore, etc...).
	Type = Backup
 
	# Type de sauvegarde à effectuer (Full, Incrementale, etc...)
	Level = Incremental
 
	# Fichiers qui seront sauvegardés par ce job.
	FileSet = "Incrementale"
 
	# Planification du job.
	Schedule = "WeeklyCycle"
 
	# Les fichiers seront sauvegardés sur le Storage "File".
	Storage = File
 
	# Les messages concernant ce job seront envoyés au Director dans la section "Standard" de la directive "Message".
	Messages = Standard
 
	# Type de pool qui sera utilisé par ce job.
	Pool = SauvegardeIncrementale
 
	# Priorité d'exécution du job lorsqu'il est en file d'attente.
	# Par défaut la priorité est de 10.
	Priority = 10
 
	# Fichier permettant de restaurer les fichiers sur un serveur.
	# Ce fichier peut-être une alternative à un catalogue erroné.
	Write Bootstrap = "/var/lib/bacula/%c.bsr"
}
 
#
# Template pour la sauvegarde totale.
#
JobDefs {
	# Nom du template qui sera appelé dans le job.
	Name = "Totale"
 
	# Type du job (Backup, Restore, etc...).
	Type = Backup
 
	# Type de sauvegarde à effectuer (Full, Incrementale, etc...).
	Level = Full
 
	# Fichiers qui seront sauvegardés par ce job.
	FileSet = "Totale"
 
	# Les fichiers seront sauvegardés sur le Storage "File".
	Storage = File
 
	# Les messages concernant ce job seront envoyés au Director dans la section "Standard" de la directive "Message".
	Messages = Standard
 
	# Type de pool qui sera utilisé par ce job.
	Pool = SauvegardeTotale
 
	# Priorité d'exécution du job lorsqu'il est en file d'attente.
	# Par défaut la priorité est de 10.
	Priority = 10
 
	# Fichier permettant de restaurer les fichiers sur un serveur.
	# Ce fichier peut-être une alternative à un catalogue erroné.
	Write Bootstrap = "/var/lib/bacula/%c.bsr"
}
 
#
# Template pour la sauvegarde d'un catalogue. 
#
JobDefs {
	# Nom du template qui sera appelé dans le job.
	Name = "Catalogue"
 
	# Type du job (Backup, Restore, etc...).
	Type = Backup
 
	# Type de sauvegarde à effectuer (Full, Incrementale, etc...).
	Level = Full
 
	# Serveur ou se trouve le catalogue.
	Client = backup01.goldzoneweb.info
 
	# Fichiers qui seront sauvegardés par ce job.
	FileSet = "Catalogue"
 
	# Les fichiers seront sauvegardés sur le Storage "File".
	Storage = File
 
	# Les messages concernant ce job seront envoyés au Director dans la section "Standard" de la directive "Message".
	Messages = Standard
 
	# Type de pool qui sera utilisé par ce job.
	Pool = SauvegardeCatalogue
}
 
#
# Template pour la restauration. 
#
JobDefs {
	# Nom du template qui sera appelé dans le job.
	Name = "Restauration"
 
	# Type du job (Backup, Restore, etc...).
	Type = Restore
 
	# Fichiers qui seront restaurés.
	FileSet = "Totale"
 
	# Les fichiers seront sauvegardés sur le Storage "File".
	Storage = File
 
	# Les messages concernant ce job seront envoyés au Director dans la section "Standard" de la directive "Message".
	Messages = Standard
 
	# Type de pool qui sera utilisé par ce job.
	Pool = SauvegardeTotale
}
 
#
# Sauvegarde Totale
#
Job {
	# Nom du job.
	Name = "Totale"
 
	# JobDefs (template) à utiliser.
	JobDefs = "Totale"
 
	# Serveur sur lequel se déclenchera le job.
	Client = Cartman
 
	# Délai d'attente des ressouces ou Client de 2 minutes.
	# C'est à dire que si un client mais du temps à répondre à la requête alors il a 2 minutes.
	Max Wait Time = 2 minutes
}
 
#
# Sauvegarde incrémentale.
#
Job {
	# Nom du job.
	Name = "Incrementale"
 
	# JobDefs (template) à utiliser.
	JobDefs = "Incrementale"
 
	# Serveur sur lequel se déclenchera le job.
	Client = Cartman
 
	# Délai d'attente des ressouces ou Client de 2 minutes.
	# C'est à dire que si un client mais du temps à répondre à la requête alors il a 2 minutes.
	Max Wait Time = 2 minutes
}
 
#
#  Job de sauvegarde du catalogue.
#
Job {
	# Nom du job.
	Name = "SauvegardeCatalogue"
 
	# JobDefs (template) à utiliser.
	JobDefs = "Catalogue"
 
	# Planification du job.
	Schedule = "WeeklyCycleAfterBackup"
 
	# Script de sauvegarde du catalogue (lance un "mysqldump").
	# "Catalogue" étant le nom du catalogue à sauvegarder (voir la configuration dabs "bacula-dir").
	RunBeforeJob = "/etc/bacula/scripts/make_catalog_backup.pl Catalogue"
 
	# Supprime les copies du catalogue un fois la sauvegarde terminée.
	RunAfterJob  = "/etc/bacula/scripts/delete_catalog_backup"
 
	# Fichier permettant de restaurer le catalogue.
	Write Bootstrap = "/var/lib/bacula/Catalogue.bsr"
 
	# Priorité du job.
	# Ici la priorité est inférieure à un job standard ce qui aura \
	# pour incidence de mettre le job en attente tant que l'incrémentale, la totale, ou le différencielle \
	# ne sera pas terminé.
	Priority = 11
}
 
#
# Job de restauration des données. 
#
Job {
	# Nom du job.
	Name = "Restauration"
 
	# JobDefs (template) à utiliser.
	JobDefs = "Restauration"
 
	# Serveur sur lequel seront restaurées les données.
	Client = Cartman
 
	# Répertoire sur le serveur distant ou seront stockées les données restaurées.
	Where = /home/bacula/restore
}

La liste des directives pour les ressources Job et JobDefs sont disponibles à cette adresse : http://www.bacula.org/fr/dev-manual/Configurer_Director.html#SECTION00463000000000000000

/etc/bacula/conf.d/filesets.conf
/etc/bacula/conf.d/jobs.conf
/etc/bacula/conf.d/pools.conf
/etc/bacula/conf.d/storages.conf
/etc/bacula/conf.d/messages.conf
/etc/bacula/conf.d/clients.conf
/etc/bacula/conf.d/schedules.conf

Ce fichier de configuration est le plus simple, il permet de définir les informations du Director sur une machine distante afin que cette dernière puisse être sauvegardée.

#
# Liste des Directors qui sont autorisés à se connecter à ce client.
#
Director {
	# Nom du Director. "localhost" peut poser problème.
	Name = backup01.goldzoneweb.info-dir
 
	# Mot de passe qui sera utilisé pour se connecter au director.
	Password = "S8jSXrIaGjucBQlFuEhmbp2jVEXf3r1v"
}
 
#
# Configuration du daemon Filer présent sur le client.
#
FileDaemon {
	# Nom de la machine distante.
	# C'est le nom qu'il sera nécessaire de renseigner dans le fichier "/etc/bacula/conf.d/clients.conf".
	Name = Cartman-fd
 
	# Port utilisé par le Filer.
	FDport = 9102
 
	# Répertoire ou seront stockés les fichiers de travail de Bacula.
	WorkingDirectory = /var/lib/bacula
 
	# Répertoire ou sera créé l'ID du processus daemon Bacula (filer).
	Pid Directory = /var/run/bacula
}
 
#
# Envoie tous les messages au Director sauf les fichiers passée et les fichiers restaurés.
#
Messages {
	Name = Daemon
	director = backup01.goldzoneweb.info-dir = all, !skipped, !restored
}

La liste des options pour le Filer est disponible à cette adresse : http://www.bacula.org/fr/dev-manual/Configura_Client_Fi_Daemon.html

La ou les personne(s) responsable(s) de l'administration du système Bacula.

Nous utilisons ce terme pour un job Bacula qui sauvegarde des fichiers.

Le bootstrap est un fichier ASCII qui contient, sous une forme compacte, les commandes qui permettent à Bacula ou à l'utilitaire autonome bextract de restaurer les contenus d'un ou plusieurs volumes, par exemple, l'état courant d'un système qui vient d'être sauvegardé. Avec un fichier bootstrap, Bacula peut restaurer votre système sans catalogue. Vous pouvez créer un fichier bootstrap depuis un catalogue pour extraire le fichier que vous voulez.

Le catalogue est utilisé pour stocker des informations sommaires concernant les Jobs et Clients, les fichiers qui ont été sauvegardés ainsi que le ou les volume(s) où ils ont été sauvegardés. L'information stockée dans le catalogue permet à l'administrateur ou aux utilisateurs de déterminer quels jobs ont été exécutés, leur statut, ainsi que d'importantes caractéristiques de chaque fichier sauvegardé. Le catalogue est une ressource en ligne, mais ne contient pas les données pour les fichiers sauvegardés. La plupart des informations stockées dans le catalogue le sont aussi sur les volumes de sauvegarde (i.e. cartouches). Bien sur, les cartouches auront aussi une copie du fichier en plus de ses attributs (voir ci-dessus).

La fonction Catalogue est de celles qui distinguent Bacula de simples programmes de sauvegarde et archivage tels que dump et tar.

Dans la terminologie de Bacula, le mot Client désigne une machine sauvegardée, et est synonyme de File service ou File Daemon. Nous nous y référons assez souvent par “le FD”. Un client est défini dans une ressource de fichier de configuration.

Le programme qui interface le Director, permettant à l'administrateur de contrôler Bacula.

Terminologie Unix pour un programme toujours présent en arrière plan pour prendre en charge une tâche donnée. Sur les systèmes Windows, ainsi que certains Linux, les daemons sont appelés Services.

Le terme directive est utilisé pour désigner une entrée ou enregistrement à l'intérieur d'une ressource dans un fichier de configuration qui définit un élément spécifique. Par exemple, la directive Name définit le nom de la ressource.

Le principal daemon serveur de Bacula qui planifie et dirige toutes les opérations de Bacula. Occasionnellement, nous le désignons par “le DIR”.

Une sauvegarde qui inclut tous les fichiers modifiés depuis le lancement de la dernière sauvegarde complète (Full). Notez que d'autres logiciels de sauvegarde peuvent définir ceci différemment.

Les Attributs de fichiers sont toutes les informations nécessaires au sujet d'un fichier pour l'identifier, et toutes ses propriétés telles taille, date de création, date de modification, permission, etc. En principe, les attributs sont intégralement manipulés par Bacula de sorte que l'utilisateur n'a jamais à s'en préoccuper. Les attributs n'incluent pas les données du fichier.

Le daemon exécuté sur l'ordinateur client à sauvegarder. Il est aussi désigné par Service Fichier (File Service) et parfois Service Client ou FD.

Un FileSet est une ressource d'un fichier de configuration qui définit les fichiers à sauvegarder. Il consiste en une liste de fichiers ou répertoires inclus, une liste de fichiers ou répertoires exclus et la façon dont les fichiers seront stockés (compression, chiffrement, signatures). Pour plus de détails consultez le paragraphe Définition de la Ressource FileSet dans le chapitre Director de ce document.

Une sauvegarde qui inclut tous les fichiers modifiés depuis le lancement de la dernière sauvegarde complète (Full), différentielle, ou incrémentale. Normalement spécifié dans la directive Level (niveau) dans la définition de la ressource Job, ou dans une ressource Schedule.

Un Job Bacula est une ressource de configuration qui définit le travail que Bacula doit effectuer pour sauvegarder ou restaurer un client particulier. Un Job consiste en un Type, (Type : backup, restore, verify, etc.), un Niveau (Level : full, incremental, …), un FileSet, et un lieu de Stockage où écrire les fichiers (Storage device, Media Pool). Pour plus de détails consultez le chapitre Définition des Ressources Job de ce document.

Le programme qui s'interface avec chacun des daemons pour permettre à l'utilisateur ou à l'administrateur de surveiller le statut de Bacula.

Une ressource est une partie d'un fichier de configuration qui définit une unité spécifique d'information disponible pour Bacula. Par exemple, la ressource Job définit toutes les propriétés d'un Job spécifique : nom, schedule (planification), volume pool, type de sauvegarde, niveau de sauvegarde, etc.

Une Restore est une ressource de configuration qui décrit l'opération de restauration d'un fichier (perdu ou endommagé) depuis un medium de sauvegarde. C'est l'opération réciproque d'une sauvegarde, sauf que, dans la plupart des cas, une restauration concernera un petit ensemble de fichiers tandis qu'une sauvegarde concerne le plus souvent l'ensemble des fichiers d'un système. Bien sur, après une défaillance de disque(s), Bacula peut être appelé à effectuer une restauration complète de tous les fichiers qui étaient sur le système.

Un Schedule est une ressource de configuration qui définit le moment de l'exécution du Job Bacula. Pour utiliser un schedule, la ressource Job se réfère au nom du Schedule. Pour plus de détails, consultez la Définition de la ressource Schedule dans le chapitre Director de ce document.

Terminologie Windows pour désigner un daemon – Voir plus haut. Elle est maintenant fréquemment utilisée dans les environnements Unix aussi.

Les informations retournées par les Storage services qui localisent de façon unique les fichiers sur un medium de sauvegarde. Elles consistent en deux parties : l'une appartient à chaque fichier sauvegardé, l'autre à l'ensemble du Job. Normalement, cette information est sauvegardée dans le catalogue de sorte que l'utilisateur n'a pas besoin de connaissances particulières des adresses de stockage. L'adresse de stockage inclut les attributs de fichiers (voir plus haut) ainsi que la localisation unique de l'information sur le volume de sauvegarde.

Le Storage Daemon, parfois désigné par “SD” est le programme qui écrit les attributs et les données sur un Volume de Stockage (Storage Volume) (Usuellement une cartouche ou un disque).

Désigne en principe le dialogue interne entre le File Daemon et le Storage Daemon. Le File Daemon ouvre une session avec le Storage Daemon pour sauvegarder un Fileset, ou pour le restaurer. Une session est associée à un et un seul Job Bacula (voir plus haut).

Il s'agit d'un job qui compare les attributs du fichier actuel aux attributs qui ont été préalablement stockés dans le catalogue Bacula. Cette fonction peut être utilisée pour détecter les modifications de systèmes de fichiers critiques, à la façon de Tripwire. L'un des avantages majeurs de l'utilisation de Bacula pour cette tâche est que sur la machine que vous voulez protéger, vous pouvez n'exécuter que le File Daemon. Le Director, le Storage Daemon et le catalogue peuvent résider sur une autre machine. Par conséquent si votre serveur est un jour compromis, il est peu probable que la base de données de vérification ait été trifouillée.

Verify peut aussi être utilisé pour s'assurer que les données les plus récemment écrites sur un volume sont cohérentes avec ce qui figure dans le catalogue (c-à-d il compare les attributs de fichiers), ou encore, confronter le contenu du volume aux fichiers originaux sur le disque.

Une opération d'archivage est effectuée après une sauvegarde, et consiste en l'exclusion des volumes sur lesquels les données sont sauvegardées de l'utilisation courante. Ces volumes sont marqués “Archived”, et ne sont plus utilisés pour sauvegarder des fichiers. Tous les fichiers contenus sur un Volume Archive sont supprimés du catalogue. PAS ENCORE IMPLEMENTE.

Une opération Update synchronise les fichiers du système distant sur ceux du local. Ceci est l'équivalent d'une fonctionnalité rdist. PAS ENCORE IMPLEMENTE.

Bacula reconnait plusieurs sortes de périodes de rétention. Les plus importantes sont la période de rétention des fichiers, la période de rétention des jobs et la période de rétention des volumes. Chacune de ces périodes de rétention désigne la durée pendant laquelle l'enregistrement spécifique sera conservé dans le catalogue. Ceci ne doit pas être confondu avec le temps pendant lequel les données sauvegardées sur un volume sont valides.

La période de rétention des fichiers détermine la durée pendant laquelle les enregistrements concernant les fichiers seront gardés dans le catalogue. Cette période est importante car le volume des enregistrements relatifs aux fichiers occupe, de loin, le plus d'espace dans la base de données. Par conséquent, vous devez vous assurer qu'un “élagage” (NDT : pruning) régulier de ces enregistrements est effectué. (Voir la commande retention de la Console pour plus de détails sur ce sujet).

La période de rétention des jobs est la durée pendant laquelle les enregistrements relatifs aux jobs seront conservés dans le catalogue. Notez que tous les enregistrements relatifs aux fichiers sont attachés aux jobs qui ont sauvegardé ces fichiers. Les enregistrements relatifs aux fichiers peuvent être purgés tout en conservant ceux relatifs aux jobs. Dans ce cas, l'information concernant les jobs exécutés restera disponible, mais pas les détails des fichiers sauvegardés. Normalement, lorsqu'un job est purgé, tous les enregistrements concernant les fichiers qu'il a sauvegardé le sont aussi.

La période de rétention des volumes est la durée minimale de conservation d'un volume avant qu'il ne soit réutilisé. Bacula n'effacera, en principe, jamais un volume qui contient la seule copie de sauvegarde d'un fichier. Dans les conditions idéales, le catalogue maintiendrait les entrées pour tous les fichiers sauvegardés pour tous les volumes courants. Une fois qu'un volume est écrasé, les fichiers qui étaient sauvegardés dessus sont automatiquement effacés du catalogue. Cependant, s'il y a un très gros pool de volumes ou si un volume n'est jamais écrasé, le catalogue pourrait devenir énorme. Pour maintenir le catalogue dans des proportions gérables, les informations de sauvegarde devraient être supprimées après une période de rétention des fichiers définie.

Une opération de scan consiste en un balayage du contenu d'un volume ou d'une série de volumes. Ces volumes et les informations concernant les fichiers qu'ils contiennent sont restaurés vers le catalogue Bacula. Une fois ces informations restaurées, les fichiers sauvegardés sur ces volumes pourront être aisément restaurés. Cette fonction est particulièrement utile si certains volumes ou jobs ont dépassé leur période de rétention et ont été élagués ou purgés du catalogue. Le balayage des données des volumes est effectué en utilisant le programme bscan. Consultez la section bscan du chapitre sur les utilitaires Bacula de ce manuel pour plus de détails.

Un volume est une unité d'archivage, usuellement une cartouche ou un fichier nommé sur disque où Bacula stocke les données pour un ou plusieurs jobs de sauvegarde. Tous les volumes Bacula ont un label unique (logiciel) écrit sur le volume par Bacula afin qu'il puisse être assuré de lire le bon volume. (En principe, il ne devrait pas y avoir de confusion avec des fichiers disques, mais avec des cartouches, il est facile de monter la mauvaise).

Bacula est utilisé pour sauvegarder via le réseau un ensemble de postes clients et de serveurs. Son originalité réside, en partie, dans le fait qu'il utilise un SGBD libre (MySQL, PostgreSQL) pour gérer le catalogue des sauvegardes, ce qui lui permet de gérer largement plus d'un milliard d'objets sans dégradation des performances.

Un autre avantage de Bacula est qu'il sait piloter et utiliser des périphériques de stockage professionnels, tels que les robots à bandes. Disponible sur de nombreuses plate-formes, ce logiciel est assez largement utilisé dans l'industrie, l'éducation et même dans le milieu bancaire. (source Wikipedia)

Les services Catalogue ont pour tâche de maintenir à jour la base de données des index de fichiers et volumes pour tous les fichiers sauvegardés. Les services Catalogue permettent à l'administrateur système ou à l'utilisateur de localiser rapidement et restaurer n'importe quel fichier. Les services Catalogue de Bacula le placent dans une catégorie différente de programmes tels que tar et bru, puisque le catalogue Bacula maintient un enregistrement de chaque volume utilisé, chaque job exécuté et chaque fichier sauvegardé ce qui permet des restaurations et une gestion de volumes efficaces.

1. Director : Ce daemon gère l'ensemble de Bacula ainsi que les autres daemons.
2. Storage : Ce daemon gère les médias ou seront écrits les données (disque dur, lecteur de bande, etc…).
3. Filer : Ce daemon gère la partie client, c'est à dire que ce daemon est installé sur toutes les machines à sauvegarder.

• Director : 9101 (TCP)
• Filer : 9102 (TCP)
• Storage : 9103 (TCP)

Bacula permet de sauvegarder des clients ayant pour système d'exploitation :

• Mac OSX
• Unix
• Linux
• Windows

De manière (très) grossière, voici le fonctionnement de Bacula (schéma présent sur la plupart des sites parlant de Bacula) :

La terminologie de Bacula est tirée du site officiel. Pensez à la garder sous le coude lors de l'installation de Bacula, elle vous sera précieuse !!
Lien : Terminologie Bacula

La version de Bacula présente dans les dépôt Debian n'est plus du tout à jour… (2.4.4). Pour remédier à ce problème nous allons ajouter un backports à notre “/etc/apt/sources.list”.

Pour se faire nous devons insérer la source adéquate.

echo "deb http://www.backports.org/debian lenny-backports main contrib non-free" >> /etc/apt/sources.list

Mise à jour d'APT pour qu'il prenne en charge notre nouvelle source.

# aptitude update

A la suite de cette commande, APT va râler parce qu'il ne trouve pas la signature GPG du dépôt.
La résolution de ce problème est on ne peut plus simple, elle consiste à installer un paquet contenant la clé GPG.

# aptitude install debian-backports-keyring

Maintenant que notre serveur à moyen d'accéder à une version récente de Bacula, nous allons pouvoir passer à l'installation des paquets.
Vérifions tout de même que nous avons la bonne version à disposition.

# apt-cache policy bacula

Résultat :

root@backup01:~# apt-cache policy bacula
bacula:
  Installé : 5.0.2-1~bpo50+1
  Candidat : 5.0.2-1~bpo50+1
  Étiquette de paquet : 5.0.2-1~bpo50+1
 Table de version :
 *** 5.0.2-1~bpo50+1 500
        400 http://www.backports.org lenny-backports/main Packages
        100 /var/lib/dpkg/status
     2.4.4-1 500
        500 http://ftp.fr.debian.org lenny/main Packages

Celle qui nous intéresse est la version 5.0.2. Nous allons donc installer le paquet “bacula” en indiquant que nous souhaitons le support MySQL.

# aptitude install bacula bacula-director-mysql -t lenny-backports

Le paramètre “-t lenny-backports” indique que nous souhaitons installer le paquet “bacula” présent sur le dépôt www.backports.org

Debconf va poser quelques questions au sujet de la configuration MySQL.

Bacula sera configuré à l'aide DBConfig.

Mot de passe “root” MySQL (super-utilisateur).

Mot de passe MySQL de l'utilisateur Bacula qui accédera au catalogue.

Confirmation du mot de passe MySQL.

A la suite de cela est créée une base de données “bacula” ainsi qu'un utilisateur MySQL “bacula” ayant tous les droits sur la base de données sus-citée.
Pour vérifier que la base de données “bacula” a bien été créé il suffit de lancer la commande suivante :

# mysql -u bacula -p -e "SHOW DATABASES;" | grep bacula

Résultat :

bacula

Si vous êtes adepte du pinning, voici la démarche à suivre pour qu'APT mette uniquement le paquet “bacula” à jour depuis le dépôt www.backports.org

Créez un fichier “preferences” dans “/etc/apt/” (s'il n'existe pas) et placez-y ceci :

Package: *
Pin: origin www.backports.org
Pin-Priority: 400

Package: bacula
Pin: origin www.backports.org
Pin-Priority: 500

Package: bacula-server
Pin: origin www.backports.org
Pin-Priority: 500

Package: bacula-client
Pin: origin www.backports.org
Pin-Priority: 500

Lien vers la configuration de Bacula : Configuration du système de sauvegarde Bacula

Bacula est utilisé pour sauvegarder via le réseau un ensemble de postes clients et de serveurs. Son originalité réside, en partie, dans le fait qu'il utilise un SGBD libre (MySQL, PostgreSQL) pour gérer le catalogue des sauvegardes, ce qui lui permet de gérer largement plus d'un milliard d'objets sans dégradation des performances.

Un autre avantage de Bacula est qu'il sait piloter et utiliser des périphériques de stockage professionnels, tels que les robots à bandes (Bibliothèque de bande (en)). Disponible sur de nombreuses plate-formes, ce logiciel est assez largement utilisé dans l'industrie, l'éducation et même dans le milieu bancaire. (source Wikipedia)

La version de Bacula présente dans les dépôt Debian n'est plus du tout à jour… (2.4.4). Pour remédier à ce problème nous allons ajouter un backports à notre “/etc/apt/sources.list”.

Pour se faire nous devons insérer la source adéquate.

echo "deb http://www.backports.org/debian lenny-backports main contrib non-free" >> /etc/apt/sources.list

Mise à jour d'APT pour qu'il prenne en charge notre nouvelle source.

# aptitude update

A la suite de cette commande, APT va râler parce qu'il ne trouve pas la signature GPG du dépôt.
La résolution de ce problème est on ne peut plus simple, elle consiste à installer un paquet contenant la clé GPG.

# aptitude install debian-backports-keyring

Site officiel : http://httpd.apache.org/ Dernière version : 2.2.15

Comme vous vous doutez, ici nous parlerons du serveur web Apache dans sa version 2.0, j'utilise cette version depuis quasiment mes débuts sous Linux.
Les puristes iront dire que la version 1.3 est plus rapide et blablabla, et je le concède (mais de pas grand chose).
Pour ma part je trouve cette version “obsolète” (voila comment se mettre des gens à dos ^^). Pour information la version 2.2 existe déjà depuis pas mal de temps.

Apache n'est pas le seul dans ce domaine sous Linux mais je ne vous parlerai pas de autres.
Alors pourquoi ai-je choisi Apache et pas un autre ?

• La documentation (pas tout le temps en français) est complète et assez simple à comprendre.
• Des modules à profusions et parfois fort sympatiques comme nous le verrons par la suite.
• L'existance d'une communauté française active ce qui est plutôt agrèable quand un problème récurant survient.

L'installation est simple, le serveur sera préparé pour recevoir le support PHP.

Informations sur le paquet apache2 se trouvant dans Sarge :

13:21 root@serveur ~# aptitude show apache2
Paquet : apache2
État: installé
Automatiquement installé: non
Version : 2.0.54-5sarge1
Priorité : optionnel
Section : web
Responsable : Debian Apache Maintainers <debian-apache@lists.debian.org>
Taille décompressée : 81,9k
Dépend: apache2-mpm-worker (= 2.0.54-5sarge1) | apache2-mpm-prefork (= 2.0.54-5sarge1) | apache2-mpm-perchild (=
        2.0.54-5sarge1)
Fourni par : apache2-mpm-worker, apache2-mpm-prefork, apache2-mpm-perchild
Description : next generation, scalable, extendable web server
 Apache v2 is the next generation of the omnipresent Apache web server. This version - a total rewrite - introduces many
 new improvements, such as threading, a new API, IPv6 support, request/response filtering, and more.

Passons à l'installation :

# aptitude install apache2-common apache2-mpm-prefork apache2-threaded-dev

• apache2-common installe le système de base.
• apache2-mpm-prefork est requis pour le fonctionnement de PHP sur cette version du serveur web.
• apache2-threaded-dev fournit des options comme a2enmod a2ensite, etc…

Résultat :

13:42 root@serveur ~# aptitude install apache2 apache2-mpm-prefork apache2-threaded-dev
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
0 mis à jour, 0 nouvellement installés, 3 réinstallés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 0o/406ko dans les archives.
Après dépaquetage, 0o d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer ? [O/n]
(Lecture de la base de données... 31595 fichiers et répertoires déjà installés.)
Préparation du remplacement de apache2 2.0.54-5sarge1 (en utilisant .../apache2_2.0.54-5sarge1_i386.deb) ...
Dépaquetage de la mise à jour de apache2 ...
Préparation du remplacement de apache2-mpm-prefork 2.0.54-5sarge1 (en utilisant .../apache2-mpm-prefork_2.0.54-5sarge1_i386.deb) ...
Dépaquetage de la mise à jour de apache2-mpm-prefork ...
Préparation du remplacement de apache2-threaded-dev 2.0.54-5sarge1 (en utilisant .../apache2-threaded-dev_2.0.54-5sarge1_i386.deb) ...
Dépaquetage de la mise à jour de apache2-threaded-dev ...
Paramétrage de apache2-mpm-prefork (2.0.54-5sarge1) ...
Starting web server: Apache2.

Paramétrage de apache2-threaded-dev (2.0.54-5sarge1) ...
Paramétrage de apache2 (2.0.54-5sarge1) ...

Si vous ne comptez pas utiliser PHP sur le serveur le MPM worker suffira.

13:42 root@serveur ~# aptitude show apache2-mpm-worker
Paquet : apache2-mpm-worker
État: non installé
Version : 2.0.54-5sarge1
Priorité : optionnel
Section : net
Responsable : Debian Apache Maintainers <debian-apache@lists.debian.org>
Taille décompressée : 504k
Dépend: libapr0 (>= 2.0.54), libc6 (>= 2.3.2.ds1-21), libdb4.2, libexpat1 (>= 1.95.8), libldap2 (>= 2.1.17-1), libpcre3 (>= 4.5), libssl0.9.7, zlib1g (>=
        1:1.2.1), apache2-common (= 2.0.54-5sarge1)
Est en conflit: apache2-mpm-prefork, apache2-mpm-perchild
Remplace: apache2-mpm-threadpool (< 2.0.53)
Fournit: httpd-cgi, httpd, apache2, apache2-modules
Description : high speed threaded model for Apache2
 The worker MPM provides a threaded implementation for Apache2. It is considerably faster than the traditional model, and is the recommended MPM.

 Worker generally is a good choice for high-traffic servers because it has a smaller memory footprint than the prefork MPM.

Voila donc ça c'est fait. :)
Pour finir, je vous propose quelques commandes qui vous seront utiles.

• Pour relancer le service :

# /etc/init.d/apache2 restart

• Pour faire relire le fichier configuration :

# /etc/init.d/apache2 reload

• Pour arrêter le service :

# /etc/init.d/apache2 stop

• Pour démarrer le service :

# /etc/init.d/apache2 start

• Pour connaître le status du service :

# /etc/init.d/apache2 status

• Pour activer un module (installé) :

# a2enmod lemod

• Pour désactiver un module :

# a2dismod lemod

• Pour activer un site :

# a2ensite lesite

• Pour désactiver un site :

# a2dissite lesite

eAccelerator est un système de cache d'op-codes. Euh mais un op-code c'est quoi ?

Op-code signifie “opération-code”. A l'issue d'une compilation, le code PHP est transformé en listes d'instructions élémentaires destinées à être exécutées. Ces listes d'instructions sont précisément appelées “tableaux d'op-codes”. En d'autres termes, les op-codes sont un intermédiaire entre le code PHP que nous connaissons et les instructions du processeur, bien que plus proches des instructions processeur que du code PHP original.

Source : Magazine Programmez N°92 (Décembre 2006).

L'utilisation d'un système de cache va optimiser des étapes redondantes telles que le parsing ou la compilation de vos scripts PHP.
La mise en cache permet de produire des tableaux d'op-codes identiques jusqu'à modification de votre script, ces tableaux seront stockés dans la mémoire vive ou sur le disque dur et seront appelés lors de la seconde exécution de votre script.

En général l'utilisation d'un système de cache augmente de 3 à 4 fois la vitesse d'exécution de vos scripts, cependant ne pensez pas que ce genre de pratique réglera tous vos problèmes car un script mal écrit le restera toujours même avec un système de cache.

eAccelerator est basé sur l'extension MMCache.

Il n'y a pas encore de paquet pour la version 5 de PHP, nous allons donc travailler à partir des sources.
L'installation est assez simple rassurez-vous. ;)

Afin de pouvoir compiler eAccelerator nous allons avoir besoin des paquets “php5-dev” et “make” qui contiennent les outils nécessaires, notamment phpize.
Une petite vérification de sa présence sur le dépôt.

# aptitude show php5-dev

Résultat :

16:28 root@serveur ~# aptitude show php5-dev
Paquet : php5-dev
Nouveau: oui
État: installé
Automatiquement installé: non
Version : 5.2.1-0.dotdeb.1
Priorité : optionnel
Section : devel
Responsable : Guillaume Plessis <gui@php.net>
Taille décompressée : 3113k
Dépend: autoconf, automake1.4, libssl-dev, libtool, shtool, php5-common (>= 5.2.1-0.dotdeb.1)
Description : Files for PHP5 module development
 This package provides the files from the PHP5 source needed for compiling additional modules.

 PHP5 is an HTML-embedded scripting language. Much of its syntax is borrowed from C, Java and Perl with a couple of
 unique PHP-specific features thrown in. The goal of the language is to allow web developers to write dynamically
 generated pages quickly.

Installation des paquets.

# aptitude install php5-dev make

Une fois le paquet installé, nous allons passer au téléchargement des sources d'eAccelerator pour l'installer, actuellement la version du programme est 0.9.5.3.

# cd /usr/src/
# wget http://bart.eaccelerator.net/source/0.9.5.3/eaccelerator-0.9.5.3.tar.bz2

Une fois les sources téléchargées on les décompresse (le paquet bzip2 est nécessaire pour décompresser un .bz2).

# tar xvjf eaccelerator-0.9.5.3.tar.bz2

Nous obtenons un répertoire eaccelerator-0.9.5.3, plaçons-nous dedans et commençons l'installation.
phpize va générer les fichiers nécessaires à la compilation.

# /usr/bin/phpize

Résultat :

16:37 root@serveur /usr/src/eaccelerator-0.9.5.3# /usr/bin/phpize
Configuring for:
PHP Api Version:         20041225
Zend Module Api No:      20060613
Zend Extension Api No:   220060519

Une fois le fichier configure généré nous pouvons passer à la configuration de la compile, toujours dans le même répertoire.

# ./configure --enable-eaccelerator=shared --with-eaccelerator-sessions --with-eaccelerator-optimizer --with-eaccelerator-info --with-php-config=/usr/bin/php-config

# ./configure --enable-eaccelerator=shared --with-eaccelerator-info --with-php-config=/usr/bin/php-config

La configuration est quand à elle un peu plus complexe car une mauvaise configuration peut contrairement à l'effet espéré dégrader les performances !
Tout se passe dans le fichier de configuration de PHP à savoir php.ini qui se trouve dans /etc/php5/apache2/, ouvrez-le puis ajoutez-y ceci à la fin :

extension="eaccelerator.so"
eaccelerator.shm_size           = "32"
eaccelerator.cache_dir          = "/var/www/eaccelerator"
eaccelerator.enable             = "1"
eaccelerator.optimizer          = "1"
eaccelerator.check_mtime        = "1"
eaccelerator.debug              = "0"
eaccelerator.filter             = ""
eaccelerator.shm_max            = "1M"
eaccelerator.shm_ttl            = "0"
eaccelerator.shm_prune_period   = "0"
eaccelerator.shm_only           = "0"
eaccelerator.compress           = "1"
eaccelerator.compress_level     = "9"
eaccelerator.keys               = "shm_and_disk"
eaccelerator.sessions           = "shm_and_disk"
eaccelerator.content            = "shm_and_disk"
eaccelerator.allowed_admin_path = "/var/www/"
eaccelerator.log_file           = "/var/log/apache2/eaccelerator.log"

Maintenant on créé le répertoire qui accueillera le contenu du cache.

# mkdir /var/www/eaccelerator
# chown www-data:www-data /var/www/eaccelerator
# chmod 755 /var/www/eaccelerator

Explications :

• extension=“eaccelerator.so” déclare l'ajout de la librairie à PHP, si cette ligne est commentée eAccelerator ne sera pas lancé.
• eaccelerator.shm_size = “32” détermine le total de mémoire en méga que eAccelerator peut utiliser.
• eaccelerator.cache_dir = ”/var/www/eaccelerator” indique le répertoire contenant le cache.
• eaccelerator.enable = “1” active le système de cache, 0 désactive eAccelerator.
• eaccelerator.optimizer = “1” active l'optimizer interne, 0 le désactive.
• eaccelerator.check_mtime = “1” permet de vérifier les fichiers PHP modifiés et ainsi les mettre de nouveau en cache avec les modifications effectuées.
• eaccelerator.filter = ”“ indique le type de fichier qui devront être mis en cache, exemple “*.php *.phps *.phtml”.
• eaccelerator.debug = “0” désactive le mode debug.
• eaccelerator.shm_max = “1M” interdit la mise en mémoire partagé des fichiers supérieurs à 1Mo.
• eaccelerator.shm_ttl = “0” ne supprime aucun fichier qui n'a pas eu accès à la mémoire partagé.
• eaccelerator.shm_prune_period = “0” n'essaye pas de supprimer les scripts qui n'ont pas eu accès à la mémoire partagé (à vérifier).
• eaccelerator.shm_only = “0” autorise l'accès à la mémoire vive et au disque dur, si la valeur est à 1 alors eAccelerator n'a accès qu'à la mémoire vive.
• eaccelerator.compress = “1” active la compression, 0 la désactive.
• eaccelerator.compress_level = “9” détermine le niveau de compression, 9 est le maximum.
• eaccelerator.keys = “shm_and_disk” autorise la mise en cache des clés sur le disque dur et dans la mémoire vive.
• eaccelerator.sessions = “shm_and_disk” autorise la mise en cache des sessions sur le disque dur et dans la mémoire vive.
• eaccelerator.content = “shm_and_disk” autorise la mise en cache du contenu sur le disque dur et dans la mémoire vive.
• eaccelerator.log_file = /var/log/apache2/eaccelerator.log créé un fichier de log pour eAccelerator.

Relancez Apache.

# /etc/init.d/apache2 restart

En allant sur la page infos.php vous devriez voir apparaître ceci :

with eAccelerator v0.9.5.3, Copyright (c) 2004-2008 eAccelerator, by eAccelerator

Si ce n'est pas le cas vérifiez que la librairie soit bien déclarée dans le php.ini

Le panneau de contrôle d'eAccelerator consiste en une page PHP, cette page se trouve dans le répertoire eaccelerator-0.9.5.3 sous le nom control.php, placez cette page dans /var/www/ par exemple.
Il faut absolument ajouter la directive suivante dans le php.ini auquel cas une erreur sera affichée :

eaccelerator.allowed_admin_path = "/var/www/

• eaccelerator.allowed_admin_path = ”/var/www/ indique le répertoire ou sera placée la page control.php qui permet l'administration d'eAccelerator.

/var/www/ détermine le répertoire ou se trouvera la page control.php
Pour accéder à cette page un mot de passe est demandé, vous pouvez le modifier en éditant la page control.php

Relancez Apache si vous venez de l'ajouter.

# /etc/init.d/apache2 restart

Voila à quoi vous attendre :

Si vous avez besoin de mémoire supplémentaire pour l'utilisation de vos scripts, vous pouvez augmenter la taille de la valeur eaccelerator.shm_size qui se trouve dans php.ini
Exemple :

eaccelerator.shm_size = "64"

Pour que cela fonctionne, il faut que la taille demandée soit inférieure ou égale à la taille de segment de mémoire partagé configurée au niveau noyau.

Vérifiez la taille actuelle.

# cat /proc/sys/kernel/shmmax

Résultat :

# 67108864

Si le résultat retourné est 33554432 alors il faut modifier le paramètre suivant dans /etc/sysctl.conf

kernel.shmmax = 67108864

Ou de façon temporaire :

# echo 67108864 > /proc/sys/kernel/shmmax

Merci Calimero pour cette précision.

Le wiki GZW est un récit de mon expérience dans le monde de l'hébergement web (Web Hosting dans la langue de Shakespear).

En effet depuis maintenant plusieurs années je m'occupe de la plate-forme GoldZone Web Hosting et je peux vous assurer que c'est le meilleur moyen d'apprendre !

Je vais essayer de vous éviter les pièges dans lesquels je suis tombés, de vous souffler des optimisations sympathiques, de vous faire découvrir des applications (je l'espère) et pleins d'autres bonnes choses.

Toute mes indications seront basées sur un système Linux et pour être plus précis la distribution Debian GNU/Linux dans sa version Lenny, je vous rassure il n'y a que peu de différences au niveau de la configuration suivant la distribution que vous utilisez (emplacement des fichiers de configuration, version des paquets, etc…)

Un forum en guise de support est disponible sur le forum officiel GoLDZoNE Web HoSTING à l'adresse suivante : http://forum.goldzoneweb.info
Avant de commencer j'espère que vous êtes motivé(e) et que vous avez une machine à café près de vous.

• Administration système.
  • Debian GNU/Linux, Red Hat Entreprise Linux, AIX, FreeBSD
• Serveur web.
  • Apache, SuExec, Virtualhost basique, Virtualhost dynamique, SSL, CGI
  • Modules Apache : Evasive, Cband, Security, Deflate, Layout, FCGID, Mono, WSGI
  • Langages : PHP, Ruby, Python, Perl
• Serveur de messageries.
  • Postfix, Courier, Nullmailer, Amavis, SpamAssassin, Policyd, SASL, Webmail, SSL/TLS, Perdition
• Serveur de noms.
  • Bind, Création d'une zone, Résolution inverse, Outils de vérification, Réplication de zone
• Systèmes de monitoring.
  • Nagios, Centreon, Hddtemp, PhpSysinfo, Smartd, Mailgraph, Ganglia, Mytop, AWStats
• Systèmes de sauvegardes.
  • Rsync, Mysqldump, Bacula, Time Navigator
• Systèmes de protection.
  • IPTables, AIDE, Rootkit Hunter, chkrootkit
• Serveurs de bases de données.
  • MySQL, PostgreSQL, Sybase, Oracle
• Serveurs de transferts de fichiers.
  • ProFTPd, Tranferts FXP, Quotas, SSL/TLS
  • Modules ProFTPd : Ban
• Système de versioning.
  • Subversion, Trac, Redmine, GIT
• Système de haute disponibilité.
  • Heartbeat, DRBD, Réplication MySQL, Cluster NFS, SAN, Round Robin DNS, Channel Bonding, Pacemaker
• Applications web.
  • PhpMyAdmin, PhpPgAdmin, Postfix Admin, ProFTPd Administrator, OCS Inventory NG, Panel-GZW
• Serveur de déploiement.
  • Cobbler, Puppet, Koan, Versioning
• Virtualisation.
  • Xen, KVM, VMWare ESX, VMWare Tools, Proxmox
• Changelog.
  • 2006, 2009, 2010

GoldZone Web 2005 - 2010

L'installation de Rootkit hunter (rkhunter) n'a rien de compliqué, en effet le paquet est disponible dans les dépôts Debian.

# aptitude install rkhunter

La version présente dans les dépôts ne sera pas à jour, il est donc nécessaire de le faire soit même.

# rkhunter --update

19:34 root@serveur ~# rkhunter --update
[ Rootkit Hunter version 1.3.2 ]

Checking rkhunter data files...
  Checking file mirrors.dat                                  [ No update ]
  Checking file programs_bad.dat                             [ No update ]
  Checking file backdoorports.dat                            [ No update ]
  Checking file suspscan.dat                                 [ No update ]
  Checking file i18n/cn                                      [ No update ]
  Checking file i18n/en                                      [ No update ]
  Checking file i18n/zh                                      [ No update ]
  Checking file i18n/zh.utf8                                 [ No update ]

Pour effectuer une analyse complète de votre système, il suffit de taper la commande suivante.

# rkhunter -c

Pour plus d'informations sur l'utilisation de Rootkit hunter :

# rkhunter --help

Si lors du scan vous obtenez le message suivant, pas de panique !

/usr/sbin/unhide                                  [ Warning ]
/usr/sbin/unhide-linux26                          [ Warning ]

Il suffit de lancer la commande suivante :

# rkhunter --propupd

Résultat d'un check avec Rkhunter.

Voir le changelog.

L'installation de chkrootkit n'a rien de compliqué, en effet le paquet est disponible dans les dépôts Debian.

# aptitude install chkrootkit

Pour effectuer une analyse complète de votre système, il suffit de taper la commande suivante.

# chkrootkit

Pour plus d'informations sur l'utilisation de chkrootkit :

# chkrootkit -h

Résultat d'un check avec chkrootkit.

Voir le changelog au complet.

PhpSysInfo est une application PHP qui permet d'obtenir des informations sur le serveur (OS, Matériel, t°, Ram, Disques, etc…)
Ce n'est pas un outil indispensable mais bon c'est fun.

La paquet phpsysinfo se trouve dans les dépôts Debian cependant ce n'est toujours pas la version finale (3.0rc6).

# aptitude install phpsysinfo

Avec la version 2.5.1 la configuration pouvait se faire à l'aide de la commande “dpkg-reconfigure”, désormais la configuration s'effectue directement dans le fichier “/etc/phpsysinfo/config.php”.

Modification de la langue :

define('lang', 'fr');

Affichage du virtualhost utilisé par PhpSysInfo :

define('useVhost', true);

Affichage de la température du serveur (nécessite l'installation de lm-sensors, autrement laissez sur ”false”) :

define('sensorProgram', 'lmsensors');

Afficher les systèmes de fichiers montés avec l'option ”bind” (comme pour une ISO par exemple) :

define('showBind', true);

Cacher la présence de certains points de montage (NFS par exemple) :

define('hideMounts', '/media/nfs1');

Cacher la présence d'une interface réseau : define('hideNetworkInterface', 'sit0');</code>

Afficher la température des disques durs (nécessite l'installation de hddtemp) :

define('hddTemp', 'tcp');

Afficher une barre représentant la charge du serveur (attention c'est un peu plus gourmand en ressources) :

define('loadBar', true);

Afficher des répertoires ou sont installés des applications (ou autres) :

define('addPaths', '/opt','/opt/tomcat');

Pour accéder à PhpSysinfo : http://adresse-du-serveur/phpsysinfo

Voir le changelog complet.

Installation du système de sauvegarde.
Configuration du système de sauvegarde.
Installation du service de sauvegarde sur les clients.

• Juillet 2010.
  • Mise à jour du tutorial sur Bind.
  • Rédaction de ”Nullmailer”.

• Janvier 2009.
  • Publication du tutorial.
• Juillet 2010.
  • Ajout d'information au sujet d'un TTL pour un enregistrement de type A.
  • Ajout d'information sur la prise en charge d'un enregistrement SPF.

Une zone DNS est un fichier ou se trouve les enregistrements d'un domaine. Les enregistrements sont les liens entre les adresses IP et les noms, cela sert donc à la résolution de nom. Nous verrons plus bas qu'il existe aussi la résolution inverse.

Comme indiqué ici, les zones DNS doivent se trouver dans le répertoire “/var/cache/bind/”, cela n'est pas obligatoire bien sûr mais autant rester le plus proche de la configuration initiales. Pour chaque nom de domaine un fichier de zone devra être créé, le fichier de configuration “named.conf.local” devra être lui aussi renseigné avant que Bind prenne en compte le nouveau domaine.

Dans une zone nous allons trouver plusieurs types, ces types sont décrits juste en dessous.

$ORIGIN - Contient le nom de la zone (dans notre cas goldzoneweb.info), on fait appel à cette directive lorsque l'on souhaite utiliser des noms non qualifiés (qui ne se finissent par par un point (.) Nous pouvons donc remplacer ceci :

webmail.goldzoneweb.info.       IN      A       192.168.0.65

webmail                         IN      A       192.168.0.65

Je vous conseille de l'ajouter à vos zones DNS même si vous utilisez des noms qualifiés.

$TTL (Time To Live) - En général cette valeur est associée à un nombre, 86400. Ce dernier est en secondes ce qui fait 24 heures. Au bout de ces 24 heures le cache du serveur sera réinitialisé.
Pour rappel, dans une zone DNS il est possible de définir une durée de validité pour chaque enregistrement, si cette durée n'est pas définie alors ça sera la valeur de $TTL qui sera utilisée.

webmail.goldzoneweb.info.   3600    IN      A       192.168.0.65

Il est possible de préciser les valeurs autrement qu'en secondes, dans le tableau ci-dessous vous pouvez voir que l'on peut utiliser : des heures, des jours, des mois, des semaines et même des années !!

Source : http://www.linux-kheops.com

SOA (Start Of Authority) définit les paramètres globaux d'une zone, il ne peut y avoir qu'un seul enregistrement SOA par zone.
Cette enregistrement comporte plusieurs directives :

• @ - Cette arobase contient le nom de la zone renseignée dans le fichier “named.conf.local”. On pourrait la remplacer par le nom de domaine en question (goldzoneweb.info).

• ns1.goldzoneweb.info. - C'est le FQDN du serveur de noms. A la fin se trouve un ., ce dernier est d'une extrême importance il ne faut donc pas l'oublier !!

• goldyfruit.free.fr. - C'est l'adresse email du responsable du domaine, notez bien que l'arobase (@) a été remplacée par un point (.). Comme ci-dessus ne pas oublier le . à la fin.

• Serial - A chaque mise à jour de la zone le numéro de série doit être modifié, la RFC préconise la façon suivante : AAAA MM JJ NO (Année Mois Jour Numéro) soit 2009012702 (02 représente la deuxième modification de la zone).

• Refresh - Indique au bout de combien de temps (en seconde) le serveur DNS esclave tente de rafraîchir la zone se trouvant sur le serveur DNS maître. Si le numéro de série est différent alors la zone sera transférée.

• Retry - Intervalle de temps (en seconde) avant que le serveur DNS esclave tente de rafraîchir la zone se trouvant sur le serveur DNS maître après un raté (uniquement lorsqu'un “Refresh” a échoué).

• Expire - Intervalle de temps (en seconde) avant que le serveur DNS esclave considère le serveur DNS maître comme mort. Il devient donc autoritaire (responsable) de la zone jusqu'à ce que le serveur DNS maître réapparaisse.

• TTL Minimum - Intervalle de temps (en seconde) qui détermine la durée de vie minimum du cache.

Ce qui donnerait :

$TTL 86400
@       IN      SOA     ns1.goldzoneweb.info. goldyfruit.free.fr. (
                     2009012801         ; Numéro de série / Serial.
                           3600         ; Rafraîchissement / Refresh.
                            900         ; Nouvelle tentative / Retry.
                        1209600         ; Expiration / Expire.
                          86400 )       ; Durée cache minimum / TTL Minimum.

Refresh, Retry et Expire sont des limites de temps. Ces limites vont permettre au serveur DNS esclave de savoir quoi faire en cas de non-réponse du serveur DNS maître.

Littérairement parlant cela veut dire :

• Une fois le délai de Refresh atteint, le serveur DNS esclave va contacter le serveur DNS maître pour avoir des informations sur le numéro de série de la zone.
  
• Si cette prise de contact échoue alors le serveur DNS esclave essaiera à nouveau de contacter le serveur DNS maître à la fin du délai Retry.
  
• Si il n'y arrive toujours pas alors le serveur DNS maître sera considéré comme hors-ligne une fois le délai Expire atteint.

A (Address) - Ce champ permet de faire la correspondance un nom et une adresse IP. Ce qui veut dire dans notre cas que lorsque nous taperons l'adresse http://webmail.goldzoneweb.info nous atterrirons sur le serveur web 192.168.0.65.

webmail                         IN      A       192.168.0.65

webmail.goldzoneweb.info.       IN      A       192.168.0.65

Il est aussi possible d'indiquer un TTL à un enregistrement A.

webmail.goldzoneweb.info.       1H     IN      A       192.168.0.65

IN (INternet) - Ce champ permet d'indiquer que c'est une zone dédiée à l'internet. Il n'est pas obligatoire de la placer dans chaque enregistrement, à vous de voir.

webmail.goldzoneweb.info.       IN      A       192.168.0.65

webmail.goldzoneweb.info.               A       192.168.0.65

NS (Name Server) - Ce champ permet de définir les serveurs ayant autorités sur la zone. Serveur DNS primaire, secondaire, tertiaire, etc…

goldzoneweb.info.       IN      NS       ns1.goldzoneweb.info.

                        IN      NS       ns1.goldzoneweb.info.

@                       IN      NS       ns1.goldzoneweb.info.

ns1.goldzoneweb.info.   IN       A       192.168.0.5

ns2.goldzoneweb.info.   IN       A       10.0.0.5

ns3.goldzoneweb.info.   IN       A       172.22.2.5

MX (Mail EXchanger) - Ce champs permet de définir les serveurs de messageries qui seront utilisés pour le nom de domaine. En règle générale deux serveurs de messageries suffisent, cependant il est nécessaire de préciser une priorité par MX.

Avant de déclarer les enregistrement MX il est nécessaire de créer deux sous-domaines (enregistrement A)

mx01.goldzoneweb.info.       IN      A       192.168.0.30
mx02.goldzoneweb.info.       IN      A       192.168.0.31
@                            IN      MX      10       mx01.goldzoneweb.info.
@                            IN      MX      20       mx02.goldzoneweb.info.

PTR (PoinTeR) - Ce champ permet d'effectuer une résolution de nom inverse, à partir de l'adresse IP nous obtenons le nom du serveur.

La résolution de nom inverse est une zone à part entière, nous verrons cela un peu plus tard.

65                              IN      PTR       webmail.goldzoneweb.info.

65                                      PTR       webmail.goldzoneweb.info.

65.0.168.192                    IN      PTR       webmail.goldzoneweb.info.

SRV (SeRVices) - Ce champ permet de spécifier l'emplacement d'un service ainsi que son port présents sur un serveur. Il permet de faire la même chose que le champ MX pour le SMTP mais aussi pour tous les autres services.

Une liste des services supportés est disponible ici : http://www.dns-sd.org/ServiceTypes.html

_postgresql._tcp                        SRV     0      1      5432       pgsql01.goldzoneweb.info.

Un enregistrement SRV contient les informations suivantes :

• Service: le nom symbolique du service concerné.
• Protocole: généralement, c'est soit TCP, soit UDP.
• Nom de domaine: le domaine de validité de l'enregistrement.
• TTL: champ standard DNS indiquant la durée de validité (Time-To-Live, durée de vie) de la réponse.
• Classe: champ standard DNS indiquant la classe (c'est toujours IN).
• Priorité: la priorité du serveur cible.
• Poids: poids relatif pour les enregistrements de même priorité.
• Port: le port TCP ou UDP où le service est disponible.
• Cible: le nom du serveur qui fournit le service concerné.

Source Wikipedia

TXT (TeXTe) - Ce champ permet entre autre de définir un enregistrement SPF (Sender Policy Framework).

goldzoneweb.info.               IN      TXT       "v=spf1 ip4:192.168.0.30 ip4:192.168.0.31 a mx ptr mx:mx01.goldzoneweb.info mx:mx02.goldzoneweb.info ~all"

SPF (Sender Policy Framework) - Ce champ permet de fournir un enregistrement SPF (voir ci-dessus) nécessaire aux serveurs de messagerie.

goldzoneweb.info.               IN      SPF       "v=spf1 ip4:192.168.0.30 ip4:192.168.0.31 a mx ptr mx:mx01.goldzoneweb.info mx:mx02.goldzoneweb.info ~all"

/!\ ATTENTION /!\ : Le champ SPF n'est pas accepté par tous les serveurs (1and1 par exemple), la zone ne sera pas transférée si le serveur distant ne l'accepte pas.

HINFO (Hardware INFO) - Ce champ permet de fournir des informations au sujet du serveur DNS. Il doit fournir des informations sur l'architecture matériel ainsi que sur le système d'exploitation.

goldzoneweb.info.               IN      HINFO       "Intel Core 2 Duo" "Debian GNU/Linux Lenny"

CNAME (Canonical NAME) - Ce champ permet de créer un alias sur un domaine ou sous-domaine déjà existant.

www                             IN      CNAME       goldzoneweb.info

imap                            IN      CNAME       goldzoneweb.info

ssh                             IN      CNAME       goldzoneweb.info

ssh                                     CNAME       goldzoneweb.info

Le principe du wildcard permet de ne pas avoir à créer un enregistrement pour chaque sous-domaine. Imaginez que vous avez plus de 1000 sites web hébergés sous le domaine “.goldzoneweb.info”, vous allez vraiment ajouter les 1000 enregistrements dans votre zone DNS ?

NON !!

Vous allez ajouter un enregistrement avec un ”joker” (*), ce joker permet de prendre en compte tout ce qui se trouve avant “.goldzoneweb.info”.

*.goldzoneweb.info.                 IN      A        192.168.0.64

Voici un petit exemple de tout ce que nous avons vu précédemment. Ce fichier représente une zone DNS pour le nom de domaine ”goldzoneweb.info”. Un fichier “db.goldzoneweb.info.conf” a été créé dans le répertoire “/var/cache/bind/”

$ORIGIN goldzoneweb.info.
$TTL 86400 ; Durée maximale du cache.
@       IN      SOA     ns1.goldzoneweb.info. goldyfruit.free.fr. (
                     2009012801         ; Numéro de série. (Serial)
                           3600         ; Rafraîchissement. (Refresh)
                            900         ; Nouvelle tentative. (Retry)
                        1209600         ; Expiration. (Expire)
                          86400 )       ; Durée cache minimum. (TTL Minimum)
 
;------------------------
; Enregistrements NS.
;------------------------
; Serveurs de noms.
@                                   IN      NS       ns1.goldzoneweb.info.
@                                   IN      NS       ns2.goldzoneweb.info.
@                                   IN      NS       ns3.goldzoneweb.info.
 
;------------------------
; Enregistrements MX.
;------------------------
; Serveurs de messageries.
@                                   IN      MX       10       mx01.goldzoneweb.info.
@                                   IN      MX       20       mx02.goldzoneweb.info.
 
;------------------------
; Enregistrement TXT et HINFO.
;------------------------
goldzoneweb.info.                   IN      TXT      "v=spf1 ip4:192.168.0.30 ip4:192.168.0.31 a mx ptr mx:mx01.goldzoneweb.info mx:mx02.goldzoneweb.info ~all"
goldzoneweb.info.                   IN      HINFO    "Intel Core 2 Duo" "Debian GNU/Linux Lenny"
 
;------------------------
; Ajout du joker (wildcard).
;------------------------
*.goldzoneweb.info.                 IN      A        192.168.0.64
 
;------------------------
; Enregistrements A.
;------------------------
; Serveurs de noms.
ns1.goldzoneweb.info.               IN      A        192.168.0.5
ns2.goldzoneweb.info.               IN      A        10.0.0.5
ns3.goldzoneweb.info.               IN      A        172.22.2.5
 
; Serveurs de messageries.
mx01.goldzoneweb.info.              IN      A        192.168.0.30
mx02.goldzoneweb.info.              IN      A        192.168.0.31
 
; Sous-domaines.
goldzoneweb.info.                   IN      A        192.168.0.64
webmail.goldzoneweb.info.           IN      A        192.168.0.65
webftp.goldzoneweb.info.            IN      A        192.168.0.66
mysql-manager.goldzoneweb.info.     IN      A        192.168.0.67
pgsql-manager.goldzoneweb.info.     IN      A        192.168.0.68
 
;------------------------
; Enregistrements CNAME.
;------------------------
; Alias.
www                                 IN      CNAME    goldzoneweb.info.
ftp                                 IN      CNAME    goldzoneweb.info.
ssh                                 IN      CNAME    goldzoneweb.info.
pop                                 IN      CNAME    webmail.goldzoneweb.info.
sql01                               IN      CNAME    mysql.goldzoneweb.info.

Ne surtout pas oublier de relancer le service Bind afin que les modifications soient prises en compte.

# rndc reload

Voir le changelog complet.

Après chaque modification, il est nécessaire de relancer le service Bind.

# rndc reload

La commande “rndc” est normalement la ”seule” commande à utiliser pour administrer Bind. Toutes les distributions permettent de démarrer/arrêter/relancer le service via le script présent dans l'initd et cela fonctionne; cependant garder à l'esprit que “rndc” fournie plusieurs options et que c'est la méthode la plus sûr (nous verrons pourquoi plus tard).

# rndc --help

Bind possède plusieurs fichiers de configuration (sous Debian tout du moins), ces fichiers se trouvent dans le répertoire “/etc/bind/”. En voici la liste (non-exhaustive):

• /etc/bind/named.conf
• /etc/bind/named.conf.local
• /etc/bind/named.conf.options

- Le fichier “named.conf” contient la configuration par générale de Bind.

- Le fichier “named.conf.local” doit contenir toutes les déclarations de zone. En effet dès qu'une zone (nous en reparlerons plus tard ici) est créée ce fichier doit être mis à jour afin d'inclure cette zone dans la configuration de Bind.

- Le fichier “named.conf.options” va contenir toutes les options citées ici (récursivité, forwarding, etc…), les ACL (que nous verrons ici), les vues, la gestion des logs (que nous verrons aussi ici), etc…

Comme indiqué juste au dessus, lorsque une zone DNS est créée il est nécessaire de la déclarer dans le fichier “/etc/bind/named.conf.local”. Ce fichier est découpé en sections (options et zone).

zone "goldzoneweb.info" {
	type master;
	file "goldzoneweb.info.conf";
};

Ce qui veut dire que la zone s'appelle ”goldzoneweb.info”, elle est de type ”master” et fait appel au fichier ”goldzoneweb.info.conf”.

Par défaut Bind va chercher les zones dans le répertoire “/var/cache/bind/” via la directive “directory ”/var/cache/bind”;” présente dans le fichier “named.conf.options”, si la zone se trouve ailleurs il est nécessaire d'indiquer le chemin complet vers cette dernière. Comme par exemple :

file "/etc/bind/zones/goldzoneweb.info.conf";

Une zone peut-être de type “master”, “slave”, “stub” ou “forward”.

• master : Indique à Bind qu'il est autoritaire sur la zone.
• slave : Inquique à Bind qu'il n'est pas autoritaire sur la zone.
• stub : Indique à Bind qu'il n'est pas autoritaire sur la zone et qu'il ne doit répliquer que les serveurs de noms et non la totalité de la zone.
• forward : Indique à Bind qu'il doit rediriger les requêtes de la zone vers un autre serveur DNS (cf. forwarders).

Bind est capable de transférer la zone dont il est autoritaire (master) vers des serveurs DNS secondaires (slave).

zone "goldzoneweb.info" {
	type master;
	file "goldzoneweb.info.conf";
        allow-transfer { 192.168.0.10; };
        notify yes;
};

La directive “allow-transfer” permet le transfert d'une zone vers un serveur DNS esclave (ici 192.168.0.10). Si vous souhaitez envoyer la zone sur plusieurs serveurs la syntaxe exacte est la suivante :

allow-transfer { 192.168.0.10; 10.11.2.65; };

Bind possède deux protocoles de transfert :

• AXFR : Protocole par défaut, il est utilisé pour envoyer la totalité de la zone vers les serveurs esclaves.
• IXFR : Ce protocole n'envoie que les modifications effectuées sur la zone, l'avantage est un transfert peu gourmand en bande passante. N'est utilisable uniquement avec le Dynamic DNS (DDNS).

La directive “allow-query” autorise (ou pas) un serveur distant à effectuer une ou plusieurs requêtes DNS (pour obtenir la version du version, le SOA, etc…) sur notre serveur.
La valeur de cette option sera différente dans le cas d'un serveur DNS local d'entreprise et dans le cas d'un serveur DNS internet.

Si les restrictions de votre serveur dédié à l'internet sont trop bloquantes, un site tel que l'AFNIC vous dira que votre serveur est mal configuré car il n'arrivera pas à récupérer les informations dont il a besoin pour valider votre configuration.

Configuration d'une zone DNS dédiée à l'internet.

zone "goldzoneweb.info" {
	type master;
	file "goldzoneweb.info.conf";
        allow-transfer { 192.168.0.10; };
        notify yes;
        allow-query { any; };
};

Vous pouvez voir le mot clés “any” qui signifie que le serveur accepte toutes les requêtes, certains diront que ce n'est pas la meilleure solution (et ils n'auront pas tout à fait tord) mais comment être sûr que les adresses IP des serveurs de l'AFNIC par exemple ne changeront pas ?

Configuration d'une zone DNS dédiée à l'intranet.

zone "goldzoneweb.info" {
	type master;
	file "goldzoneweb.info.conf";
        allow-transfer { 192.168.0.10; };
        notify yes;
        allow-query { 192.168.0.10; 192.168.0.11 };
};

Ici nous autorisons les serveurs DNS “192.168.0.10” et “192.168.0.11” à envoyer des requêtes à notre serveur, ces serveurs font partis de notre intranet il n'y a donc pas de gros risques.

Pour interdire les requêtes DNS il suffit d'ajouter le mot clés “none”.

allow-query { none; };

Ne surtout pas oublier de relancer le service Bind afin que les modifications soient prises en compte.

# rndc reload

Voir le changelog complet.

Nullmailer est un utilitaire qui permet de rediriger les mails envoyés depuis un serveur (Apache ou MySQL par exemple) vers un serveur de messageries de type Postfix, Exim ou autre MTA.

Cette solution vous permet de raccorder rapidement et simplement un serveur à une plate-forme de messagerie.

Nullmailer est disponible dans les dépôts Debian, cela va donc nous faciliter son installation.

# aptitude install nullmailer

La configuration se fait lors de l'installation du paquet. Debconf vous affiche ceci à l'écran :

Ce nom doit-être identique à celui présent dans le fichier “/etc/mailname”.

Cette fenêtre vous demande l'adresse IP ou DNS du serveur de messagerie.

Cette option évite que les emails destinés à l'administrateur soit mis en attente dans la ”queue” du MTA. Ils seront envoyés tout de suite.
Vous pouvez donc entrer l'adresse suivante : admin@goldzoneweb.info ou laisser le champ vide.

Une fois la configuration terminée normalement le service “nullmailer” se lance automatiquement. Si ce n'est pas le cas :

# /etc/init.d/nullmailer restart

Résultat :

Stopping mail-transfer-agent: nullmailer.
Starting mail-transfer-agent: nullmailer.

Dans le fichier “/var/log/syslog” vous devriez voir ceci apparaître :

Jul 20 11:59:09 backup01 nullmailer[5960]: Rescanning queue.

Les fichiers de configuration de Nullmailer se trouvent dans le répertoire “/etc/nullmailer/”. Un petit “ls” dans ce répertoire nous montres qu'il existe deux fichiers :

• remote
• adminaddr

Dans le fichier “remote” se trouve notre serveur de messagerie. Il faut savoir qu'il est possible d'ajouter plusieurs serveurs de messageries dans ce fichier.

# cat /etc/nullmailer/remote

Résultat :

mail.goldzoneweb.info
mail2.goldzoneweb.info

Dans le fichier “adminaddr” se trouve l'adresse email de notre tendre et cher administrateur système .

# cat /etc/nullmailer/adminaddr

Résultat :

admin@goldzoneweb.info

Après envoie d'un message vous devriez avoir quelque chose comme cela dans le fichier “/var/log/syslog” :

Jul 20 13:15:05 backup01 nullmailer[6209]: Rescanning queue.
Jul 20 13:15:22 backup01 nullmailer[6209]: Trigger pulled.
Jul 20 13:15:22 backup01 nullmailer[6209]: Rescanning queue.
Jul 20 13:15:22 backup01 nullmailer[6209]: Starting delivery: protocol: smtp host: mail.goldzoneweb.info file: 1279624521.6219
Jul 20 13:15:22 backup01 nullmailer[6220]: smtp: Failed: 554 5.7.1 <bob.leponge@goldzoneweb.info>: Relay access denied
Jul 20 13:15:22 backup01 nullmailer[6209]: Sending failed:  Permanent error in sending the message
Jul 20 13:15:22 backup01 nullmailer[6209]: Starting delivery: protocol: smtp host: mail2.goldzoneweb.info file: 1279624521.6219
Jul 20 13:15:23 backup01 nullmailer[6221]: smtp: Succeeded: 250 2.0.0 Ok: queued as 5A3172B6002
Jul 20 13:15:23 backup01 nullmailer[6209]: Sent file.
Jul 20 13:15:23 backup01 nullmailer[6209]: Delivery complete, 0 message(s) remain.

Nullmailer permet de modifier l'adresse de l'émetteur d'un mail.

Exemple d'un envoie de mail sous l'utilisateur système “root” :

# env | mail -s "Environnement de l'utilisateur système root" bob.leponge@goldzoneweb.info

Dans le fichier “/var/log/syslog” on peut voir que le message a bien été envoyé depuis root@goldzoneweb.info.

Jul 20 13:29:17 newton postfix/qmgr[7910]: 6C16CE8B91: from=<root@goldzoneweb.info>, size=803, nrcpt=1 (queue active)
Jul 20 13:29:17 newton postfix/smtpd[28481]: disconnect from mail.goldzoneweb.info[000.000.000.000]
Jul 20 13:29:18 newton postfix/smtp[28486]: 6C16CE8B91: to=<bob.leponge@goldzoneweb.info>, relay=mail.goldzoneweb.info[000.000.000.000]:25, delay=0.68, delays=0.01/0.01/0.24/0.42, dsn=2.0.0, status=sent (250 2.0.0 OK 1279625357 x28si7902893wbx.64)

Jusque là rien de bien méchant n'est-ce pas ? Et bien détrompez-vous, cela peut rapidement poser problème si la boîte root@goldzoneweb.info n'existe pas sur le serveur.

Exemple du message d'erreur :

<root@goldzoneweb.info>: Recipient address rejected: User unknown in virtual mailbox table;

Pour résoudre cela il suffit de renseigner le fichier “/etc/environment” dans lequel nous lui indiquons deux nouvelles variables d'environnement.

NULLMAILER_SUSER="robot"
NULLMAILER_SHOST="goldzoneweb.info"

Désormais lorsqu'un message sera envoyé depuis le système (et si rien n'est précisé dans les en-têtes), il aura pour émetteur robot@goldzoneweb.info.

from=<robot@goldzoneweb.info> to=<bob.leponge@goldzoneweb.info> proto=SMTP helo=<goldzoneweb.info>

Il est nécessaire de relancer le service pour que les modifications soient prises en compte.

# /etc/init.d/nullmailer restart

Le principe de ce mod est assez sympa et couplé à IPTables il peut être vraiment efficace.
Il est permet de limiter la casse en cas d'attaque de type DDoS ou de brute force et tout autres attaques de ce type.

Ca mise en place est simple et il en est de même pour sa configuration.

Evasive n'est pas installé par défaut avec Apache, à nous de le compiler.

On télécharge les sources.

# wget http://www.zdziarski.com/projects/mod_evasive/mod_evasive_1.10.1.tar.gz

Une fois l'archive décompressée, on se place dans le répertoire obtenu puis on lance la compilation de celui-ci.

# apxs2 -cia mod_evasive20.c

Résultat :

3:08 root@serveur ~/mod_evasive# apxs2 -cia mod_evasive20.c
/usr/bin/libtool --silent --mode=compile gcc -prefer-pic -pipe -I/usr/include/xmltok -I/usr/include/openssl -Wall -O2 -DAP_HAVE_DESIGNATED_INITIALIZER -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -pipe -I/usr/include/xmltok -I/usr/include/openssl -Wall -O2 -pthread -I/usr/include/apache2  -I/usr/include/apr-0   -I/usr/include/apr-0 -I/usr/include  -c -o mod_evasive20.lo mod_evasive20.c && touch mod_evasive20.slo
mod_evasive20.c: In function `create_hit_list':
mod_evasive20.c:118: warning: control reaches end of non-void function
mod_evasive20.c: In function `access_checker':
mod_evasive20.c:212: warning: implicit declaration of function `getpid'
mod_evasive20.c:212: warning: long int format, int arg (arg 3)
mod_evasive20.c: In function `destroy_hit_list':
mod_evasive20.c:301: warning: control reaches end of non-void function
/usr/bin/libtool --silent --mode=link gcc -o mod_evasive20.la  -rpath /usr/lib/apache2/modules -module -avoid-version    mod_evasive20.lo
/usr/share/apache2/build/instdso.sh SH_LIBTOOL='/usr/bin/libtool' mod_evasive20.la /usr/lib/apache2/modules
/usr/bin/libtool --mode=install cp mod_evasive20.la /usr/lib/apache2/modules/
cp .libs/mod_evasive20.so /usr/lib/apache2/modules/mod_evasive20.so
cp .libs/mod_evasive20.lai /usr/lib/apache2/modules/mod_evasive20.la
cp .libs/mod_evasive20.a /usr/lib/apache2/modules/mod_evasive20.a
ranlib /usr/lib/apache2/modules/mod_evasive20.a
chmod 644 /usr/lib/apache2/modules/mod_evasive20.a
PATH="$PATH:/sbin" ldconfig -n /usr/lib/apache2/modules
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/lib/apache2/modules

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,--rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
chmod 644 /usr/lib/apache2/modules/mod_evasive20.so
[activating module `evasive20' in /etc/apache2/httpd.conf]

Voila, la compilation est terminée.
Maintenant nous allons créer un fichier mod_evasive.load dans /etc/apache2/mods-available/ pour y ajouter ceci :

LoadModule evasive20_module   /usr/lib/apache2/modules/mod_evasive20.so

Dans /etc/apache2/httpd.conf la ligne suivant est à supprimer :

LoadModule evasive20_module   /usr/lib/apache2/modules/mod_evasive20.so

Chargement du module Evasive.

# a2enmod mod_evasive

L'installation du module Evasive est terminée, c'était simple non ?

Dans /etc/apache2/conf.d/ nous allons créer un fichier evasive.conf contenant ceci :

<IfModule mod_evasive20.c>
 
# Taille de la table.
DOSHashTableSize 2048
 
# Nombre de même pages visibles par la même IP.
DOSPageCount 2
 
# Nombre de même sites visibles par la même IP.
DOSSiteCount 50
 
# Intervalle autorisant l'affichage de la même page par la même adresse.
DOSPageInterval 1
 
# Intervalle autorisant l'affichage du même site par la même adresse.
DOSSiteInterval 1
 
# Durée de blocage.
DOSBlockingPeriod 10
 
# Adresse email de notification en cas d'attaque.
DOSEmailNotify "adresse@email.com"
 
# Destination du log.
DOSLogDir "/var/log/evasive/"
 
# Bannissement de l'IP en cas de bloquage.
#DOSSystemCommand "/sbin/iptables -I INPUT -s %s -j DROP"
 
# Liste blanche.
DOSWhiteiLt 127.0.0.1
 
</IfModule>

Les valeurs données dans cette exemple sont à adapater selon votre serveur.

DOSSystemCommand "/sbin/iptables -I INPUT -s %s -j DROP"

Pour que l'adresse IP soit ajoutée à IPTables il est nécessaire que l'utilisateur “www-data” ait les droits pour manipuler IPTables (via sudo par exemple).

Explications :

• DOSHashTableSize Size of the hash table. The greater this setting, the more memory is required for the look up table, but also the faster the look ups are processed. This option will automatically round up to the nearest prime number.
• DOSPageCount définie le nombre de fois ou une page peut être appelée par la même adresse IP avant que celle-ci soit bloquée.
• DOSSiteCount définie le nombre de fois ou un site peut être demandé par la même adresse IP avant que celle-ci soit bloquée.
• DOSPageInterval détermine un interval en seconde qui autorise l'affichage de la même page avant un bloquage.
• DOSSiteInterval détermine un interval en seconde qui autorise l'affichage de d'un même site avant un bloquage.
• DOSBlockingPeriod détermine la durée de bloquage.
• DOSEmailNotify permet qu'un email soit envoyé à chaque bloquage d'adresses IP.
• DOSSystemCommand permet de définir une commande bien précise en cas d'attaque (bannissement de l'adresse IP dans IPTables par exemple).
• DOSLogDir détermine le chemin ou seront stockés les logs d'attaques.
• DOSWhiteList définie une liste blanche d'adresse IP.

Apache ne sait pas créer le répertoire /var/log/evasive/ tout seul, nous allons donc l'aider.

# mkdir /var/log/evasive

Il est nécessaire de placer les bons droits sur le répertoire qui vient d'être créé autrement Apache remplira le “syslog” du message suivant :

mod_evasive[17111]: Couldn't open logfile /var/log/evasive/dos-10.11.2.7: Permission denied

# chown www-data:www-data /var/log/evasive

La configuration est terminée, il ne reste plus qu'à relancer Apache.

# /etc/init.d/apache2 reload

Un script écrit en Perl permet de tester votre installation. Il nous faut donc créer un fichier test-evasive.pl contanant ceci :

#!/usr/bin/perl
 
# test.pl: small script to test mod_dosevasive's effectiveness
 
use IO::Socket;
use strict;
 
for(0..100) {
  my($response);
  my($SOCKET) = new IO::Socket::INET( Proto   => "tcp",
                                      PeerAddr=> "127.0.0.1:80");
  if (! defined $SOCKET) { die $!; }
  print $SOCKET "GET /?$_ HTTP/1.0\n\n";
  $response = <$SOCKET>;
  print $response;
  close($SOCKET);
}

Source du code : http://tools.web4host.net/modevasive/test.txt

On le rend exécutable.

# chmod +x test-evasive.pl

Puis on commence le test (l'option DOSWhiteLt 127.0.0.1 doit être commentée).

# ./test-evasive.pl

Le résultat est visible sur cette page.

Mise en place d'un cluster NFS à l'aide de Heartbeat et DRBD.

La solution suivante permet d'obtenir un partage NFS haute disponibilité. Cela peut être nécessaire dans le cas d'une grappe de cluster web par exemple, ou plusieurs serveurs Apache ont leurs “DocumentRoot” sur le serveur NFS.

En plus de la redondance, les données sont centralisées et donc plus facile à sauvegarder.

Pour mettre cela en œuvre nous avons utilisé les applications suivantes :

1. Heartbeat 2.1.4.
2. DRBD 8.2.6.
3. NFS supportant le protocole v4.
4. RedHat EL 5.2.

Une partition de 300Mo a été créée sur les deux serveurs, cette dernière et non-formatée et non-montée. Les partitions doivent-être de la même taille !!
Elle sera utilisée par DRBD sous le nom ”/dev/drbd0”, elle sera partagée entre les deux serveurs.

Dessus se trouveront le contenu du répertoire ”/var/lib/nfs” ainsi qu'un répertoire “partage”.

1. Le contenu du répertoire ”/var/lib/nfs” doit être déposé sur la partition ”/dev/drbd0” afin que les deux serveurs NFS aient exactement les mêmes informations (etab, xtab, etc…).

1. Le répertoire “partage” contient les informations à partager.

Nos deux serveurs, l'adresse IP virtuelle, le client :

1. heartbeat1 - 10.11.2.45
2. heartbeat2 - 10.11.2.48
3. client - 10.11.2.50
4. cluster - 10.11.2.65

Ces informations sont à indiquer dans le fichier ”/etc/hosts” de chaque serveur.

Actuellement aucun paquet RPM n'est disponible pour la version 8.2.6 de DRBD. Il suffit d'aller sur le site officiel puis de télécharger les sources.
Une fois téléchargée et décompressée, il suffit de créer un paquet de la façon suivante :

# cd drdb-2.6
# make
# make rpm

Des paquets sont crées sous le répertoire “dist/i386”, il suffit d'installer les paquets “drbd-8.2.6-3” et “drbd-km-2.6.18_92.1.17”.
Le paquet “drdb-km” est un module pour le noyau, il permet par exemple de recueillir des informations dans ”/proc/drbd” sur le statut du disque ”/dev/drbd0”.

Ne pas oublier de charger le module.

# depmod -a
# modprobe drbd

Pour être sur que le module soit bien chargé, on utilise la commande “lsmod | grep drbd”. Cette dernière doit retourner une ligne.
Aux prochains reboot, le module sera chargé automatiquement.

Passons à la configuration de DRBD, le fichier se trouve dans ”/etc/” et il a pour nom “drbd.conf”.

global {
            minor-count 1;
}

resource nfs { # Nom de notre ressource, ici c'est "nfs".
            protocol C; # Il y a trois protocoles, A, B et C.

            #incon-degr-cmd "echo 'DRBD Degraded!' | wall; sleep 60 ; halt -f"; # Si le partage est considérait comme défectueux, un message sera envoyé à  tout les utilisateurs connectés. 60 secondes après l'envoi du message, le système reboot.

            # DRBD sur le serveur "heartbeat1".
            on heartbeat1 {
                        device /dev/drbd0; # Le nom de notre device "drdb".
                        disk /dev/sda2;    # Partition physique utilisée sur le serveur "heartbeat1".
                        address 10.11.2.45:7788; # Adresse IP du serveur "heartbeat1" et port sur lequel sera écouté DRBD.
                        meta-disk internal; # Stocke les meta-data sur le disque système.
            }

            # DRBD sur le serveur "heartbeat2".
            on heartbeat2 {
                        device /dev/drbd0; # Le nom de notre device "drdb", doit-être identique à  celui sur "heartbeat1".
                        disk /dev/sda2;    # Partition physique utilisée sur le serveur "heartbeat1".
                        address 10.11.2.48:7788; # Adresse IP du serveur "heartbeat1" et port sur lequel sera écouté DRBD.
                        meta-disk internal; # Stocke les meta-data sur le disque système.
            }

            disk {
                        on-io-error panic; # Si le de disque "/dev/drdb0" est défectueux on bascule sur l'autre serveur.
            }

            net {
                        max-buffers 2048; # Mise en cache avant écriture sur le disque.
                        ko-count 4; # Le partage est annulé si cette valeur est dépassée.
                        #on-disconnect reconnect; # Si le partage est déconnecté alors on essaye de se reconnecter.
            }

            syncer {
                        rate 10M; # Vitesse de synchronisation entre les deux serveurs (en méga).
                        al-extents 257; # Un extents est égal à  4Mo, cette option définie la taille de la hot-area qui est utilisée pour inscrire les meta-data. Nécessaire à  une re-synchronisation en cas de crash d'un des deux disques.
            }

            startup {
                        wfc-timeout 0; # Temps d'attente du deuxième au lancement du daemon "drbd" (en seconde).
                        degr-wfc-timeout 120; # Temps d'attente du deuxième nœud en cas de crash (en seconde).
            }
}

Le fichier “drbd.conf” doit-être identique sur les deux serveurs.

Maintenance la configuration de DRBD est terminée, nous allons créer la zone des meta-data sur “heartbeat1” via la commande :

# drbdadm create-md nfs

On lance le service sur “heartbeat1”.

# /etc/init.d/drbd start

Lors du lancement DRBD va indiquer qu'il ne trouve pas le second disque (“heartbeat2”), il va alors se mettre en attente jusqu'à ce que le serveur “heartbeat2” soit configuré.
Nous allons donc taper “yes” pour quitter l'attente.

Pour vérifier que le disque a bien été configuré, il suffit d'aller vérifier le contenu du fichier ”/proc/drbd”, il doit être en “secondary” comme ci-dessous :

            0: cs:Connected st:Secondary/Unconfigured ds:UpToDate/UpToDate C r---

Sur le serveur “heartbeat2”, nous allons effectuer la même manipulation que celle sur le serveur “heartbeat1” à savoir :

# drbdadm create-md nfs

Ce qui doit retourner le contenu suivant (”/proc/drbd”):

            version: 8.2.6 (api:88/proto:86-88)
            GIT-hash: 3e69822d3bb4920a8c1bfdf7d647169eba7d2eb4 build by root@heartbeat1, 2008-11-05 10:58:09
             0: cs:Connected st:Secondary/Secondary ds:UpToDate/UpToDate C r---
                ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 oos:0

Les meta-data ont été initialisées sur les deux disques, il est maintenant nécessaire d'indiquer un disque primaire. Nous allons faire du disque ”/dev/drbd0” sur le serveur “heartbeat1” un disque primaire.

# drbdadm -- --overwrite-data-of-peer primary nfs

Dès lors, la synchronisation entre les deux disques s'effectue. Vous pouvez voir en temps réel cette synchronisation via la commande :

# watch cat /proc/drbd

Quand la synchronisation sera terminée, vous devriez avoir le résultat suivant (”/proc/drbd.conf”):

            version: 8.2.6 (api:88/proto:86-88)
            GIT-hash: 3e69822d3bb4920a8c1bfdf7d647169eba7d2eb4 build by root@heartbeat1, 2008-11-05 10:58:09
             0: cs:Connected st:Primary/Secondary ds:UpToDate/UpToDate C r---
                ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 oos:0

DRDB est désormais installé et configuré.

Pour pouvoir utiliser la partition ”/dev/drdb0” il est nécessaire de la formater. Nous allons la formater en “ext3” (il est possible de le faire en “reiserfs”).
Bien sûr il est nécessaire d'utiliser un système de fichiers journalisé. La commande est à exécuter depuis le serveur “heartbeat1”.

# mkfs.ext3 -L nfs /dev/drbd0

Si vous essayez d'exécuter la commande ci-dessus sur le serveur “heartbeat2” vous aurez droit au message d'erreur qui suit :

mkfs.ext3: Wrong medium type while trying to determine filesystem size

Cela est du au fait que le serveur “heartbeat1” est primaire et que “heartbeat2” est secondaire donc en lecture seule !!

Une fois la partition formaté, on monte cette dernière dans le répertoire ”/data” par exemple puis on créé un fichier via la commande “touch”.

# mkdir /data
# mount /dev/drbd0 /data
# cd /data
# touch test_drdb

On démonte la partition ”/dev/drbd0” puis en la passe en seconde sur le serveur “heartbeat1” et en primaire sur le serveur “heartbeat2”.

# cd ~
# umount /data
# drbdadm secondary nfs

Sur le serveur “heartbeat2” on passe la partition ”/dev/drbd0” en primaire puis on la monte dans le répertoire ”/data”.

# drbdadm primary nfs
# mkdir /data
# mount /dev/drbd0 /data
# cd /data

Dans le répertoire ”/data” nous devrions voir le fichier “test_drbd”, si tel est le cas à la synchronisation entre les deux disques s'est effectuée avec succès.

Voilà , DRBD est fonctionnel !!

Sous RedHat EL 5.2 il est nécessaire de modifier deux fichiers avant de pouvoir déplacer le contenu du répertoire ”/var/lib/nfs” vers la partition ”/dev/drbd0”.

Les fichiers à modifier sont les suivants :

1. /etc/modprobe.d/modprobe.conf.dist

Ligne 125 : Remplacer ”/var/lib/nfs/rpc_pipefs” par ”/var/lib/rpc_pipefs”.

                      Ligne 139 : Remplacer "/var/lib/nfs/rpc_pipefs" par "/var/lib/rpc_pipefs".

1. /etc/idmapd.conf

Ligne 4 : Remplacer “Pipefs-Directory = /var/lib/nfs/rpc_pipefs” par “Pipefs-Directory = /var/lib/rpc_pipefs”.

Arrêt de tout les services NFS et démontage de “rpc_pipefs”. Le montage système “rpc_pipefs” est automatiquement monté à chaque démarrage du serveur par le module “sunrpc”.

# /etc/init.d/nfslock stop
# /etc/init.d/nfs stop
# /etc/init.d/rpcidmapd stop
# umount -a -t rpc_pipefs

Le répertoire “rpc_pipefs” présent dans ”/var/lib/nfs” est désormais inutilisé, on peut donc le déplacer vers ”/var/lib”. Une fois ce répertoire déplacé, on remonte “rpc_pipefs” dans son nouveau répertoire.

# mv /var/lib/nfs/rpc_pipefs /var/lib/
# mount -t rpc_pipefs sunrpc /var/lib/rpc_pipefs

On relance le service “rpcidmapd”.

# /etc/init.d/rpcidmapd start

Ces opérations sont effectuées automatiquement au démarrage du système, nous les effectuons à la main juste pour de simples tests. :)

On peut désormais déplacer le répertoire ”/var/lib/nfs” vers notre partition ”/dev/drbd0”. La partition est à monter sur le serveur “heartbeat1”, une fois le répertoire déplacé il faut créer un lien symbolique vers de ”/data/nfs” vers ”/var/lib/nfs”.

# mount /dev/drbd0 /data
# mv /var/lib/nfs /data/
# ln -sfn /data/nfs /var/lib/nfs

Le lien doit pointer comme ceci :

lrwxrwxrwx  1 root      root      12 nov  7 14:36 nfs -> /data/nfs

Sur le serveur “heartbeat2”, on supprime le répertoire ”/var/lib/nfs” puis on créé uniquement un lien comme ci-dessus.

# ln -sfn /data/nfs /var/lib/nfs

Sur les deux serveurs il est nécessaire de modifier le fichier ”/etc/sysconfig/nfs” afin de lui indiquer le nom ou l'adresse IP virtuelle de notre cluster.

A la fin du fichier ajouter ceci :

STATD_HOSTNAME=cluster

STATD_HOSTNAME=10.11.2.65

Il reste maintenant à partager le(s) répertoire(s) que nous voulons exporter. Dans notre cas à§a sera le répertoire ”/data/partage” qui sera partagé pour le client “10.11.2.50”. Cet export se configure dans le fichier ”/etc/exports” et est à faire sur les deux serveurs.

/data/partage           10.11.2.50(rw,sync)

Pour exporter le répertoire on tape la commande suivante :

# exportfs -av

Il est très important d'empêcher “nfs” et “nfslock” de se lancer automatiquement au démarrage du serveur car c'est à Heartbeat de le faire !!! Pour se faire on utilise la commande “chkconfig” :

# chkconfig nfs off
# chkconfig nfslock off

Ces actions sont à effectuer sur les deux serveurs.

La configuration du serveur NFS est terminée.

Heartbeat propose des paquets pour plusieurs distributions (RedHat, Debian,Suse, Mandriva, etc…), il suffit d'aller récupérer les trois paquets suivants sur leur site web.

1. heartbeat-stonith-2.1.4-2.1
2. heartbeat-pils-2.1.4-2.1
3. heartbeat-2.1.4-2.1

L'installation des paquets s'effectue via la commande RPM (ou Yum si vous avez un dépôt).

# rpm -ivh heartbeat*.rpm

La configuration de Heartbeat consiste à :

1. Indiquer les noeuds faisant partis du cluster.
2. Quelques options de bases.
3. Les actions à effectuer en cas de panne d'un des noeuds.
4. Le type de communication entre les deux serveurs.

Et se partage trois fichiers de configuration :

1. /etc/ha.d/ha.cf - Configuration globale de Heartbeat (nœuds, temps entre les battements, logs, etc…).
2. /etc/ha.d/authkeys - Configuration du chiffrement entre les nœuds.
3. /etc/ha.d/haresources - Actions à effectuer en cas de crash d'un des noeuds (service à démarrer, etc…).

La configuration doit-être identique sur tous les noeuds du cluster.

logfacility     local0 # Log dans le syslog.
keepalive       2 # Temps entre chaque battement (en seconde).
deadtime        10 # Temps avant qu'un noeud soit considéré comme mort
(en seconde).
bcast           eth0 # Interface sur laquelle est envoyé le broadcast.
node            heartbeat1 heartbeat2 # Serveurs présents dans le cluster.
autofailback             off # Le serveur maître ne reprend pas le contrôle une fois en ligne.
wartime                        5 # Au bout de 5 secondes sans battement une alerte sera envoyée dans les logs (en seconde).
initdead           60 # Fait passer le "daedtime" à  60 secondes au démarrage du serveur.

auth 2 # Méthode à  utiliser (en fonction avec le reste du fichier).
1 crc # Méthode peut sécurisé.
2 sha1 SuperPhraseDeLaMortQuiTue # Méthode très sécurisé.
3 md5 SuperPhrase # Méthode sécurisé.

# Serveur maître du cluster.
heartbeat1 \
            # Ressource "nfs" à  utiliser.
            drbddisk::nfs \
            # Montage de la partition "/dev/drbd0" en "ext3" dans le répertoire "/data".
            Filesystem::/dev/drbd0::/data::ext3 \
            # Exécution du script "killnfsd".
            killnfsd \
            # Lancement du service "nfs".
            nfs \
            # Lancement du service "nfslock".
            nfslock \
            # Effectue une pause de quelques secondes.
            Delay::3::0 \
            # Adresse IP virtuelle du cluster.
            IPaddr::10.11.2.65

killall -9 nfsd ; exit 0

Une fois le script créé, il faut le rendre exécutable.

# chmod +x /etc/ha.d/resource.d/killnfsd

Comme dit plus haut, la configuration est identique sur tout les noeuds du cluster, nous allons donc envoyer nos fichiers sur le serveur “heartbeat2” via la commande “scp” du protocole SSH.

# scp -r /etc/ha.d root@10.11.2.48:/etc/

Par défaut Heartbeat n'est pas lancé au démarrage du serveur. Pour remédier à ce problème il suffit de taper les commandes ci-dessous sur les deux serveurs :

# chkconfig --add heartbeat
# chkconfig --level 2345 heartbeat on

Le wiki GZW est un récit de mon expérience dans le monde de l'hébergement web (Web Hosting dans la langue de Shakespear).

En effet depuis maintenant plusieurs années je m'occupe de la plate-forme GoldZone Web Hosting et je peux vous assurer que c'est le meilleur moyen d'apprendre !

Je vais essayer de vous éviter les pièges dans lesquels je suis tombés, de vous souffler des optimisations sympathiques, de vous faire découvrir des applications (je l'espère) et pleins d'autres bonnes choses.

Toute mes indications seront basées sur un système Linux et pour être plus précis la distribution Debian GNU/Linux dans sa version Lenny, je vous rassure il n'y a que peu de différences au niveau de la configuration suivant la distribution que vous utilisez (emplacement des fichiers de configuration, version des paquets, etc…)

Un forum en guise de support est disponible sur le forum officiel GoLDZoNE Web HoSTING à l'adresse suivante : http://forum.goldzoneweb.info
Avant de commencer j'espère que vous êtes motivé(e) et que vous avez une machine à café près de vous.

• Administration système.
  • Debian GNU/Linux, Red Hat Entreprise Linux, AIX, FreeBSD
• Serveur web.
  • Apache, SuExec, Virtualhost basique, Virtualhost dynamique, SSL, CGI
  • Modules Apache : Evasive, Cband, Security, Deflate, Layout, FCGID, Mono, WSGI
  • Langages : PHP, Ruby, Python, Perl
• Serveur de messagerie.
  • Postfix, Courier, Amavis, SpamAssassin, Policyd, SASL, Webmail, SSL/TLS, Perdition
• Serveur de noms.
  • Bind, Création d'une zone, Résolution inverse, Outils de vérification, Réplication de zone
• Systèmes de monitoring.
  • Nagios, Centreon, Hddtemp, PhpSysinfo, Smartd, Mailgraph, Ganglia, Mytop, AWStats
• Systèmes de sauvegarde.
  • Rsync, Mysqldump, BackupPC, Bacula, Time Navigator
• Systèmes de protection.
  • IPTables, AIDE, Rootkit Hunter, chkrootkit
• Serveurs de bases de données.
  • MySQL, PostgreSQL, Sybase, Oracle
• Serveurs de transferts de fichiers.
  • ProFTPd, Tranferts FXP, Quotas, SSL/TLS
  • Modules ProFTPd : Ban
• Système de versioning.
  • Subversion, Trac, Redmine, GIT
• Système de haute disponibilité.
  • Heartbeat, DRBD, Réplication MySQL, Cluster NFS, SAN, Round Robin DNS, Channel Bonding, Pacemaker
• Applications web.
  • PhpMyAdmin, PhpPgAdmin, Postfix Admin, ProFTPd Administrator, OCS Inventory NG, Panel-GZW
• Serveur de déploiement.
  • Cobbler, Puppet, Koan, Versioning
• Virtualisation.
  • Xen, KVM, VMWare ESX, VMWare Tools, Proxmox
• Changelog.
  • 2006, 2009, 2010

GoldZone Web 2005 - 2010

Partionnement conseillé pour une plateforme d'hébergement.
Ajouter les dépots nécessaires à votre sources.list
Installation de paquets sympas.
Le petit aide mémoire des commandes utiles.
Deux, trois optimisations c'est toujours ça de gagné.
SSH ? C'est quoi ? Comment je l'utilise ? SSH
Sécuriser un minimum votre Sarge.
Compilation d'un noyau Linux avec le patch Grsecurity.
Mise en place des quotas système Linux.
Création d'un tunnel à l'aide de l'outil SSH.
Vider la mémoire swap sans redémarrer le serveur.
Réinstallation de tous les paquets présent sur le système.
Création de routes statiques sous Debian GNU/Linux.