CentOS 7 : démarrer Anaconda en PXE

Je voulais, à la base, écrire un billet sur une installation particulière de CentOS 7. J'ai donc voulu utiliser mon "infrastructure de boot PXE" à la maison et commencer à gribouiller un kickstart, mais quand j'ai démarré ma machine virtuelle sur le réseau, le drame :

dracut-initqueue[584]: Warning: Could not boot.
dracut-initqueue[584]: Warning: /dev/root does not exist

Ma configuration pxelinux à ce moment est la suivante :

LABEL centos7amd64
        MENU LABEL Install CentOS 7 x86_64 (interactive)
        KERNEL pub/centos/7/os/x86_64/isolinux/vmlinuz
        APPEND initrd=pub/centos/7/os/x86_64/isolinux/initrd.img ip=dhcp inst.repo=ftp://X.Y.Z.T/pub/centos/7/os/x86_64/ inst.ks=ftp://X.Y.Z.T/pub/ks/c7_x86_64.cfg

Et bien entendu, le même type de configuration fonctionne en CentOS 6.

Ce message d'erreur arrive à des moments et des types d'installation parfois différents, de ce que j'ai lu. Et la résolution n'est pas toujours la même. Dans mon cas, il a fallu que j'ajoute le chemin vers un fichier squashfs, qui doit contenir l'OS minimal pour démarrer Anaconda je crois. Cela donne donc la configuration suivante :

LABEL centos7amd64
        MENU LABEL Install CentOS 7 x86_64 (interactive)
        KERNEL pub/centos/7/os/x86_64/isolinux/vmlinuz
        APPEND initrd=pub/centos/7/os/x86_64/isolinux/initrd.img root=live:ftp://X.Y.Z.T/pub/centos/7/os/x86_64/LiveOS/squashfs.img ip=dhcp inst.repo=ftp://X.Y.Z.T/pub/centos/7/os/x86_64/ inst.ks=ftp://X.Y.Z.T/pub/ks/c7_x86_64.cfg

J'espère que cela rendra service à d'autres !

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux ! Si en plus vous avez des remarques, ou des propositions d'améliorations, n'hésitez pas : les commentaires sont là pour ça !

Crédit photo : Mattias - Car Glass 03.

NetBSD : recompilation d'un noyau pour intégrer NPF dans un domU

Dans un billet précédent, j'abordais l'installation d'une machine virtuelle Xen NetBSD en mode paravirtuel. NetBSD, comme Linux, dispose en plus d'un noyau, de modules permettant d'étendre ses fonctionnalités. Ainsi, l'une des briques de pare-feu de NetBSD, NPF, est disponible sous forme de module. Le problème avec ce module, c'est qu'il n'est pas compatible avec un noyau domU. Il est donc nécessaire de recompiler un noyau NetBSD pour en profiter, en incluant le pilote NPF directement dedans plutôt qu'en module.

Récupération des sources

Recompiler un noyau NetBSD est assez facile. D'abord, je récupère les sources, ici celles de NetBSD 7.1 :

nils@shell2:/srv$ export CVSROOT="anoncvs@anoncvs.NetBSD.org:/cvsroot"
nils@shell2:/srv$ export CVS_RSH="ssh"
nils@shell2:/srv$ cvs checkout -r netbsd-7-1-RELEASE -P src

La documentation officielle le fait dans /usr/src, mais je le fais dans /srv/src, cela ne pose pas de problème.

Si vous souhaitez recompiler un système complet (et pas juste le noyau), il faudra aussi récupérer xsrc, ce que je ne ferai pas ici.

Création d'une configuration noyau personnalisée

Maintenant que les sources sont disponibles, je crée un fichier de configuration pour notre nouveau noyau. Pour cela pas besoin de repartir de zéro, je vais tout simplement copier un fichier existant, et ajouter l'option qui m'intéresse. A noter que les configurations de noyau pour NetBSD sont placées dans les sous-arborescences des différentes architectures. Dans mon cas, mes machines virtuelles sont en x86_64, ce qui correspond à amd64 côté NetBSD :

nils@shell2:/srv$ cd src
nils@shell2:/srv/src$ sys/arch/amd64/conf

Le fichier de configuration du noyau utilisé par défaut est GENERIC, et il en existe aussi un spécialisé pour un invté Xen : XEN3_DOMU. Je vais copier ce dernier au lieu de le modifier pour facilement différencier ma configuration de l'officielle :

nils@shell2:/srv/src/sys/arch/amd64/conf$ cp -vp XEN3_DOMU XEN3_DOMU_NPF

