Le Blog Utux

HTTP 200 GET /

ENLARGE YOUR HP PROLIANT MICROSERVER GEN8 - épisode 1

Rédigé par uTux 2 commentaires

Je possède depuis plus de 2 ans un HP ProLiant MicroServer Gen8 qui tourne sous FreeNAS et fait office de NAS comme son nom l'indique. Équipé d'un Celeron G1610T, il tourne sous FreeNAS a offert des performances correctes jusqu'à ce que je décide un jour d'activer le chiffrement des disques. Ce processeur ne supporte pas les instructions AES-NI, donc le chiffrement et déchiffrement sont fait de manière logicielle, c'est lourd.

Pour y remédier il est possible de changer le CPU et se tourner vers des Xeon un peu plus costauds. J'ai donc commandé un E3-1260L (4c/8t @2.40Ghz). Niveau TDP on passe de 35W pour le Celeron à 45W ce qui reste correct pour le refroidissement semi-passif, surtout que le CPU ne tourne pas à 100% en permanence. Ce CPU offre 8 cœurs logiques, le turbo, et les instructions AES-NI ce qui devrait booster FreeNAS et les jails FreeBSD que je lui fais supporter.

En attente de réception du CPU !

FreeBSD: jouons avec iocage

Rédigé par uTux Aucun commentaire

En 2018, en matière de containers il n'y a pas que Docker ou LXC, il y a aussi FreeBSD et ses jails :) en fait ça existait longtemps avant et c'est plutôt bien fichu. J'ai longtemps utilisé le framework ezjail qui a l'avantage d'être simple et de fonctionner sans ZFS (j'avais un serveur anémique à base d'Atom 32 bit).

