Proxmox Virtual Environnement

Proxmox VE s’installe sur un serveur nu, à partir d’une image iso téléchargeable sur le site officiel. Etant donné qu’il repose sur une distribution Debian Lenny, il est tout à fait possible de l’installer, sur un système existant, à partir de paquets. La dernière version (1.8) utilise les extensions de virtualisation des processeurs 64 bits, elle n’est disponible que pour cette architecture, inutile donc,  de tenter une installation sur une machine 32 bits.

Une interface web d’administration offre une surveillance et une gestion simplifiée des machines virtuelles KVM (kernel-based Virtual Machine) et para-virtuelles OpenVZ . Nous pouvons en quelques clics, créer, modifier, supprimer, démarrer, arrêter, suspendre ou visualiser l’état d’une machine.

Des outils, en lignes de commandes, permettent des fonctionnalités plus poussées, telles que la sauvegarde à chaud par snapshot ou la restauration.  Enfin, des fonctions de clustering permettent, par exemple, la migration à chaud de machines virtuelles d’un serveur physique à un autre.

Je vous propose ci-dessous, trois petites démonstrations en screencast. La première montre l’utilisation de l’interface Web pour la création et l’installation d’un serveur virtuel kvm sous Debian Squeeze, la deuxième, le clonage de ce serveur à l’aide des outils de snapshot et de restauration et enfin, la troisième, la création d’un cluster de deux serveurs Proxmox VE ainsi que la migration d’une machine virtuelle d’un serveur vers l’autre.

Démo n°1 – Installation d’un serveur virtuel Debian.

Click here to view the video on YouTube.

Démo n°2 – Utilisation des outils de sauvegarde et de restauration pour le clonage d’une VM.

Click here to view the video on YouTube.

Démo n°3 – Création d’un cluster Proxmox VE et migration à chaud.

Click here to view the video on YouTube.

Sources :

• Site officiel Proxmox,
• Wikipedia.

Sa première originalité est sa capacité à embarquer une version portable de Virtualbox (portable-Virtualbox) pour permettre l’exécution de la distribution dans une machine virtuelle, directement depuis Windows, sans aucune installation, ni reboot. Sa deuxième est, sous réserve d’espace suffisant, la possibilité de conserver les documents présents sur la clé et de continuer à l’utiliser de façon tout à fait classique.

L’opération se déroule en cinq étapes :

Etape 1 :

• Choix du périphérique de stockage USB qui va accueillir la distribution,

Etape 2 :

• Choix de la source entre :
• Une image locale au format iso, dmg ou zip,
• Le téléchargement manuel ou automatique à partir d’une bonne liste de distributions. Des tests sont réalisés pour trouver le miroir le plus rapide, – classe !
• Un CDRom ou DVD inséré dans le lecteur.

Etape 3 :

Etape 4 :

Etape 5 :

Liens :

• Site officiel : www.linuxliveusb.com
• Distributions supportées.

Pour reprendre la définition de « Wikipedia » :

Le code QR ou QR Code (en anglais) est un code-barres en 2 dimensions (code matrice) pouvant stocker jusqu’à 7089 caractères numériques, 4296 caractères alphanumériques (contrairement au code-barre « traditionnel » qui lui ne peut stocker que de 10 à 13 caractères) ou 2953 octets . Il a l’avantage de pouvoir stocker beaucoup d’informations tout en étant petit et rapide à scanner. Ainsi, le sigle « QR » dérive de « Quick Response » car le contenu peut être décodé rapidement.

Ce type de code, par sa capacité, permet de « stocker » un petit texte, une adresse e-mail, une url, un numéro de téléphone ou encore une vcard complète. Il présente l’intérêt de pouvoir être interprété rapidement à partir d’un PDA ou d’un téléphone, bien sûr munis d’un appareil photo et d’une petite application permettant le décodage. Le contenu, en fonction de son type, peut être, ensuite, traité directement par l’appareil : pointage du navigateur vers l’url, création d’un nouvel email,  import de la vcard dans le carnet d’adresses, etc… Un concept qui ravie les adeptes de gadgets mobiles, en permettant, en un shoot, la saisie d’adresses ou d’url, pas toujours très pratique, voir fastidieuse sur ce genre d’appareil.

Application "Barcode scanner" sur un téléphone Androïd (HTC Hero)

Pour créer son propre QR Code, il existe de nombreux générateurs en ligne, en voici quelques uns, la liste est loin d’être exhaustive :

• http://qrcode.kaywa.com,
• http://www.snapmaze.com,
• http://zxing.appspot.com/generator.

Comme pour les codes barres classiques (1 dimension), ce qui va m’intéresser, c’est bien entendu de pouvoir les générer en local… et si possible en lignes de commandes ( eh oui ! Encore !).