Je peux ensuite éditer mon nouveau fichier, et aller chercher cette ligne :

#pseudo-device  npf                     # NPF packet filter

Il suffit alors de commenter cette ligne, et de sauvegarder le fichier. Passons maintenant à la compilation en elle-même.

Compilation du noyau NetBSD personnalisé

La compilation d'un noyau NetBSD peut se faire de deux manières : manuellement ou via l'aide d'un script nommé build.sh. Ce script est capable, depuis n'importe quel OS compatible, de créer très simplement non seulement un noyau, mais aussi une release complète de NetBSD. Ce script est fourni dans les sources, et se trouve d'ailleurs à la racine.

D'abord, compilons les outils nécessaires :

nils@shell2:/srv/src/sys/arch/amd64/conf$
nils@shell2:/srv/src$ ./build.sh -U -u -m amd64 tools

Autre détail intéressant, et c'est aussi la raison de la présence de l'option -U dans la commande précédente, je n'ai pas besoin d'être root pour ces opérations :) Passons donc à la compilation du noyau à proprement parler :

nils@shell2:/srv/src$ ./build.sh -U -u -m amd64 kernel=XEN3_DOMU_NPF

Selon la puissance de la machine, quelques minutes plus tard un résultat similaire au suivant devrait apparaître :

===> Kernels built from XEN3_DOMU_NPF:
  /srv/src/sys/arch/amd64/compile/obj/XEN3_DOMU_NPF/netbsd
===> build.sh ended:      Sun Jun 18 20:29:39 CEST 2017
===> Summary of results:
         build.sh command:    ./build.sh -U -u -m amd64 kernel=XEN3_DOMU_NPF
         build.sh started:    Sun Jun 18 20:29:26 CEST 2017
         NetBSD version:      7.1
         MACHINE:             amd64
         MACHINE_ARCH:        x86_64
         Build platform:      NetBSD 7.1 amd64
         HOST_SH:             /bin/sh
         MAKECONF file:       /etc/mk.conf
         TOOLDIR path:        /srv/src/obj/tooldir.NetBSD-7.1-amd64
         DESTDIR path:        /srv/src/obj/destdir.amd64
         RELEASEDIR path:     /srv/src/obj/releasedir
         Updated makewrapper: /srv/src/obj/tooldir.NetBSD-7.1-amd64/bin/nbmake-amd64
         Building kernel without building new tools
         Building kernel:     XEN3_DOMU_NPF
         Build directory:     /srv/src/sys/arch/amd64/compile/obj/XEN3_DOMU_NPF
         Kernels built from XEN3_DOMU_NPF:
          /srv/src/sys/arch/amd64/compile/obj/XEN3_DOMU_NPF/netbsd
         build.sh ended:      Sun Jun 18 20:29:39 CEST 2017
===> .

Il me suffit donc de copier le fichier /srv/src/sys/arch/amd64/compile/obj/XEN3_DOMU_NPF/netbsd sur mon dom0 et de l'utiliser dans un fichier de configuration Xen pour un domU !

Et NPF alors ?

Une fois notre domU démarré à l'aide de ce noyau, il suffit de suivre la documentation de NPF.

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux ! Si en plus vous avez des remarques, ou des propositions d'améliorations, n'hésitez pas : les commentaires sont là pour ça !

Crédit photo : D - 15 photography - GT3 RS.

pbulk : aller plus loin sur les paramètres

Aujourd'hui, je me suis dit que j'allais encore parler de mon Raspberry Pi 2. Oui, celui-là même qui en ce moment passe sont temps à compiler des paquets pkgsrc. J'avais commencé par parler de la mise en place de pbulk, puis il y a peu j'ai abordé les problèmes d'alimentation rencontrés suite à cette mise en place.

Cette fois-ci, ce n'est pas une question d'alimentation, mais de limites systèmes. J'indiquais dans mon billet les options suivantes en tête du fichier pbulk.conf :

ulimit -t 3600 # set the limit on CPU time (in seconds)
ulimit -v 2097152 # limits process address space

Le premier problème que j'ai eu s'est matérialisé sous la forme d'un pur et simple kill lors de la compilation d'un paquet. Difficile ensuite de comprendre que celui-ci arrivait au bout d'une heure ! J'ai donc compilé le dit paquet manuellement et me suis rendu compte que cela mettait bien plus d'une heure. Cela peut sembler surprenant au premier abord, mais j'avais oublié que même en ayant 4 coeurs, un Raspberry Pi 2 est bien moins puissant qu'un PC classique x86_64. Il met donc, logiquement, bien plus de temps pour créer un même paquet. J'ai donc fini par commenter ces deux directives, pour voir si d'autres paquets, auparavant en échec pour des raisons obscures, peuvent compiler sans soucis.

