22 déc. 2017

NetBSD : haute disponibilité avec CARP

Turner Twins, acrobats, 1937 / by Sam HoodNetBSD dispose depuis la version 4.0 d'une implémentation du protocole CARP. Il s'agit d'un protocole, à l'origine prévu pour les routeurs, permettant à un groupe de machines de disposer d'une adresse IP flottante. Si la machine principale venait à être indisponible, une machine secondaire peut alors prendre le relai. CARP permet donc de mettre en place de la haute disponibilité.

Je me suis amusé à mettre en place une configuration CARP sur les deux serveurs DNS de mon LAN. Pourquoi ? J'ai remarqué que bien souvent, selon les OS, quand on spécifie deux serveurs DNS dans les paramètres réseau, même si la redondance est là, on peut sentir un ralentissement :

  • le client va faire du round-robin et donc régulièrement des requêtes vont échouer ;
  • le client va d'abord s'adresser au premier serveur DNS de sa liste, et si celui-ci est indisponible, il attendra un timeout avant de passer au suivant.

Il y a probablement d'autres moyens d'adresser ces problèmes, mais cela m'a fourni une excuse de jouer avec CARP, c'est le plus important :)

CARP se présente en fait sous forme d'une carte réseau fictive dont le pilote est disponible dans le noyau. Quand je dis disponible, c'est qu'en théorie l'option est compilée dans le noyau GENERIC, mais cela n'est pas forcément le cas sur toutes les plateformes. Ainsi, j'ai dû recompiler un noyau contenant pseudo-device carp.

Une fois que CARP est bien disponible, il suffit tout simplement de créer une nouvelle interface réseau sur chaque machine. La machine principale aura un poids plus fort que la machine secondaire, et portera l'adresse IP flottante en temps normal.

Sur la machine principale :

# ifconfig carp0 create
# ifconfig carp0 vhid 101 pass motdepassehalakon 10.13.37.42 netmask 255.255.255.0

Sur la machine secondaire :

# ifconfig carp0 create
# ifconfig carp0 vhid 100 pass motdepassehalakon 10.13.37.42 netmask 255.255.255.0

On peut alors vérifier que l'adresse IP flottante est joignable. A noter la présence d'un mot de passe permettant de limiter les cas de "vol d'IP flottante", ici positionné à "motdepassehalakon"

Pour que cela tienne au redémarrage, il faut bien entendu que la configuration soit enregistrée quelque part. En fait, en terme de configuration, il s'agit tout simplement de la configuration de la carte réseau carp0, ici sur la machine principale :

$ cat /etc/ifconfig.carp0
create
up
vhid 101 pass motdepassehalakon 10.13.37.42 255.255.255.0

Ensuite sur la machine secondaire :

$ cat /etc/ifconfig.carp0
create
up
vhid 100 pass motdepassehalakon 10.13.37.42 255.255.255.0

Maintenant, il ne reste plus qu'à tester... en débranchant la prise !

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

Crédit photo : State Library of New South Wales - Turner Twins, acrobats, 1937 / by Sam Hood.

17 déc. 2017

Quelques statistiques du blog

Suite au commentaire de Xate dans un récent billet, quelques statistiques sur les billets (blogmas ou pas) sur la première quinzaine de décembre. Pour cela, je me suis servi de mes one-liners en awk décrits ici et .

Les billets les plus vus

Commençons par les billets les plus visités :