Il existe un petit programme qui fait ça très bien et qui se nomme judicieusement : qrencode.

qrencode est intégré dans la majeure partie des distributions, si ce n’était pas votre cas, vous pouvez toujours télécharger les sources sur le site officiel.

Ce petit outil permet de générer une image au format png, à partir d’une ou plusieurs chaînes de caractères.

$ qrencode --help
qrencode version 3.0.3
Copyright (C) 2006, 2007, 2008 Kentaro Fukuchi
Usage: qrencode [OPTION]... [STRING]
Encode input data in a QR Code and save as a PNG image.
 
-h           display this message.
--help       display the usage of long options.
-o FILENAME  write PNG image to FILENAME. If '-' is specified, the result
will be output to standard output. If -S is given, structured
symbols are written to FILENAME-01.png, FILENAME-02.png, ...;
if specified, remove a trailing '.png' from FILENAME.
-s NUMBER    specify the size of dot (pixel). (default=3)
-l {LMQH}    specify error collectin level from L (lowest) to H (highest).
(default=L)
-v NUMBER    specify the version of the symbol. (default=auto)
-m NUMBER    specify the width of margin. (default=4)
-S           make structured symbols. Version must be specified.
-k           assume that the input text contains kanji (shift-jis).
-c           encode lower-case alphabet characters in 8-bit mode. (default)
-i           ignore case distinctions and use only upper-case characters.
-8           encode entire data in 8-bit mode. -k, -c and -i will be ignored.
-V           display the version number and copyrights of the qrencode.
[STRING]     input data. If it is not specified, data will be taken from
standard input.

La plupart des paramètres disposent d’une valeur par défaut, ce qui simplifie la mise en œuvre pour une utilisation « classique ». Il suffit de préciser le nom de fichier en sortie et le contenu à encoder.

$ qrencode -o test1.png « http://www.jopa.fr »
$ qrencore -o test2.png < test.txt

Pour en savoir plus :

• QR-code ? Clovis Darrigan répond,
• Wikipedia,
• QrEncode,

Sur ce site, tu vas apprendre à construire une borne d’arcade en 6 mois. Les esprits chagrins diront que 6 mois, c’est très long.
Effectivement, c’est très long, surtout qu’on peut construire une borne d’arcade en 24 heures.
Seulement voilà, je suis assez mauvais en bricolage, d’où les 6 mois
Je remercie au passage l’auteur du site ci-dessus, sur lequel je me suis basé pour construire la borne.
Ce site est donc fait pour toi, qui possèdes à peu près le même niveau que moi en bricolage, c’est à dire un niveau 0 sur une échelle de 10.

Pour la leçon de bricolage, c’est par là !

]]> http://www.jopa.fr/index.php/2009/08/17/construire-sa-borne-darcade-en-6-mois/feed/ 3 http://www.jopa.fr/index.php/2009/07/16/linux-pam-et-mirror-une-authentification-rfid/ http://www.jopa.fr/index.php/2009/07/16/linux-pam-et-mirror-une-authentification-rfid/#comments Wed, 15 Jul 2009 23:10:03 +0000 Jopa http://www.jopa.fr/?p=1461 Cette pluvieuse journée du 14 juillet m’a permis de poursuivre mes petits travaux sur le lecteur rfid « Mir:ror ». Dans les articles précédents, je me suis surtout intéressé au déclenchement d’événements en fonction des puces rfid détectées (ou pas) par le lecteur, oubliant l’essence même du RFID : l’authentification. J’ai donc profité de ce temps à ne pas mettre mon chat dehors pour écrire un module PAM (Pluggable Authentification Module) permettant d’authentifier un utilisateur via le Mir:ror.

L’idée est simple : si mon Mir:ror est connecté à l’ordinateur et qu’un fichier contenant mon rfid est présent dans mon répertoire, je veux pouvoir ouvrir ma session à l’aide d’une puce RFID (carte, badge, ztamp:s, laaaaapin…) à la place de saisir mon mot de passe.

Je ne vais pas m’attarder ici à décrire la manière dont est codé le module, je vous laisse le soin de lire les sources… Je vais me contenter d’expliquer son installation et son utilisation.

Mise en garde :

Pour plusieurs raisons dont la simplification du module et mes piètres talents de développeur, il va sans dire que ce petit programme ne doit pas être utilisé en environnement sécurisé. Par contre, pour la maison, c’est plutôt fun !

Nous touchons ici à une partie sensible du système : l’authentification. Les manipulations ci-dessous sont donc à réaliser avec prudence.

Compilation :

