Dans ce papier (de 2009), Luiz André Barroso and Urs Hölzle (entre autres) de Google Inc. présente une introduction aux “Warehouse-Scale Computers” (abrégé WSC); une introduction aux grands datacenters du l’industrie du Web.

Alors certes c’est assez loin de notre quotidien (à la fois en termes d’échelle mais également en termes de métier car on ne construit pas tous les jours un nouveau datacenter) mais ce papier nous aide à nous projeter dans ce qu’est un datacenter chez les acteurs du Cloud d’aujourd’hui. Une merveille qui présente très certainement ce que seront nos datacenters traditionnels à terme, les impacts que cela aura sur les architectures applicatives.

L’objectif ici n’est pas de reprendre l’exhaustivité de ce papier de 90 pages mais de vous faire part des éléments, à mon sens, les plus marquants et qui s’articule autour de plusieurs axes :

• Présentation des concepts généraux d’un datacenter, ses services, son organisation (Alimentation électrique, gestion de climatisation…)
• Un zoom particulier sur les serveurs qui composent un datacenter
• Une analyse très détaillée des enjeux énergétiques associés
• Une discussion (et des études de cas) autour des TCO
• Un zoom particulier sur les pannes et leurs origines

#1 – “Architectural Overview & DataCenter Basics”

Peut-être étiez-vous au courant mais les datacenters sont souvent classifiés en plusieurs types, offrant des niveaux de redondance (et donc au final de disponibilité) différents.

• Tier I et II. Un seul acheminement de l’électricité et de climatisation. Offre une disponibilité < 99,7%
• Tier III. Les circuits de distribution électrique et de climatisation sont redondés (Actif/Passif). Offre une disponibilité < 99,98%
• Tier IV. Le redondance est en actif/actif, la disponibilité grimpe à 99,995%

Un datacenter (et ceux décrits dans le papier) proposent également une offre de services

• Power. Alimenter le système de climatisation, les serveurs…
  Ce papier est un trés bon moyen de comprendre le circuit de l’énergie électrique au sein d’un datacenter (et notamment les concepts de Uninterruptable Power Supply – UPS ou Power Distribution Unit – PDU).
  Nous en reparlerons ultérieurement mais c’est l’un des axes d’optimisation les plus importants
• Storage. Stocker les données
  Plusieurs systèmes possibles :
  - du NAS. De mémoire, le papier ne s’attarde pas trop sur l’utilisation ou pas de SAN (Difficile donc de savoir s’ils en utilisent ou pas et si non, si cela est du à des coûts prohibitifs ou des fonctionnalités inadaptées à ces architectures distribuées)
  - du Distributed File System s’appuyant sur des disques locaux. Ainsi la résilience est gérée par le Distributed File System (et la réplication au niveau applicatif des fichiers) et non par l’infrastructure “hardware” sous-jacente. A titre d’exemple, c’est un axe trés fort des solutions “NoSQL” ou même “in-memory datagrid”.
  En termes de disques, ce sont plutôt des “desktop-class” que des “enterprise-grade” principalement à cause de la différence de prix. Ce n’est pas sans rappeler l’étude de Google sur les taux de pannes des disques durs.
• Network. Transférer la donnée
  Bien entendu, pour optimiser les coûts, différents types de switchs, réseaux sont utilisés suivant que l’on soit “à l’entrée du DC” ou bien à l’entrée d’un rack.
  Les réseaux type Ethernet sont privilégiés à de l’Infiniband par exemple principalement pour des raisons de compromis entre performance et coût.

Ce graphique donne quelques éléments de mesures sur des métriques classiques (Capacité de stockage, bande passante, latence).
Ces métriques sont simplement agrégées du serveur (Local sur le graphe), au rack puis au datacenter (abrégé WSC dans la légende)

#2 – Hardware Building Blocks = Cost-efficient hardware

Cette étude propose une comparaison du ratio coût/performance de 2 types de serveurs (qui a été basé sur les benchs du TPC-C). Pour l’un, le Superdome (128 cores). Coût : 12 M€.
Pour l’autre, le Proliant (4 cores). Coût : 75 k€.

En somme, ce tableau compare le coût de la scalabilité horizontale et de la scalabilité verticale. Ainsi, la ligne “TPC-C price / performance” montre que le Proliant est 3 fois plus efficace (selon le ratio défini préalablement) que le Superdome. Ce ratio est encore plus important d’après la ligne “price/performance (server HW only)” qui retire de l’équation le coût du stockage et donc compare des “capacités de traitement”.

C’est un élément de comparaison qui omet un point : absorber le même “throughtput” avec les deux types d’infrastructure n’induit pas la même architecture. Là où le “Superdome” permettra de centraliser, l”option “Proliant” imposera de distribuer… Et distribuer imposera des communications entre process.

Dans le cas du modèle centralisé, les process partagent la même mémoire et la communication entre process est de l’ordre de 100ns (la figure précédente 1.3 le montre). A l’inverse et dans le modèle distribué, les process devront communiquer sur LAN (avec un ordre de grandeur de 100µs). Cela a forcément un impact sur les performances globales, impact montré par ce graphe (lisez bien la légende qui définit l’axe des ordonnées) :

Ainsi, un unique processeur 128 cores (représentant le Superdome) peut être de l’ordre de 10 fois plus performant qu’un cluster de 32 machines 4 cores (représentant un cluster de Proliant) si la communication entre process est élevé. C’est beaucoup moins vrai si la communication entre process est faible. J’avoue qu’il me manque une quantification de “communication élevée” et “faible” notamment pour pouvoir le transposer au Gossip Protocol que l’on utilise souvent dans des stockages distribués.

Ce papier va plus loin et compare ensuite la performance d’un cluster de Superdome avec un cluster de Proliant (toujours en fonction du niveau de communication inter-process qui du coup est distribuée) et démontre qu’à trés grande échelle (> 1500 cores) l’option Superdome ou “high-end server” n’offre plus de réels avantages de performance par rapport à l’option Proliant (quelque soit le niveau de communication inter-process). Rajouter à cela le coût : l’option Superdome ou “high-end server” n’est réellement plus intéressante.

#3 – “Energy and Power Efficiency” : le réel challenge

L’énergie est un sujet d’actualité, notamment à une époque où l’on parle d’énergie renouvelable. Cela traduit deux choses. La première est qu’il y a un enjeu fort autour de l’optimisation de l’utilisation qui est faite de l’électricité dans les datacenters. La seconde, conséquence du point précédent, une volonté voire une nécessité d’optimiser les coûts.

Un indicateur de cette efficience est donc défini ainsi (et adresse des domaines distincts de l’ingénierie) :

(a) PUE

James Hamilton en parle dans ce papier mais le PUE mesure l’efficacité de l’utilisation de l’énergie électrique (en quelque sorte, cela mesure la perte d’énergie entre l’électricité qui rentre dans le datacenter (ce qui est facturé au final) et l’énergie qui arrive effectivement au niveau des serveurs).

C’est donc une mesure de la qualité du bâtiment lui même et, en simplifiant un peu, la plupart des sources de surcoûts (et donc de dégradation du PUE) sont liées à l’énergie électrique consommée uniquement pour climatiser (entre 40% et 70% de l’énergie électrique). Il y a également des pertes d’énergie lors des conversions haut voltage (115kV) vers bas voltage (220V).

Ainsi, les meilleurs datacenters affichent aujourd’hui un PUE < 1.2 (la majorité étant vers 2 voire plus haut… Les axes d’amélioration sont alors doubles :

• améliorer l’efficience des transformateurs électriques types UPS (c’est assez loin de notre métier).
• limiter l’utilisation qui est faite de la climatisation (électrique). Cela peut passer par l’utilisation de refroidissements mécaniques (cooling tower) ou à eau mais aussi (et là on touche à un mythe) par des salles machines plus chaudes. Ainsi, on pourrait monter les températures jusqu’à 27°C sans voir une augmentation des taux de pannes (cette idée est également reprise dans cette étude de Google sur les pannes des disques durs)

(b) SPUE

Ce paramètre est finalement très proche du PUE mais au niveau d’une machine. SPUE pour Server PUE. L’idée est de mesurer l’énergie utile c’est à dire celle qui permet d’alimenter la carte mère, les disques, les CPU, RAM. On a ainsi une mesure de l’énergie perdue dans l’alimentation, le ventilateur etc…

La plupart des serveurs ont aujourd’hui des ratios entre 1,6 et 1,8 (autrement dit plus de 60% de perte) alors qu’à l’état de l’art, on devrait être à 1,2.

Ainsi PUE * SPUE donne une mesure de la perte d’énergie électrique. Un datacenter standard annonce un total de 3,2… Autrement dit pour chaque 1W utile, il faut injecter 2,2W supplémentaires…

(c) Measuring the efficiency of computing

On cherche à mesurer, sur l’énergie électrique qu’il reste pour alimenter carte mère, CPU, RAM, disques, la partie qui est effectivement transformée en travail : en somme la partie qui permet de répondre à des requêtes ou à exécuter des calculs…
On mesure ainsi un “Performance to Power Ratio” (qui est forcément dépendant de l’architecture physique de la machine). James Hamilton dans ce papier en parlait déjà : l’objectif est d’optimiser le “work done by joule”.

Dans ce graphe la performance est définie comme le nombre de transactions par seconde.

En bref, le ratio n’est pas linéaire. Un serveur qui fonctionne à 100% ne consomme que 30% de plus qu’un serveur en standby (Active idle). C’est la courbe bleue. De fait, le ratio (en rouge) tombe fortement et globalement un serveur qui fonctionne en dessous de 50% de charge “consomme plus qu’il ne travaille”…

Alors ce comportement pourrait être acceptable sauf que les serveurs passent la plupart de leur temps entre 10 et 50%… (je vous invite à aller voir page 55 l’étude qui l’explique). Dès lors le rêve serait une consommation proportionnelle à l’utilisation que l’on fait de la machine (Energy-Proportional Computing). En somme, si la machine est passive (idle), elle consommerait zéro Watt. On pourrait ainsi imaginer des serveurs proposant non pas une consommation linéaire en fonction de la charge mais des zones d’optimum. Typiquement, un optimum du ratio performance-to-power pour des charges entre 20 et 50%… exactement l’inverse de ce que l’on a aujourd’hui.

De façon plus proche, les prochains challenges autour de cette consommation énergétique touche au disque dur. Les CPUs ont beaucoup travaillé pour avoir une consommation proportionnelle à leur utilisation mais des composants comme la RAM ou le disque trés peu (page 59)

#4 – “Modeling Costs” : à un moment, il faut bien…

TCO, Capex, Opex… Autant de termes que l’on pourrait, de prime abord, considérer comme un sujet de financier ou de comptable mais qui, au final, sont bien des sujets d’architecture…

Cette section propose un modèle de TCO, des exemples de calculs mais surtout des éléments de métriques qui peuvent servir de base de comparaison avec d’autres solutions IaaS type AWS.

• Capex. Le Capex s’exprime en dollar per “critical watt”, autrement dit par Watt utile à l’équipement IT. Rappelez-vous du PUE et vous verrez qu’il faut plus de Watts que ce qu’on imagine… A ce jeu, un Datacenter coûte entre 10 et 15$ le “critical Watt” et est rentabilisé sur une période de 10 à 15 ans. En somme autour des $0,10/W par mois.
  A ce titre également, un serveur (alors bien entendu cela dépend du type de serveur, de sa consommation, de son prix et de sa période de rentabilité (autour de 4 ans) ) coûte $0,20/W par mois (pour un serveur de 4000$ amorti sur 4 ans).

Petit exercice de mathématiques Sachant qu’un serveur (2,7GHz, 4G de RAM) est utilisé en moyenne à 30% dans le mois (et donc consomme 190W d’après le graphe 5.3) et permet de servir 10 requêtes / seconde, est-il préférable d’aller sur EC2 ? La requête ramène une liste qui fait 30ko et le stockage n’est pas considéré.

• Opex. L’Opex est plus complexe à modéliser car il prend en compte le personnel pour exploiter mais aussi la sécurité, l’emplacement géographique, le coût des licences, l’administration.

#5 – Dealing with failures and repairs

Définir le niveau de fiabilité d’un système est fondamentalement un compromis entre le coût d’une panne (avec de l’évident comme par exemple le CA perdu mais du plus subtile comme le coût de réparation…) et l’investissement nécessaire à sa prévention.

A ce titre, la stratégie traditionnelle est basée sur l’utilisation de matériel fiable. C’est finalement souvent lié au fait que les applicatifs n’ont pas été architecturés pour être résilients à des pannes matérielles. C’est finalement plus simple. C’est également étrange car VonNeumann a démontré en 1956 que tous les systèmes fiables, ont été construits sur des composants non fiables.
Ainsi, certains systèmes ont été conçus pour accepter ces pannes, pour fonctionner avec des composants non fiables : des “low-end servers”. Dès lors, ces systèmes plus complexes présentent des avantages de coûts d’infrastructure (nous en avons parlé précédemment) mais aussi des avantages opérationnels (plus de fenêtre de maintenance, de déploiement…)

Principaux types de pannes et indicateurs

Les fautes peuvent être catégorisées :

• Corrupted. la donnée est perdue, impossible à regénérer
• Unreachable. Le service est down, impossible à accéder
• Degrader. Le service est disponible mais dans un mode dégradé
• Masked. Des fautes ont lieu mais elles sont transparentes pour l’utilisateur final (ce qui ne veut pas dire qu’elles doivent être transparentes pour l’IT en général…)

Au delà de la catégorisation, cela permet d’offrir différents indicateurs :
- Le yield dans le cas de Brewer. Il s’agit du pourcentage de requêtes réalisées.
- L’apdex dont parle le site apdex.org. Il s’agit du pourcentage de requêtes ayant le temps de réponse attendu.

Supervision de la performance

Il existe quelques outils (certainement trés “cutting-edge” ou de niveau académique) qui visent à superviser, diagnostiquer les problématiques de performance sur des plateformes distribuées.

Il sera intéressant de positionner tout cela par rapport au marché commercial (peut-être des solutions type Dynatrace).

Principales causes de pannes

Différentes études (dont certaines datent de 1990) ont démontré (et Google confirme)

que les principales pannes sont liées à des problèmes de configuration, de software ou même humain. Ce qu’à également montré cette étude issue de Recovery Oriented Computer project de Berkeley, c’est que le taux d’erreurs liées au system management n’a fait qu’augmenter (et je ne pense pas que cette courbe se soit inversée depuis 1993, nos systèmes étant encore plus complexes, distribués…)

Le lecteur averti aura noté que c’est un des axe d’amélioration dont parlent beaucoup les protagonistes de DevOps.

Et de conclure…

Difficile de conclure sur une telle densité d’information…Il est acquis que ces papiers permettent de satisfaire notre soif de curiosité.
Mais il faut également y voir un moyen de comprendre les problématiques de ceux qui font les datacenters. Je ne parle pas spécialement des sysadmins dont les problématiques nous sont familières mais de ceux qui font les buildings, achètent les machines, gèrent la climatisation, etc.
Il est vrai que cette échelle est rarement rencontrée. Il n’en reste pas moins vrai que l’enjeu énergétique est aujourd’hui réel dans nos datacenters et que ces datacenters sont trés certainement les images de ce que seront nos datacenters demain.
N’oublions pas également que ces études sont faites par ceux qui “font le Cloud”. Ce sont donc les datacenters dans lesquels nos applications “cloudifiées” (ie. dont l’architecture a été adaptée) devront fonctionner :
- le hardware choisit s’oriente vers du commodity server-class machines en partie car le ratio cout / performance est plus intéressant.
- la résilience se doit d’être gérée au niveau applicatif (sur la base du hardware choisi précédemment) et doit permettre de garantir le fonctionnement du service. C’est une des grandes leçons de noSQL : gérer la résilience au niveau applicatif (réplication JVM) plutôt qu’au niveau infrastructure (réplication SAN)
- l’écart de performance entre la RAM et le disque est réel (même avec des SSD). Dans le même temps, les capacités de RAM aujourd’hui sont proches du Tera. Enorme ! Il est fort probable que Big Data nous emmène vers ce débat.

Maintenant, repensons à tout cela ; les enjeux électriques, low-end server, le nombre de pannes associées à des erreurs humaines… Remettons-nous en mémoire les messages, les technologies ou pratiques autour de noSQL, DevOps… Reprenons nos architectures, nos systèmes d’information “traditionnels”… Ça change 2 ou 3 trucs non ? :o)

