Logo Liopen
Mise en place d'un dépot NuGet privé sous Linux

J'ai découvert il y'a quelques mois Chocolatey et son compagnon BoxStarter, solution de déploiement d'environnements Windows.

Aussi utiles que soient ces applications, j'ai rencontré deux problèmes lors de leur utilisation:

L'idée était également de pouvoir héberger les paquets sur mon portable (sous Linux) et configurer des VM Windows sans avoir à démarrer une machine Windows au préalable. J'ai donc effectué un travail d'ingénierie inverse pour reproduire le comportement du serveur NuGet en Python. Le résultat s'appelle Chocorepo et est disponible ici.

Si vous souhaitez utiliser Chocorepo, gardez en tête qu'il n'a pas été développé pour être utilisé en environnement hostile et est proposé sans aucunes garanties

Présentation

Chocorepo est développé en Python. Il utilise plusieurs modules dont WSGI pour la gestion des requètes HTTP et Pyslet pour la gestion du protocole OData.

La bibliothèque Pyslet possède l'avantage de masquer une grande partie de la "plomberie" qui doit être mise en place pour offrir un service OData. Il suffit de lui fournir un fichier de méta-données (fichier XML) et de définir des classes pour chaque fonctions que l'on souhaite proposer, Pyslet s'occupe de gérer les appels et les réponses.

Pour Chocolatey, le fichier de méta-données se trouve à l'adresse https://chocolatey.org/api/v2/$metadata.

Chocorepo utilise une base de données SQLite3 pour stocker les informations à propos des paquets disponibles (nom, version, description, auteur, etc.). Les fichiers de base de données sont créés à partir du fichier de méta-données s'ils n'existent pas. Par défaut, les fichiers s'appellent dbrepo.db (qui contient la liste des paquets et les informations associées) et dbstream.db (qui contient une copie du fichier .nupkg de chaque paquet disponible).

Chocorepo a été développé pour offrir son service derrière un proxy Nginx et il écoutera les requètes sur http://127.0.0.1:8080/ (modifiable grâce aux variables SERVICE_PORT et SERVE_ADDRESS du fichier repo.py).

Installation

L'installation de Chocorepo est simple et se fait en 4 étapes :

Configuration de Nginx

La configuration de Nginx se limite à l'ajout d'un VirtualHost et la configuration du proxy :

    server {
        root /home/pkg; # Where .nupkg files are stored
        index index.html index.htm;

        server_name chocopkg;

        location /nuget/ {
            proxy_pass http://127.0.0.1:8080/nuget/;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-for $proxy_add_x_forwarded_for;
            proxy_set_header Host $host;
            proxy_connect_timeout 10;
            proxy_send_timeout 90;
            proxy_read_timeout 90;
            proxy_redirect off;
            proxy_set_header Connection close;
            proxy_pass_header Content-Disposition;
            proxy_pass_header Content-Length;
            proxy_hide_header Content-Type;
            add_header Content-Type application/atom+xml;
        }
    }

Création d'un paquet NuGet

Un paquet NuGet (extension .nupkg) est basiquement un fichier .zip contenant la description du paquet (fichier .nuspec) et les directives d'installation sous forme de script Powershell. Pour faire simple, je vais prendre l'exemple de Notepad++.

Le fichier d'installation chocolateyInstall.ps1 ressemble à :

    $packageName = 'notepadplusplus'
    $installerType = 'EXE'
    $url = 'http://chocopkg/npp.6.6.9.Installer.exe'
    $url64 = $url
    $silentArgs = '/S'
    $validExitCodes = @(0)

    Install-ChocolateyPackage "$packageName" "$installerType" "$silentArgs" "$url" "$url64" -validExitCodes $validExitCodes

Le nom du paquet, le type d'installeur et les URL de téléchargement du programme d'installation sont les paramètres les plus importants. Les paquets peuvent posséder un script d'installation plus complexe, c'est simplement du Powershell.

Le fichier de description notepadplusplus.nuspec ressemble à :

    <?xml version="1.0"?>
    <package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
        <metadata>
            <id>notepadplusplus</id>
            <version>6.6.9</version>
            <title>Notepad++</title>
            <authors>Don Ho</authors>
            <owners>Denis</owners>
            <projectUrl>http://notepad-plus-plus.org/</projectUrl>
            <requireLicenseAcceptance>false</requireLicenseAcceptance>
            <description>Notepad++ est un editeur de texte sous licence GPL. Fonctionne sous Windows</description>
            <summary>Notepad++ est un éditeur de texte.</summary>
            <tags>editeur texte notepadplusplus windows gpl</tags>
            <releaseNotes />
            <copyright />
        </metadata>
    </package>