A l'heure où j'écris ceci, le bulk build n'est pas terminé, mais j'ai déjà pu voir que le paquet qui m'a mis sur la voie est créé avec succès, ainsi que d'autres qui ne pouvaient pas être créés du fait de l'absence de ce premier.

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux ! Si en plus vous avez des remarques, ou des propositions d'améliorations, n'hésitez pas : les commentaires sont là pour ça !

Crédit photo : Joe deSousa - Gears.

Raspberry Pi : Attention à l'alimentation !

Il y a quelques mois, j'avais publié un billet sur pbulk. J'avais pris en exemple la configuration mise en place sur un Raspberry Pi 2B. Ce n'était pas une totale réussite, car parfois le Raspberry Pi gelait. Non, pas passer en dessous de 0°C, mais plutôt avoir un système qui ne répond plus. Plus rien, ou presque, la petite carte ne répondant qu'au ping.

On débranche, on rebranche, et ça repart. Jusqu'au suivant. Difficile dans ces conditions de construire presque 1500 paquets logiciels pour mes autres Raspberry Pi. La configuration d'alimentation choisie à l'époque avait pour but de limiter le nombre de prises de courant occupées : un PiHub, accompagné de son alimentation 5V 3,5A. Je pensais que pour 2 Raspberry Pi B+ et 2 2B, cela allait suffire. Finalement non, et non seulement les bulks ne passaient plus et finissaient par corrompre la carte SD, mais en plus l'alimentation a fini par lâcher.

Avant que l'alimentation du PiHub ne lâche, j'avais déjà déplacé le Raspberry Pi 2B dédié aux bulks sur une alimentation dédiée, en utilisant un chargeur de téléphone mobile. Lui aussi ne suffisait pas finalement, puisque j'ai eu quelques gels. Alors que faire ?

Une fois l'alimentation du PiHub hors service, j'ai finalement craqué pour un autre bloc, délivrant cette fois-ci 4,8A au total, mais dont certains ports peuvent délivrer jusqu'à 2A d'intensité. Depuis lors, je construits mes environ 1500 paquets par semaine sans problème depuis plus de trois semaines !

Moralité : il faut bien choisir l'alimentation de ses Raspberry Pi ! Cela peut poser certains problèmes !

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux ! Si en plus vous avez des remarques, ou des propositions d'améliorations, n'hésitez pas : les commentaires sont là pour ça !

Crédit photo : Teresa Walter/USFWS - Electrial fixtures to control that backup power generator.

En retard !

Je n'ai pas tenu le coup. Au moment de la publication de ce billet, 2 billets manquent à l'appel : celui du 9 et celui du 11 décembre. J'aurais pu éviter celui du 11 en publiant ce billet directement, mais je ne vois pas l'intérêt de publier à une heure tardive, autant assumer.

Et donc, qu'est-il arrivé ? Tout simplement, deux choses :

  • je suis arrivé à court de billets écrits à l'avance ;
  • mes journées se sont avérées plus longues et plus remplies que je ne le pensais, oubliant de publier le dernier billet que j'avais en stock.

J'ai donc deux billets à rattraper. Pour quand ? Je ne sais pas. Mais j'ai bien l'intention de les publier d'ici le 24 décembre !

Un autre problème s'est posé à moi durant la publication des billets récemment. Quelque chose que j'arrivais à gérer lors d'une publication hebdomadaire, mais beaucoup plus difficile à maintenir lors d'une publication quotidienne : partager mes billets sur les réseaux sociaux. En effet, j'effectue tout cela à la main, lors de la publication du billet. Pourquoi ? Quelques éléments :

  • les systèmes de partage de billets que j'ai pu tester pour Dotclear ne fonctionnent plus ;
  • hors de question de filer un accès à mes comptes de réseaux sociaux à un acteur tiers comme IFTTT ;
  • je n'ai pas encore cherché ou trouvé un système que je peux héberger moi-même pour publier mes billets sur Facebook, Twitter, Mastodon et Linkedin (et Diaspora en option) ;
  • un billet partagé a plus de visite qu'un billet non partagé sur les réseaux sociaux (oui, j'aime un minimum être lu) ;
  • j'ai, selon les billets, plus de réactions sur les réseaux sociaux que sur les commentaires.