Pour pouvoir compiler pam_mir-ror, il nous faut installer un version récente de la librairie de développement pam (libpam-dev). J’ai utilisé la version 1.0.1 proposée par défaut sous Debian Lenny.

$ sudo aptitude install libpam-dev

L’archive contenant les sources est téléchargeable ci-dessous :

• pam_mir-ror.0.2.tar.gz

Une fois téléchargée, il faut la décompresser et tout simplement lancer la commande « make ».

$ tar -xvzf pam_mir-ror.0.2.tar.gz
$ cd pam_mir-ror.0.2
$ make

Si tout se passe bien, nous devrions obtenir deux binaires :

• read_mir-ror : Un petit outil permettant la lecture à partir du Mir:ror,
• pam_mir-ror.so : Le module pam.

read_mir-ror

Le petit outil read_mir-ror va nous permettre de tester le lecteur. Il suffit de l’exécuter et d’approcher une puce rfid.

$ sudo ./read_mirror
0000D0081A025303420200D2

La série de chiffres affichée n’est rien d’autre que l’ID de l’objet détecté.

Il est préférable d’utiliser read_mirror avec les droits root, au moins la première fois, pour l’accès au périphérique mir:ror. Par défaut, le mir:ror n’est accessible que par root. Les droits du handler sont changés à la première utilisation de la fonction de détection (inclue dans l’outil et le module). Il serait certainement plus propre de coder un petit outil qui serait automatiquement lancé par udev ou hotplug au branchement du Mir:ror, mais pour un module PAM, ce n’est pas très important.

Génération du fichier utilisateur

Le même outil (read_mir-ror), va nous permettre de générer le fichier .authtag contenant le rfid propre à chaque utilisateur :

Pour l’utilisateur courant :

$ sudo ./read_mirror > ~/.authtag
$ sudo chmod 400 ~/.authtag

Pour un autre utilisateur  (toto):

$ sudo ./read_mirror > /home/toto/.authtag
$ sudo chmod 400 /home/toto/.authtag

Il faut bien entendu présenter la puce au lecteur juste après la commande ./read_mirror.
Le fichier .authtag doit maintenant contenir le tag :

$ cat ~/.authtag
0000D0081A025303420200D2

Module PAM  :  pam_mir:ror.so

Pour qu’il soit utilisable par PAM, il faut que pam_mir:ror.so soit présent dans /lib/security (lib64/security pour une architecture 64 bits)

$ sudo cp pam_mir-ror.so /lib/security

ou pour un module 64 bits :

$ sudo cp pam_mir-ror.so /lib64/security

La dernière étape va être l’ajout du module à PAM. Pour cela, il nous faut éditer le fichier :
/etc/pam.d/common-auth pour y ajouter, avant les modules pam_unix.so ou pam_unix2.so :

auth             sufficient         pam_mir-ror.so

/etc/pam.d/common-auth

#
# /etc/pam.d/common-auth - authentication settings common to all services
...
auth    sufficient                      pam_mir-ror.so
# here are the per-package modules (the "Primary" block)
auth    [success=1 default=ignore]      pam_unix.so nullok_secure
# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth    required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config

Avant de rebooter frénétiquement la machine pour voir ce que ça peut donner avec gdm,  je conseille vivement de tester sur une console (crtl-alt-F1 par exemple)… Comme expliqué en début d’article, nous touchons ici à une partie sensible du système et c’est mieux de garder la main pour éviter des pirouettes telles qu’un redémarrage en single user ou à partir d’un liveCD pour réparer.

J’ai fait en sorte que le module loggue un minimum. En fonction du système, ces logs sont visibles dans /var/log/auth.log ou /var/log/syslog.

Dernière version des sources : pam_mir-ror.0.2.tar.gz

]]> http://www.jopa.fr/index.php/2009/07/16/linux-pam-et-mirror-une-authentification-rfid/feed/ 11 http://www.jopa.fr/index.php/2009/07/12/violet-mirror-acces-device-c/ http://www.jopa.fr/index.php/2009/07/12/violet-mirror-acces-device-c/#comments Sun, 12 Jul 2009 00:22:12 +0000 Jopa http://www.jopa.fr/?p=1415 Dans mon précédent article, je présentais mir:ror, le petit lecteur RFID commercialisé par la société Violet.  Après avoir survolé leur application « Mirware » et mis en évidence les limites de son utilisation, je vais mettre « les mains dans le cambouis » pour essayer de comprendre comment communiquer avec Mir:ror.  L’idée étant de pouvoir coder de petits outils capables de réagir à des tags RFID.

D’un point de vu système, Mir:ror est directement reconnu sous Linux et accessible via le handler de périphérique /dev/hidrawX (où X est le numéro de périphérique, normalement « 0″ si c’est le premier appareil du genre connecté).

