16 déc. 2017

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.

15 déc. 2017

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.

14 déc. 2017

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.

10 déc. 2017

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.

8 déc. 2017

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.

Propulsé par Dotclear