root@vhost2:~/tmp# grep "GET /post/" ./access.log | awk '{frequencies[$7]++;} END {for (field in frequencies) printf "%s\t%d\n" , field , frequencies[field];}' | sort -nr -k 2,2 | head -20
/post/python-3-outils-anaylser-code     1527
/post/make-automatiser-quelques-taches-avec-un-makefile 260
/post/livre-apprendre-a-programmer-avec-python  243
/post/xz-pour-une-meilleure-compression-de-ses-fichiers 224
/post/centos-7-desactiver-firewalld-reactiver-iptables  209
/post/2016/12/29/Vous-naviguez-toujours-sur-un-site-HTTPS       192
/post/livre-introduction-au-langage-c   168
/post/logrotate-exemple-vite-fait       165
/post/paris-open-source-summit-2017-jour-2      161
/post/en-retard 152
/post/paris-open-source-summit-2017     143
/post/centos-7-desactiver-firewalld-reactiver-iptables/ 124
/post/Trouver-des-fichiers-doublons-avec-fdupes 123
/post/raspberry-pi-attention-alimentation       112
/post/2009/11/09/Utilisation-transparente-d-une-passerelle-SSH  83
/post/2011/10/03/Installation-de-phpMyAdmin-sur-CentOS-6        76
/post/pbulk-aller-plus-loin-sur-les-parametres  72
/post/systemd-reconfigurer-unite-service        71
/post/2017/02/13/clamav-installation-et-scan-antivirus-sur-macos        69
/post/2016/12/29/Vous-naviguez-toujours-sur-un-site-HTTPS&fromurl=redirect.asp  67

Le billet le plus populaire est donc celui sur les outils d'analyse de code Python, et de loin ! Je note que j'ai mal écrit "analyser" dans l'URL, il faudra vraiment que je fasse attention à cela à l'avenir ! Il m'arriver d'ailleurs régulièrement de dépublier puis republier un billet en m'apercevant que l'URL ne me convient pas. J'en profite pour remercier Dashie pour notre conversation sur Mastodon, sans ça je n'aurais pas eu l'idée d'écrire ce billet.

Les tag les plus vus

Quels tags sont les plus populaires ?

root@vhost2:~/tmp# grep "GET /tag/" ./access.log | awk '{frequencies[$7]++;} END {for (field in frequencies) printf "%s\t%d\n" , field , frequencies[field];}' | sort -nr -k 2,2 | head -20
/tag/NetBSD     73
/tag/Apache     55
/tag/CentOS     50
/tag/PHP        47
/tag/Linux/page/3       46
/tag/Linux      41
/tag/Perl       40
/tag/ssl        38
/tag/blogmas    34
/tag/Awstats    32
/tag/Mac%20OS%20X       31
/tag/RHEL       31
/tag/mp3        29
/tag/pkgsrc     29
/tag/RPM        29
/tag/macOS      28
/tag/Xen        27
/tag/ssh        27
/tag/tls        27
/tag/https      25

Visiblement, je commence à devenir populaire pour NetBSD, Apache, CentOS et PHP ! Dommage que pkgsrc soit un peu bas à mon goût. Le tag blogmas n'est pas non plus super populaire.

Les referers

D'où viennent les visites ?

root@vhost2:~/tmp# grep "GET /post/" ./access.log | awk '{frequencies[$11]++;} END {for (field in frequencies) printf "%s\t%d\n" , field , frequencies[field];}' | sort -nr -k 2,2 | head -20
"-"     5077
"http://www.google.co.uk/url?sa=t&source=web&cd=1"      468
"https://blog.anotherhomepage.org/"     203
"https://www.google.fr/"        196
"https://www.journalduhacker.net/"      193
"http://blog.anotherhomepage.org/"      124
"https://blog.anotherhomepage.org/post/centos-7-desactiver-firewalld-reactiver-iptables/"       66
"http://blog.anotherhomepage.org/post/centos-7-desactiver-firewalld-reactiver-iptables/"        58
"https://blog.anotherhomepage.org/post/centos-7-desactiver-firewalld-reactiver-iptables"        52
"https://blog.anotherhomepage.org/post/python-3-outils-anaylser-code"   45
"https://www.google.com/"       31
"https://blog.anotherhomepage.org/category/Humour"      29
""      28
"https://socialmediascanner.eset.com"   24
"https://blog.anotherhomepage.org/page/2"       22
"https://blog.anotherhomepage.org/post/2009/11/09/Utilisation-transparente-d-une-passerelle-SSH"        19
"https://www.google.fr" 19
"https://www.journalduhacker.net/s/asxn1a/python_3_outils_pour_analyser_son_code"       16
"https://blog.anotherhomepage.org"      15
"https://blog.anotherhomepage.org/feed/tag/Linux/atom"  15