Tant que j'y suis dans les difficultés actuelles, j'ai de plus en plus de mal à trouver des images d'illustration, de préférence dans une licence très permissive : Flickr dispose d'une option "Aucune restriction de droits d’auteur connue" bien pratique.

Malgré tout, je souhaite continuer cette série de billets quotidiens. Qui pour m'encourager ?

Crédit photo : Sergey Kochkarev - Almost 3am.

Trouver des fichiers doublons avec fdupes

Il m'arrive d'avoir des fichiers en double : copie à l'arrache au moment de changer d'ordinateur, copie avant de modifier un fichier que je ne modifie finalement pas, sauvegardes diverses... bref, avec le temps, on peut se retrouver avec pas mal de fichiers doublons. Pour moi, c'est principalement de la musique.

Un moyen de repérer ces doublons est d'utiliser fdupes. Ce logiciel vérifie plusieurs attributs pour comparer les fichiers, comme la taille, une somme de contrôle MD5, voire même une comparaison bit à bit. Il suffit de lui donner un répertoire à vérifier, et il fait le travail. Ce répertoire peut très bien être un point de montage distant, comme un export NFS ou CIFS.

Dans mon cas, j'ai décidé de lancer la commande suivante :

fdupes -R -s -S /Volumes/nils/ | tee -a ./fdupes.log

J'ai choisi de renvoyer la sortie de fdupes dans tee et de conserver un fichier de log. Pour les options :

  • -R permet une recherche récursive ;
  • -s permet de prendre en compte les liens symboliques ;
  • -S montre la taille.

Voici un exemple de la sortie, pour un fichier :

3178172 bytes each:
/Volumes/nils/Musique/laptop/Serge Gainsbourg - Histoire de Melody Nelson/02 - Ballade de Melody Nelson.mp3
/Volumes/nils/Musique/laptop_old/Serge Gainsbourg - Histoire de Melody Nelson/02 - Ballade de Melody Nelson.mp3

Une dernière fonctionnalité intéressante est celle de laisser fdupes gérer l'effacement des fichiers doublons, mais je préfère d'abord vérifier qu'il n'y a pas d'erreur.

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux !

Crédit photo : Pascal - Day 341.

Python : 3 outils pour analyser son code

Suite à mon billet blogmas make : automatiser quelques tâches avec un Makefile, une discussion intéressante a suivi sur Mastodon, où Dashie me signalait sa préférence pour pylint pour analyser la validité de son code Python. Je saisis donc l'occasion, non pas d'argumenter pour mon choix, ou celui de Dashie, mais plutôt d'énumérer quelques possibilités pour qui souhaite avoir un code lisible, et se conformer à des conventions de style de code.

Exit pep8, bonjour pycodestyle !

Et là, les choses deviennent très drôles, car je voulais commencer par parler de pep8. Je lance donc la commande pep8 dans mon code Python :

nils@dalaran-wifi:~/fabfile$ pep8 *.py
/opt/pkg/lib/python2.7/site-packages/pep8.py:2124: UserWarning: 

