Il parait que Diaspora commence à devenir sympathique... alors pourquoi ne pas essayer de l'installer chez soi ;) Le wiki officiel détaille l'installation de Diaspora sur FreeBSD, mais je trouve certains passages très confus, et l'utilisation de MySQL ou MariaDB n'est aucunement mentionnée. Personnellement j'utilise FreeBSD 9.2 avec des jails, je veux donc éviter Postgresql car ce dernier ne tourne pas en jail (à moins de modifier des paramètres, mais je n'ai pas très envie). Je suis donc parti sur MariaDB.

• Durée estimée : de 1h à 4h selon la méthode d'installation (pkng ou ports)
• Niveau : Avancé (bonne connaissance du sysadmin sous Linux, ainsi que de nginx et mysql)
• Pré requis: Un nom de domaine qui pointe sur le serveur (peut être fait avec le fichier hosts pour tester)

Aperçu

Le fonctionnement de Diaspora est détaillé sur le wiki. Voici un aperçu simplifié :

Le contenu statique, comme les images, est servi directement par nginx à partir du répertoire de l'application. Les contenus dynamiques en revanche sont traités par rails qui communique avec ses processus gérés par sidekiq à travers redis. Les données persistantes, comme les posts, les commentaires, sont stockés dans MySQL. Cela peut sembler compliqué, mais le schéma ci-dessus et la mise en place des composants rendra les choses plus évidentes.

Lire la suite de FreeBSD 9.2 + Jail + Diaspora + MariaDB + Nginx

Pour alimenter un peu mon blog, voici un petit retour d'expérience sur la mise en place d'un serveur Minecraft chez moi. Bon tout d'abord il y a des pré requis techniques, il faut un bon CPU et 2GB de RAM ou plus, car java le jeu est très gourmand. Chez moi j'utilise des jails sur mon serveur FreeBSD afin de tout séparer proprement, et j'utilise les ports car les packages binaires sur les dépôts officiels ne me conviennent pas.

Création de la jail

Je créé à l'aide de ezjail-admin une jail nommée minecraft avec l'IP 192.168.0.7 :

(hôte)# ezjail-admin create minecraft 're0|192.168.0.7'

Je démarre cette jail, je me connecte dessus afin de paramétrer le mot de passe root, puis je ferme tout :

(hôte) # ezjail-admin start minecraft
(hôte) # ezjail-admin console minecraft
(minecraft) # passwd
(minecraft) # exit
(hôte) exit

Je me connecte en SSH sur ma jail (si vous voulez vous connecter en root il faut mettre le PermitRootLogin à yes dans /etc/ssh/sshd_config de la jail au préalable) :

$ ssh root@192.168.0.7

J'installe pkg et portmaster, deux outils pour gérer mes ports plus facilement :

(minecraft) # cd /usr/ports/ports-mgmt/pkg
(minecraft) # make install clean
(minecraft) # pkg2ng
(minecraft) # cd /usr/ports/ports-mgmt/portmaster
(minecraft) # make install clean

Je paramètre mon make.conf :

(minecraft) # vi /etc/make.conf
WRKDIRPREFIX=           /var/ports
DISTDIR=                /var/ports/distfiles
PACKAGES=               /var/ports/packages
INDEXDIR=               /var/ports
WITHOUT_X11=            yes
OPTIONS_UNSET=X11
WITH_PKGNG=             yes

Notez qu'il est possible de modifier le template des jails, afin que les nouvelles jails aient automatiquement certains paramètres. Exemple depuis l'hôte : /usr/jails/newjail/etc/ssh/sshd_config.

Installation de Java

J'utilise OpenJDK7, car la version 8 est encore déconseillée aux utilisateurs finaux, et la compilation sera plus longue (car il va compiler aussi la 7). Le paquet Java officiel est également disponible dans les ports mais il fait appel à la couche de compatibilité Linux. C'est donc plus simple d'utiliser OpenJDK7 qui est natif.

(minecraft) # cd /usr/ports/java/openjdk7/
(minecraft) # make install clean

La compilation va être plutôt longue. Je laisse les options par défaut.

Récupération et lancement du serveur Minecraft

Je télécharge le serveur Minecraft depuis le site officiel :

(minecraft) # cd /root
(minecraft) # fetch https://s3.amazonaws.com/Minecraft.Download/versions/1.7.9/minecraft_server.1.7.9.jar