Seuls les balises <id/>, <version/> et <requireLicenseAcceptance/> sont obligatoires. Les autres sont fortement recommandées afin de fournir aux utilisateurs un minimum d'informations sur la fonction du logiciel proposé.

Un dossier est créé pour le paquet notepadplusplus :

Arboresence d'un paquet

Le fichier notepadplusplus.nuspec est déposé dans le dossier notepadplusplus et le fichier chocolateyInstall.ps1 dans le dossier tools. La dernière étape consiste à générer le fichier notepadplusplus.nupkg avec NuGet (fourni avec Chocolatey) :

Création de notepadplusplus.nupkg

La paramètre -NoPackageAnalysis permet de passer outre le test de conformité de NuGet.

Importation d'un paquet NuGet dans le dépot privé

Je rappelle que Chocorepo n'est pas développé pour gérer les paquets NuGet malicieux, n'importez pas de fichiers dont vous ignorez la provenance.

Le programme import.py permet d'importer un paquet NuGet dans la base de données de Chocorepo :

    $ python import.py notepadplusplus.nupkg

Installation d'un paquet

Pour installer un paquet provenant de notre dépot privé, il faut rajouter le paramètre -source à Chocolatey :

Liste des paquets

Installation d'un paquet

N'hésitez pas à me faire un retour si vous l'utilisez et à proposer une PR sur GitHub.

 

Migration d'une machine Microsoft Hyper-V vers VMware vCloud Director

Il existe de multiples plate-formes de virtualisation et il arrive parfois que l'ont ai besoin de migrer une machine virtuelle d'une solution à une autre. Dernièrement, un partenaire utilisant Hyper-V de Microsoft nous a fourni une VM à intégrer dans un socle VMware vCloud Director.

Il nous a envoyé un fichier .vhd. Ce format n'est pas exploitable tel quel par VMware mais heureusement plusieurs outils permettent, après quelques manipulations, de convertir celui-ci en vApp utilisable.

La migration se fait en 4 étapes :

La première étape consiste a convertir le fichier .vhd en format .ovf grâce à VirtualBox. On crée une nouvelle machine virtuelle avec VirtualBox :

Création d'une VM dans VirtualBox

Création d'une VM dans VirtualBox

La seule information importante concerne le type et la version du système d'exploitation installé dans le .vhd. Les autres propriétés pourront être modifiées dans vCloud. Pour le disque dur virtuel, nous allons attacher le fichier .vhd fourni par le partenaire :

Création d'une VM dans VirtualBox

La dernière manipulation consiste à convertir la machine nouvellement créée en fichier .ovf en utilisant la fonction Fichier/Exporter une application virtuelle de VirtualBox :

Export vers .ovf

Export vers .ovf

Export vers .ovf

Nous obtenons plusieurs fichiers à la fin de la conversion :

    $ ls
    VHD2OVF-disk1.vmdk  VHD2OVF.mf  VHD2OVF.ovf

Avant de pouvoir déployer la machine, il faut éditer le fichier .ovf pour l'adapter en supprimant les périphériques n'existant pas sur la plate-forme vCloud : contrôleur disque, carte son, carte réseau, etc.

Afin de rendre le fichier acceptable par vCloud, il faut générer un condensat SHA-1 du fichier .ovf et inscrire le résultat dans le fichier Manifest (.mf) généré par VirtualBox.

Nous avons maintenant un modèle OVF valide que nous pouvons envoyer sur la plate-forme vCloud. Pour cela, nous allons utiliser le programme ovftool issu du kit VMware Open Virtualization Format Tool. Pour cela, nous avons besoin de plusieurs informations :

Une fois toutes ces informations en main, on lance la commande :

    ovftool --vCloudTemplate VHD2OVF.ovf \
      "vcloud://identifiant:mot_de_passe@adresse_du_serveur:443?org=nom_de_lorganisation&vappTemplate=VHD2OVF&catalog=nom_du_catalogue&vdc=nom_du_vdc"

Si l'envoi s'est bien passé, on retrouve la vApp dans vCloud, il ne reste plus qu'à déployer et éditer les propriétés pour ajouter une interface réseau, de la mémoire, etc.

Prêt à être déployé

 

Serveur PPPoE avec OpenBSD 5.5

