Solutions Linux 2007 Compte-Rendu des Conférences

, par  Olivier Duquesne aka DaffyDuke , popularité : 1%
Au boulot |

Déploiement

Déploiement à grande échelle d’une solution libre d’inventaire et de gestion de parc par Walid NOUH / Atos Origin

– Les slides de la conférence

L’exploitation de Linux à large échelle par Patrice LALLEMENT / RIFT

– solution à base de master de CD Rom : fragile, un master par site, assez statique. Nécessite des master par matériel. Long pour un déploiement à grande échelle.
– solution en client léger : il suffit de maintenir le server. Problème, sur la plupart des déploiements récents, il s’agit de postes lourds qui font tourner des applications déportées, ce qui revient à maintenir les deux solutions.
– virtualisation : chaque machine tourne dans une image virtuelle facilement déplyable et modifiable : xen/vmware/qemu .

Utilisation de Mondorescue (Disaster Recovery) par Bruno Cornec / HP

  • génération de CD/DVD/ISO , archivage au format lzo / gzip / afio (afio car l’archivage se fait fichier par fichier, alors que cpio s’apparente plus à tar) tout en prenant en compte la géométrie des disques (bientôt la configuration RAID grâce à l’intégration d’outils HP tels que hpacucli, hponcfg, conrep, TBC). Les images sont bootables dans un qemu.
  • basé sur mindi (mini-distribution Linux bootable)
  • interfaces en GUI ou ligne de commande
  • ABSOLUMENT PAS PREVU pour effectuer des sauvegardes.
  • restauration possible via CD/PXE/iLo
  • permet le changement de filesystem
  • possibilité de faire de la comparaison système courant / système archivé
  • possibilité de déploiement par clônage (attention au matériel)
  • Slide présenté à Solutions Linux

Supervision avec des logiciels libres

Par Bruno Paul Martin / Bull

Avant de pouvoir superviser un ensemble de machines, il convient d’identifier plusieurs éléments :
– établir un inventaire des éléments à superviser et des configurations :

– observer les journaux d’évènement

  • syslog-ng
  • OpenSIMS (Security Infrastructure Management System / gestion d’évènement de sécurité)

– définir des états de disponibilité et

  • des équipements
  • des services
  • Interfaces de monitoring :

    mon / MRTG [1] / Oreon

    (frontend Nagios, notion de SLAs) / cacti / ZenOSS (successeur de Crickett)

– effectuer des mesures de performance.

  • performance réelle : je roule à 52 km/h
  • performance sous condition : je roule 43 km en respectant les limitations de vitesse
  • performance limite : je peux rouler jusqu’à 210 km/h

– Il faut ensuite consolider ces différents indicateurs et établir des seuils de quantité/qualité/défaut/criticité.

– A la suite de quoi on peut ouvrir un système de gestion d’incident

– Présentation succinte de ZenOSS :

  • GUI pour la gestion, le reporting
  • Composé de modules : Zenmodel (conf), Zenrrd (collecte), Zenevents (monitoring)

Messagerie et Anti-Spam

Généralité et précisions sur le spam sous forme d’image, par Louis Nyffenegger / HSC

– D’après secuser 2006 : 95 % des mails sont des spams dont 30 % envoyés depuis des machines zombie.
– La plupart des méthodes antispam se basent sur des filtres baysiens. Ceux-ci se montrent particulièrement inefficace pour des images. Et que dire des spams via GPRS et voix sur IP. A l’heure actuelle, il s’agit essentiellement de texte sur fond coloré. Mais la difficulté à venir, c’est le texte sur fond de paysage, les gifs animés, les sons etc ...
– Un peu de métriques : sur 5000 spams ayant un score de 8 à 14, 2200 contenaient une image dont 70 images une seule fois, 1 image 10 fois, 1 image 1000 fois.
– Mis à part les filtres baysiens, on peut se baser sur des hash/md5 et faire apprendre manuellement les spams et les hams. Problème cette méthode est longue, et un md5 change si un pixel change. Le problème est similaire sur des comparaisons de signature.
– La parade efficace à ce jour est FuzzyOCR (plugin spamassassin)

  • il se base sur un datamining d’image (calcul moyen par couleur, géolocalisation de point, découpe et calcul)
  • Etude humaine avec kppv (recherche d’images proche)
  • Etude des kmeans : classification automatique en groupes de spams/hams, apprentissage par proximité : la qualité s’améliorant avec le nombre de groupes

– Les slides de la présentation

Méthode de filtrage par listes grises : milter-greylist, par Emmanuel Dreyfus / ESPCI, contributeur ipsec-tools