Note : Pour un maximum de sécurité il est recommandé de créer un utilisateur minecraft, avec son propre dossier /home afin d'exécuter le jeu. Dans ce tutoriel, pour faire simple, et puisque nous sommes dans une jail dédiée, je passe cette étape et fais tout en root.

(minecraft) # java -Xmx1024M -Xms1024M -jar minecraft_server.1.7.9.jar nogui

Après quelques secondes la carte est générée, et il est possible de se connecter à ce serveur depuis un autre poste qui exécute Minecraft. Pour leses connexions de l'extérieur il faut penser à rediriger le port 25565 depuis le routeur.

Performances

La compilation de Java a pris plus de 4h sur mon serveur à base d'Atom 32 bits à 1,6GHz, un temps non négligeable ! Pour l'exécution du .jar, il est possible de diminuer les paramètres mémoire, car mon serveur n'a que 1GB de RAM, je ne peux donc pas allouer 1GB au jeu sous peine de le faire tomber. J'ai utilisé java -Xmx512M -Xms512M -jar minecraft_server.1.7.9.jar nogui. A l’exécution, la commande top m'a montré que le système est très sollicité, le CPU est en moyenne a 50% de charge, avec des pointes à 100%.

Lorsque je joue sur ce serveur, j'observe d'importantes latences, avec des blocs qui ne disparaissent que 1 seconde après avoir été cassés, en résumé ce n'est pas vraiment jouable. Un Atom 32 bits + 1GB de ram n'est donc pas suffisant pour supporter un serveur Minecraft.

Conclusion

Il est très facile de faire un serveur Minecraft sur FreeBSD, même dans une jail, par contre les pré requis techniques sont plutôt importants. Un CPU 64 bits double cœur pas trop vieux et 2GB de RAM ou plus sont recommandés, surtout si vous prévoyez d'accueillir une dizaine de joueurs.

XEN n'est pas nouveau pour moi, j'en parlais sur ce blog en 2011. Mais à l'exception de la solution XenServer, c'était relativement obscur, compliqué, et déprécié par les distributions Linux au profil de solutions alternatives (KVM et LXC). Je pensais vraiment que Xen allait disparaitre ou sombrer dans l'oubli. En fait non car en 2014 non seulement XEN est toujours très utilisé (par exemple chez AWS, le cloud Amazon), mais il est en plus upstream dans le kernel Linux et géré par la Linux Fundation. Il est donc revenu en force dans toutes les distributions Linux. J'ai été surpris de constater que maintenant on peut l'installer et l'utiliser très facilement sur Debian Wheezy, je vais partager mon expérience sur cet article ;)

Notions Dom0 et DomU

Sur des hyperviseurs comme Hyper-V ou VMware nous sommes habitués à exécuter des machines virtuelles depuis l'hôte. Or sur XEN cette notion est différente, l'hôte devient une machine virtuelle XEN avec des privilèges d'administration nommée Dom0. Donc au démarrage votre serveur doit démarrer XEN et ensuite le Dom0 sur lequel vous vous connectez. On peut limiter la RAM et les vcpus de Dom0 comme pour les autres.

Les autres VMs que l'on va faire tourner sur XEN, et qui elles n'ont pas de privilèges particuliers, sont nommés DomU. Voici un schéma pour récapituler :

Dans le cas de cet article, le Dom0 est Debian Wheezy. Cela peut paraître assez abstrait comme ça, mais si vous le mettez en oeuvre, vous comprendrez !

Installation de Debian

L'installation se fait à partir d'une ISO tout à fait normale de Debian. Personnellement je suis parti sur une Wheezy amd64 en netinstall, donc la debian-7.4.0-amd64-netinst.iso. Il est possible d'utiliser LVM avec XEN, mais je préfère faire simple pour le moment, je choisis donc un partitionnement assisté avec tout dans une même partition.

Installation de XEN

Sur une Debian Wheezy fraichement installée, il suffit d'installer le paquet xen-hypervisor :

# apt-get install xen-hypervisor

Boot automatique sur Xen

Passer Xen en priorité dans grub :

# dpkg-divert --divert /etc/grub.d/08_linux_xen --rename /etc/grub.d/20_linux_xen
# update-grub

Configuration du réseau (bridge)

Il suffit de modifier le fichier /etc/network/interfaces pour avoir un Bridge. Exemple pour moi qui suis en DHCP :

#The loopback network interface
auto lo
iface lo inet loopback

iface eth0 inet manual

auto xenbr0
iface xenbr0 inet dhcp
   bridge_ports eth0