Lors de la refonte de l'infrastructure d'interconnexion des sites d'un client, j'ai été confronté à un problème de validation de la nouvelle solution. Afin de m'assurer que le paramètrage des routeurs est valide et qu'il n'y aura pas de surprise lors du déploiement (on branche et ça fonctionne, surtout pour les sites distants de plusieurs centaines de kilomètres et n'ayant pas de technicien sur site), il m'a fallu tester au plus proche des conditions réelles. Le client possède sur certains sites des connexions ADSL dont l'authentification est basée sur PPPoE. J'ai donc mis en place un serveur PPPoE qui m'a permis de contrôler la conformité des configurations. Pour cela, j'ai utilisé npppd(8) disponible de base avec OpenBSD. Voici l'architecture mise en place :

Architecture réseau

Tous les routeurs clients sont configurés pour monter une session PPPoE sur l'interface WAN qui est reliée au switch (switch qui joue le rôle du modem/bridge des sites du client). Le configuration du routeur OpenBSD est la suivante :

(Les valeurs framed-ip-address étaient configurées avec les adresses IP fixes fournies par le FAI du client)

Les clients et le routeur sont visibles les uns des autres sur le réseau. Depuis le réseau d'un site client, j'arrive à atteindre le réseau d'un autre site donc tout fonctionne, il n'y a plus qu'à déployer.

 

Java7u45 et les applications auto-signées/non-signées

L'un de mes clients utilise des applications Java que les developpeurs n'ont pas signé numériquement ou dont la signature est invalide. De ce fait, les versions de Java récentes (Oracle JRE > 7u25) affichent des alertes lors du lancement de l'application qui agacent les utilisateurs.

La solution la plus naturelle est de demander aux développeurs de faire leur travail correctement (signer numériquement les applets) mais ce n'est pas toujours possible (développeur injoignable par exemple). Il y'a également l'option consistant à conserver une version antédiluvienne de Java mais je vous assure que vous ne voulez pas faire ça...

Et dans ce cas, c'est à l'administrateur de mettre en place une solution permettant de valider l'application grâce aux Deployment Rule Sets

Pour mettre en place ces règles de déploiement, nous avons besoin :

Une autorité de certification a été créée avec OpenSSL, on a donc deux fichiers .PEM : la clé privée (cakey.pem) et la clé publique (cacert.pem). La première étape consiste à créer un magasin de clefs utilisable avec les outils Java. On le créé en important un fichier au format PKCS#12 :

        $ openssl pkcs12 -export -out cacert.p12 -inkey cakey.pem -in cacert.pem
        $ keytool -importkeystore -destkeystore caclient.jks -srckeystore cacert.p12 \
        -srcstoretype PKCS12 -alias CAClient

Dans un éditeur de texte, on crée un fichier .XML contenant les règles de déploiement. Ici, c'est très simple si l'adresse de l'applet commence par http://srvapplet:8080 elle est considérée comme sûre :

<!-- ruleset.xml -->
<ruleset version="1.0+">
    <rule>
        <id location="http://srvapplet:8080" />
        <action permission="run" />
    </rule>
</ruleset>

L'étape suivante consiste à mettre ce fichier .XML dans un .JAR puis de signer le .JAR avec notre autorité de certification :

        $ jar -cvf DeploymentRuleSet.jar ruleset.xml
        $ jarsigner -verbose -keystore caclient.jks -signedjar DeploymentRuleSet.jar \
        DeploymentRuleSet.jar CAClient

Finalement on installe l'autorité de certification (à coup de GPO, c'est très facile) et on copie le fichier DeploymentRuleSet.jar dans le dossier %windir%\Sun\Java\Deployment sur les postes des utilisateurs.

L'application est maintenant considerée comme sûre par la machine virtuelle Java.

 

Erreur de segmentation au lancement d'un programme basé sur l'API VMWare VIX

Lors de l'utilisation du SDK de l'API VMWare VIX, j'ai rencontré un problème sur une machine Debian Wheezy. Tous les programmes utilisant cette API se finissaient avec une erreur de segmentation.

    $ /usr/share/doc/vmware-vix/samples/fhostopen
    Erreur de segmentation

L'erreur provient de l'ordre de chargement des bibliothèques. Ce patch permet de corriger ce problème.

 

Flasher son disque SSD OCZ sous Ubuntu

Le site du constructeur OCZ propose un outil pour mettre à jour le micrologiciel de ses produits pour les systèmes Microsoft Windows et Apple MacOS X mais la seule alternative lorsque l'on utilise un système Linux est de télécharger l'image du CD de démarrage, la graver, booter dessus et espérer que l'interface réseau soit reconnue par le système. Et si ce n'est pas le cas (comme sur ma machine), impossible de télécharger le firmware et de flasher le SSD.

La solution consiste à extraire l'outil de mise à jour et à le lancer de façon autonome depuis le système d'exploitation courant. Voici les différentes étapes à effectuer :

OCZ Toolbox sous Ubuntu