– Lié à une analyse comportementale d’un humain lors d’un envoi de mail avec mise en cache du triplet ip/adresse expéditeur/adresse destinataire et utilisation d’un délai maximal de réexpédition. Le courrier arrive donc en retard sauf s’il est déposé en liste blanche.
– milter-greylist est intégrable à postfix bien qu’initialement prévu pour sendmail.
– conséquence : croissance non négligeable de la file d’attente, des ressources qui ne sont bien entendu pas infinies.
– sont venues se greffer des règles de DNSRBL, de blacklistage/whithelistage, filtrage suivant le contenu
– on peut à terme imaginer le même genre de réglage mais par utilisateur dans une interface web par exemple, intégrer un système de statistiques, etc ...

QPMSTPD par Arnaud Assad / Cap Gemini

– qmail est un MTA pas complètement libre qui nécessite énormément de dépendances puisque son auteur a tout réécrit : syslog, mailq, bind etc ...
– qpsmtpd est un frontend perl qui permet de gérer en amont les spams, virus, hoax, chain mails et scams


– Exemple de plugins :

  • spam_ehlo : si ehlo yahoo mise en quarantaine, Yahoo ne s’identifiant jamais en tant que Yahoo.
  • ident_pof : identification de l’OS
  • geo_ip : Exemple de statistique
  • apache:qpsmtpd : permet d’utiliser apache en proxy smtp (fork un LISTEN en :25), il faut cependant créer un pseurdo qmaildir avant
  • check_earlytalker : vérifie les retour de code 2XX pour logguer/rejeter/etc ...
  • tarpits : garde une socket active si le MTA enrant est considéré comme spam

– Nettographie

Le projet SIGNAL-SPAM : Francis Bouvier / Direction du Développement des Médias

C’est une association crée en 2005 après une réflexion dès 2003 qui regroupe 7 autorités :

  • les institutions : la direction du développement des médias, la CNIL, le mninistère de la justice, l’office de lutte contre la cybercriminalité
  • des associations : l’AFA, l’AFOM (opérateurs mobiles), la BSA, la FEVAD (Vente à Distance)
  • des entreprises : SNCF, La Poste, Microsoft

– Il s’agit d’un outil de reporting de pishing, vol d’identité, arnaques sociales, réseaux criminels organisés.
– Contrairement à la boiteaspam@cnil.fr qui n’était qu’un document Excell, il s’agira ici d’une architecture web comblète avec un formulaire en ligne de dénonciation.
– Il permettra les recoupements avec d’autres services comme SpotSpam (Europe), CNSA, LAP.

Bases de Données

Exemple de migration Oracle vers PostgreSQL, par Ugo Brunel / BULL

– Utilisation d’un outil ora2pg
– Durée d’intervention : transfert d’environ 11 Go en une journée (prise en compte de tous les éléments même les archivelogs) , 19 j pour la réécriture du code (shell/php)
– retour d’expérience :

  • doublons de vues dans les schémas tolérés en oracle
  • séparation obligatoire des données des contraintes, index, et clés étrangères. Ces dernières sont à recréer à la main.
  • attention la configuration par défaut de PostgreSQL est prévue pour une machine à 64 Mo de RAM
  • en php5 est arrivé pdo, un connecteur base de données qui permet de faire abstraction de la couche de base de donnée façon jdbc.

– Les slides de la conférence

Retour d’expérience d’une migration Oracle vers PostgreSQL par François Debray / Socopa

– Socopa c’est quoi :

  • une entreprise agroalimentaire qui fourni les cantines, boucheries, grandes surfaces et fabricants de produits dérivés.
  • 23 sites, 8500 postes clients et 250 serveurs (AIX/Linux/Windows), administrés par 70 personnes

– Pourquoi ?

  • coût des licences
  • homogénéisation du parc
  • soucis de centralisation, portabilité et traçabilité

– Comment ?

  • déploiement de SAP sous Linux avec un connecteur EAI/Websphere
  • le sgbd devient alor PostgreSQL dans un
  • cluster heartbeat2 actif/passif avec synchro en drdb
  • passage de RedHat/Pg7.4 lors de l’étude à debian/Pg8 en production.

– La base de données

  • petite base (2,5 Go) mais qui nécessite une très haute disponibilité (gestion des automates en temps réel)
  • 3 millions de transaction / jour , un temps de réponse de 11 ms
  • 180 tables
  • coût de maintenance de 20 minutes/jour

– Les slides de la conférence

Exemple de migration Microsoft SQL vers Firefird par Philippe Makowski / A6-CMO


– Mode opératoire :

  • réécriture du code avec Database Workbench
  • création de la structure de base de façon manuelle dans un premier temps avec protection des triggers
  • utilisation de fbexport pour le dump