Suggestion d'articles :

1. Introduction à la Programmation Orientée Acteurs
2. Socle technique des applications Java EE : dans le WAR ou dans le serveur ?

En 2007 ITIL (IT Infrastructure Library), a lancé sa version V3 en devenant le référentiel le plus répandu de bonnes pratiques pour le management de services informatiques (ITSM). Il se focalise sur le « comment » gérer chaque phase d’un service, en contraste par rapport à des autres référentiels qui se focalisent sur le « quoi », ce qu’on doit gérer.

ITIL v3 élargit le périmètre en donnant une vue “cycle de vie” des services, par rapport à sa deuxième version (v2) qui se focalisait sur les processus pour le Soutien de Services (Service Support) et la Fourniture de Services (Service Delivery)[i],

Cet article vous présente d’une façon globale ITIL à l’égard de la version 3 en montrant son but, les bonnes pratiques proposées pour gérer chaque phase d’un service et ce dont il faut tenir compte pour l’adoption de ce référentiel.

Tout d’abord, qu’est-ce que c’est un service ?

ITIL entend par service « l’ensemble des moyens mis en œuvre pour produire de la valeur pour un client, sans que celui-ci n’en supporte ni les coûts spécifiques et supplémentaires ni les risques associés ». En conséquence, une relation client-fournisseur est établie, le fournisseur du service pouvant être interne ou externe à l’entreprise. Pour illustrer l’idée d’un service, voici une liste de services :

• Services d’hébergement (applications, bases de données, sites internet, …)
• Service de support et maintenance applicatif
• Services de messagerie (Email, chat, …)
• Service de connectivité (internet, vpn, …)
• Service de vidéo conférence et de téléphonie
• …

Pour quoi un référentiel sur le management de services informatiques ?

Les DSI et les fournisseurs de services externes doivent :

• Fournir des services à valeur ajoutée au métier
• Rendre un service de qualité en respectant les contrats de service et les coûts
• Augmenter la flexibilité et la rapidité du système pour intégrer les mises à jour des services existants et la mise en place de nouveaux services, tout en sécurisant l’existant

Pour atteindre ces objectifs il faut mettre en place une organisation horizontale de collaboration entre les différents acteurs (clients, métier, conception, développement, exploitation, qualité,…).

ITILv3 cherche à vous aider à assurer ce rôle de fournisseur de services d’une façon efficace et il vous fourni de bonnes pratiques pour savoir:

• Comment créer et gérer un portefeuille de services ?
• Comment concevoir des services qui donnent de la valeur (alignement métier-SI)?
• Comment améliorer et sécuriser les mises en production de nouveaux projets et de changements tout en préservant l’existant ?
• Comment traiter plus efficacement les incidents, événements et les problèmes dans le SI ?
• Comment gérer les changements des actifs et les configurations?
• Comment mettre en place des mesures et des indicateurs dans les processus de la DSI pour améliorer la gouvernance ?
• Comment assurer la disponibilité, la continuité, la sécurité, la capacité et la fiabilité de services ?
• Comment formaliser les compromis client-fournisseur et comment on définit des contrats de niveaux de service (SLA ou Service Level Agreements), contrats de niveaux d’exploitation (OLA ou Operational Level Agreements) et contrats de sous-traitance (UC ou Underpinning Contracts) ?
• Comment mettre en place une amélioration continue des services ?
• …

Alors ITILv3 vous propose :

• Un découpage du cycle de vie d’un service en 5 phases :

  

  Image 1.  Phases du cycle de vie

  Stratégie de services :

  Transformer le SI en un actif stratégique de l’entreprise en identifiant les besoins des clients pour définir les services qui produisent de la valeur et que respect le coût de fourniture. Il se traduit par la construction d’un portefeuille de services.

  Conception de services :

  Concevoir un service en prenant en compte tous les éléments liés au development et á l’exploitation. La solution doit réponde aux attentes du client, aux niveaux de service engagés et à ce qu’ils soient en phase avec la capacité de l’infrastructure et l’architecture du SI.

  Transition de services :

  Mettre en place de nouveaux services et de mises à jour dans un environnement de production d’une façon sécurisée et effective en préservant la bonne exploitation du système.

  Exploitation de services :

  Assurer la bonne fourniture du service aux utilisateurs en respectant les niveaux de services engagés. Assurer le monitoring du service, la bon gestion des incidents et des problèmes ainsi que le traitement de demandes de services et d’accès.

  Amélioration continue de services :

  Mesurer et suivre les différents processus de gestion de services pour aider à définir les actions correctives afin d’améliorer les services existants et son alignement avec les objectifs stratégiques.

• Une mise en place de processus standard pour chaque phase du cycle de vie et la création de 4 fonctions ou unités fonctionnelles:

Image 2.  Processus et fonctions ITIL v3

• Une définition des activités et interactions par processus

Image 3. Activités du processus de gestion des événements.

• Une définition de rôles et responsabilités par processus (Matrice RACI)

• Une définition de mesures et indicateurs par processus (KPI)

Ne pas oublier !

Si vous voulez implémenter ITIL dans votre organisation n’oubliez pas :

• De définir les objectifs organisationnels. L’objectif ne peut pas être « mettre en place ITIL », cette démarche doit répondre à un besoin d’amélioration dans l’organisation.
• De former et sensibiliser les acteurs pour que tout le monde soit familiarisé avec les termes, les objectifs et les gains qui emporte la démarche. ITIL implique un changement organisationnel et culturel au sein de l’entreprise donc il peut être difficile à implémenter si tout le monde ne partage pas la même vision.
• D’analyser votre organisation actuelle et identifiez le GAP qu’il y a par rapport aux meilleures pratiques pour identifier où ITIL peut vous aider.
• De définir une roadmap par phases en priorisant les processus qu’à la fois vous donne plus de valeur (pour atteindre les objectifs définis) et qui sont plus simples à mettre en place. Ne pas faire un « Big Bang ».
• De mesurer dès le début! La seule façon de savoir si vous atteignez les objectifs est de définir des indicateurs et mesures qui vous indiquent le progrès et la performance de vos processus.
• De mettre en place un cadre d’amélioration continue. Les processus ont besoin d’évoluer, d’être ajustés et d’être optimisés à travers le temps pour qu’ils soient bien adaptés spécifiquement à chaque organisation et qu’ils accompagnent les évolutions métier.

Complémenter ITIL

ITIL peut être complémenté et peut cohabiter avec des autres référentielles comme COBIT, ISO 27002, CMMI, etc. Des autres méthodologies comme le Lean peuvent encore améliorer les processus qui ont été mise en place (Lean-ITIL)[ii]. Un seul référentiel ne fait pas tout et même si dans sa version 3, le périmètre d’ITIL a été élargi, il ne couvre pas tous les aspects de la gestion informatique.

En conclusion

ITILv3 propose de bonnes pratiques pour comment gérer chaque phase du cycle de vie de services et pour faire collaborer d’une façon organisée tous les acteurs en mettant en place de processus et de responsabilités. D’après des études[iii] on a pu constater que cette démarche permet aux fournisseurs de services (internes ou externes) d’améliorer la qualité dans la fourniture de services et la satisfaction du client. Il permet aussi l’alignement métier avec l’identification et la mise en place de nouveaux services qui donnent de la valeur.

