Le Blog Utux

HTTP 200 GET /

5 systèmes que j'aimerais tester

Rédigé par uTux Aucun commentaire

Ceci est une liste purement subjective de systèmes d'exploitations que j'aimerais bien tester en desktop ou en serveur "si j'avais le temps, si j'avais un use case, si j'avais un vieux notebook qui traîne dans un coin, si j'avais un petit serveur dispo pour monter un lab..."

GhostBSD

GhostBSD screenshot

J'adore FreeBSD, cela fait plus de 10 ans que je l'utilise sur 1 ou 2 serveurs dans un coin d'Internet ou de ma maison. A l'origine il me servait pour les jails - avant que Docker n'existe - sur une machine trop peu puissante pour supporter toute forme de virtualisation. J'avais même des jails en Debian GNU/kFreeBSD afin de combiner le meilleur des deux mondes.

Cependant, je n'ai jamais pu me motiver à utiliser FreeBSD en desktop car outre l'installation laborieuse de l'environnement de bureau complet, certaines features sont un peu moins pratiques que chez Linux (keymap, Wifi, hibernation...). Je dois admettre également que Docker me manque, bien que je pourrais apprendre à m'en passer en buildant mes propres jails.

GhostBSD est à FreeBSD ce que Manjaro est à Archlinux : une version prête à l'emploi pour un usage desktop. Et c'est un peu triste à dire mais depuis que DesktopBSD et PC-BSD/TrueOS sont morts, il ne reste que GhostBSD et NomadBSD pour remplir ce rôle.

GhostBSD pourrait être une bonne solution pour me permettre d'expérimenter le desktop sous FreeBSD.

Q4OS (Trinity)

Q4OS screenshot

Q4OS est une distribution Debian fournie avec l'environnement KDE Plasma ou Trinity, un fork de KDE 3.5 toujours maintenu. Alors que ce dernier n'est pas aussi populaire que MATE (qui rempli le même rôle en continuant à faire vivre l'esprit de GNOME2) Q4OS fait beaucoup d'efforts pour en proposer une version bien intégrée et agréable visuellement.

J'avoue que KDE 3.5 titille une fibre nostalgique en moi, même si je m'en souviens surtout comme d'un environnement bordélique et surchargé. Q4OS pourrait me donner l'occasion de me réconcilier avec ce DE.

Mageia

Mageia screenshot

On ne présente plus Mageia, le fork le plus fidèle à l'esprit d'origine de feu Mandriva. Je suis habituellement très critique envers cette distribution pour diverses raisons mais je dois avouer qu'elle a le mérite d'être encore là et d'être toujours indépendante. Dans un précédent article je disais même que je pourrais me réfugier dessus si jamais un jour Debian venait à disparaitre (ce qui était un pur exercice de pensée).

Utiliser sérieusement et longuement Mageia me permettrait peut-être de comprendre l'amour que portent certains utilisateurs à cette distribution qui manque gravement de moyens et qui vit dans le passé :)

OpenSuse

OpenSUSE screenshot

Lorsque l'on s'aventure sur le territoire des distributions Linux développées par une entreprise, on a généralement affaire au trio Red Hat, Ubuntu et SUSE. OpenSuse est la distribution communautaire gratuite disponible en deux cuvées : Leap (alignée sur la version de Suse Linux Enterprise Server - ou SLES) ou Tumbleweed (rolling release).

A l'instar de Drakeconf pour Mageia, OpenSuse dispose d'un outil graphique de configuration - Yast2 - dont j'ai beaucoup de mal à comprendre l'intérêt mais heureusement rien ne nous oblige à l'utiliser.

Suse ayant encore une bonne image auprès du grand public, en produisant gratuitement une distribution stable d'une grande qualité, j'aimerais bien trouver un jour un cas d'usage pour OpenSuse en desktop ou en serveur.

OpenIndiana

OpenIndiana screenshot

Après avoir écumé les distributions Linux et être passé par FreeBSD, NetBSD, OpenBSD... que reste-t-il ? Et bien la famille Solaris semble constituer une bonne piste. Le hic c'est qu'il n'existe plus vraiment de communauté pour maintenir les forks libres que sont OpenIndiana et OmniOS.

Malgré tout j'aimerais bien que ces systèmes reviennent en force afin de nous proposer un peu d'exotisme dans le monde des sysadmins.

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 ?

Fil RSS des articles de ce mot clé