Note : Si comme moi vous faites vos essais dans VirtualBox, méfiance. Si on utilise déjà un pont dans VirtualBox, xenbr0 ne fonctionnera pas correctement (les domU peuvent pinger dom0 mais pas internet). J'ai pas mal bloqué sur ce problème et finalement la solution consiste à laisser VirtualBox en NAT.

Installation des Xen Tools

Xen-tools permet de créer facilement des domU à partir de templates, et c'est la solution la plus simple :

# apt-get install xen-tools

Configuration du template Xen Tools

On édite le fichier /etc/xen-tools/xen-tools.conf. Voici les lignes à modifier pour notre cas :

dir = /home/xen
size   = 10Gb      # Disk image size.
fs     = ext4     # use the EXT4 filesystem for the disk image.
bridge = xenbr0
ext4_options     = noatime,nodiratime,errors=remount-ro

Et voilà.

Déploiement d'un DomU Debian

Note : Il faut prendre soin de rebooter après les manipulations précédentes, afin d'avoir Xen et le Dom0 opérationnels avant d'aller plus loin.

Voici la commande pour créer un hôte de type Debian Wheezy qui sera nommé Wheezy :

# xen-create-image --hostname wheezy --dhcp --vcpus 1 --pygrub --dist wheezy

WARNING
-------

  You appear to have a missing vif-script, or network-script, in the
 Xen configuration file /etc/xen/xend-config.sxp.

  Please fix this and restart Xend, or your guests will not be able
 to use any networking!


General Information
--------------------
Hostname       :  wheezy
Distribution   :  wheezy
Mirror         :  http://ftp.fr.debian.org/debian/
Partitions     :  swap            128Mb (swap)
                  /               10Gb  (ext4)
Image type     :  full
Memory size    :  128Mb
Kernel path    :  /boot/vmlinuz-3.2.0-4-amd64
Initrd path    :  /boot/initrd.img-3.2.0-4-amd64

Networking Information
----------------------
IP Address     : DHCP [MAC: 00:16:3E:EB:96:45]


Creating swap on /dev/vg0/wheezy-swap
Done

Creating ext4 filesystem on /dev/vg0/wheezy-disk
Done
Installation method: debootstrap
Done

Running hooks
Done

No role scripts were specified.  Skipping

Creating Xen configuration file
Done

No role scripts were specified.  Skipping
Setting up root password
Generating a password for the new guest.
All done


Logfile produced at:
	 /var/log/xen-tools/wheezy.log

Installation Summary
---------------------
Hostname        :  wheezy
Distribution    :  wheezy
IP-Address(es)  :  dynamic
RSA Fingerprint :  83:21:28:49:d9:93:38:ae:5a:11:41:23:fa:3a:6e:05
Root Password   :  UzNRAZe4

Pour démarrer notre DomU :

# xm create wheezy.cfg 
Using config file "/etc/xen/wheezy.cfg".
Started domain wheezy (id=2)

Pour se connecter à ce DomU, deux possibilités : avec SSH si on connaît l'IP, ou avec la commande xm console :

# xm console wheezy

Pour en sortir, arrêter la VM, ou utiliser la combinaison CTRL+]

Pour arrêter le DomU depuis le Dom0, utiliser la commande xen-delete-image :

# xm destroy wheezy

Note : la commande xm destroy va provoquer l'arrêt brutal du domU.

Déploiement d'un DomU NetBSD

Bon un DomU en Debian c'était facile parce qu'on peut utiliser xen-tools qui automatise tout. Maintenant la même chose avec NetBSD, qu'il va falloir installer à la main. Tout d'abord, on télécharge et on extrait la version installable et la version normale de NetBSD version Xen :

# wget ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-6.1.3/amd64/binary/kernel/netbsd-INSTALL_XEN3_DOMU.gz
# wget ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-6.1.3/amd64/binary/kernel/netbsd-XEN3_DOMU.gz
# gunzip netbsd-INSTALL_XEN3_DOMU.gz
# gunzip netbsd-XEN3_DOMU.gz

Ensuite on doit créer un fichier une image qui servira de support de stockage pour le DomU :

# mkdir -p /home/xen/domains/netbsd
# dd if=/dev/zero of=/home/xen/domains/netbsd/disk.img bs=1 count=0 seek=10G

Création d'un fichier de configuration pour notre domU NetBSD (il est possible de copier celui du domU Wheezy précédemment créé pour aller plus vite puis le modifier) :