Le principal obstacle pour son adoption est qu’il doit faire face à la résistance aux changements organisationnels[iv]. Risque majeur des échecs qui peut être maitrisé avec la formation, la sensibilisation ou la certification[v] des acteurs au référentiel pour les aligner sur les buts et les bénéfices qu’ITIL peut apporter.

Il a été adopté par des entreprises comme NASA, HSBC, IBM, Telefonica, HP, BT entre autres et ses pratiques son le pilier pour acquérir la certification de l’organisation dans le standard ISO/IEC 20000[vi]. Ils existent beaucoup des sites web[vii] où on peut approfondir sur le contenu et le détaille de chaque phase et processus en plus des ouvrages officiels publiés par son organisme créateur l’office du commerce britannique (OGC).

Suggestion d'articles :

1. ITIL : Information Technology Infrastructure Library
2. La gestion des processus IT
3. Autres standards de gestion des processus IT

Principes

Les actions possibles

Un grand nombre d’actions sont ainsi possibles avec les outils de déploiement de configuration :

• Installer un paquet système (RPM, Deb, pkg…)
• Installer un fichier à partir du référentiel, en utilisant éventuellement un système de gabarits pour y placer des données dépendantes de chaque machine (exemple : l’adresse IP d’écoute du service)
• Mettre en place ou modifier une tâche planifiée
• Créer un répertoire
• Supprimer un répertoire/fichier
• Tirer un lien symbolique
• S’assurer que tel ou tel fichier/répertoire dispose de droits prévus
• Changer le montage d’un système de fichiers (local ou réseau)
• Et finalement, le saint Graal : lancer une commande quelconque. On comprend bien qu’il est simplement possible de faire tout et n’importe quoi
  • Reboot de la machine
  • Redémarrage d’un service
  • Déploiement d’un artefact
  • Initialisation d’une base
  • Import de données
  • Remise en marche d’une réplication
  • …

Exemples

À la Puppet :

file { "/etc/plop":
    owner => root,
    group => root,
    mode  => 644,
}

[...]
files:
"/tmp/patapouf"
create    => "true",
perms   => m_u_g("644", "root", "root"); 

body perms m_u_g(m,u,g)
{
mode            =>      "$(m)";
owners          =>      { "$(u)" };
groups          =>      { "$(g)" };
}

file "/tmp/something" do
 owner "root"
 group "root"
 mode "644"
 action :create
end

Utilisation

Modélisation de la configuration

# extrait d'un fichier de configuration cfengine v2
# déclaration des groupes
groups:
    sql_servers = (db1 db2 dev1) # 3 machines dans ce groupe
    web_servers = (www1 www2 dev1) # idem, dev1 est dans les deux groupes
    san_users = ( ReturnsZero(/bin/grep -qi san /etc/mtab) ) # groupe dynamique

# installation automatique de paquets
packages:
    any::
        # tous les systèmes ont systématiquement NTP et SNMP installés
        openntpd       action=install
        snmpd          action=install

    web_servers::
        apache2        action=install
    san_users::
        san_diag_package action=install

Et pour les DevOps, hmm ?

Conclusion

Les outils de déploiement automatisé apportent une très forte capacité à fluidifier et industrialiser des mises en production. C’est une brique qui se justifie souvent pour des tailles de parcs serveurs conséquentes et pour laquelle un ticket d’entrée est toujours à évaluer (en terme de temps et de compétences à acquérir).

Par rapport à l’utilisation du shell, qui restait à l’initiative de l’exploit’ et éventuellement à disposition des dev – et finit par former un véritable serpent de mer au fur et à mesure de l’ajout de fonctionnalités et de spécificités – nous avons ici de véritables outils communs pour le déploiement des applications. Par ailleurs, tout comme le shell, ces outils Open Source ont les défauts et qualités inhérents à leur écosystème : rapides à mettre en œuvre, légers, mais un peu spartiates dans l’utilisation ; et principalement cantonnés aux *nix.

Comme bien souvent, c’est l’organisation à laquelle l’outil participe qui fera le succès d’une mise en prod et non l’outil en lui même. Le mariage entre l’approche organisationnelle DevOps et ces socles techniques semblent très prometteur.

Suggestion d'articles :

1. Passer du shell à Puppet
2. Présentation de CFengine 3 le 8/12
3. DevOps ou le Lean appliqué aux activités IT du développement à la production

Nous avons vu dans les articles précédents comment ssh permettait à Bob de chiffrer ses connexions aux serveurs, comment sudo permettait de restreindre et de tracer qui fait quoi, et comment screen pouvait éviter à Bob de perdre du temps. Fort des ces outils, Bob a commencé à automatiser plusieurs tâches, mais se heurte à des problèmes d’échelle : taper une fois un mot de passe passe, mais cent fois trois mots de passe ne passe plus. Nous allons voir dans cet article quelques utilisations avancées de ssh. Bob, donc, n’a pas envie de taper plusieurs fois le mot de passe pour se connecter à un serveur. Il regarde la man page de ssh, et un grand sourire illumine son visage : il a trouvé. « Ils sont forts, très forts… »

S03E01 : Socket

Bob préfèrerait éviter de jouer avec les clés publiques / clés privées : il faut les déployer partout, et pour résoudre son problème (s’authentifier plusieurs fois par serveur) il faudrait les laisser en clair sur les serveurs, ce qu’il n’aime pas beaucoup faire. Ainsi le compromis « je tape mon mot de passe une fois au lieu de trois mais je ne laisse pas mes clés en clair » lui semble acceptable pour quelques serveurs. La première option qu’il a envisagée est d’utiliser des clés privées protégées par un mot de passe et d’utiliser ssh-agent pour n’avoir à saisir qu’une fois le mot de passe pour dé-sceller la clé. Certes c’est efficace, mais Bob choisit une autre méthode…

Selon la man page, il a le choix entre modifier les commandes ssh de son script et modifier le fichier de configuration de ssh propre à l’utilisateur qui lance le script (.ssh/config depuis le répertoire home de l’utilisateur en question). Après réflexion il décide de modifier son script, car modifier le fichier de configuration impose ce dilemme :

• Faire une configuration globale, qui ne sera utile qu’un petit nombre de fois
• Faire une configuration par hôte à contacter, ce qui peut s’avérer fastidieux en fonction du nombre de machines

Il ajoute donc à la première occurrence de ssh « -MS /tmp/%l-%h-%p », puis dans les suivantes « -S /tmp/%l-%h-%p » et dans la dernière « -S /tmp/%l-%h-%p -O exit ». Il relance son script, et tape le mot de passe… Une seule fois par serveur.

Quel démon du jardin magique Bob a-t-il invoqué pour que les choses se passent ainsi ?

[seti@home]~$ ssh server -MS /tmp/%l-%h-%p -Nf
Password:
[seti@home]~$ ls -l /tmp
0 srw------- 1 gab gab 0 avril 12 18:46 home-server-22
[seti@home]~$ ssh server -S /tmp/%l-%h-%p 'ls -p'
work/
recup/
[seti@home]~$ ssh server -S /tmp/%l-%h-%p -O exit
Exit request sent.


L’option -S de ssh permet de définir un socket (nommé) de contrôle, -M de dire que la commande ssh correspondante en est le maître, et « -O exit » de fermer ce socket. En d’autres termes : la première commande permet à ssh de créer un socket de contrôle ; il tape son mot de passe pour se connecter à la machine distante, mais ne lance par de shell dans un premier temps (options -Nf). Les invocations suivantes de ssh utilisent ce socket et donc les informations d’authentification, et la dernière permet de fermer ce socket. La socket UNIX ainsi créée permet de piloter la session SSH qui reste résidente. Les droits associés à cette chaussette sont par défaut limités à l’utilisateur uniquement, ce qui est plutôt une bonne chose.

S03E02 : Tunnels

Baignant dans la satisfaction qui sied à tout inventeur fier de son œuvre , Bob se rappelle un épineux problème qui touche l’architecture Web de son entreprise.  Architecture qui, basiquement, peut se résumer ainsi :

Il se trouve qu’il y a un problème sur le service Web, et soupçonne la couche HTTPS apportée par le mandataire inverse de contribuer au problème. Bob se dit que s’il pouvait, du navigateur de son poste, accéder en HTTP sans ‘S’ au serveur Web directement, ça pourrait le faire avancer dans la résolution de ce bug.

Bien sûr, il pourrait paramétrer le reverse proxy pour qu’il accepte le HTTP ou faire de violents trous dans le pare-feu de l’entreprise. Que neni, faire des modifications dans la sacro-sainte DMZ sera vu d’un très mauvais œil, et moins il touche la configuration de l’ensemble du système, plus il a de chances de trouver le bug et de tout remettre dans l’état dans lequel il l’a trouvé.

Encore tout électrisé, et se rappelant de la man page de ssh, Bob retourne la consulter ; il croit se rappeler que ssh avait quelques options qui lui seraient bien utiles. Jusqu’à maintenant lesdites options (et surtout leur description) lui avaient parues du lorem ipsum, mais après une seconde relecture, Bob finit par comprendre qu’il y a sans doute moyen de moyenner.

Il fait quelques essais sur un poste *nix (c’est tout de même plus facile), puis fait la même chose avec son PuTTY. Il retire la configuration du proxy de son navigateur, et hop ! Il accède au serveur Web, en clair, ou du moins, comme semble le penser son butineur jovial.

Allons bon… ssh serait donc si magique pour mettre en place un serveur Web sur le poste client ?

Presque pas, mais pas très loin.

Ssh permet, entre autres, de faire des tunnels TCP : l’option -L fait que ssh écoute sur un port sur la machine client, et transmet tout ce qui lui est adressé sur ce port à la machine à laquelle il est connecté, et de cette machine à une troisième machine qu’il est possible de spécifier. Schématiquement :

Et avec un exemple en ligne de commande, depuis ‘poste utilisateur’ :

[seti@home]$ ssh bob@serveur1 -L 8080:serveur2:80 -Nf

Que l’on traduirait par : connecte-toi à serveur1 en tant que Bob, ouvre le port 8080 sur ma machine et transmets tout ce qu’on t’y adresse au serveur2 sur le port 80, n’exécute pas de commande distante, mets-toi en tâche de fond une fois que c’est fait. Notez que par défaut l’écoute sur le port 8080 se fait sur localhost, et que le trafic ‘poste utilisateur’ -> serveur1 est chiffré par ssh, alors que le trafic serveur1 -> serveur2 est en ‘clair’. Pour accéder donc au serveur2 au travers de ce tunnel, Bob va donc taper dans son navigateur http://localhost:8080/.

Comble du raffinement et cauchemar des responsables sécurité, l’option -R propose exactement le même fonctionnement que l’option -L, mais en utilisant le tunnel SSH pour remonter un flux à rebrousse-poil. Cette fois-ci c’est la machine de destination (serveur1 dans notre exemple) qui se met à l’écoute de paquets entrants et qui les fait suivre au travers du tunnel SSH vers une machine accessible du poste utilisateur, ou le poste utilisateur lui-même bien entendu.

Bob, qui est maintenant depuis plusieurs jour sous ibuprofène à forte dose pour tenter de percevoir avec calme et sérénité le potentiel de ces deux options, finit par acquis de conscience la page de man et reste finalement en arrêt sur l’option -w. Cette option ne se contente plus de monter des tunnels unidirectionnels entre deux machines, elle met en place sur des machines *nix de part et d’autre des interfaces réseau virtuelles de type tun. Tout le trafic qu’il souhaite aura tout loisir de passer d’une machine à l’autre et vice-versa, pour peu qu’il ait mis en place des routes réseau adéquates. Un VPN directement utilisable en SSH, sans avoir à ouvrir de ports supplémentaires, ni à installer d’applications en plus, c’en est trop, ses nerfs lâchent.

Quizzz

Réponse au quizzz du billet précédent : screen réagit à une certaine séquence d’échappement et permet de changer le titre d’une fenêtre non-interactivement. Et d’autres termes : faites le bon echo, et screen changera le titre de la fenêtre.
printf "\ekTitre\e\\"
ou
echo -n -e "\ekTitre\e\\"
Si vous placez cette commande dans votre fichier de profile, le titre sera mis à votre fenêtre screen dès que vous vous connectez. Reste des problèmes :