pep8 has been renamed to pycodestyle (GitHub issue #466)
Use of the pep8 tool will be removed in a future release.
Please install and use `pycodestyle` instead.

$ pip install pycodestyle
$ pycodestyle ...

  '\n\n'

Donc, pep8 est obsolète, il faut utiliser pycodestyle. Heureusement, celui-ci est disponible dans pkgsrc :

nils@dalaran-wifi:~$ sudo pkgin av|grep codestyle
py27-codestyle-2.3.1 Python style guide checker
py27-pep8-1.7.1      Python style guide checker (obsolete, use py-codestyle)
py34-codestyle-2.3.1 Python style guide checker
py34-pep8-1.7.1      Python style guide checker (obsolete, use py-codestyle)
py35-codestyle-2.3.1 Python style guide checker
py35-pep8-1.7.1      Python style guide checker (obsolete, use py-codestyle)
py36-codestyle-2.3.1 Python style guide checker
py36-pep8-1.7.1      Python style guide checker (obsolete, use py-codestyle)

Bon, là aussi le message est clair : pep8 c'est fini, faut changer de crèmerie.

flake8 l'aggrégateur

Un autre outil dont j'avais entendu parler, c'est flake8. Celui-ci est assez intéressant, car c'est justement une combinaison de plusieurs outils : pep8, pyflakes, mccabe, et potentiellement d'autres via des plugins.

pylint, qui fait tout, sauf le café

Pylint ne fait pas que vérifier la conformité par rapport à des standards ou styles de code, il permet aussi de faire de la détection d'erreur, de proposer du refactoring de code et de faire des diagrammes UML via Pyreverse. Entre ça, et l'intégration à un environnement de développement ou à un système d'intégration continue, le moins qu'on puisse dire, c'est que pylint est très complet !

En conclusion : faut tester !

Je n'ai pas encore eu le temps de me faire un avis. Je compte bien sûr tester tout cela, dès que je remet le nez dans du code Python !

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux !

Crédit photo : Pascal - Study in Pink.

Paris Open Source Summit 2017 - jour 2

Ce billet arrive un peu tard, mais ces deux jours du Paris Open Source Summit 2017 furent assez remplis : entre des visiteurs sur le stand LinuxFr.org, les personnes sur les autres stands, et les tirages au sort pour faire gagner des livres, je n'ai pas eu le temps de m'ennuyer !

Quelques photos de ces deux jours de salons :

Affiche LinuxFr.org sur le stand

L'urne utilisée lors des tirages au sort

Les mains innocentes de Tris

Le mégaphone, avant le tirage au sort du premier jour

LinuxFr.org à bord d'une Tesla Model X

Une peluche PHP sur le stand de l'AFUP

La mouette OpenOffice sur le stand LibreOffice

Le retour du mégaphone pour le tirage au sort du deuxième jour

Quelques autocollants sur le stand de Framasoft

A l'année prochaine pour une nouvelle édition du Paris Open Source Summit !

Paris Open Source Summit 2017

Depuis maintenant plusieurs années, je suis fidèle au rendez-vous du salon qui maintenant s'appelle le Paris Open Source Summit. Et comme toujours, vous pourrez me retrouver sur le stand de LinuxFr.org. Toujours selon la tradition, il y aura :

  • des autocollants ;
  • des livres à gagner (tirage au sort en fin de journée, il faut être présent pour gagner) ;
  • du chocolat (et cette année, j'ai mis le paquet !) ;
  • et une partie de l'équipe du site !

Je vous attends donc au stand B29 pour ces deux jours de salon ! Si vous ne pouvez pas venir, faites-moi signe sur les réseaux sociaux, et dites-moi si vous souhaitez que je visite un stand en particulier !

make : automatiser quelques tâches avec un Makefile

Quand on parle d'automatisation, on pense tout de suite à des outils qui permettent du déploiement automatisé, comme Ansible, Chef, Puppet ou Salt. Mais bien avant d'en arriver là, il y a eu (GNU) make.

Après m'être pas mal amusé avec Fabric, en ce moment je me met à Ansible (mieux vaut tard que jamais). J'apprécie de pouvoir, assez rapidement, effacer des fichiers temporaires ou effectuer certaines vérifications. Avoir un Makefile est une solution qui, pour le moment, m'apparaît comme simple et élegante.

Ainsi, dans le répertoire où je stocke mes recettes Fabric, j'ai créé un fichier nommé, sans surprise, Makefile. Son contenu est à peu près le suivant :

clean:
        rm -f *.pyc *.pyo *~ */*.pyc */*.pyo */*~ .*~ .DS_Store */.DS_Store

pep8:
        pep8 *.py

J'ai donc deux cibles :

  • la première, clean, fait comme on s'en doute, du nettoyage, c'est-à-dire de la suppression de fichiers temporaires ou de fichiers qui n'ont pas vocation à servir (comme les paramètres d'affichage de répertoire sous macOS) ;
  • la deuxième me permet de vérifier que mon code Python est bien conforme aux standards de style Python, regroupés dans le PEP8 (voir chez Sam et Max pour une explication en français, mais attention, c'est un peu NSFW).

Une fois que je suis dans mon répertoire, et que j'ai fini d'éditer mes fichiers, je peux vérifier que tout cela respecte le PEP8 avec la commande make pep8. Pour faire le ménage dans mes fichiers, ça sera make clean. Ah, si je pouvais réellement faire le ménage chez moi comme ça ;)

En fait, make est bien plus complet et complexe que cela, et ne se limite pas à faire le ménage. On peut, et c'est pour cela qu'il existe, compiler et installer des programmes. Je m'en sers aussi pour installer mon petit confort sur une nouvelle machine.

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux ! Et puis n'hésitez pas à proposer vos propres cibles make en commentaires !

Crédit photo : Daniel Lobo - Meteoro.

Propulsé par Dotclear