– Problèmes rencontrés

mssql
firebird
indicateurs 128 caractères
espace compris !		 31
booléens 1 ou 0 1 ou 0 ou
char(1) (T/F)
autoincréments indenté généré avec déclencheur
GUID (Global Unique Ident) uniq char(36), géré par la librairie UDF
performances lenteurs sur les vues, corrigées en firebird2
date du 1/1/1753 à 31/12/9999 du 1/1/100 au 29/02/32768
longueur de varchar() 8000 32767

– Intérêt ressenti de la communauté de communes (Bordeaux)

  • fiabilité
  • pas de maintenance
  • pas de tuning (le moteur firebird est prévu pour s’adapter à la configuration matérielle), les deux seuls paamètres modifiables sont la taille de page et la mémoire cache
  • le client windows se résume à une seimple dll

– Utilisateurs de Firebird

  • XpertMart / MindWrap / Tabulex / DRB Systems

– Netographie

Migration DB2 vers MySQL au Crédit Mutuel par Serge Frezefond / dir. tech. Mysql AB

– Outils

– Le cas du Crédit Mutuel

  • migration vers mysql de toutes les applications web (site institutionnel, courtage, voyages)
  • site de la banque en ligne (1,5 milliards d’enregistrements)
  • aggrégat de calcul
  • génération d’état comptable
  • utlisation des snapshot NetApp pour le clonage.

– A venir dans MySQL / Roadmap (extraits)

vues matérialisées 2007
roles 5.2
partitionnement 5.1
support XML 5.1
scheduler 5.1
moteur falcon 5.2

– A noter, MySQL Cluster permet de répartir une instance RAM sur la RAM totale d’un cluster, pas dans un serveur unique.

Virtualisation : Xen de A à Xen

Différentes solutions pour Linux par Nicolas Parpandet / 1G6

– Intérêts de la virtualisation

  • faire cohabiter plusieurs OS ou applications
  • facilité de déploiement : définition de modèle, copie aisée, indépendance matérielle / distribution de produits
  • économie du nombre de machines, réduction des coûts d’infrastructure
  • tests de portabilité dans les développements
  • sécurité : systèmes indépendants, montage de honeypots
  • assurer une continuité de service sur des logiciels abandonnés (ex : Windows NT4)

– Virtualisation de Système d’Exploitation

  • 1 seul noyau, 1 libc, 1 séparateur de process
  • problèmes de partage de ressources, isolation faible
  • solutions : OpenVZ, VServers, Chroot

– Virtualisation Système

  • BIOS / émulation matérielle / réécriture de code processeur à la volée
  • utilisation essentiellement personnelle pour des test d’OS/groupware/etc ...
  • généralement une seule image émulée par poste car très consommateur de ressources
  • solutions : VMWare (propriétaire), PearPC (Apple), QEmu (GPL, multiOS : simule x86/MIPS/SPARC/ARM/...)

– Virtualisation Machine

  • UML / User Mode Linux
  • 1 noyau exécutable, vu en tant que processus
  • utilisé par des hébergeurs ou des debuggers du kernel
  • intégré au kernel natif
  • faibles performances

– Paravirtualisation

  • mise en place de fermes de serveurs dans des mini OS
  • dissociation matérielle
  • création rapide d’images
  • utilisé pour de la mise en recette, qualification, pré-production
  • méthode sécurisée
  • performances idéales, limitation CPU/RAM
  • utilisation de snapshot
  • solutions, Xen : utilisation d’un hyperviseur, mini-noyau Linux, bon isolement, bonnes perf, utilisation des instructions Intel VT et AMD P6. Fedora a développé un Virt-Manager (GUI graphique)

– Virtualisation matérielle

  • Assez neuf
  • Virtualisation de CPU
  • solutions : VMWare-ESX (distribution linux avec vmkernel, avec une console d’admin graphique distante) , KVM (kernel 2.6.20)

XEN , comment çà marche ? par Daniel Veillard / Red Hat

– bref historique

  • développé initialement par l’université de Cambridge avec un dom0 sous Windows (fonds de la part de Microsoft)
  • présentation à l’Ottawa Linux Symposium 2004
  • révolution multiOS comparable à la révolution du multitâche.
  • caractère antinomique de la réduction des coûts ET des risques

– Architecture

  • un hyperviseur, un dom0 (tourne dans le ring 1 et 3 en archi x86 ou 3 uniquement en x64) et des domU (ring 3)
  • un bus entre les domU qui réparti les appels hyperviseurs
  • les drivers matériels sont en mode user, mais chaque appel système est trappé par un patch kernel lourd et intrusif depuis le 2.6.18, grace à une glibcx et une encapsulation en python.
  • le XenStore (base de données) : elle gère les accès concurrents entre dom0, domU et hyperviseur. Système de snooping qui s’apparente aux trigger des bdd classiques
  • le Xend Daemon : démon en C dans le dom0 d’où problèmes de perf.