Pas grand-chose à dire de ce côté, si ce n'est que beaucoup n'ont pas de referer, et en creusant un peu, le lien vers Google UK est utilisé par la même IP, et toutes les visites vont sur le billet sur les outils d'analyse de code Python. J'ai par contre été cité par le Journal du Hacker, ce qui fait bien plaisir !

Des erreurs ?

Quelques trucs étranges :

root@vhost2:~/tmp# awk '{frequencies[$9]++;} END {for (field in frequencies) printf "%s\t%d\n" , field , frequencies[field];}' < ./access.log | sort -nr -k 2,2 | head -10
200     48038
301     17578
304     10958
404     834
"-"     716
503     464
302     229
400     143
206     22
403     17

Voyons voir les erreurs 404 :

root@vhost2:~/tmp# grep -w "404" access.log | awk '{frequencies[$7]++;} END {for (field in frequencies) printf "%s\t%d\n" , field , frequencies[field];}' | sort -nr -k 2,2 | head -10
/post/centos-7-desactiver-firewalld-reactiver-iptables/ 66
/pages/Welcomerobots.txt        64
/wp-login.php   45
/ads.txt        20
/tag/Apachepage/2       12
/pages/Welcomelicense.txt       12
/a2billing/common/javascript/misc.js    11
/post/2017/01/21/macOS-installer-pkgsrc-pour-beneficier-de-plus-de-logiciels    11
/apple-app-site-association     11
/post/  11

Résultat : sans doute des tentatives de bruteforce du blog, pensant qu'il s'agit d'un Wordpress ou d'autre chose. Par contre, il faudra que je regarde plus attentivement les billets à propos de firewalld et de pkgsrc sur macOS.

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

Crédit photo : Bernard Spragg. NZ - Passing Time 2010 ).

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.

9 mai 2017

Xen : installation d'un invité domU NetBSD

the handlerDans le billet précédent, j'ai abordé la création d'un hyperviseur Xen (dom0) NetBSD. Il est donc temps de s'occuper du système invité NetBSD, le domU.

Création du domU Xen

Pour créer notre domU, nous avons besoin de 3 éléments présents sur le dom0 :

  • un fichier de disque dur (on pourrait utiliser LVM ou une partition, mais cela est moins flexible) ;
  • dans le cas de NetBSD, un fichier de noyau ;
  • et un fichier de configuration.