• si vous ne vous connectez pas en screen le printf / echo affichera des choses pas belles,
• si dans le screen local (machine1) vous vous connectez à une autre machine (machine2) sur laquelle vous avez implémentez cette astuce, votre titre de screen (sur machine1) ne rechangera pas une fois que vous vous serez déconnecté de machine2.

Une solution est de tester la variable TERM de la session, d’agir en conséquence, et de mettre la séquence (\ekTitre\e\\) dans le prompt. Voici un exemple en bash à mettre dans votre .bashrc :

[ "$TERM" == "screen" ] && ST="\ek`hostname -s`\e\\" export PS1="[\u@\h]\w$ST "

Vous trouverez plus d’informations dans la man page de screen, section TITLES.

Conclusion

ssh, sudo et screen, au delà de tout autre outil système, rendent chaque jour d’immenses services aux administrateurs système, et leur font gagner en temps, en sécurité et en sérénité, à tel point qu’il nous semble délicat d’administrer efficacement des machines *nix sans eux. Un grand pouvoir impliquant de grandes responsabilités, ces facilités d’administration sous-entendent que vous compreniez ce que ces commandes font afin de ne pas laisser ouvert des failles (ou gouffres) de sécurité. Si vous ne connaissiez pas ces trois petits outils, nous espérons vous avoir mis l’eau à la bouche (et que, comme nous, vous ne pourrez plus vous en passer). Si vous les connaissiez, ce qui est plus probable, nous espérons vous avoir appris quelques astuces.

Suggestion d'articles :

1. Les 3 S de l’administrateur UNIX, saison 1
2. Les 3 S de l’administrateur UNIX, saison 2
3. OCTO recrute un(e) administrateur(trice) réseau, responsable help desk

Nous avons vu dans l’article précédent deux outils bien pratique : ssh et sudo. L’un permet de chiffrer une connexion à une machine, le second permet d’exécuter une commande sous le nom d’un autre utilisateur.

Nous avons laissé Bob dans un état détresse insoutenable : un coup de pelleteuse a coupé ses précieuses connexions au serveur distant, lui faisant perdre 1h de compilation, sa vérification des mauvais secteurs sur un disque de 1Tio, son environnement calé aux petits oignons et sans doutes un miroir. Bob aurait pu éviter tout cela s’il avait connu le 3ème S de l’administrateur Unix.

Extrêmement utile et pourtant si peu connu, screen permet de multiplexer plusieurs de sessions shell dans un seul terminal.

S02E01 : Screen

« Aha », me faites-vous, « mais moi je lance plusieurs onglets dans mon gnome-terminal et j’ai la même chose ».

Gnome-terminal (sous icewm). Remarquez que l'onglet de gauche porte le nom du serveur local, tandis que celui de droite celui du serveur distant

Bien entendu, ce serait trop simple.

Revenons à Bob. Après ce coup de pelleteuse en plein cœur, Bob, rentre chez lui et réfléchit à un moyen de ne plus perdre heures de compilations et environnements. Il passe un coup de fil à un collègue, qui, parce qu’il n’a pas que ça à faire, lui répond sèchement « man screen ».

Une fois chez lui, Bob saute sur son ordi et tape « man screen ». D’abord perplexe, Bob lit l’immeeeennnnse man page de screen, fait quelques essais et s’exclame « Ah OUAIS, quand même ! ». Il se connecte ni une ni deux depuis chez lui à son poste de travail, de là se connecte au serveur distant malade, lance sa compilation, la reconstruction des miroirs et le badblocks (retrouver les commandes avec les bons paramètres : 3 minutes), refabrique son environnement de test (retrouver les valeurs à mettre dans les variables : 15 minutes) et… Tue violemment son gnome-terminal, éteint sa machine et va se coucher (le sommeil, ça n’a pas de prix).

Quelle mouche a donc piqué Bob ? Pourquoi a-t-il éteint sa machine alors que les tâches distantes n’étaient pas terminées ? Aurait-il perdu l’esprit au bénéfice, certes, de son sommeil, mais tout de même ?

Un screen sur une machine (jhary), duquel part deux connexions à deux serveurs (rhynn et corum)

Screen, donc, est un multiplexeur de sessions : vous vous connectez à une machine distante, vous tapez screen, et vous avez une nouvelle session. De cette session vous pouvez en créer d’autres (Ctrl+a c), beaucoup d’autres, et ce sans avoir à vous connecter à nouveau à la machine. Vous pouvez passer rapidement de l’une à l’autre (Ctrl+a <espace>), les renommer (Ctrl+a A), remonter dans l’historique (Ctrl+a <escape>), et bien sûr y lancer des commandes.

Jusqu’ici, rien de mieux que gnome-terminal.

Il se trouve que si la connexion au serveur distant vient à être coupée, le screen distant, lui, vit toujours. Et vous pouvez vous (re)connecter plus tard à la machine, éventuellement d’un autre poste, et reprendre votre screen (screen -r). Vous êtes ainsi à l’abri d’une coupure réseau (mais pas d’une extinction de serveur : si ce dernier est éteint, votre screen meurt). Étant à l’abri lui aussi, et sachant qu’il pourrait regarder le résultat le lendemain, Bob a pu aller se coucher sans avoir à attendre la fin de la compilation.

Un petit dessin permet de vite appréhender le concept.

Connexions classique à un serveur distant. Une connexion => un shell

Connexion à un serveur distant avec screen . Une connexion => plusieurs shell

Voici un arbre de processus pour essayer de comprendre ce qui se passe :

root   ?        Ss   Feb28   0:00 /usr/sbin/sshd
root   ?        Ss   09:50   0:00  \_ sshd: arno [priv]
arno   ?        S    09:50   0:00      \_ sshd: arno@pts/1
arno   pts/1    Ss   09:50   0:00          \_ -bash
arno   pts/1    S+   09:51   0:00              \_ screen
root   ?        Ss   09:51   0:00                  \_ SCREEN
arno   pts/2    Ss   09:51   0:00                      \_ bash
root   pts/2    S+   09:51   0:00                      |   \_ tail -F /var/log/everything.log
arno   pts/4    Ss   09:51   0:00                      \_ bash
root   pts/4    S+   09:51   0:00                      |   \_ vim /etc/ssh/sshd_config
arno   pts/5    Ss   09:51   0:00                      \_ bash
arno   pts/5    R+   09:51   0:00                          \_ ps afxu

La session SSH est dans le tty pts/1 et lance la partie client (screen en minuscules). Si la connexion ssh est coupée, c’est ce client qui va finir prématurément sa vie, mais la partie pur multiplexage (SCREEN en majuscules) n’est rattaché à aucun tty (fonctionne en mode démon) et va donc résister aux pannes réseau. C’est donc ce SCREEN qui va lancer d’autres commandes et shell (bash dans le cas présent, avec des tty différents) dans lesquelles on va alors pouvoir jongler avec sudo au besoin. Dans cet exemple, le tail -f et le vim sont lancés avec les droits de root, alors que le ps utilise un compte standard.

S02E02 : screen, encore

Le lendemain, fier, Bob se reconnecte à son serveur, reprend son screen et appelle un collègue.

Il lui fait part de sa découverte de la nuit. Son collègue est ébahit et teste screen sur le même serveur que Bob.

Vous pouvez avoir autant de screen en mémoire que le permet cette dernière, vous pouvez nommer les screen afin de ne pas prendre celui d’un collègue (screen -S <nom>, screen -rS <nom>), vous pouvez les imbriquer (d’un serveur vous connecter à un autre et y lancer screen, dans lequel vous pourrez lancer des commandes) (Ctrl+a a <commande pour le screen imbriqué>).

Après avoir mitonné un élégant .screenrc (fichier de configuration de screen propre à un utilisateur), Bob décide d’assener le coup fatal à son collègue : il lui dicte une commande à taper (screen -r bob/27518), et Bob et son collègue se retrouvent dans le même screen. Un screen, deux claviers, des milliers de possibilités. Tout ce que tape l’un, l’autre le voit et peux le corriger. Il y a évidemment possibilité de se marcher sur les doigts (l’un tape un caractère, l’autre tape <del>) mais surtout de montrer à l’autre ce que vous êtes en train de faire sans avoir à l’expliquer au téléphone, et ce même si vous êtes à 800km l’un de l’autre…

Raffinement suprême : vous pouvez ainsi taper un mot de passe pour votre collègue sans que celui-ci ne le voit …

Ce qu’a fait Bob est activer le mode multi-utilisateur de screen (‘multiuser on’, dans son .screenrc) et autoriser son collègue à utiliser le même screen que lui (Ctrl+a : acladd <collègue>).

Fort de ces commandes, Bob décide de faire de la télégestion : il a un script (qu’il lance dans un screen pendant qu’il regarde les logs dans un autre) qui se connecte à ses serveurs pour y faire certaines choses (via sudo, notamment). Le problème est que son script doit se connecter 3 fois à chaque serveur. Bob, fainéant puisque Perliste, ne voit pas pourquoi il devrait le taper 3 fois son mot de passe alors qu’il se connecte à la même machine ; il voudrait ne le taper qu’une seule fois, voire pas du tout, mais sans toutefois laisser une clé ou un mot de passe en clair quelque part.

Nous verrons dans le dernier article comment aider Bob et lui indiquerons en prime comment faire passer tous les animaux de la savane par un trou de souris.

Conclusion

Screen est un multiplexeur de terminal. Il vous permet, avec un seul shell, d’avoir plusieurs sessions. ‘screen’ est la première commande que je tape en arrivant sur n’importe quel serveur Unix. Malheureusement elle est trop rarement installée, ce qui est extrêmement dommage vu l’utilité qu’elle a et le temps qu’elle fait gagner (ou plutôt : évite de faire perdre).

Quizzz

Plutôt qu’un bête bash (ou ksh) sauriez-vous faire en sorte que le nom du shell dans votre screen soit le nom du serveur auquel vous vous connectez ? (oui, comme gnome-terminal)

En ce qui concerne la quizzz du billet précédent :

Bravo à mangouste06 ! En effet vim est un outil qui a la fâcheuse fonction de pouvoir lancer des commandes externes (et donc par exemple un shell) avec la commande « ! ». Une fois un vim démarré, il suffit de taper « !bash ». Une première étape consiste à utiliser rvim plutôt que vim qui interdit l’exécution de commandes externes. Malheureusement, il n’empêchera pas l’ouverture d’un autre fichier, comme un script lancé au redémarrage, ce qui laisse une grande place à l’imagination. Pour ce genre de contrôle d’accès, préférer une gestion serrée des droits sur le système de fichiers, à base de groupes par exemple, ou des solutions à base de SELinux/grsecurity.

C’est pour cette raison qu’en paramétrant sudo il vaut mieux tout interdire et n’autoriser que certaines commandes plutôt que tout autoriser et interdire les commandes dangereuses.

Un tips pour la route, en ce qui concerne sudo : avoir un shell sous le nom d’un utilisateur qui n’est pas censé pouvoir en avoir (nobody, pour l’exemple) : sudo -u nobody bash.

Et pour finir cet article, un exemple de .screenrc (celui d’Arnaud, un des auteurs de l’article) :

shell bash
caption always "%{=b}%?%F%:%45=%n*%f %t%?%?%F%{r}%:%{s kk}%?%H%?%F%{-}%? %L=%-Lw%45L>%?%F%{g}%?%n*%f %t%?%F%{-}%?%+Lw%-17= %?%F%{y}%Y-%m-%d %c"
defscrollback 2000
scrollback 2000

Ce qu’il donne dans la vraie vie :

Voici l'exemple d'une sesssion screen. On se retrouve dans un terminal classique. Seule la barre d'information en bas trahit de la présence de screen. Les onglets (ici au nombre de trois) ont été configurés pour avoir des titres explicites, l'onglet actif est en vert. en rouge à gauche, la machine sur laquelle on se trouve, ce qui devient vite impératif quand on est en train de jongler entre les machines et les imbrications de screen.