La petite application « discover-device« , fournie avec Mirware, permet de le détecter automatiquement :

Attention tout de même aux droits, le périphérique n’est par défaut accessible que par root, il faudra lui changer les droits ou utiliser le script « installer.sh » pour le faire, avant de pouvoir l’exploiter avec un utilisateur standard.

Commençons par voir ce qu’il se passe avec un simple « cat » du fichier :

Des hiéroglyphes s’affichent lorsque nous approchons ou retirons un tag… C’est plutôt bon signe, et visiblement c’est binaire ! Nous devrions y voir plus clair avec un affichage en hexadécimal.  Hexdump est idéal pour ça !

La première ligne (0000 0000 0000 0000 0000 0000 0000 0000 *) nous indique que tant qu’il ne se passe rien, on lit des zéros… Où…Qu’on lit des zéros tant qu’il ne se passe rien ! (c’est plutôt normal).
Les deux lignes suivantes (0102 0000 d008 1a02 5303 4202 00d2 0000 – 0000 0000 0000 0000 0000 0000 0000 0000) s’affichent lorsqu’un tag est approché, les deux dernières ( 0202 0000 d008 1a02 5303 4202 00d2 0000 – 0000 0000 0000 0000 0000 0000 0000 0000 ) lorsqu’on éloigne le tag.

Après plusieurs tests, j’en déduis assez facilement que les deux premiers octets (0102 ou 0202) codent l’évènement. J’en ai repéré 4 types :

• 0×0102 : Tag rfid détecté,
• 0×0202 : Tag rfid retiré,
• 0×0501 : Le mir:ror est mis à l’envert,
• 0×0401 : Le mir:ror est remis à l’endroit.

Les 12 octets suivants semblent identifier la puce RFID.

A titre de test, écrivons rapidement un petit bout de code C, prenant le device en paramètre et affichant les évènements et le tag associé :

// Jopa - Petit test du Mir:ror : test_mirror.c
#include <stdio.h>
#include <stdlib.h>
 
int main(int argc, char *argv[]) {
  FILE *mirror;
  short unsigned int block;
  short unsigned int event;
  char tag[25];
  int i;
 
  //Vérification du paramètre (device)
  if (argc!=2) {
        printf ("Usage : %s mirror_device \n\n",argv[0]);
        exit(-1);
  }
 
  // Ouverture du fichier device
  mirror = fopen(argv[1],"rb");
  if (!mirror) {
        printf("Accès à  %s impossible !\n",argv[1]);
        exit(-1);
  }
 
  // Boucle en lecture
  while (1) {
     fread(&event,2,1,mirror);
     if (event!=0) {
        // Evenement detecté, lecture de l'ID
        for (i=0;i<6;i++) {
            fread(&block,2,1,mirror);
            sprintf(&tag[i*4],"%04X",block);
        }
 
 //Affichage en fonction de l'événement
        switch (event) {
            // Tag On
            case 0x102 :
                printf("%s : ON\n",tag);
                break;
 
             //Tag Off
             case 0x202 :
                 printf("%s : OFF\n",tag);
                 break;
 
             //Mirror envers
             case 0x501 :
                 printf("MIR:ROR ENVERS\n");
                 break;
 
             //Mirror endroit
             case 0x401 :
                   printf("MIR:ROR ENDROIT\n");
                    break;
 
             //Default
             default :
                   printf("Evénement inconnu\n");
        } //switch
      } //if (event
   } //while (1)
} // main()

En quelques lignes, nous ouvrons le périphérique dont le handler est passé en paramètre et bouclons sur sa lecture, 2 octets par 2 octets.
Quand autre chose que « 0″ est détecté, c’est forcément un changement d’état. Nous lisons ensuite l’identifiant de la puce RFID.
La dernière partie affiche un message en fonction de l’évènement détecté.

Il ne reste plus qu’à le compiler et le tester :
$ gcc test_mirror.c -o test_mirror
$ ./test_mirror

Pour compléter l’exemple, nous pouvons rajouter l’exécution d’un script associé au tag et à son approche ou son éloignement. Les scripts pourraient être stockés dans le répertoire de l’utilisateur et porter l’<id>-on.sh ou l’<id>-off.sh comme nom. Pour l’exemple :

• 0000D0081A025303420200D2-on.sh : Lancement de Firefox sur le blog de Jopa

#!/bin/sh
firefox http://www.jopa.fr

• 0000D0081A025303420200D2-off.sh : Lancement de Thunderbird

#!/bin/sh
thunderbird

$ chmod +x ~/0000D0081A025303420200D2-*.sh