– Ce qui marche

  • bonne isolation des machines virtuelles
  • bonne gestion des CPUs
  • migration à chaud : sur une appli web, le débit moyen est de 860 Mb/s , descend un peu pendant la copie à cause de l’utilisation CPU, redescend encore un peu pendant le test final de check d’intégrité final et propagation ARP, puis revient à son niveau initial.
  • de 0 à 10% de dégradation des perfs par rapport à une machine physique.
  • Utilisation de virtual device (iSCSI, LVM, NBD, éventuellement QNBD ?) : mais attention aux problèmes de cache disque durant les phases de migration.
  • Il existe un plugin munin pour le reporting
  • Il existe différentes interfaces de gestion de cluster : Enomalism, Virt-Manager, DTC-Xen

– Ce qui pose problème

  • L’hyperviseur est relativement instable car souvent réécri d’une version à une autre.
  • pas de copie par snapshot car la machine tourne en RAM, pas de stockage sur le filesystem (sauf éventuellement dans le cas d’utilisation de fs le permettant tels LVM ou GFS, à tester)
  • A noter toute machine émulée réagi différemment suivant qu’elle ait un kernel modifié ou un kernel natif puisque les appels systèmes ne sont pas trappés de la même façon par l’hyperviseur.
  • Le code est relativement neuf, le code pour la gestion matériel est incomplet
  • le patch kernel est très intrusif
  • on ne peut pas faire tourner Xen sur des plateformes de plus de 64 Go de RAM
  • Ne fonctionne décidément plus sur archi PPC64
  • depuis Xen3, max à 3 cartes réseaux. Celles ci supportent le bonding mais pas le vlan 801q . Pire que tout, la numérotation change parfois au reboot !

– A venir

  • virtualisation complète grace à l’implémentation de code QEmu au niveau CPU (Intel et AMD). Les développements sont longs car l’architecture x86 n’est pas révue pour.
  • virtualisation complète grace à KVM (natif en 2.6.20)
  • virtualisation comlète grace à lquest (en gros un QEmu dans le dom0)
  • une séparation du dom0 (type hurd)
  • Le rêve des développeurs : implémentation native d’une API commune libvirt qui serai commune à Xen, QEmu, et KVM ....

– La présentation complète à Solutions Linux 2007

Xen, mise en oeuvre industrielle, retour d’expérience, par Stéphane Grand / architecte technique au centre Open Source d’Atos Origin

– problématique initiale

  • empilement de serveurs
  • charge applicative de temps en temps, consommation souvent faible de ressources.
  • établir une normalisation de déploiement, méthodolgie, habilitation, gestion des privilèges, etc ...
  • calcul de coût : 9000 € pour 4 Go de RAM / 14 lames par blade / 7 blades
  • calcul énergétique : 1 serveur : 800 W / 1 blade 300 W + 14 lames : 4200 W

– Utilisation de Xen

  • pour des serveurs de déploiements : un socle Xen est installé via PXE, qui installe des images applicatives, elles même bootable via PXE pour installer une JVM en local ou sur une baie SAN, avec 1 vlan par ferme.
  • validation technique de la plateforme : 3 jours

– Notes

  • Les virtual machines doivent être réparties selon la criticité, de façon à rendre le service le plus redondant possible vis à vis des autres blades
  • chaque lame est doté de 8 Go de RAM : 512 Mo réservé pour le dom0 , 2 Go par JVM (serveurs JoNAS)

– Les slides de la conférence

Retour d’expérience pour le développement par Romain Couderc / Cap Gemini

– Utilisation

  • sert de montage de plateforme pour des études de faisabilité (Proof Of Concept)
  • Maquettage et avant-vente
  • Reprise d’activité
  • assurer une démarche qualité

– Réalisations concrètes :

  • Dans le cadre de l’OSS Partner, une plateforme sert à la hotline sur 2000 serveurs physiques qui ont été virtualisés : reproduction d’anomalies
  • Provisionnement : déploiement d’images LAMP pour des stations de travail sur différents profils (développeurs/administrateurs/...), et pouvoir faire de la veille technologique
  • Etude : bench i/o par exemple, choix techno de filesystem : GFS ou OCFS , montage d’IDS

Annexes

– Mes liens sur Del.Icio.Us
– La suite, Solutions Linux, vu de l’intérieur

Navigation

Publications Derniers articles publiés