Suggestion d'articles :

1. Les 3 S de l’administrateur UNIX, saison 3
2. Les 3 S de l’administrateur UNIX, saison 1
3. OCTO recrute un(e) administrateur(trice) réseau, responsable help desk

Ce billet est le premier d’une série de trois articles à propos d’outils que notre expérience nous pousse à considérer in-dis-pen-sable à tout administrateur *nix : S*, S* et S* (oui, nous gardons le suspens)

Généralement, les gens connaissent le premier. Un peu plus rarement le second. Le troisième, quant à lui, est généralement mal connu.

Loin de révolutionner les habitudes (quoique … ), voici une rétrospective des services rendus par ces trois outils et leurs cas d’utilisation les plus courants.

Voyons un cas classique d’utilisation des deux premiers outils. Pour ce faire, glissons-nous derrière notre ami Bob.

Bob investigue sur un incident de production qui vient d’arriver sur un serveur dans le centre de production situé sur un autre site. Il va devoir comparer différents fichiers de configuration, suivre des journaux en temps réel, arrêter/redémarrer des démons, peut-être faire une compilation, remonter un miroir RAID, bref la routine de l’admin.

Avant, Bob utilisait telnet. S’étant fait tiré les oreilles par son fils qui lui a démontré par A + WireShark que le mot de passe passait en clair, lui et ses collègues utilisent maintenant ssh.

S01E01 : Ssh

Ssh permet de se connecter à une machine en chiffrant la communication. Il est possible de s’authentifier à cette machine en login/mot de passe, clé publique/privée, ou d’autres méthodes plus ou moins fortes. Il peut faire bien bien plus que vous connecter à une machine mais pour l’instant cantonnons-nous à cette fonction : ssh permet de se connecter avec login/mot de passe.

Ssh est composé d’une partie serveur et d’une partie cliente. La partie cliente le plus connue sous *nix (et MacOS) est OpenSSH, implémentation du protocole ssh par l’équipe d’OpenBSD. Le client le plus connu sur Windows est PuTTY.

Bob se connecte donc en ssh sur le serveur. Avant il se connectait avec le compte root, maintenant aussi. Du moins essai-t-il parce qu’aujourd’hui ça ne fonctionne pas.

Il peste quelques minutes puis se rappel un mail envoyé par un des ses collègues. Il le retrouve et ce mail dit en substance que par mesure de sécurité le login en tant que root est désactivé (sage décision, soit dit en passant, car un éventuel attaquant devra ainsi deviner, pour se connecter, un login en plus d’un mot de passe, et même ainsi l’attaquant n’aura qu’un compte utilisateur standard) et qu’il faut maintenant se connecter avec son compte standard, et de préférence nominatif.

Bob se connecte donc avec son compte standard sur le serveur de destination et … s’aperçoit qu’il ne peut pas faire les tâches qu’il voulait (redémarrer des services, scruter les logs, … ) parce qu’il n’est pas root.

Un tantinet énervé par cette perte de temps, il appelle son collègue, lui hurle dessus pour lui demander comment faire pour se connecter en root. Pour toute réponse son collègue lui dit « man sudo » et raccroche.

S01E02 : Sudo

Ne connaissant pas sudo, il tente benoîtement ‘su’, qui ne fonctionne plus. « §$@&!!! Le mot de passe root a été changé ! » Il rappelle son collègue et atterrit directement sur son répondeur (il perçoit un rire sardonique mais peut-être n’est-ce que dans son imagination … )

Encore plus énervé, il se résigne à taper ‘man sudo’. Au fur et à mesure de sa lecture, les sourcils froncés de Bob s’écartent, se lèvent, et un sourire se dessine sur ses lèvres. A la fin de la man page il s’exclame « Ah ouais quand même ! », et exécute ses tâches d’administration … sans jamais devoir devenir root.

Exemple d'utilisation de sudo. Ici, la commande est autorisée et sudo est configuré, soit pour ne pas demander le mot de passe pour cette commande et/ou cet utilisateur, soit l'utilisateur a déjà fourni son propre mot de passe il y a moins de 5 minutes.

Comment ? Sudo permet d’exécuter une commande particulière sous un nom d’utilisateur particulier (sudo -u <utilisateur> <commande> ) (par défaut, cet utilisateur est root, et le mot de passe de l’utilisateur qui lance sudo est demandé avant l’exécution de la commande). Sudo inscrit dans les journaux système quelle commande a été exécutée par qui, et quand. Sudo pousse le raffinement jusqu’à permettre de préciser quelle commande avec quels arguments peut être utilisée par quelle personne en tant que quelle personne sur quelle machine. Il peut aussi ne pas être du tout raffiné et permettre à tout le monde d’exécuter n’importe quelle commande en tant que root et sans avoir à fournir de mot de passe.

Le collègue de Bob n’a fait que modifier le configuration de sudo pour que chacun puisse faire les tâches qui lui incombe, et uniquement celles-ci, et a enlevé le mot de passe de l’utilisateur root pour que personne ne puisse se connecter avec cet utilisateur, en console ou à distance (ce qui est le cas par défaut sur Ubuntu, par exemple). Il s’est également assuré que les ouvertures de session ssh directement sous root soient formellement proscrites en allant déclarer la ligne PermitRootLogin no dans le /etc/ssh/sshd_config et en redémarrant sshd. Le fichier de configuration par défaut de sudo (/etc/sudoers, a éditer impérativement avec visudo) propose en général des exemple de configuration très pratiques pour mettre le pied à l’étrier.

La journée passe, et une pelleteuse maladroite tranche le lien qui relie Bob au serveur distant (l’équipe réseau assure la main sur le cœur que pour cette fois ils n’y sont pour rien). C’est dommage : le problème sur le serveur était sérieux et Bob avait plusieurs connexions avec ce serveur : une dans laquelle tournait une longue compilation, une autre dans laquelle toutes les variables environnement étaient définis pour tester l’appli avec LA session qui la faisait crasher, une dans laquelle il y avait un badblocks qui tournait à la recherche de secteurs défectueux, et une dernière dans laquelle un RAID 1 se refaisait (une beauté dans) ses miroirs.

Conclusion

Ssh, dans son utilisation de base, permet de se connecter à une machine en chiffrant la communication, tandis que sudo permet d’exécuter une commande avec le compte d’un autre utilisateur. L’utilisation de ces deux commandes permet de sécuriser les échanges de données, et a fortiori les échanges de mot de passe, et permet une grande traçabilité des actions exécutées sur une machine.

Cette première étape permet à Bob d’administrer ces serveurs UNIX de façon plus sécurisée et avec une meilleure traçabilité, mais nous verrons dans la prochaine saison comment aider Bob, grâce au troisième S, à ne plus être gêné par les coups de pelleteuse et accessoirement par des problèmes de connexions réseau qui bagottent.

Le Quizzz

D’humeur taquine (qui a dit « vengeresse » ?) Bob, têtu, cherche à lancer un vrai shell en tant que root. Il sait que via sudo il est autorisé, en tant que root, à démarrer Apache (en exécutant la commande apachectl ou apache2ctl) et à éditer des fichiers de configuration (la commande vim est permise). Il a déjà essayé sudo su - ou sudo bash et son administrateur ne lui a pas permis ces commandes. Après quelques recherches, il parvient tout de même à passer root. Sauriez-vous comment a-t-il pu faire, en supposant qu’il n’existe pas de faille de sécurité permettant une escalade de privilèges ?

Suggestion d'articles :

1. Les 3 S de l’administrateur UNIX, saison 2
2. Les 3 S de l’administrateur UNIX, saison 3
3. OCTO recrute un(e) administrateur(trice) réseau, responsable help desk

Contexte

On avait jusqu’alors pour habitude de séparer le monde des administrateurs système en deux : celui du clic à la souris et celui de la ligne de commande. Les mondes Microsoft© et UNIX© s’opposaient fondamentalement.

Les fondements de ces deux approches dans l’administration d’un serveur repose à la base sur une volonté de répondre à des objectifs différents :

clic : je veux une interface visuelle et intelligible pour toutes les opérations, surtout si je ne sais pas trop ce que je dois faire.

ligne de commande : je veux des choses très unitaires que je puisse combiner et ainsi automatiser dans tous les sens.

Malheur à l’administrateur UNIX© qui souhaitait des belles IHMs. À moins de développer des solutions Web ou de s’appuyer systématiquement sur des consoles éditeurs aussi gourmandes que surchargées de fonctions, il est difficile de proposer des écrans d’administration intuitif. En revanche, lorsqu’il s’agit d’automatiser des tâches, notre cher sysadmin (ou root dans le cas présent) dispose d’un large éventail de possibilités. Plusieurs décennies ont permis d’affiner des outils aux noms aussi légendaires que courts : cat, sed, awk, grep, cut, tr, ls, sh et bien entendu les deux solutions miracles à tous les problèmes que sont vim et Perl. L’usage du pipe «|» est un exercice de gymnastique classique lorsqu’il s’agit de chainer plusieurs commandes à la suite.

L’administrateur Windowsien est généralement plus malheureux lorsqu’il va chercher à trouver la même puissance et la même flexibilité. Il est soit contraint de se battre avec VBscript, soit obligé de se lancer dans un vrai développement .Net.

Il y a quelques années, une tentative de la part de Redmond est venue semer la zizanie dans cette guerre de tranchée depuis longtemps enlisée.

Son objectif est de proposer des serveurs plus sécurisés et qui s’administrent et s’utilisent un peu comme des serveurs UNIX. Deux briques sont ainsi présentées : un système d’exploitation sans interface graphique (Windows Server Core), et un shell avancé permettant de pratiquer toutes les opérations d’administration possibles et imaginables (PowerShell).

PowerShell se positionne donc comme une brique très stratégique et pleine de promesses. Voyons plus en détail ce que l’on trouve sous le capot de PowerShell et s’il est apte à tenir ces promesses.

Même si la version 2.0 est désormais disponible, je propose ici un retour d’expérience sur la version 1.0 sur laquelle nous disposons désormais de longs mois d’utilisation, de codage et de déploiement dans des conditions réelles de production.

Livré en standard dans les versions serveur du système d’exploitation aux fenêtres (il est un pré-requis à bon nombre de briques), vous avez également la possibilité de le déployer sur des postes clients équipés d’XP/Vista/7 sous forme d’un auto-installeur. Les sites de recueil de tutoriaux, d’exemples et autres bonnes astuces fleurissent sur la toile.

Description

Le langage

Pour décrire cet outil, disons simplement que c’est une volonté de reprendre ce qui se fait de mieux dans les langages de scripts actuels. On y retrouve donc des bribes de Perl, Python, sh, Ruby. La liste pourrait être longue.

Il implémente le sacrosaint pipe «|» dans le but de chainer des commandes. La subtilité réside ici dans le fait que ce sont bien des objets qui sont transmis au travers du tuyau et non de simples chaines de caractère comme dans un Shell ou une session DOS classique. Il est du coup possible de faire des manipulations relativement poussées, d’autant plus que beaucoup de commande acceptent des données soit au travers de paramètres, soit au travers de leur entrée (et donc via le pipe).

Le nom des commandes est généralement composé de deux termes liés par un tiret «-» : Action-Objet, ou Action désigne généralement un verbe et Objet définit le type d’objet sur lequel l’action va s’appliquer. On arrive rapidement à devoir taper des commandes relativement longues.

La mise en place d’alias permet d’utiliser des fonctions via des noms courts. Et là, que l’on ne s’y trompe pas, on obtient un mélange de DOS/sh des plus hétéroclites : cat, cls/clear, ls, ps, kill, rm/del, rmdir, sleep, sort, man complétés par un ensemble de nouvelles fonctions propres à PowerShell.

La plateforme

Comme la plupart des langages de script, on a affaire à un langage interprété, ce qui prémunie des compilations explicites et permet des interprétations à la volée de code généré dynamiquement.