Adaptons un peu le code en ajoutant une variable pour le nom du script et une commande « system » dans le « switch/case ».

   // Jopa - Test Mir:ror
 
#include <stdio.h>
#include <stdlib.h>
 
int main(int argc, char *argv[]) {
  FILE *mirror;
  short unsigned int block;
  short unsigned int event;
  char tag[25];
  // Ajout d'un variable script
  char script[256];
  int i;
 
  //Vérification du paramètre (device)
  if (argc!=2) {
        printf ("Usage : %s mirror_device \n\n",argv[0]);
        exit(-1);
  }
 
  // Ouverture du fichier device
  mirror = fopen(argv[1],"rb");
  if (!mirror) {
        printf("Accès à  %s impossible !\n",argv[1]);
        exit(-1);
  }
 
  // Boucle en lecture
  while (1) {
     fread(&event,2,1,mirror);
     if (event!=0) {
        // Evenement detecté, lecture de l'ID
        for (i=0;i<6;i++) {
            fread(&block,2,1,mirror);
            sprintf(&tag[i*4],"%04X",block);
        }
 
 //Affichage en fonction de l'événement
        switch (event) {
            // Tag On
            case 0x102 :
                printf("%s : ON\n",tag);
                //Construction du nom de script et exécution
                sprintf(script,"./%s-on.sh",tag);
                system(script);
                break;
 
             //Tag Off
             case 0x202 :
                 printf("%s : OFF\n",tag);
                 //Construction du nom de script et exécution
                 sprintf(script,"./%s-off.sh",tag);
                 system(script);
                 break;
 
             //Mirror envers
             case 0x501 :
                 printf("MIR:ROR ENVERS\n");
                 break;
 
             //Mirror endroit
             case 0x401 :
                   printf("MIR:ROR ENDROIT\n");
                    break;
 
             //Default
             default :
                   printf("Evénement inconnu");
        } //switch
      } //if (event
   } //while (1)
} // main()

Ceci n’est bien entendu qu’un exemple, écrit rapidement et pas forcément très propre. Mais il permet de mettre en évidence la simplicité avec laquelle il est possible d’accéder à des informations RFID et ouvre la porte sur des développements qui peuvent être rapidement prometteurs.

Question coût, le mir:ror se trouve un peu partout pour un 50ène d’euros. J’ai déniché le mien en solde pour moins de 30 € – Tu vois chérie, moi aussi le fais les soldes  !!! – Dans un joli coffret, sont rangés le lecteur usb, 3 « timbres » autocollants (Ztamp:s) et 2 petits lapins (Nano:Ztag), tous munis d’une puce RFID.

Le lecteur fonctionne biensûr avec les objets commercialisés par Violet, mais aussi avec n’importe quel tags RFID, pourvu qu’il  respecte la norme ISO 14443 A ou B – La carte de bus/métro de Toulouse fonctionne parfaitement par exemple.

En utilisation standard, moyennant l’installation d’un petit logiciel (Mirware) et la création d’un compte (gratuit) sur le site de Violet, nous pourrons enregistrer nos objets RFID et associer une action à leur approche ou leur éloignement du lecteur.

Après tout ce vocabulaire « Nabaztanique« , il faut bien que j’avoue que ce n’est pas pour son utilisation standard que j’ai craqué, mais pour  les  perspectives prometteuses  offertes en terme de bidouillage : Authentification pam, évènements domotiques (X10), clef de chiffrement, on peut imaginer énormément d’usages « non-officiels » … et c’est ça qui est bon !

Néanmoins, dans la suite du billet, je vais balayer une installation classique du « Mirware » sous Linux. Il faut bien commencer par là ! Cette manipulation ne présente pas de difficulté particulière, à part peut-être pour les architectures 64 bits. Dans un prochain article, je m’intéresserai au développements possibles autour du joujou !

Mirware mon beau Mirware…

J’ai réalisé ce test sur deux machines sous Ubuntu (9.04 « Jaunty jackalope » ), l’une en 32 bits, l’autre en 64. Mais Mirware devrait fonctionner sous n’importe quelle distribution, le tout étant de bien installer les librairies nécessaires.

Dans les pré-requis, il faut bien entendu une machine sous Linux, disposant d’une interface graphique et connectée à Internet. En effet, Mirware fonctionne grâce au serveur Violet.net, sur lequel seront enregistrés les tags et les actions qui leurs sont associées.  C’est un peu limitant, mais comment dire….c’est comme ça ! Domage !

L’application est disponible ici en version alpha… On regrettera l’absence des sources, mis à part pour la partie concernant la détection du périphérique, ce qui va sauver l’installation sur une distribution 64 bits.