D'abord, le fichier de disque dur. Pour le créer, il suffit d'utiliser la commande dd. La taille de ce fichier déterminera la taille du disque dur de la machine virtuelle. Créons un fichier de 4 Go (4096 blocs d'1 Mo) :

root@rogue:~# dd if=/dev/zero of=/srv/xen/images/disk/netbsd.img bs=1m count=4096

On peut remarquer que cet exemple remplit notre fichier de zéros, et ne crée pas de fichier sparse. Il semble que la gestion des fichiers sparse ne soit pas parfaite sous NetBSD, d'après le tutoriel officiel.

Ensuite, récupérons les fichiers noyau :

root@rogue:~# mkdir -p /srv/xen/images/kernels/NetBSD/NetBSD-7.1/amd64/
root@rogue:~# cd /srv/xen/images/kernels/NetBSD/NetBSD-7.1/amd64/
root@rogue:/srv/xen/images/kernels/NetBSD/NetBSD-7.1/amd64 # ftp http://cdn.netbsd.org/pub/NetBSD/NetBSD-7.1/amd64/binary/kernel/netbsd-INSTALL_XEN3_DOMU.gz
root@rogue:/srv/xen/images/kernels/NetBSD/NetBSD-7.1/amd64 # ftp http://cdn.netbsd.org/pub/NetBSD/NetBSD-7.1/amd64/binary/kernel/netbsd-XEN3_DOMU.gz

On récupère deux fichiers de noyau, car l'un d'entre eux ne sert que pour l'installation. Une fois celle-ci terminée, il faut penser à configurer notre domU avec le noyau "classique".

Nous pouvons enfin créer notre fichier de configuration, /usr/pkg/etc/xen/netbsd :

root@rogue:/usr/pkg/etc/xen# grep -v ^# netbsd | grep -v ^$
name = "netbsd"
uuid = "d0f3e8d3-2f54-11e7-b035-00301bbde894"
kernel = "/srv/xen/images/kernels/NetBSD/NetBSD-7.1/amd64/netbsd-INSTALL_XEN3_DOMU.gz"
memory = 256
vcpus = 1
vif = [ 'bridge=bridge0,mac=00:16:3E:00:00:02' ]
disk = [ '/srv/xen/images/disk/netbsd.img,raw,xvda,rw' ]

Les directives du fichier de configuration sont assez explicites, néanmoins il convient de préciser certaines choses :

  • d'abord, le nom de la machine virtuelle ("name") doit être unique ;
  • et en passant, l'uuid aussi (généré via uuidgen), mais il n'est pas obligatoire, la directive peut être vide ;
  • la mémoire est spécifiée en méga-octets ;
  • on peut spécifier plusieurs interfaces réseau ou disques durs.

On peut ajouter bien d'autres options, mais il est préférable de commencer par un fichier simple, qui démarrera une machine en mode texte, avant d'aller plus loin.

Maintenant que notre fichier de configuration est prêt, démarrons notre domU :

root@rogue:/usr/pkg/etc/xen# xl create -c netbsd

L'option -c permet d'attacher la console locale de la machine virtuelle en mode texte, et donc de pouvoir interagir avec (pour, par exemple, effectuer une installation).

Installation de NetBSD dans le domU

L'installation se passe de manière similaire à ce qui est présenté dans le guide officiel, mais à une différence près : une fois l'installation terminée, il faut quitter l'installeur (au lieu de redémarrer), puis éteindre la machine virtuelle :

# shutdown -p now

De retour dans le dom0, il faut alors changer le fichier de noyau pour un démarrage "classique" :

root@rogue:/usr/pkg/etc/xen# vi netbsd
kernel = "/srv/xen/images/kernels/NetBSD/NetBSD-7.1/amd64/netbsd-XEN3_DOMU.gz"

On peut ensuite démarrer notre machine virtuelle, dans l'exemple suivant sans attacher la console locale de celle-ci :

root@rogue:/usr/pkg/etc/xen# xl create netbsd

On est vraiment obligé de spécifier sur le noyau ?

Dans le domU d'exemple du billet précédent, le système OpenWrt était démarré grâce à pygrub, un chargeur de démarrage pour Xen. Celui-ci n'est hélas pas capable de lire le système de fichiers FFS utilisé par NetBSD. Cela n'est pas non plus possible pour pv-grub, qui n'est de toute façon pas disponible dans les paquets Xen pkgsrc.

Quelles sont alors les possibilités ? La première consiste à créer une partition /boot en ext2/3/4 au début du disque virtuel, et d'y placer noyau et configuration Grub, comme l'indique ce tutoriel. Une autre consiste à compiler soi-même une version de Grub2, qui semble maintenant gérer Xen, tout du moins d'après ce billet du blog officiel Xen, daté de janvier 2015.

Autres actions possibles

Démarrer sa machine virtuelle, c'est bien, pouvoir effectuer d'autres actions et vérifications, c'est mieux ! Voici donc, en vrac, quelques commandes utiles pour gérer ses domU :

  • xl shutdown <chemin vers le fichier de configuration> permet d'arrêter proprement celui-ci ;
  • besoin d'appuyer sur le bouton Off comme un gros barbare ? xl destroy <nomdudomU> ;
  • lister les domU en fonctionnement : xl list ;
  • et pour avoir cette liste en temps réel, présentée à la manière d'un top, on peut utiliser xl top.

D'autres commandes et paramètres sont disponibles dans la page de manuel de la commande xl.

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 : ColonelMustard - the handler''

Propulsé par Dotclear