# vi /etc/xen/netbsd.cfg
kernel = "/root/netbsd-INSTALL_XEN3_DOMU"
memory = '128'
disk = [
'file:/home/xen/domains/netbsd/disk.img,xvda1,w';
]
name = 'netbsd'
dhcp = 'dhcp'
vif = [ 'mac=00:16:3E:EB:96:41,bridge=xenbr0' ]

On démarre notre domU NetBSD créé (cette fois l'argument c va directement connecter la console) :

# xm create -c netbsd.cfg

On obtient ceci :

Il faut maintenant procéder à une installation personnalisée, en sélectionnant uniquement base et system (pas besoin du kernel qui ne sera pas utilisé car GENERIC) et une source HTTP ou FTP (l'équivalent du netinstall) pour récupérer les paquets.

Si tout se passe bien :

Une fois l'installation terminée, il faut modifier le netbsd.cfg pour utiliser l'autre kernel :

# vi /etc/xen/netbsd.cfg
kernel = "/root/netbsd-XEN3_DOMU"

Il est maintenant possible de booter sur NetBSD :

# xm create -c netbsd.cfg

Conclusion

Xen est relativement simple à utiliser sur Debian Wheezy, grâce à Xen-tools qui facilite la création de domU à partir d'un template. Quand il s'agit de créer un domU "exotique" comme NetBSD, la procédure est un peu plus longue mais reste simple et logique. Il se positionne donc comme une solution intéressante pour les serveurs n'ayant pas le support de la virtualisation complète (Intel VT-X / AMD-V). Néanmoins lorsque ces instructions sont disponibles, les solutions alternatives telles que KVM ou ses concurrents propriétaires (Hyper-V, VMware...) me semblent toujours beaucoup plus simples à administrer et offrent des performances excellentes. Y a-t-il toujours un avenir à la paravirtualisation, qui est à mi chemin entre les containers (LXC, jails...) et la virtualisation complète ? A voir...

Mon bilan est positif sur l'utilisation, mais je me questionne toujours sur la pertinence de Xen en 2014.

Ressources

• How to install a NetBSD domU on a Linux host
• Xen on Debian - Wiki

Suite à la mise en place de FreeBSD sur mon serveur avec des jails, j'ai décidé d'héberger maniatux.fr dessus. Sur mon espace client OVH j'ai donc édité ma zone DNS afin de rediriger maniatux.fr chez moi (le A pour le blog et le MX pour les mails). Voilà à quoi ressemble le serveur, placé dans le meuble télé sous la BBox (qui a finalement accepté de rediriger mes ports) :

La classe non ? La carte mère mini-ITX avec processeur Intel Atom, alimentation 12V externe et disque dur 2,5" en SATA. Côté logiciel, j'utilise nginx + php-fpm sur la jail FreeBSD.

Pour le moment pas encore de HTTPS, mais je vais mettre cela en place prochainement. A bientôt !

EDIT : Et voilà le HTTPS est en place :)

EDIT : Oui je sais, FreeBSD 10 vient de sortir, je suis d'ailleurs l'un des auteurs de cette dépêche sur Linuxfr. Mais quand j'ai commencé à migrer mon serveur, c'était encore la 9.2 qui était stable. Et avec les jails et les ports je préfère éviter de tourner sur les versions non stables...

Puisque mon serveur perso n'est pas critique (je peux me permettre une coupure d'une journée) j'en profite changer l'OS assez souvent, en quête de la perle rare ou tout simplement pour apprendre de nouvelles choses. Actuellement mon serveur ne sert que pour Jabber et la messagerie, mais à terme j'aimerai récupérer l'hébergement de mon blog (web). Or je souhaite séparer la partie web et messagerie pour la sécurité. Pour cela plusieurs solutions :

• Utiliser 2 serveurs : très consommateur en énergie et prend plus de place.
• Utilisez Linux + KVM (virtualisation) : incompatible avec mon serveur (Atom 32 bits).
• Utiliser Linux + LXC ou Linux + OpenVZ : LXC déjà exploré j'ai envie d'autre chose.
• Utiliser FreeBSD + Jails : Ouais !!!

Schéma cible

Compilation vs packages binaires

Bien que mon serveur soit de faible puissance, j'ai choisi de compiler moi-même les ports. Pourquoi ? Simplement parce que les packages binaires sont trop basiques et n'incluent pas les options sont j'ai besoin. Exemple : pour le serveur web, j'avais besoin du support fpm pour php. Or le seul moyen pour avoir cela c'est de compiler soi-même le paquet php55 et activer l'option fpm. Avec le package binaire officiel, pas de fpm.

Hôte : TARDIS