Je parlais de librairies, il nous faudra satisfaire quelques dépendances à ce sujet et en installer 3 principales :

• Qt 4.4 avec le module webkit,
• QCA 2.0.1,
• SDL 1.2

(cf le README pour plus d’infos)

$ sudo apt-get install   libqt4-webkit   libqca2   libsdl1.2debian

Nous pouvons à présent télécharger et installer le Mirware :

$ wget -c http://broad.violet.net/mirror/mirware.tar.gz
$ tar -xvzf mirware.tar.gz
$ cd mirware-0.9.9-1724
$ sudo ./installer.sh

Le script installer.sh, présent dans l’archive de Mirware, va juste caler les droits pour la détection du périphérique :

installer.sh ( pour information uniquement)

#!/bin/bash
[ "$(id -u)" -eq 0 ] || { echo "This script needs root credentials" ; exit 1 ; }
chown root discover-device || { echo "Could not change owner of discover-device to root. Do you have root credentials ?" ; exit 1 ; }
chmod a+s discover-device || exit 1
touch detected_device
 
echo "All done ! You can now plug a mir:ror and launch mirware-launcher.sh !"

Il ne reste plus qu’à connecter le mir:ror et  lancer mirware :

$ ./mirware-launcher.sh

Une icône dans la barre de notification indique que tout se passe bien. En approchant un objet du capteur, une fenêtre de connexion devrait apparaître, suivie d’un interface permettant d’enregistrer l’objet et de lui associer des actions (applications).

32 bits…C’est bien…mais 64 ?

Si vous utilisez une distribution 64 bits, il vous faudra recompiler le petit programme de détection du mir:ror : discover-device et installer les librairies utilisées par Mirware dans leur version 32 bits. Sans les sources et en l’abscence de version 64 bits, pas le choix…

Concernant la compilation de discover-device, rien de bien sorcier, il faut juste ne pas oublier de lui redonner les bons droits…
$ sudo rm discover-device
$ gcc discover-device.c -o discover-device
$ sudo ./installer.sh

Pour les librairies 32 bits, après avoir pas mal joué de l’apt-get, je suis tombé sur un script qui simplifie bien les choses (merci Cappy). Getlibs prend en paramètre un binaire et télécharge les librairies dépendantes dans leurs versions 32 et 64 bits… Le pied !

$ wget -c http://frozenfox.freehostia.com/cappy/getlibs
$ ./getlibs mirware

Pour clore ce chapitre…

…sur une utilisation classique du mir:ror, je peux ajouter qu’une grande majorité des actions proposées par le serveur sont fonctionnelles sous Linux… L’ouverture d’un dossier, le chargement d’une url, l’accès à la messagerie, à un podcast ou une webradio, la lecture d’un texte en texttospeech et j’en passe…

J’ai tout de même noté un problème gênant sur l’application permettant le lancement de scripts;  En effet, cette dernière ne sait gérer que des scripts Windows/Dos batch (.bat) ou des AppleScripts(MacOsx). Ce n’est pas très gênant pour l’utilisation que je compte en faire et comme promis, je détaillerai, dans le prochain article comment s’affranchir des contraintes du serveur Violet.net pour passer de l’autre côté du mirroir.

]]> http://www.jopa.fr/index.php/2009/07/07/violet-mirror-linux/feed/ 9 http://www.jopa.fr/index.php/2009/02/16/debian-5-lenny-is-stable/ http://www.jopa.fr/index.php/2009/02/16/debian-5-lenny-is-stable/#comments Mon, 16 Feb 2009 18:22:10 +0000 Jopa http://www.jopa.fr/?p=1180 Si vous trainez par ici, vous le savez probablement déjà… La nouvelle a déjà fait le tour des blogs : Pour la Saint-Valentin, la communauté Debian à offert à Lenny son status de « stable ».  ( La Saint-Valentin,  c’est le 14 février… ça, vous ne le savez pas forcément ! )…

www.debian.org

Mazeltov !!! Une toute nouvelle testing du nom de Squeeze est née…

Aujourd’hui, à l’heure des bureaux Compiz et Xgl, j’ai été heureux de découvrir que xsnow existait toujours, fonctionnait et n’était pas ridicule (pas trop !).

Nostalgiques et curieux devraient pouvoir l’installer à l’aide du gestionnaire de paquets de leur distribution préférée. Si ce n’était pas le cas, les sources sont disponibles à de nombreux endroits.

