Dans l'article systemd, c'est bien je citais systemd-nspawn qui est plus ou moins un équivalent à docker exec (lancement d'un binaire dans un container) ou lxc (démarrage complet du container) mais en upstream. Voici un petit cas pratique avec le lancement d'une application graphique :
Avertissement : cet article a pour but de montrer un cas d'utilisation intéressant de systemd-nspawn, mais la manipulation ci-dessous n'est pas propre, ne la faites pas à l'aveugle. La commande xhost autorise les connexions au serveur graphique tandis qu'un peu plus bas je lance l'application graphique directement en root. Vous devez donc être sûr que votre application n'est pas un keylogger ou un spyware.
La commande xhost +local: est volatile donc à refaire après un redémarrage de l'hôte. C'est pareil pour export DISPLAY=:0 dans le container car c'est une variable d'environnement.
Cette petite astuce en vrac me sert pour pac que je fais tourner dans un container Debian Jessie car il ne fonctionne actuellement plus en Testing.
Je connais bien OpenBSD pour y avoir fait tourner mon serveur pendant plusieurs mois. J'en ai un bon souvenir, c'est un système simple à comprendre et à configurer grâce à des syntaxes humainement lisibles dans les fichiers de configuration. Malheureusement OpenBSD est encore primitif sur de nombreux points, par exemple les mises à jour. En fait il n'y a aucun dispositif de mise à jour, il faut télécharger les sets en .tgz et les décompresser en écrasant le système, voire même tout recompiler. Deux autres problèmes majeurs que je vois sont d'une part le fs UFS vieillissant et lent (surtout si on compare à FreeBSD et son ZFS) et d'autre part les ports pas toujours à jour car il y a beaucoup moins de mainteneurs disponibles. C'est pourquoi je pense qu'OpenBSD est bien pour certains usages spécialisés qui peuvent se contenter des daemons de base, mais dans beaucoup d'autres cas il se fait éclater par FreeBSD et Linux, par exemple en usage stockage ou desktop.
A l'époque où j'utilisais OpenBSD (2011), le daemon web était un Apache 1.x lourdement modifié et le projet était en cours de migration vers Nginx. Mais ce dernier a été délaissé à son tour au profil de httpd, un serveur maison. Je n'y ai pas vraiment prêté attention jusqu'à récemment avec la lecture du blog de thuban (ou encore De l'épice pour la pensée) qui m'a rendu curieux. Thuban est tellement amoureux d'OpenBSD que quelques temps après l'avoir essayé, il a migré son serveur et écrit un livre.
Exemple simple
Puisqu'on est sur OpenBSD, la configuration sera forcément humainement lisible et centralisée dans un fichier. Le manpage est consultable ici. OMG UN MANPAGE, MER IL ET FOU ! Et oui, sur Linux les manpage sont souvent imbuvables, mais sur OpenBSD ce n'est pas le cas. Pas de panique, on va faire un exemple ensemble :)
On va simplement configurer notre httpd pour servir une page lorsque l'IP du serveur est appelée.
Voici ce qu'on met dans notre /etc/httpd.conf :
server "default" {
listen on * port 80
}
Par défaut, notre serveur travaillera dans /var/www/htdocs et /var/www/logs. On créé une page html de test :
echo "Hello" > /var/www/htdocs/index.html
On autorise httpd à démarrer :
echo httpd_flags="" >> /etc/rc.conf.local
Puis on démarre httpd :
/etc/rc.d/httpd start
En tapant l'adresse IP du serveur dans votre navigateur, vous devriez avoir le Hello sur fond blanc.
Vous pouvez éventuellement jeter un œil aux fichiers de logs :
On édite notre /etc/httpd.conf dans lequel on va définir nos paramètres globaux, ainsi que nos fichiers splittés de vhost :
chroot "/var/www"
logdir "/var/log/httpd"
include "/etc/httpd/site1.conf"
include "/etc/httpd/site2.conf"
Note : la ligne chroot est inutile ici car sa valeur par défaut est déjà /var/www néanmoins je trouve utile de la préciser, par souci de lisibilité.
/etc/httpd/site1.conf :
server "default" {
listen on * port 80
root "/htdocs/site1"
}
/etc/httpd/site2.conf :
server "ssl" {
listen on * tls port 443
root "/htdocs/site2"
tls certificate "/etc/ssl/cert.pem"
tls key "/etc/ssl/key.pem"
}
Note :root doit être un chemin relatif au chroot. Par exemple le /htdocs/site2 se rapporte implicitement à /var/www/htdocs/site2.
Après avoir rechargé httpd, l'accès à notre serveur en http (port 80) doit afficher le site 1 :
Et l'accès en https (port 443) doit afficher le site 2 :
Conclusion
httpd est un serveur web simple à prendre en main qui ne plaisante pas avec la sécurité, le chroot ayant une place importante dans son fonctionnement. Alors faut-il laisser tomber Apache et Nginx ? Pour un usage basique, c'est à dire servir des pages web, pourquoi pas, car c'est simple et robuste. En revanche, pour des usages avancés, non. À part renvoyer les requêtes dans un socket en fastcgi et servir du contenu statique, on ne peut pas faire grand chose. Pas de reverse proxy par exemple, ce rôle étant confié à relayd. Un autre point agaçant est le fait qu'en cas d'erreur le daemon httpd refuse de démarrer mais n'affiche aucune erreur et ne produit aucun log, donc bonne chance pour debugger.
Si vous êtes un amoureux d'OpenBSD, il est évident que vous ne tarderez pas à migrer vers httpd. Si vous n'êtes qu'un simple Linuxien, j'espère que cet article aura chatouillé votre curiosité.
J'utilise backuppc sur mon NAS à la maison pour sauvegarder mes VPS. J'aime cet outil car il est assez simple et s'appuie sur SSH + rsync des logiciels connus.
Pour un serveur Linux avec rsync, backuppc va tout sauvegarder à partir de /, ce qui est bien mais il y a des répertoires qu'on a pas forcément envie d'inclure, par exemple /tmp et /run qui sont volatiles ou /mnt qui est utilisé comme point de montage.
Avant je faisais comme ça :
Sauf qu'il s'avère que cette exclusion est un peu violente puisqu'elle ne va pas s'appliquer qu'aux répertoires situés à la racine, mais à tous. Et donc j'ai eu des surprises en constatant que dans ma sauvegarde, /var/www/dokuwiki/data/media était lui aussi exclu, ainsi que /var/www/dokuwiki/data/tmp.
Bon cette fois ce n'était pas méchant, mais voici la bonne pratique pour les exclusions, utiliser des chemins absolus :
J'adore FreeNAS parce que c'est du FreeBSD bien exploité (zfs + jails) et mis en forme proprement au travers d'un webui. J'en parle un peu plus dans cet article et vous encourage toujours à mettre votre NAS propriétaire synlogy et compagnie à la décharge pour vous acheter un vrai serveur digne de ce nom.
FreeNAS 9.10 est disponible depuis peu et se base sur FreeBSD 10.3 ce qui nous amène bhyve, l'hyperviseur concurrent à qemu-kvm très prometteur qui nous permet de faire tourner des VM Linux (entre autres) en plus des jails. Même si cette feature est encore considérée comme expérimentale par FreeNAS, elle est tout même documentée.
FreeNAS fournit l'outil iohyve qui s'inspire de iocage et s'appuie fortement sur zfs. iohyve est génial parce qu'il est non seulement simple à utiliser mais en plus très intuitif car on retient rapidement les commandes. Notez que dans FreeNAS 10 bhyve sera présent dans le webui, pour le moment il faut encore y aller à la main ;)
/!\ Avertissement /!\
Il ne faut pas modifier les fichiers système de FreeNAS, car non seulement ils seront écrasés lors de la prochaine mise à jour, mais en plus ils risquent d'interférer avec le webui. Par exemple au lieu de modifier le /etc/rc.conf on va plutôt aller dans la section tunables qui est prévue à cet effet. On installe pas non plus de paquets avec pkg. Toutes les manipulations du paragraphe suivant font appel à des outils déjà présents qui travaillent dans le zpool contenant les données.
Installation d'une VM ubuntu-server-16.04
La première chose à faire est de configurer iohyve, il va créer ses dataset ainsi que le bridge si celui-ci n'existe pas déjà. Notez que la manipulation n'écrase pas vos dataset ou votre zpool, ne vous embêtez pas à en faire un autre. Dans l'exemple suivant, mon zpool est data et mon interface réseau bge1 :
[root@freenas] ~# iohyve setup pool=data kmod=1 net=bge1
Setting up iohyve pool...
On FreeNAS installation.
Checking for symbolic link to /iohyve from /mnt/iohyve...
Symbolic link to /iohyve from /mnt/iohyve successfully created.
Loading kernel modules...
bridge0 is already enabled on this machine...
Setting up correct sysctl value...
net.link.tap.up_on_open: 0 -> 1
Le dataset Firmware sert pour démarrer des guest en UEFI mais nous ne l'utiliserons pas. Si vous voulez en savoir plus, vous pouvez consulter cette page de wiki détaillant l'installation de Windows avec iohyve.
Pour que iohyve et les modules kernel soient chargés au démarrage, on les ajoute dans la section General > Réglages dans le webui de FreeNAS :
Les paramètres ont l'air évidents, mais trois d'entre eux méritent un petit complément :
loader=grub-bhyve : Par défaut iohyve ne va pas charger de bios ou uefi dans bhyve donc il doit utiliser un bootloader externe, ici c'est grub2-bhyve.
ram=1G : pour ubuntu, ne pas mettre moins, j'ai essayé avec 256M et j'ai eu ce bug. Une fois l'installation terminée par contre, on peut baisser.
os=d8lvm : je n'ai pas trouvé beaucoup de détails mais cela indique à iohyve le type de système invité. d8lvm correspond à Debian 8 avec stockage lvm (ce que ubuntu propose par défaut). Sans lvm on peut utiliser os=debian.
Maintenant, on ouvre une seconde console (CTRL+ALT+F2) ou une seconde connexion SSH, puis on se connecte à la console de la VM (il n'y a rien pour le moment, c'est normal, elle ne fonctionne pas) :
[root@freenas] ~# iohyve console vm-ubuntu
On revient sur le premier terminal / SSH, puis on lance l'installation de la VM :
On retourne dans votre second terminal et là on voit enfin des choses apparaître :)
Cela rappelle beaucoup les installations de VM sur Xen.
On fait une installation normale de Ubuntu avec le réseau qui s'auto configure via DHCP. Lorsque c'est terminé, le reboot risque de ne pas fonctionner, il faut donc le faire à la main :
[root@freenas] ~# iohyve stop vm-ubuntu
Stopping vm-ubuntu...
[root@freenas] ~# iohyve list
Guest VMM? Running rcboot? Description
vm-ubuntu YES NO NO Tue Jul 12 22:38:55 CEST 2016
[root@freenas] ~# iohyve start vm-ubuntu
Starting vm-ubuntu... (Takes 15 seconds for FreeBSD guests)
Et la console confirme que ça fonctionne :)
Et voilà, ça fonctionne :)
La VM a même accès au réseau, on peut donc se logguer en SSH !
Conclusion
Encore une fois FreeNAS envoie du lourd et exploite les capacités de FreeBSD. iohyve permet d'utiliser bhyve + zfs tout en étant bien pensé et intuitif, et c'est une qualité rare (regard inquisiteur pointé vers lxd chez Canonical). Il est désormais possible d'avoir des VMs Linux sous FreeNAS ce qui conforte une fois de plus le fait que vous devriez jeter votre NAS propriétaire pour acheter un vrai serveur x86.
C'est pas possible. Je tombe sur ce problème tellement souvent que je me pose des questions. Le symptôme : vous lancez une recherche de mises à jour sur Windows 7, ça dure une éternité, ça n'aboutit jamais :
Vous pouvez toujours attendre...
J'ai souvent dépanné des Windows 7 et je n'ai jamais rencontré ce problème, sauf depuis 2016 qui est justement l'année où Microsoft use de son monopole pour vous forcer à passer sur Windows 10, faut-il y voir un lien ?
Bon courage pour pour dépanner, vous allez écumer les forum Microsoft, changer des clés de registre, purger des dossiers dans system32, et surtout prier parce que c'est complètement foireux. Windows Update est vraiment le système de mises à jour le plus nul de l'univers.
EDIT : Bon en fait après ~2 heures de recherche, ça a aboutit, donc cette fois j'ai eu de la chance. Mais j'ai eu de nombreuses fois le cas où ça n'aboutit jamais (sur d'autres machines) et je suis loin d'être le seul à me plaindre de ce problème.