Un des points notable est que le langage est interprété dans la CLR (moteur d’exécution .Net, qui pourrait être plus ou moins comparé à la JVM), ce qui donne accès, presque mécaniquement à tout le fond de développement du monde .Net. Il est donc aisé de s’appuyer sur des briques classiques comme Log4Net pour gérer ses journaux, ou même de développer ses propres fonctions dans des langages .Net natifs (C# par exemple).

Pour illustrer cet atout, il est par exemple possible de produire en C# une HashTable d’objets .Net et la récupérer directement dans du code PS pour poursuivre le traitement, sans devoir passer par la case conversion/transformation.

En terme d’accès natifs, citons bien sûr les systèmes de fichiers, mais également la base de registres, les annuaires LDAP, les requêtes WMI, les objets COM.

Pour démarrer un PowerShell, soit on ouvre directement une console PowerShell, soit on lance d’abord une console DOS (cmd) dans laquelle on empile l’interpréteur PowerShell, comme on le ferait avec des Shell UNIX.

Les bibliothèques

Comme dit précédemment, il est possible d’utiliser n’importe quelle bibliothèque .Net préalablement produite dans n’importe quel langage de la suite .Net. Mais c’est dans l’intention que se trouve la nouveauté dans les bibliothèques proposées.

Un effort a été massivement consenti puisque les grosses briques d’infrastructure de MS fournissent systématiquement des extensions (appelées Snapins) pour PowerShell : Exchange, ActiveDirectory (Quest fournit d’ailleurs une bibliothèque très pratique à utiliser), IIS, SQL Server. Désormais, pour tout ce qui est faisable par une interface Graphique, une CommandLet (cmdlet) existe pour faire la même chose en ligne de commande ou par script.

On peut même aller plus loin en précisant que certaines fonctions avancées ne sont disponibles qu’en ligne de commande. On se retrouve donc dans un modèle qui se rapproche étonnement de celui d’UNIX.

Grande lacune de la version 1.0, citons le manque de méthodes d’accès à des interpréteurs PS de manière distante. On a toujours la possibilité de venir encapsuler des PS au travers de SSH/Cygwin/bash, au risque de se retrouver assez vite face à une situation des plus scabreuses en terme de gestion des droits, des interpréteurs, des environnements.

Quelques exemples

Voici quelques exemples de choses faisables. Je me place ici dans la position d’un UNIXien qui cherche à retrouver ses petits.

Commençons par le fameux «RTFM». La commande Get-Help (ou get-help, car le langage n’est pas sensible à la casse) associée à n’importe quelle autre commande retournera la page d’aide. Get-Help Get-Help vous retournera un équivalent du man man. On retrouve dans les pages d’aide des sections comme NAME, SYNOPSIS, SYNTAX, DETAILED DESCRIPTION, RELATED LINKS, REMARKS.

Ensuite, on va pouvoir passer à la consultation des alias en place pour découvrir quel est le nom de la vraie commande qui se cache derrière un nom plus court ou plus UNIX-aware.

PS C:\Temp> alias kill

CommandType     Name       Definition
-----------     ----       ----------
Alias           kill       Stop-Process

On le voit le formatage nous produit une sortie sous forme d’un tableau, ce qui laisse à penser que l’on a au moins 3 propriétés à l’objet retourné.

Passons à l’étape suivante avec l’utilisation du pipe qui va nous permettre d’appliquer ici un filtre.

PS C:\Temp> Get-Process | where { $_.ProcessName -eq "Powershell"}

Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName
-------  ------    -----      ----- -----   ------     -- -----------
    530      44    80372       3884   633    47,19   7748 powershell
    730      51   240740     255976   658   400,84  40756 powershell

Les puristes crieront que cette opération peut-être plus simplement écrite sous la forme ps -name PowerShell, mais l’objectif ici est d’introduire les notions de where et la variable automatique $_, qui ne surprendra aucun Perlist digne de ce nom.

Pour accéder au journal d’événements, là où un root ferait un tail -20 /var/log/syslog, un Administrator serait plutôt tenté de lancer la commande suivante :

Get-EventLog -logname application | select -last 20

Une fois le principe compris, nous allons pouvoir faire tourner des commandes directement utiles pour un administrateur.

get-MailboxStatistics | `
   where {"IssueWarning","ProhibitSend","MailboxDisabled" -contains $_.StorageLimitStatus} | `
   format-Table DisplayName,TotalItemSize

Dans cette commande, qui doit être exécutée sur un serveur Exchange, nous allons pouvoir collecter la liste des Boites aux lettres qui sont en dépassement de quota.

Voyons comment supprimer tous les contacts d’une organisation Exchange en une passe :

Get-MailContact -ResultSize Unlimited | Remove-MailContact -Confirm:$False

Ça y est, nous avons accès à des commandes dangereuses, puissantes, à donner des sueurs froides à tout responsable de production, le bonheur quoi.

Regardons plus en détail le langage en tant que tel. Rien de bien perturbant si ce n’est que l’on est souvent confronté à plusieurs approches pour effectuer une même opération. Exemple ici avec une simple somme des valeurs d’une liste.

$myList = $(8, 2, 5, 4, 10, 9, 34, 244)
$sum = 0
for ($i = 0; $i -lt $myList.length; $i++)
{
	$sum += $myList[$i]
}

$sum = 0
foreach ($i in $myList)
{
 	$sum += $i
}

$sum = 0
$myList | % { $sum += $_ }

Dernier petit exemple pour montrer les notations des fonctions, listes, dictionnaires et quelques-unes de leurs manipulations, sans autre intérêt que celui de la démonstration.

function TweakMyData([hashtable]$aDict, [array]$aList, [int]$aValue)
{
	$aList | % {
		if ($myDict.containsKey($_))
		{
			$myDict[$_] += $aValue
		}
	}
}

$myDict = @{"un" = 1 ; "deux" = @("item1", "item2"); "trois" = "tagada"}
$myList = @("un", "deux", 38)

write "avant:"
$myDict | ft

TweakMyData $myDict $myList 3

write "après:"
$myDict | ft

Et dans la vraie vie, qu’est ce que ça donne ?

Effectivement on peut à peu près tout faire

Dans le cadre de mise en place d’outils d’automatisation, d’alimentation automatique d’entrées comptes, de boites aux lettres de compte OCS, on arrive  à devoir chainer un ensemble conséquent d’opérations techniques. À ce jour, il a toujours été possible de le  faire en PowerShell. Parfois une commandlet fait tout en une passe, parfois il est nécessaire d’en chainer plusieurs, mais dans tous les cas on arrive à ses fins. On arrive assez vite à faire des scripts de plusieurs centaines de ligne de code pour traiter tous les cas de figure.

L’environnement naturellement distribué des infrastructures annuaire/messagerie conduit généralement à devoir gérer deux problématiques classiques : le manque d’atomicité des opérations globales (qui rend pénible les retours arrière) et les délais de réplication d’annuaire qui peuvent engendrer pas mal de surprises.

La gestion des erreurs est perfectible

En l’absence de structure de type try-catch-finalize, inutile de rêver, on s’arrache les cheveux avec des blocs trap.

Là où un shell UNIX n’offre que peu de solutions élégantes, on pouvait espérer d’un outil aussi récent une avancée plus impressionnante en termes de gestion des erreurs.

Si on le compare à d’autres langages de scripts/interprétés «modernes» (Python, Ruby), c’est selon moi un défaut majeur, qui semble-t-il a été comblé dans la version 2.0.

Le typage des objets est aléatoire

Comme la plupart des langages de scripts les variables ne sont pas vraiment typées et c’est dynamiquement que l’interpréteur essaye de comprendre les types d’objets à lire/produire. Là ou certains langages se sortent très bien de cette situation, PowerShell peine à rendre les choses simple. On arrive très fréquemment à devoir aider l’interpréteur à prendre les bonnes décisions à grands coups de [string].

Les performances sont mauvaises

L’utilisation systématique d’objets dans toutes les parties du code entraine une sanction sans appel. On en arrive du coup à devoir proposer un script épaulé par une bibliothèque dynamique écrite en C# qui vient implémenter des routines qui seraient bien trop lentes en PS.

L’effet est immédiat, car on parvient à rendre certaines portions de code plusieurs centaines de fois plus rapides.

L’impact est de devoir maitriser deux langages, dont l’un nécessite un environnement de développement complet pour être compilé, dommage.

La stabilité est discutable

Au moment où le comportement d’un script devient non reproductible, il est grand temps de fermer et relancer sa console PowerShell. Ce jugement, certes peu flatteur est malheureusement constaté soit directement dans une console, soit lorsque l’on développe dans l’éditeur multi-usage/débogueur qu’est PowerGUI (lui-même écrit en PS).

Fort heureusement, lorsqu’il s’agit de lancer des tâches planifiées en PS, on démarre un interpréteur tout neuf qui fait tourner notre script favori et finit par se terminer, on n’est donc généralement pas dans un cas d’utilisation problématique.

Conclusion

Je m’interroge sur l’objectif profond de la mise en place de PowerShell. Je suis partagé entre plusieurs sentiments.

Faut-il y voir une tentative d’attirer les UNIXiens vers la plateforme aux fenêtres ? Est-ce finalement un aveu de la suprématie indiscutable du modèle des scripts ? Un relent de réalisme face à la grogne des Administrators qui souffrent de ne pouvoir faire des traitements en masse ?

Quoi qu’il en soit, le fossé ne me semble que partiellement comblé. L’arrivée de PowerShell 2.0 apporte son lot d’améliorations, mais je me garderai bien des effets d’annonce sans avoir un réel retour d’expérience dans la durée, qui fera sans doute l’objet un nouveau billet.

Suggestion d'articles :

1. Mes bonnes pratiques en PowerShell v2
2. N’oublions pas Windows Mobile
3. La stratégie Windows Phone 7

J’ai eu la chance d’assister à une éclairante présentation de Philip Evans, Directeur Associé Senior, The Boston Consulting Group à l’Usi 2009 intitulée Stratégie 2.0.

Cette session m’a inspiré cet article, dans lequel je vous propose une brève introduction à ce qu’est un contrat horizontal et comment il peut bouleverser son marché. Dans une seconde partie je tente d’évaluer comment les offres de Cloud peuvent être considérées comme un tel contrat. Enfin je terminerai en vous narrant un scénario fictif décrivant un tel bouleversement, qui appelle deux questions.

Le contrat horizontal et l’histoire de l’IBM 360.

Le contrat horizontal désigne une norme (technique) qui facilite la coopération des acteurs de chaque coté de la norme. Phillip Evans estime que ces contrats, lorsqu’ils sont transverses à un secteur d’activité, favorisent la réorganisation des acteurs du secteur par couche (l’auteur parle de « Stack », à 1 minute 17). Prenons le cas des téléphones portables, la création d’une norme de chargeur pour mobile devrait permettre au marché de se réorganiser : les acteurs « fabriquant de chargeurs » vont pouvoir s’appuyer sur cette norme pour investir le marché.

Ce phénomène de réorganisation d’un secteur d’activité autour d’un contrat horizontal a pavé l’histoire de l’informatique, nous avons tous vécu au moins une révolution de cet ordre. L’exemple de la mise au point de l’architecture du système 360/370 chez IBM, présenté dans cette session est fondateur. C’est effectivement la mise au point de contrats d’interfaces (deux dans le document, un étant le jeu d’instruction machine, l’autre étant la standardisation des canaux vers les périphériques électriques) qui aura permis à IBM d’assurer la compatibilité et la modularité de leur production logicielle et machine. C’est également la mise au point de ces contrats, ainsi que leur exploitation effective, qui a transformé définitivement le marché des technologies de l’information.

(Notez pour la petite histoire que c’est au cours du projet Poughkeepsie préparant l’arrivée du 360 que le mot architecture aurait été utilisé pour la première fois en informatique).

C’est ainsi par exemple que la normalisation du jeu d’instruction X86 pour processeurs a permis a de nombreux constructeurs (Intel, Cyrix, AMD, VIA,…) de mener la compétition sur le marché désormais spécifique du processeur.

Mais bien d’autres exemples viennent rapidement à l’esprit avec les couches OSI et internet, JAVA puis les serveurs d’application, ou encore DirectX. A chaque fois une API, un contrat, qui galvanise le marché et lui offre l’opportunité de changer profondément d’une organisation verticale, avec quelques acteurs parallèles susceptibles d’adresser tout ou partie de la pile à une organisation horizontale, clairement segmentée avec les acteurs adressant un ou plusieurs étages de la pile. Cet effet d’empilement du marché favorise la concurrence par étage en permettant aux acteurs de se concentrer et d’échanger sur une base commune, en ayant la garantie que le sol ne va pas se dérober.
La compétition s’organise donc par étage, et plus par silo. Philip Evans ajoute à ce sujet à la fin de sa présentation que les règles de sélection économique sont bien différentes selon qu’on est en bas ou en haut de la pile.

Le contrat horizontal, aujourd’hui le Cloud

Cette idée de réorganisation du marché par le contrat horizontal est éclairante dans le domaine du Cloud. En effet les offres de Cloud des trois grands acteurs (Amazon, Microsoft et Google) proposent chacune un contrat qui permet de découper le marché horizontalement entre des fournisseurs de plateformes et le reste du monde.

En réalité le contrat n’est pas encore uniforme, chaque acteur proposant ses spécificités, mais on observe cependant une grande uniformité dans les services et le niveau des contrats proposés (l’uniformité va jusqu’au prix de ces services).

Pour illustrer ce propos, voici une déclinaison du modèle prototypique d’une pile selon Philip Evans,

protoptypique stack

appliqué aux trois offres :

Fournisseur	Implémentation de la pile Cloud

On observe que les deux contrats AppEngine et Azure sont sensiblement équivalents, et pourraient se traduire par : « Développez une application selon notre contrat, on vous garantit en retour qu’elle pourra être hébergée sur notre infrastructure que nous vous louerons à l’usage ».
Le contrat d’Amazon se situe un peu plus bas dans la pile, qui se traduit en remplaçant « Développez une application » par « Déployez votre Virtual Machine ».

Pour résumer, le contrat horizontal permet une transformation du marché, et les premières offres de Cloud définissent un contrat horizontal pour le développement et le déploiement d’applications. On peut donc s’attendre à ce que le marché de l’application ( construction, et exploitation ) se réorganise profondément. C’est un vaste sujet, qui fera l’objet d’un prochain article.

Le contrat horizontal et demain, YouAreTheCloud?

Fort de cette observation, et toujours au cours de cet USI 2009, j’ai été abreuvé de statistiques sur le marché de l’IT :

• 800 000 PC dans les datacenters Google
• 270 millions de foyers ont un accès haut débit
• Il y a plus d’1 milliard de PC dans le monde, deux en 2014

Les précédentes observations, ainsi que ces chiffres m’ont inspiré l’expérience d’esprit suivante (accrochez vous).

Une nouvelle compagnie  (qu’on appellera YouAreTheCloud.com) loue aux particuliers leur machine et leur bande passante afin de proposer un service équivalent à celui d’AppEngine ou d’Azure.

Pour le particulier :YouAreTheCloud.com vous demande de vous inscrire, d’installer un logiciel, et de laisser votre machine allumée et connectée. En échange, ce service vous paye, au pro rata de la bande passante, du CPU et de l’espace disque que le logiciel utilise. L’équivalent d’un SETI@home mais rémunéré. Est-ce que vous signez? (moi oui, sachant que je paye quoi qu’il arrive ma bande passante, et que je laisse parfois tourner ma machine à la maison, et si j’ai le choix de la bande passante, du cpu et du disque que je mets à disposition)

Pour le développeur :YouAreTheCloud.com vous propose d’utiliser l’infrastructure louée aux particuliers pour déployer à un prix défiant toute concurrence vos applications. Est-ce que vous signez? (moi oui pour toutes mes applications dont les données ne sont pas confidentielles)

Est-ce possible (techniquement)? vaste sujet, mais la plupart des briques nécessaires existent déjà en open source. On trouve déjà des outils permettant de faire un systeme de fichier distribué, l’équivalent de la BigTable, et des implémentations de MapReduce. Les serveurs d’application sont légion, les load balanceurs également. En fait même le SDK AppEngine est open source… Reste à packager l’ensemble et à héberger les serveurs master, restent aussi tous les problèmes liés à la gestion du fail over sur ce type d’infrastructure. Rien d’impossible.

Le résultat de cette expérience d’esprit, c’est que YouAreTheCloud.com est capable de proposer un service équivalent à ceux d’Azure ou GoogleAppEngine en s’appuyant sur une infrastructure louée aux particuliers.

Imaginons que cette offre ait un petit succès en convainquant 5 possesseurs de haut débit sur mille. Cela représente 1,35 millions de PCs au bas mot.

Comme les bonnes histoires présentent des situations grises, les clients développeurs ne sont pas au rendez vous, la plupart étant un peu frileux concernant la viabilité ou la sécurité d’un tel système, il essayent mais ne payent pas.

Pendant ce temps chez  YouAreTheCloud.com :

Les petits gars de  YouAreTheCloud.com sont maintenant à la tête d’une infrastructure équivalente à celle de Google. Ils se demandent comment ils pourraient exploiter cette gigantesque infrastructure, ajoutée à l’étage de service, et à celui de plateforme, gracieusement mis à disposition. Qu’en faire?

C’est là que Joe lance un jour à la machine à café : « et si on montait un système équivalent à Google avec un moteur de recherche et des liens sponsorisés, où on reverserait une partie des bénéfices aux particuliers? »
« Ouais! », réponds Bill, « scannons le web, indexons l’ensemble, on a l’infra pour, ouvrons une place de marché du lien sponsorisé, et reversons une partie des bénéfices aux particuliers à qui on loue nos machines. »
John, qui fait figure de chef, n’en perd pas une miette, et lance le projet, comme sa dernière bonne idée pour sauver la boutique.
Ce revirement fait un buzz incroyable dans la communauté, si bien que ce nouveau moteur de recherche commence à représenter une part des requêtes conséquente. Les marques s’engouffrent voyant là une belle opportunité de surfer sur le buzz et de se refaire une image en publiant sur un média tendance, et disons le, assez funky. Le système est lancé.

Demande d’aide

Et la morale de cette histoire me direz-vous?
Cette histoire m’inspire deux questions, pour lesquelles j’ai besoin d’aide, vos réponses m’intéressent pour élargir ma réflexion sur ces sujets.

Deux questions donc :

Le changement résultant de cette histoire à grande échelle sur lequel je reste dubitatif est le bilan écologique. Si il est probable que le bilan soit négatif en terme de consommation électrique dans la période de transition (à la consommation actuelle de Google s’ajoute celle des PC désormais utilisés par YouAreTheCloud.com), je m’interroge sur le bilan après cette période.

• Est-ce que le bilan écologique serait meilleur avec le search effectué par YouAreTheCloud.com ou par les datacenters des grands industriels de l’infrastructure?

La seconde question concerne la gouvernance de YouAreTheCloud.com.
D’un point de vue financier, les acteurs du Cloud doivent fairent des investissements massifs en infrastructure, à l’achat (les machines et les locaux) et en fonctionnement (l’électricité et les réseaux) .
Dans le cas de YouAreTheCloud.com, ces investissements sont directement assumés par les particuliers qui louent leur propre infrastructure. C’est donc une sorte d’actionnariat en nature, qui donne droit à des dividendes en fonction de la performance de l’entreprise. Très classique finalement.

• Mais cet actionnariat en nature devrait-il donner accès aux mêmes droits qu’un actionnaire a classiquement?  À moins? À plus?

C’est à vous!

MAG
PS: YouAreTheCloud.com est une société fictive.

PPS: Pendant la rédaction de cet article, un acteur Majeur, VMWare a fait l’acquisition de SpringSource.

Suggestion d'articles :

1. Petit-déjeuner Cloud Computing le 10 décembre
2. Les risques juridiques du Cloud Computing

Vous aimez que l’on vous parle ? Vos serveurs aussi. Mais trop de conversations simultanées fait mal à la tête, surtout quand personne ne finit ses phrases ; et il en est de même avec vos serveurs.

Présentation

Le syn flood est une attaque réseau faisant partie de la classe des DDoS (Distributed Denial of Service), qui elle-même fait partie de la classe des DoS (Denial of Service).

Comme tout DoS, l’attaque vise à saturer la machine (ou le réseau) attaqué afin qu’elle/il ne puisse plus rendre le service pour lequel elle/il est conçu-e.

Elle utilise la pile TCP, et elle consiste à ouvrir des connexions sans jamais les fermer.

Pour rappel: une ouverture de connexion TCP (TCP, hein, pas UDP) consiste en un three way handshake (poignée de main en trois étapes), dont voici le détail avec pour l’exemple les serveurs de nos stars mondiales, Alice et Bob.

ServeurAlice, poliment : Salut, ServeurBob, je peux te parler?

ServeurBob, s’il est disponible, et tout aussi poliment: Salut, ServeurAlice, oui bien sûr!

ServeurAlice heureux: chouette!

Et le serveur d’Alice dit ce qu’il a à dire.

Dans le texte, et sans le sous-titrage, ça donne:

A->B: paquet TCP avec flag SYN levé, à destination d’un port supposé ouvert, disons 80

B->A: paquet TCP avec flags SYN et ACK levés

A->B: paquet TCP avec flag ACK levé.

Quand le serveur de Bob reçoit le premier TCP SYN, il note dans un coin de sa têt … mémoire que c’est le serveur d’Alice (avec tel port source) qui lui parle, lui envoie un SYN ACK (là, la connexion est dans l’état half-open, semi-ouvert) et … attend la suite.

Suite, normalement, qui est soit un ACK signifiant que le serveur d’Alice désire réellement établir la connexion, soit un RST (reset, mettant fin à la connexion) signifiant que le serveur d’Alice, en fait, boude et ne veut pas/plus parler au serveur de Bob (et dans ce cas, le serveur de Bob libère la mémoire)

Le problème, c’est que bien souvent le nombre de connexions half-open est limité par le noyau de l’OS. Ça s’appelle la queue de backlog (à ne pas confondre avec le backlog que l’on utilse dans les méthodes agiles), et sur mon Linux (2.6.30) c’est le paramètre /proc/sys/net/ipv4/tcp_max_syn_backlog, et il est mis à 1024 (hé oui, mon Linux est une fille : il peut tenir 1024 conversations simultanées). Sur les Windows, il n’y a pas réellement de valeur par défaut mais il existe un mécanisme de backlog dynamique.

Supposons que le serveur d’Alice soit possédé par une malotrue jalouse, Eve, et envoie plein de paquets SYN au serveur de Bob, et ignore les réponses de Bob (ne renvoie pas le ACK correspondant). Dans ce cas, le serveur de Bob va allouer de la mémoire à ces connections half-open, envoyer les paquets SYN ACK adéquats, et attendre (que le caramel … )

Que se passe-t-il lorsque la taille de la queue du backlog est atteinte ? Si le serveur de Bob ne plante pas, il est en déni de service : il ne peut plus honorer les tentatives de connexion légitimes (d’Alice ou de ses autres ami-e-s)

Une attaque syn flood consiste à saturer le serveur de demandes de connexions pour justement provoquer ce déni de service.

Protection

Comme tout DoS, se protéger d’un syn flood n’est pas chose aisée, surtout quand l’attaque est en cours.

Mais cette technique étant relativement ancienne (mi 90) des mécanismes de prévention existent. Je vais décrire ici seulement les mécanismes que vous pouvez mettre en œuvre (il en existe que seul votre ISP peut implémenter).

Quand vous êtes sous le feu de l’attaque

Les écrans de monitoring de votre réseau vous indiquent que l’occupation mémoire de vos serveurs a grimpé en flèche, que le nombre de connexions simultanées est atteint, que le taux d’occupation de vos tuyaux crève le plafond, et votre pare-feu vous alerte qu’il y a bien trop de tentatives de connections ?

Si vous êtes chez vous, la led de votre box clignote comme une dingue et votre surf est lent (et accessoirement un tcpdump est bien trop bavard à votre goût) ?

Bravo, vous êtes en train de vous faire noyer.

Que faire ?

En tant qu’entreprise, les attaques syn flood sont monnaie courante. Et ce d’autant plus que vous êtes connu. La cause peut aller d’un piratin du dimanche qui s’ennuie chez lui parce qu’il pleut (dans ce cas le flood ne dure pas bien longtemps et n’est pas bien méchant, peut-être même que vous ne l’avez pas remarqué) à un réseau de pirates qui veulent vous faire chanter, et dans ce cas le flood peut durer plusieurs jours avec les conséquences que je vous laisse imaginer sur votre chiffre d’affaire et votre image.

Si les connexions arrivent d’un lot identifié d’adresses IP, il suffit de recenser ces adresses et de les bloquer pendant un certain temps : hé oui, ces IP peuvent être les machines de vos clients, entreprises ou particuliers, et leur interdire l’accès ad vitam aeternam n’est pas une bonne idée.

Si ce nombre d’adresses IP est conséquent, ce qui arrive le plus souvent, il ne vous reste plus beaucoup de choix:

• Faire le gros dos et attendre que l’orage passe. Ce n’est clairement pas la meilleure solution mais c’est parfois la seule …
• Vous pouvez essayer de trouver une sorte de logique dans les adresses qui vous attaquent. En effet il se peut que vous soyez attaqué par un botnet. Celui-ci étant composé d’ordinateurs répartis dans le monde, vous pouvez essayer de vous couper de la partie du monde d’où proviennent les paquets : n’autorisez que les adresses dont le plan d’adressage est dans la partie du monde qui vous intéresse. Chaque pays ayant plus ou moins ses propres plages d’adresses (cf par ici). Néanmoins cette attaque est inefficace si les malotrus sont rusés au point d’usurper les adresses et les mettre dans le plan d’adressage qui vous intéresse.

Avant d’être sous le feu de l’attaque

Le mieux est encore de mettre en place les mécanismes de protection avant de subir l’attaque.

Au niveau infrastructure :

• Il faut dimensionner votre infrastructure pour supporter ce genre d’attaque. Si vous pensez que votre brin d’entrée est suffisamment dimensionné pour supporter le trafic « régulier », pas beaucoup plus, il y a de forte chances que vous soyez sensible à ces attaques.
• De même si vos serveurs sont un peu justes en mémoire et cpu, et si vous n’avez aucun moyen de superviser ce qu’il s’y passe.
• Avez-vous pensé aux processus à mettre en œuvre si cette attaque vous tombe dessus ?

Plus bas niveau, et plus immédiatement actionnable, au niveau matériel :

• Le plus répandu, et le plus efficace, est de limiter le nombre de sessions half-open simultanées. Tous les systèmes d’exploitations ont cette possibilité. Mais surtout votre pare-feu cette capacité, sous un nom ou un autre, avec plus ou moins de raffinement dans le paramétrage. Vos routeurs ont sans doute aussi ces options.
• Dans la même idée, vous pouvez jouer avec les paramètres de la pile IP de votre système d’exploitation, ou ce que propose votre pare-feu : durée de vie d’une session half-open, d’une session tcp, … Sous Linux, visitez du côté de chez Swa… du côté de /proc/sys/net/ipv4/. La documentation se trouve dans les sources du noyau (Documentation/networking/ip-sysctl.txt) ou du coup sur le net. Sur les BSD c’est dans les paramètres du pare-feu (pf.conf). Sur Windows, il faut visiter la base de registre.
• Utiliser les cookies syn (non, ne téléphonez pas à votre (grand-)mère pour lui demander la recette … ) : l’idée est de ne pas allouer la mémoire nécessaire à la connexion dès le premier paquet SYN reçu, mais à la place renvoyer au client, dans le paquet SYN ACK, un numéro de séquence spécial (chiffrement des ports sources et destination, adresses IP sources et destination, et timestamp). Le serveur alloue la mémoire une fois la réponse ACK reçue, réponse qui doit contenir le bon numéro de séquence, bien sûr.

Conclusion

J’espère que cet article vous a instruit sur ce type d’attaque et vous a fait prendre conscience de la menace.

Les moyens de s’en protéger sont multiples (et variés) et vont du tuning de système d’exploitation à l’adaptation de votre infrastructure.

Les 31 Mars, 1er et 2 Avril se tenait le salon Solution Linux OpenSource. J’y suis allé faire un tour non seulement pour voir d’anciens collègues et visiter les stands des associations, mais surtout pour assister à une table ronde et des tutoriels qui m’intéressaient ce jour: Comment gérer son infrastructure virtuelle (table ronde du matin), le framework AJAX OpenExt et les RIA industrialisés avec PHP (tutoriels de l’après-midi). Je voulais voir comment ces sujets industriels allaient être traités par le Monde Libre.

Je vais scinder en 2 billets, afin de rendre la lecture plus digeste, et commencer, partie 1, par…

Comment gérer son infrastructure virtuelle

Table carré ronde avec comme intervenant: Oracle, Red Hat, Microsoft, Sun, Novell, Ikoula et Arkea.

Oui, il manque Citrix et surtout VMWare. On pourrait débattre longtemps sur leur absence et la présence de Microsoft, mais disons pour l’instant que ni l’un ni l’autre n’offre de solution open source et n’ont donc pas de raisons d’être présent à ce salon.

L’ambiance était assez étrange, ça m’a fait penser à un marché où chacun disait « ils sont beaux, mes poivrons! »: chacun cherchait clairement à défendre et vendre sa solution. Pour autant, chacun était respectueux des autres (il n’y a pas eu de lancé de troll)

D’Oracle, RedHat, Microsoft, Sun et Novell, chacun avait sa solution de virtualisation.

Présentation des chevaliers et de leurs armes:

• Virtualisation de serveur pour Oracle. Avec haute disponibilité de la base de données (par exemple) J’avoue ne pas avoir vraiment compris à quel niveau et de quelle manière Oracle faisait de la virtualisation. Ils disent ‘paravirtualisation’, mais ils n’ont pas cité d’OS. Quid des autres applications, dans ce cas? Supporte-t-ils tous les OS? Beaucoup de questions sans réponses…
• KVM pour RedHat: Pour rappel, KVM est un module noyau Linux qui permet à ce dernier de faire de la virtualisation et d’utiliser les instructions de virtualisations fournies par Intel (Intel-VT) et AMD (AMD-V). RedHat supporte donc KVM, en plus de Xen.
• Microsoft a sa propre solution: Hyper-V. Téléchargeable gratuitement. Microsoft est surtout fier de son module d’administration: System Center Virtual Machine Manager (est-il possible des pendre des marketeux pour manque d’imagination dans le choix des noms de produit?)
• Sun propose xVM: une famille de 4 produits: xVM Server, xVM VirtualBox, xVM Ops Center et VDI software, qui n’est « pas sec » (sic!).
• Novell propose Xen plus des outils d’administration, obtenus lors de l’achat de PlateSpin. Notamment Orchestrate.
• Ikoula, qui est un hébergeur, jouait le rôle de contre-pouvoir: Ikoula est « utilisateur » de la virtualisation.
• Arkea, éditeur de solutions de sauvegarde.

Débats

Une fois passé la présentation des éditeurs et de leurs solutions, plusieurs thèmes ont été abordés, dont voici quelques grandes idées:

• Ne pas tout virtualiser pour le plaisir (et surtout la base de données, en fait le seul mini troll de la table ronde),
• Penser à sécuriser physiquement (l’alimentation, par exemple). Virtualiser, c’est bien, mais ça rend l’infrastructure d’autant plus sensible au matériel,
• Problème de compétences internes. Virtualisation, donc nouvelle technologie. A-t-on les compétences en interne? Choix éditeur ou open source?
• Problème de coût de licences vs. coût du matériel. A étudier de prêt,
• Problème de stockage: les images disque prennent de la place…

Un point intéressant a été soulevé: celui du cycle de vie des machines virtuelles.

Comment les sauvegarder, par exemple? Cette question explique la présence d’Arkea, qui propose une solution de sauvegarde. Il faut penser à sauvegarder l’image de la VM mais aussi les données des applis qu’elle héberge: une image disque n’est qu’un gros fichier; endommagé il ne sert plus à grand chose. Et un fichier s’endommage plus facilement qu’un disque dur…

Mais aussi comment gérer leur prolifération? la tendance est à la multiplication des VM puisque c’est facile à mettre en œuvre. Microsoft annonce que le nombre de licences commandé à augmenté (je n’ai plus le chiffre en tête) »grâce » à la virtualisation. J’y vois là un symptôme: où avant on s’arrangeait avec l’OS qu’on avait installé, maintenant on virtualise … quitte à racheter une licence (virtualisation = facilité? quitte à payer? on n’est pas censé être en crise économique, normalement? :) )