Ici par exemple.

]]> http://www.jopa.fr/index.php/2008/12/01/xsnow-nest-pas-mort/feed/ 5 http://www.jopa.fr/index.php/2008/11/29/scellement-de-fichiers-avec-tripwire/ http://www.jopa.fr/index.php/2008/11/29/scellement-de-fichiers-avec-tripwire/#comments Fri, 28 Nov 2008 23:10:34 +0000 Fade & Jopa http://www.jopa.fr/?p=860 Pour la surveillance d’un système, il est vital de savoir quand des fichiers sont modifiés, supprimés ou ajoutés. C’est une base indispensable pour s’assurer de l’intégrité d’une machine.
Tripwire est un outil de scellement de fichiers, il crée une référence du système  de fichiers et est capable de générer des rapports sur tout ce qui a bougé. Comme sous Unix/Linux tout est fichier, si quelque chose change, tripwire le voit !

La suite de l’article est issue d’une documentation co-écrite par ma collègue Françoise, initialement pour un usage interne.

1 – Installation

Sous Debian :

# aptitude install tripwire

Deux passphrases sont demandées pour la génération de deux certificats (site et local).

2 – Configuration

2.1 – Fonctionnement des fichiers de config

Les fichiers de configuration et de règles de tripwire sont sous forme binaire et signés par le certificat local.

• /etc/tripwire/tw.cfg
• /etc/tripwire/tw.pol

Ces fichiers ne sont pas éditables directement. Il faut passer par leur version texte qui ne doit, bien entendu pas être stockée sur la machine surveillée :

• twcfg.txt
• twpol.txt

Une fois le fichier texte édité, la commande suivante permet de générer le fichier binaire et de les signer (la passphrase est demandée).

# tripwire --update-policy -Z low fichier.txt

2.2 – Le fichier de règles (policy) : tw.pol / twpol.txt

Ce fichier permet de définir les répertoires à analyser et leur degré d’importance. Des alertes seront générées en fonction de la sensibilité des fichiers.