L'hôte est FreeBSD 9.2 i386 installé en UFS, avec les rôles d'hôte pour les jails et serveur DNS (named). Pour l'instant uniquement du cache, on verra ultérieurement s'il y a besoin de déclarer des zones. Named est installé dans le système de base, donc aucune manipulation particulière à faire à part l'activer dans le rc.conf et commenter la petite ligne dans /var/named/etc/namedb/named.conf qui spécifie qu'il ne faut écouter qu'en 127.0.0.1. Pour gérer mes jails, j'utilise ezjail, un outil de fainéant qui permet non seulement de tout gérer très facilement, mais en plus de générer un template avec des montages dynamiques.

root@TARDIS:~ # jls

   JID  IP Address      Hostname                      Path

     1  192.168.0.4     xmpp                          /usr/jails/xmpp

     2  192.168.0.3     www                           /usr/jails/www

     3  192.168.0.2     mail                          /usr/jails/mail

Pour que toutes mes nouvelles jail utilisent le bon serveur DNS, il faut éditer le fichier /usr/jails/newjail/etc/resolv.conf et ajouter l'IP qui va bien.

Jail : mail

La jail mail est destinée à recevoir, stocker, envoyer des mails. J'utilise un backend sqlite que j'ai mis en place en suivant ce tutoriel très complet (légère adaptation à faire pour utiliser sqlite à la place de mysql). Il faut commencer par installer dovecot2 en activant le support sqlite. Puis on installe Postfix en activant aussi le support sqlite mais également l'authentification SASL via dovecot. Je voulais que mon serveur de messagerie puisse gérer plusieurs domaines, d'où mon choix d'une structure plus complexe avec un backend sql.

Lorsqu'un mail est reçu, il est traité par Postfix qui vérifie dans la base sqlite si le domaine existe bien. Si oui il le transmet alors à Dovecot qui va se charger de le stocker à l'emplacement qui va bien. Lorsqu'un utilisateur veut envoyer un mail, il le soumet à Postfix (submission 587) qui demande à Dovecot si l'utilisateur est authentifié. Tous les échanges sont sécurisés en STARTTLS.

Jail : www

La jail www est destinée à faire office de serveur web. Pour l'installation de php, il faut compiler php55 avec le support de fpm, mais aussi php55-extensions qui permet de supporter session, gd (requis par pluxml), et d'autres si besoin.

C'est sur cette jail que mon blog (maniatux.fr) sera bientôt rapatrié. L'adresse e-mail de contact sera elle rapatriée sur la jail précédente (mail) car comme je l'ai indiqué, je peux gérer plusieurs domaines. Pluxml étant très léger et sans base de données, le serveur devrait tenir.

Jail : xmpp