J'utilise FreeNAS et bien que leur web-ui permette depuis longtemps de créer des jails, cette solution est trop rigide, il est par exemple impossible d'upgrader une jail :( Bonne nouvelle, dans les dernières versions (avec le web-ui en beta ou via la ligne de commandes) on a droit à iocage qui est plus souple et supporte (entre autres) les upgrades.

Création d'une jail FreeBSD

Tout comme iohyve, il faut commencer par définir un pool de stockage ZFS. Cela peut être un pool existant, il ne l'écrase pas mais créé quelques datasets. Par exemple pour utiliser le pool data:

[root@freenas] ~# iocage activate data
ZFS pool 'data' successfully activated.

Ensuite on télécharge un template qui va servir à créer nos jails. Par exemple pour récupérer 11.1-RELEASE:

[root@freenas] ~# iocage fetch
[0] 9.3-RELEASE (EOL)
[1] 10.1-RELEASE (EOL)
[2] 10.2-RELEASE (EOL)
[3] 10.3-RELEASE
[4] 10.4-RELEASE
[5] 11.0-RELEASE (EOL)
[6] 11.1-RELEASE

Type the number of the desired RELEASE
Press [Enter] to fetch the default selection: (11.1)
Type EXIT to quit: 6
Fetching: 11.1-RELEASE

Downloading : MANIFEST [####################] 100% 0Mbit/s
Downloading : base.txz [####################] 100%  13.44Mbit/s
Downloading : lib32.txz [####################] 100%  12.66Mbit/s
Downloading : doc.txz [####################] 100%  10.76Mbit/s
Downloading : src.txz [####################] 100%  11.94Mbit/s
 11.94Mbit/sExtracting: base.txz... 
Extracting: lib32.txz... 
Extracting: doc.txz... 
Extracting: src.txz... 

* Updating 11.1-RELEASE to the latest patch level... 
src component not installed, skipped
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching public key from update4.freebsd.org... done.
Fetching metadata signature for 11.1-RELEASE from update4.freebsd.org... done.
Fetching metadata index... done.
Fetching 2 metadata files... done.
Inspecting system... done.
Preparing to download files... done.
Fetching 151 patches.....10....20....30....40....50....60....70....80....90....100....110....120....130....140....150 done.
Applying patches... done.

The following files will be updated as part of updating to 11.1-RELEASE-p9:
[--- blablabla ---]
Installing updates... done.

On peut créer une jail nommée "unbound":

root@freenas:~ # iocage create -r 11.1-RELEASE -n unbound
unbound successfully created!

On lui met une adresse IP (en mode shared car j'ai encore quelques soucis avec le VNET):

root@freenas:~ # iocage set vnet=off unbound
Property: vnet has been updated to off
root@freenas:~ # iocage set ip4_addr="em0|192.168.0.201/24" unbound
Property: ip4_addr has been updated to em0|192.168.0.201/24

On démarre la jail:

root@freenas:~ # iocage start unbound
* Starting unbound
  + Started OK
  + Starting services OK

On entre dans la jail:

root@freenas:~ # iocage console unbound

FreeBSD 11.1-RELEASE (GENERIC) #0 r321309: Fri Jul 21 02:08:28 UTC 2017

Welcome to FreeBSD!

Release Notes, Errata: https://www.FreeBSD.org/releases/
Security Advisories:   https://www.FreeBSD.org/security/
FreeBSD Handbook:      https://www.FreeBSD.org/handbook/
FreeBSD FAQ:           https://www.FreeBSD.org/faq/
Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/
FreeBSD Forums:        https://forums.FreeBSD.org/

Documents installed with the system are in the /usr/local/share/doc/freebsd/
directory, or can be installed later with:  pkg install en-freebsd-doc
For other languages, replace "en" with a language code like de or fr.

Show the version of FreeBSD installed:  freebsd-version ; uname -a
Please include that output and any error messages when posting questions.
Introduction to manual pages:  man man
FreeBSD directory layout:      man hier

Edit /etc/motd to change this login announcement.
root@unbound:~ #

Autres features

  • Créer ses propres templates, utile pour créer des jails prêtes à l'emploi (avec SSH + authorized_keys, par exemple).
  • Upgrade des jails
  • Snapshots (et oui, zfs...)
  • VNET (la jail a sa propre stack réseau, utile pour les manipulations pare-feu ou vpn)
  • Limitations CPU & mémoire
  • Installation automatique de paquets
  • Montage de volumes bind
  • Création de jails kFreeBSD (à titre de proof of concept)
  • A la manière des dataset/pool zfs, chaque jail a des propriétés modifiables (get/set)
  • Ecrit en python

Conclusion

J'utilise iocage pour une jail backuppc et j'en suis plutôt content. Si l'aspect VNET reste à améliorer, on a quand même fait un grand pas par rapport à la solution maison de FreeNAS.

iocage c'est le meilleur de FreeBSD: les jails et zfs. La syntaxe est claire, facile à retenir et me donne presque envie de m'y remettre et de migrer tous mes services dessus. Je vous encourage à l'essayer! Je vous encourage aussi à manger du FreeNAS, c'est bon pour la santé.

Le rolling release c'est pas toujours bien (pour ansible)

Rédigé par uTux Aucun commentaire

Il y a des gens qui préfèrent les distributions stable telles que debian et il y en a d'autres qui, au contraire, veulent du rolling release. Sur serveur j'ai toujours privilégié la stabilité, donc debian mais je n'ai pas toujours le choix.

Mon NAS tourne sous FreeNAS, et ayant besoin d'étendre ses possibilités j'ai ajouté quelques jails qui offrent donc du FreeBSD quasi upstream. Or FreeBSD a une base stable mais la plupart des ports/packages non. J'ai fait la configuration avec Ansible pour pouvoir tout réinstaller facilement sans me poser de question (voir Docker, Ansible, NixOS : le savoir (re)faire). Et justement le cas s'est présenté, suite au passage au chiffrement des disques j'ai du backuper/restaurer toutes les données et recréer mes jails. Le problème est qu'Ansible n'a pas pu jouer les playbook à cause de cet aspect rolling release qui fait que le comportement ou les fichiers de conf des logiciels à installer a changé. Je pense notamment à unbound, je parse le /usr/local/etc/unbound.conf à la recherche d'une ligne "listen 0.0.0.0" que je créé si elle n'existe pas. Or depuis peu elle est présente dans une autre contexte, cela induit donc mon playbook en erreur. Ce n'est pas trop grave, il m'a fallu moins de 1h pour tout corriger et tout installer.

J'étudie la possibilité de remplacer ces jails FreeBSD par des machines virtuelles debian, car FreeNAS supporte la virtualisation avec bhyve. Une grande stabilité est nécessaire pour orchestrer et automatiser les choses proprement.

Docker >_<

Rédigé par uTux 12 commentaires

Je ne vais pas me faire des amis, mais j'ai un problème avec Docker et je vais l'illustrer en le comparant avec ezjail qui permet de gérer les jails sous FreeBSD.

Pour afficher la liste des containers dans Docker :

$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
c516f8fcbc57        httpd:v5            "/bin/bash"         9 minutes ago       Up 2 seconds        80/tcp              tender_mirzakhani

Attendez, c'est pas fini ! Cette commande ne va afficher que les containers en cours d'exécution. Si on veut tout :

$ docker ps -a
CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS                     PORTS               NAMES
c516f8fcbc57        httpd:v5            "/bin/bash"            9 minutes ago       Up 22 seconds              80/tcp              tender_mirzakhani
974607db9cb7        httpd:v5            "apache2-foreground"   18 minutes ago      Exited (0) 8 minutes ago                       gigantic_engelbart

Et pour entrer dans un container :

$ docker exec -t -i gigantic_engelbart /bin/bash
root@974607db9cb7:/var/www/html#

Ok. Maintenant voyons comment on fait pour lister des containers avec ezjail sous FreeBSD :

ezjail-admin list
STA JID  IP              Hostname                       Root Directory
--- ---- --------------- ------------------------------ ------------------------
DR  1    127.0.1.1       jls-web-10                     /usr/jails/jls-web-10
    1    em0|192.168.0.50
DS  N/A  127.0.1.2       jls-mail-01                    /usr/jails/jls-mail-01
    N/A  em0|192.168.0.60

Et pour entrer dans un container avec ezjail :

ezjail-admin console jls-web-10
FreeBSD 10.3-RELEASE (GENERIC) #0 r297264: Fri Mar 25 02:10:02 UTC 2016

root@jls-web-10:~ #

Voilà, une seule commande simple à retenir et pas d'options superflues.

Pourquoi les commandes Docker sont-elles aussi imbuvables ? C'est un problème courrant dans l'environnement des logiciel sous Linux, on ne sait pas faire de choses simples. git est un autre exemple symptomatique, nous sommes obligés d'avoir sous la main une anti-sèche pour ne pas nous tromper dans les commandes.

Docker étant relativement récent, pourquoi ne s'est-il pas inspiré des commandes ezjail, iohyve, iocage ou lxc qui sont beaucoup plus simples et intuitives ?

FreeNAS 9.10 : jouons avec bhyve et iohyve

Rédigé par uTux Aucun commentaire

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

On peut alors voir les dataset créés :

[root@freenas] ~# zfs list | grep iohyve
data/iohyve                                                 10.9G  1.08T    96K  /mnt/iohyve
data/iohyve/Firmware                                          96K  1.08T    96K  /mnt/iohyve/Firmware

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 :

FreeNAS tunables.

On demande à iohyve de télécharger pour nous l'ISO (il est possible de les renommer, ce que je ne fais pas dans l'exemple) :

[root@freenas] ~# iohyve fetch http://releases.ubuntu.com/16.04/ubuntu-16.04-server-amd64.iso
Fetching http://releases.ubuntu.com/16.04/ubuntu-16.04-server-amd64.iso...
/iohyve/ISO/ubuntu-16.04-server-amd64.iso/ubun100% of  655 MB 1018 kBps 10m59s

Hop, deux nouveaux datasets :

[root@freenas] ~# zfs list | grep iohyve
data/iohyve                                                 10.9G  1.08T    96K  /mnt/iohyve
data/iohyve/Firmware                                          96K  1.08T    96K  /mnt/iohyve/Firmware
data/iohyve/ISO                                              644M  1.08T    96K  /mnt/iohyve/ISO
data/iohyve/ISO/ubuntu-16.04-server-amd64.iso                644M  1.08T   644M  /mnt/iohyve/ISO/ubuntu-16.04-server-amd64.iso

Maintenant, on créé notre VM puis on lui donne ses paramètres :

[root@freenas] ~# iohyve create vm-ubuntu 10G
Creating vm-ubuntu...
[root@freenas] ~# iohyve set vm-ubuntu loader=grub-bhyve ram=1G cpu=1 os=d8lvm
Setting vm-ubuntu loader=grub-bhyve...
Setting vm-ubuntu ram=1G..
Setting vm-ubuntu cpu=1...
Setting vm-ubuntu os=debian...

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.

On jette un coup d'oeil aux zfs datasets :

[root@freenas] ~# zfs list | grep iohyve
data/iohyve                                                 10.9G  1.08T    96K  /mnt/iohyve
data/iohyve/Firmware                                          96K  1.08T    96K  /mnt/iohyve/Firmware
data/iohyve/ISO                                              644M  1.08T    96K  /mnt/iohyve/ISO
data/iohyve/ISO/ubuntu-16.04-server-amd64.iso                644M  1.08T   644M  /mnt/iohyve/ISO/ubuntu-16.04-server-amd64.iso
data/iohyve/vm-ubuntu                                      10.3G  1.08T    96K  /mnt/iohyve/vm-ubuntu
data/iohyve/vm-ubuntu/disk0                                10.3G  1.09T    64K  -

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 :

[root@freenas] ~# iohyve install vm-ubuntu ubuntu-16.04-server-amd64.iso
Installing vm-ubuntu...

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.

Fil RSS des articles de ce mot clé