La structure et la syntaxe d’un fichier source (txt) de stratégie n’est pas très complexe… Le répertoire : /usr/share/doc/tripwire/examples/ contient des exemples bien détaillés. Il est possible de partir de ces fichiers et de les adapter. La mise en commentaire (#) permet d’annuler certaines vérifications, le « ! » permet d’empêcher explicitement la vérification de certaines arborescences.

Une fois la politique définit, il faut que tripwire la prenne en compte :

# tripwire --update-policy -Z low /etc/tripwire/twpol.txt
  Parsing    policy file: /etc/tripwire/twpol.txt
  Please enter your local passphrase:
  Please enter your site passphrase:
  ...

3 – Initialisation

L’initialisation permet de construire la base de référence du système, elle se fait par la commande :

# tripwire --init
  Please enter your local passphrase:
  Generating the database...
  *** Processing Unix File System ***
  ...

4 – La vérification du système et la mise à jour

4.1 – Vérification

Par défaut, Tripwire ajoute un script de lancement au répertoire /etc/cron.daily/. Le cron déclenchera ainsi une vérification d’intégrité journalière. Il est possible exécuter une vérification d’intégrité à tout moment grâce à la commande suivante:

# tripwire --check

Lors d’une vérification d’intégrité, Tripwire analyse les objets actuels du système de fichiers et leurs propriétés, grâce aux informations stockées dans la base de références. Les violations sont imprimées à l’écran et une copie cryptée et signée du rapport est créée dans /var/lib/tripwire/report/.

 # tripwire --check
  Parsing policy file: /etc/tripwire/tw.pol
  *** Processing Unix File System ***
  Performing integrity check...
  Wrote report file: /var/lib/tripwire/report/sd-xxxx-20071127-191046.twr

  Tripwire(R) 2.3.0 Integrity Check Report

  Report generated by:          root
  Report created on:            mar 27 nov 2007 19:10:46 CET
  Database last updated on:     Never

===============================================================================
Report Summary:
===============================================================================

Host name:                    sd-xxxx
Host IP address:              xxx.xxx.xxx.xxx
Host ID:                      None
Policy file used:             /etc/tripwire/tw.pol
Configuration file used:      /etc/tripwire/tw.cfg
Database file used:           /var/lib/tripwire/sd-xxxx.twd
Command line used:            tripwire --check

===============================================================================
Rule Summary:
===============================================================================

-------------------------------------------------------------------------------
  Section: Unix File System
-------------------------------------------------------------------------------

  Rule Name                       Severity Level    Added    Removed  Modified
  ---------                       --------------    -----    -------  --------
  Invariant Directories           66                0        0        0
  Tripwire Data Files             100               0        0        0
  Other binaries                  66                0        0        0
  Tripwire Binaries               100               0        0        0
  Other libraries                 66                0        0        0
  Root file-system executables    100               0        0        0
  System boot changes             100               0        0        0
  Root file-system libraries      100               0        0        0
  (/lib)
  Critical system boot files      100               0        0        0
* Other configuration files       66                0        0        1
  (/etc)
  Boot Scripts                    100               0        0        0
* Security Control                66                0        0        1
* Root config files               100               0        0        0
  Devices & Kernel information    100               0        0        0
  (/dev)

Total objects scanned:  19373
Total violations found:  2

===============================================================================
Object Summary:
===============================================================================

-------------------------------------------------------------------------------
# Section: Unix File System
-------------------------------------------------------------------------------

-------------------------------------------------------------------------------
Rule Name: Other configuration files (/etc)
Severity Level: 66
-------------------------------------------------------------------------------

Modified:
"/etc"

-------------------------------------------------------------------------------
Rule Name: Security Control (/etc/passwd)
Severity Level: 66
-------------------------------------------------------------------------------

Modified:
"/etc/passwd"

===============================================================================
Error Report:
===============================================================================

No Errors

-------------------------------------------------------------------------------
*** End of report ***

Tripwire 2.3 Portions copyright 2000 Tripwire, Inc. Tripwire is a registered
trademark of Tripwire, Inc. This software comes with ABSOLUTELY NO WARRANTY;
for details use --version. This is free software which may be redistributed
or modified only under certain conditions; see COPYING for details.
All rights reserved.
Integrity check complete.

Dans l’exemple, le fichier /etc/passwd a été modifié.

4.2 – Affichage des rapports

# twprint -m r --twrfile /var/lib/tripwire/report/francoiseD-20081123-204116.twr

On peut également utiliser twprint pour visualiser la base de données complète ou les informations sur un fichiers en particulier.
C’est très pratique pour avoir une idée de la quantité d’informations contrôlées par Tripwire sur le système.

Pour visualiser la base de données complète, entrez cette commande:

twprint -m d –print-dbfile | less

Pour avoir des renseignements sur un fichier en particulier, tel que /etc/hosts, la commande est la suivante :

  twprint -m d --print-dbfile /etc/hosts

4.3 – La mise à jour

Si la ou les modifications détectées sont légitimes, il faut remettre à jour la base. C’est l’option –update qui permet de le faire, en s’appuyant sur un fichier rapport.

# tripwire –update -Z low –twrfile /var/lib/tripwire/report/sd-xxxx-20071127-191046.twr

Tripwire ouvrira le rapport au moyen de l’éditeur de texte par défaut. (La configuration de l’éditeur peut être modifié dans le fichier twcfg.txt).  A ce moment, vous avez la possibilité de dé-sélectionner les fichiers que vous ne désirez pas inclure dans la mise à jour de la base de données. Les mises à jour proposées commencent par un [x] , avant le nom du fichier.

Added:
[x] "/usr/sbin/longrun"

Modified:
[x] "/usr/sbin"
[x] "/usr/sbin/cpqarrayd"

Si vous voulez spécifiquement exclure une violation valide afin qu’elle ne fasse pas partie de la mise à jour de la base de données, enlevez le x.

tripwire --update -Z low --twrfile /var/lib/tripwire/report/francoiseD-20081123-204116.twr
Please enter your local passphrase:
Wrote database file: /var/lib/tripwire/francoiseD.twd

5 – Maintenance

5.1 – Régénérer la Passphrase locale

twadmin -m G -L francoiseD-local.key -P nouvellepassphrase
The local key file: "/etc/tripwire/francoiseD-local.key" exists. Overwrite (Y/N)? y
Generating key (this may take several minutes)...
Key generation complete.

5.2 – Régénérer la Passphrase site

twadmin -m G -S site.key -Q NouvellepassPhrase
The site key file: "/etc/tripwire/site.key" exists. Overwrite (Y/N)? y
Generating key (this may take several minutes)...
Key generation complete.

5.3 – Signer et encrypter

twadmin --create-cfgfile -S site.key /etc/tripwire/twcfg.txt
Please enter your site passphrase:   NouvellepassPhrase
Wrote configuration file: /etc/tripwire/tw.cfg  

twadmin --create-polfile -S site.key /etc/tripwire/twpol.txt
Please enter your site passphrase: NouvellepassPhrase
Wrote policy file: /etc/tripwire/tw.pol

5.4 – Réinitialiser la base

tripwire –init

Liens utilisés pour la rédaction de cet article :

http://www.tu-chemnitz.de/docs/lindocs/RH9/RH-DOCS/rhl-rg-fr-9/s1-tripwire-install-rpm.html

http://www.linux-kheops.com/doc/redhat72/rhl-rg-fr-7.2/ch-tripwire.html

http://www.linux-kheops.com/doc/cours/jgourdin/outils-tcp-ip/Linux-tripwire.html