La jail xmpp est destinée à faire office de serveur Jabber. J'utilise une fois de plus Prosody, que j'ai couplé avec sqlite pour le stockage des comptes (je n'aime pas le stockage en clair dans /var/lib/prosody qui est utilisé par défaut). La mise en place a été assez compliquée car en cas d'erreur, Prosody refuse de démarrer mais n'indique pas pourquoi. J'ai du spécifier un emplacement pour les logs et mettre les bons droits dessus (chown -R prosody:wheel) afin d'avoir un debug. En fait il n'arrivait pas à écrire le pid. Pour pouvoir utiliser sqlite il faut installer le port luadbi avec l'option sqlite. Après avoir un peu bataillé, ça marche.

Charge système

root@TARDIS:~ # df -h

Filesystem             Size    Used   Avail Capacity  Mounted on

/dev/ada0p2            140G    2.5G    126G     2%    /

devfs                  1.0k    1.0k      0B   100%    /dev

devfs                  1.0k    1.0k      0B   100%    /var/named/dev

/usr/jails/basejail    140G    2.5G    126G     2%    /usr/jails/xmpp/basejail

devfs                  1.0k    1.0k      0B   100%    /usr/jails/xmpp/dev

fdescfs                1.0k    1.0k      0B   100%    /usr/jails/xmpp/dev/fd

procfs                 4.0k    4.0k      0B   100%    /usr/jails/xmpp/proc

/usr/jails/basejail    140G    2.5G    126G     2%    /usr/jails/www/basejail

devfs                  1.0k    1.0k      0B   100%    /usr/jails/www/dev

fdescfs                1.0k    1.0k      0B   100%    /usr/jails/www/dev/fd

procfs                 4.0k    4.0k      0B   100%    /usr/jails/www/proc

/usr/jails/basejail    140G    2.5G    126G     2%    /usr/jails/mail/basejail

devfs                  1.0k    1.0k      0B   100%    /usr/jails/mail/dev

fdescfs                1.0k    1.0k      0B   100%    /usr/jails/mail/dev/fd

procfs                 4.0k    4.0k      0B   100%    /usr/jails/mail/proc

L'espace disque utilisé est de 2,5GB, sachant que l'on compte le système de base, le template, et l'arbre de ports. C'est assez intéressant. Voyons maintenant la charge CPU et mémoire :

last pid: 12938;  load averages:  0.00,  0.00,  0.00    up 0+22:54:08  13:14:23

48 processes:  1 running, 47 sleeping

CPU:  1.1% user,  0.0% nice,  1.5% system,  0.2% interrupt, 97.2% idle

Mem: 55M Active, 216M Inact, 113M Wired, 69M Buf, 589M Free

Swap: 4096M Total, 4096M Free

En gros même avec 3 VPS le système est très peu sollicité : 55Mo de mémoire utilisé, et CPU à 3% de charge.

Supervision

Pour assurer la supervision j'utilise tout simplement logwatch. C'est un script qui génère un rapport et envoie régulièrement un mail qui indique l'espace disque, les connexions ssh, les tentatives infructueuses d'accès à certain services. Logwatch peut être installé à partir de /usr/ports/sysutils/logwatch. Ensuite il faut spécifier Output = mail dans le logwatch.conf et ajouter un cron (@daily /usr/local/sbin/logwatch.pl).

On peut soit installer logwatch sur l'hôte uniquement, soit le mettre sur chaque jail. J'ai choisi la deuxième option pour avoir plus de détails.

Sur le serveur mail, c'est Postfix qui est utilisé pour l'envoi du rapport. Par contre sur les autres jail, j'ai laissé sendmail. Il faut éditer le fichier /etc/mail/freebsd.mc puis spécifier :

define(`SMART_HOST', `192.168.0.2')

Sauvegarder puis entrer :

m4 /etc/mail/freebsd.mc > /etc/mail/freebsd.cf

Sendmail va ensuite utiliser notre relay. Pas besoin de l'activer dans le rc.conf car il ne fonctionne pas comme un daemon dans ce cas là.

Sauvegarde

Pour les sauvegardes on parle beaucoup de bacula ou rsync. Dans mon cas j'ai choisi de faire plus simple car : 1) bacula est adapté pour les grosses infra avec plusieurs serveurs et du stockage dédié 2) rsync nécessite un support de stockage distant que je n'ai pas (mon NAS ne tourne pas 24/24). Donc je me contente d'un simple script sh :)

#!/bin/sh

tar -zcvf /root/"sauvegarde-`date -v-1d +%B-%Y`".tar.gz \

/etc \

/var/named/etc \

/usr/jails/mail/etc \

/usr/jails/mail/home \

/usr/jails/mail/usr/local/etc \

/usr/jails/www/etc \

/usr/jails/www/home \

/usr/jails/www/usr/local/etc \

/usr/jails/xmpp/etc \

/usr/jails/xmpp/home \

/usr/jails/xmpp/usr/local/etc

Et dans crontab -e :

@monthly /root/sauvegarde.sh

Le 1er du mois à minuit le script sera exécuté, et dans son nom il sera indiqué le mois (précédent). Ainsi une sauvegarde exécutée le 1er Fevrier 2014 sera nommée January-2014.tar.gz si tout se passe bien.

Je n'ai pas de bases de données dont pas besoin d'arrêter les jail avant la sauvegarde. Je sauvegarde les /etc qui contiennent la configuration et les /home qui contiennent les données. Pas besoin du reste.

Note : ezjail-admin permet de sauvegarder les jails, mais je ne l'utilise pas en raison de deux inconvénients majeurs : 1) ça sauvegarde tout incluant l'arbre des ports, ce qui est long et inutile 2) ça nécessite d'arrêter la jail, et je n'ai pas envie d'avoir des interruptions de service à chaque sauvegarde, on est pas sur Windows Server.

Conclusion

FreeBSD ça envoie du rêve, c'est très puissant, ezjail-admin est un outil qui m'a fait franchir le pas. On gère ses jails avec une facilité déconcertante. Je suis volontairement resté vague sur cet article, car le but était de présenter un retour d'expérience, et non un tutoriel qui aurait été de toutes manières trop long. Si vous vous lancez dans l'aventure et souhaitez obtenir mes fichiers de configuration ou des explications, n'hésitez pas !