Comment gérer un parc vieillissant? La virtualisation permet de garde en vie de vieilles applications, dispensant ainsi de les refactorer. Ça peut être un problème, ou pas, mais il faut avoir conscience que maintenir ainsi une vieille application sous perfusion virtuelle n’est pas forcément le meilleur moyen de la rendre pérenne, et n’est sans doutes que repousser l’échéance du refactoring… Et quid d’une VM qui n’a pas été allumée depuis des mois, de son patchage, de la mise à jour de ses applications et de l’OS? Cela ne va-t-il pas ouvrir une faille de sécurité dans votre SI, cet OS/appli non à jour?

Les ressources particulières que nécessite la virtualisation (stockages, formations, prévisions, …) nécessitent un capacity planning que les entreprises effectuent bien trop rarement.

Ikoula, une fois de plus pragmatique, suggère d’y aller calmement, de faire une étude sur la nécessité de virtualiser, sur les capacités du matériel à encaisser des VM:  10 VM sur une machine réelle ne communiquent que par 1 câble réseau réel qui n’aboutit qu’à un seul switch réel, d’où possibilité d’engorgement et d’atteinte des limites du … câble! Je n’avais effectivement pas réfléchis à cet aspect: tout virtuel qu’il soit, l’OS est hébergé par du matériel réel, qui a ses limites en termes de bande passante (réseau, I/O), stockage, mémoire, …

