Google PlusFacebookTwitter

iPXE et la fameuse erreur 0x040ee119 qui rend fou !

By on Avr 17, 2017 in Devel, Linux, OpenStack | 0 comments

Quand tout fonctionne et que tout à coup… 0x040ee119 ! Durant les derniers mois qui se sont écoulés, j’ai eu à mettre en place un système de provisioning permettant d’automatiser le plus que possible nos déploiements OpenStack. La principale étape dans ce genre de procédé étant bien sûr de déployer un système d’exploitation et pour cela il m’a fallu remettre le nez dans la fameuse pile PXE/DHCP/TFTP et cela même si j’utilise Bifrost. Bifrost consiste à utiliser Ironic (composant de la fondation OpenStack) en mode standalone ce qui signifie qu’il n’est pas nécessaire d’avoir Keystone, Glance, Neutron et Nova d’installés pour utiliser ce dernier. Le titre de cet article relate parfaitement le comportement que j’avais lors des tentatives de déploiement, un coup cela fonctionnait et le coup d’après j’avais le...

Flasher un routeur ZyXel EMG2926-Q10A de chez Vidéotron

By on Mar 25, 2017 in Autres, Embarqué, Linux | 13 comments

Vidéotron, le retour avec ZyXel… Il y a presque 4 années, je rédigeais un billet sur comment Flasher un routeur D-Link DIR-825 de chez Vidéotron. Aujourd’hui, je vais rester sur le même sujet à une petite nuance près, le routeur sera un ZyXel EMG2926-Q10A toujours de chez Vidéotron. Avant d’aller plus loin, une petite mise en garde habituelle au sujet de la procédure qui suit. Comme la plupart des changements bas niveau il existe un risque, c’est pour cela que je ne pourrai en aucun cas être tenu responsable des possibles dommages engendrés suite au remplacement du micrologiciel (firmware) ou à la suite de cette procédure. Pour la petite histoire, le modèle EMG2926-Q10A de chez ZyXel n’est en fait qu’un ZyXel NBG6716. Ce modèle découle peut-être d’un partenariat entre Vidéotron et ZyXel, je ne saurai le confirmer ! ZyXel propose par défaut un...

Paquet pcs disponible pour Debian Jessie

By on Juin 4, 2016 in Linux, OpenStack | 0 comments

Il était une fois, l’histoire de pacemaker, corosync et pcs… Pour ceux qui ne connaissent pas cette histoire, un petit résumé s’impose (je dois mettre le mot pcs ici pour le référencement). En temps normal, cette suite d’outils liée à la haute disponibilité est présente dans les miroirs officiels Debian GNU/Linux. Hélas, pour Debian GNU/Linux Jessie (8.x) ce ne fut pas le cas… Trois problèmes: Un problème avec la librairie libqp qui n’a pas été résolu à temps. [1] Le paquet corosync était plutôt en mauvais état. [2] L’équipe Debian en charge de la haute disponibilité était quasiment inactive. [3] Heureusement, même si cela arrive tard, les trois problèmes cités ci-dessus ont été résolus et ces paquets sont désormais disponibles via les backports officiels Debian. pcs, un oubli malheureux pcs permet de configurer pacemaker et corosync en ligne...

Une zone OpenStack dédiée au nested KVM

By on Oct 2, 2015 in Linux, OpenStack | 2 comments

Qu’est-ce que le nested KVM ? En informatique, le mot nested signifie imbriqué. Ce mot est souvent utilisé dans le développement (nested structure), pour KVM cela signifie simplement que si cette option est activée alors il sera possible de créer une machine virtuelle dans une autre machine virtuelle, d’où l’utilisation du mot imbriqué. Par défaut, cette fonctionnalité n’est pas activée, cela signifie donc que seules des instances de type QEMU peuvent-être créées sur des machines virtuelles. Les instances de type QEMU seront beaucoup moins performantes que des instances de type KVM. Ce billet suppose que le(s) processeur(s) utilisé(s) sur l’hyperviseur/compute est/sont de marque Intel. Activation du nested pour le module KVM Bon pour ceux qui n’étaient pas au courant (et qui n’ont pas lu le lien ci-dessus), kvm est un module du noyau Linux. Comme beaucoup...

Mise à jour du module grub2 pour Puppet

By on Mai 12, 2015 in Devel, Linux | 0 comments

Parce que j’ai fait mon grub ce weekend… Il y a maintenant un peu plus d’une année, je publiais mon premier module Puppet (puppet-grub, sans trop savoir comment cela fonctionnait je l’avoue). Quelques issues furent ouvertes sur Github, dans l’ensemble le module semblait vivre sa vie sans trop de soucis. Ayant eu enfin le courage de me décider à corriger le ticket (Refresh (update-grub) always triggered), de fil en aiguille, j’ai corrigé, modifié le module pour en sortir une nouvelle version. L’objectif était de rendre le module le plus compatible possible avec les standards de la forge Puppet. Pour se faire, j’ai dû: Remplacer le fichier Modulefile par le fichier metadata.json Vérifier l’indentation, la doc, etc… via puppet-lint Vérifier la syntaxe via puppet parser validate Autre amélioration, rendre le module compatible avec...

Swift et l’optimisation système

By on Jan 16, 2015 in Devel, Linux, OpenStack | 0 comments

Optimiser Swift c’est bien, optimiser le système c’est mieux ! Il y a quelques mois, j’ai eu envie de m’essayer à l’optimisation de Swift. Pour ceux qui auraient besoin d’un petit rappel sur ce qu’est Swift, c’est un système distribué de stockage d’objets, extensible et redondant. Swift est aussi connu sous le doux nom d’OpenStack Object Storage. Généralement, l’optimisation de Swift consiste à modifier le nombre de worker et de concurrency, c’est bien mais ce n’est pas suffisant. Swift étant destiné à du stockage de fichiers redondés, il se base donc sur deux principaux composants matériels du serveur (sans compter le processeur et la mémoire): Le disque dur La carte réseau Se sont donc ces deux composants qu’il faudra optimiser sous Linux. Pour se faire, il sera nécessaire de passer par le sysctl...

%d blogueurs aiment cette page :