Conclusion

Je m’attendais, plein d’illusions, à de vrais débâts, j’ai assisté à un concours de « moi aussi je sais le faire ». Seul Ikoula apportait du réalisme face aux sirènes des éditeurs. Mais dans un tel schéma (une table de 7 éditeurs sur une estrade face une salle, pendant 2h) pouvait-il en être autrement? Le débat pouvait-il vraiment naître?

Pour autant les points soulevés étaient intéressants, et m’ont appris quelques choses:

• La virtualisation est un domaine relativement mature pour lequel il y a de l’offre, du déploiement jusqu’à la sauvegarde en passant par l’administration,
• Il faut se poser quelques questions de bon sens avant de virtualiser: coût (des licences OS et logiciel de virtualisation), compétences, matériel, nécessité, …

Moralité, la virtualisation n’est pas la solution à tous les problèmes, comme on aurait tendance à le croire. Les offres sont séduisantes, et plus matures que ce que je le pensais, mais ce n’est pour autant qu’il faut se jetter dessus, ce que j’ai l’impression que tout le monde fait. Avant de penser « aller hop hop hop zou je virtualise! » il convient de se demander si ça en vaut vraiment le coup/coût et si vous avez les capacité de gérer sur le long terme cette technologie particulière.

Suggestion d'articles :

1. Mon salon … linux (2/2)
2. Présentation industrialisation Java au salon Solutions Linux [MAJ 17/03]
3. Performances de build Java sous Linux ?