Lorsqu’une architecture est conçue initialement, les concepteurs disposent d’un certain nombre d’éléments motivant un choix technologique par dessus un autre. Dans le cas du cloud computing, ces éléments ne sont pas fixés depuis une durée particulièrement longue et ne sont clairement pas fixés à des échéances au delà du moyen terme. La relative nouveauté du cloud computing devrait démotiver bon nombre de concepteurs d’architecture.

Dans le cas où le choix serait fait de se baser sur une architecture intégrée au sein d’un cloud quelconque, il est nécessaire de se poser très sérieusement la question de l’interopérabilité. Lorsqu’une entité va placer son architecture,  elle confiera d’une part ses données mais aussi le travail humain lié à la conception d’une plateforme. Ce travail humain a un coût relativement important en fonction de l’architecture en question. De sérieux problèmes sont à envisager dans l’éventualité d’une faillite de la société hébergeant le cloud ou même une catastrophe quelconque mettant à mal le cloud. La non-transparence des clouds actuels rend exceptionnellement compliqué l’évaluation de ces risques.

La problématique de l’interopérabilité se pose ainsi. Dans le cas où une entité utilisatrice utilisatrice d’infrastructure cloud souhaite changer d’hébergeur pour une raison X ou Y, en a-t’elle la possibilité ? Il y a bien sur plusieurs niveaux de réponse à cette question. Nous pouvons envisager une situation dans laquelle il lui est juste possible de récupérer les données applicatives ce qui impliquerait de devoir reconstruire la quasi totalité de l’infrastructure applicative. Nous pouvons également envisager une situation où il est possible de récupérer une version « packagée » des machines virtuelles ou, à l’opposé, une situation où rien n’est prévu pour être compatible avec d’autres plateformes.

De plus, ce n’est pas parcqu’il est possible de récupérer une machine virtuelle qu’il sera possible de l’exécuter sur une autre plateforme sans devoir se plonger dans les méandres du système d’exploitation pour peu que celà soit même possible.

Au final, l’interopérabilité est un enjeu majeur de toute plateforme informatique et suscite de nombreux débats habituellement. Les problématiques d’interopérabilité dans le cloud computing ne semblent pas encore avoir passioné grand monde ce qui est dommage car elle est bien réelle et existante. Le logiciel libre a clairement un rôle à jouer dans le cadre de cette standardisation avec les acteurs majeurs de l’industrie associée.

Qu’on apprécie OVH ou non, le nombre de serveurs qu’ils hébergent est réellement impressionant. Selon leurs dires, ils hébergeraient pas moins de 70.000 serveurs aujourd’hui et visent 100.000 d’ici à la fin de l’année. Selon Wikipedia, il s’agirait même du 5ème hébergeur mondial en terme de quantité de serveurs.

Leur succès est lié à leurs prix qui défient toute concurrence sur le marché des serveurs dédiés. Je ne connaissais absolument pas l’histoire d’OVH et ce qui faisait leur succès. La présentation suivante est une présentation faite par deux responsables d’OVH qui retrace l’histoire de leur société. Elle est particulièrement intéressante car elle détaille toutes les « astuces » qu’ils ont utilisé afin de pouvoir grandir au fur et à mesure. Vous y apprendrez par exemple que la quasi totalité des serveurs OVH sont refroidis par un système à eau.

FRnOG 15 – Comment héberger 70000 serveurs ? (part 1)

FRnOG 15 – Comment héberger 70000 serveurs ? (part 2)

Cette présentation est un bel exposé d’audacité et d’ingéniosité comme il en faudrait, surement, plus souvent. Il y a en tout une bonne heure de vidéo. Ceci est extrait d’une conférence FRnOG qui regroupe tous les grands opérateurs Français.

J’ai pu emprunter ce livre deux semaines à la Bibliothèque des Sciences et de l’Industrie située à l’intérieur de la Cité des Sciences. Je me suis tourné vers cette bibliothèque car il s’agissait de la plus proche de mon lieu de travail avant la reprise des cours. J’y ai cependant trouvé un large choix de livre récents traitant de nombreux sujets informatiques. J’avais plutôt été habitué aux livres poussiéreux des bibliothèques classiques. Je vous recommande donc ce lieu si vous passez dans le coin !

« Menaces sur le réseau » est un ouvrage traitant de la sécurité informatique au sens très large. Il a été écrit par un chercheur en sécurité informatique polonais qui explique les différents concepts avec une pédagogie exceptionnelle. Ce livre reprend rapidement les bases théoriques nécessaires à la compréhension des éléments techniques et vous explique différentes techniques d’attaques. Il est donc à lire si vous avez certaines bases en systèmes d’exploitation et en réseaux IP.

Ce livre permet de comprendre plus concrètement le monde de la sécurité informatique. Un exemple est l’explication du fingerprinting de systèmes d’exploitation dont l’auteur semble particulièrement friant. Vous comprendez quelles sont les traces laissées par les systèmes d’exploitation dans tous les paquets IP qu’ils émettent. Un autre exemple est le fingerprinting d’OS en se basant uniquement sur les ID des paquets IP, ce qui est pour le moins créatif mais surtout impressionnant. Grâce à une analyse statique graphique, l’auteur arrive à démontrer la possibilité de cette technique, intimement liée au fait que les ID ne sont pas générés tout à fait aléatoirement.

Au final, ce livre est à lire absolument pour tous ceux qui souhaitent s’intéresser à la sécurité dans le domaine des systèmes d’exploitation et des réseaux et qui ont quelques bases dans ces domaines. Pour ceux qui souhaitent s’intéresser aux aspects « management » de la sécurité, passez votre chemin.

Les dangers liés au cloud computing sont la conséquence directe de la dématérialisation des infrastructures physiques.

Tout d’abord, la première problématique est la localisation des données. L’abstraction des infrastructures physiques rend la localisation de données spécifiques significativement plus compliquée. Cette incertitude induit une sécurité pas forcément amoindrie mais certainement considérablement complexifiée.

Cette première problématique est évidente dans le cas des clouds publics ou privés-publics. Le client des infrastructures de cloud computing accorde une confiance totale aux prestataires en lui livrant toutes ses données. Bien que la plupart des argumentaires commerciaux mettent en avant une sécurité des données et, le plus souvent, un chiffrement, il est impossible de vérifier cela. Le client devient spectateur de la sécurisation de ces données.

Nous pouvons faire une exception à cette problématique dans le cas de clouds privés-publics. Ce cloisonnement reste tout à fait relatif. Ce cloisonnement peut être, dans le cas d’infrastructures « bas de gamme » seulement un mécanisme réseau tel que les VLAN. Ce mécanisme peut difficilement être considéré en tant que mécanisme de cloisonnement de données efficace.

Dans le cas d’infrastructures « haut de gamme », nous pouvons imaginer une architecture de type « cloud computing » exclusive à chaque client. Cette alternative se place dans le haut de gamme par le coût que cela engendre. Ce type d’offre permettrait, au passage, une plus grande flexibilité dans l’architecture à tous les niveaux.

Au final, la sécurité des données est une réelle problématique du cloud computing. Nous nous intéresserons plus tard aux problématiques d’interopérabilité des plateformes.

Nous distinguerons trois types de nuages. Le premier type, également le premier à être apparu sous la dénomination « cloud », est le nuage public. Le second type est le nuage privé. Le dernier type est un mélange des deux, c’est à dire, un nuage privé-public.

Le nuage public

La dénomination de « cloud computing » est arrivée en même temps que les grands nuages publics. Ces grands systèmes informatiques ont été rendus viables grâce à une forte automatisation et une grande efficacité des couches de virtualisation.

Dans ce type de nuage, chaque client se voit attribuer plus ou moins aléatoirement une machine virtuelle dans laquelle il pourra faire ce qu’il souhaite. Ces machines virtuelles sont soumises aux contraintes définies par l’hébergeur en fonction de ses conditions générales de vente. Chaque machine virtuelle est sensée être l’égale d’une autre et le client n’a que très peu d’amplitude pour la construction d’une véritable architecture.

Les nuages publics existant aujourd’hui ont essentiellement vocation à être des plateformes d’hébergement grand public à la manière d’OVH sur le marché des serveurs dédiés. Pour que cette comparaison soit valable, il est nécessaire d’exclure la diversification des offres d’OVH avec notamment la possibilité d’obtenir un firewall Cisco ASA. Il est peu probable qu’il soit possible d’insérer un Cisco ASA dans un grand nuage public.

La présence de l’open source dans les nuages public est très forte, surtout à travers de Xen. Amazon, Gandi, 1&1 et Rackspace sont tous basés sur Xen. Le marché des grand nuages public a peu de chance de voir une réelle présence de VMWare à cause de sa tarification. Je vous laisse imaginer le prix d’un cloud public VMWare…

Le nuage privé

Les nuages privés sont clairement orientés vers les entreprises. Il parait particulièrement improbable de voir une quelconque entreprise confier la totalité de ses données et de l’infrastructure informatique à une nébuleuse telle qu’Amazon.

Il me semble que la notion de nuage privé est quasiment équivalente à la notion de plateforme de virtualisation interne à une société. Dans ce type de nuage, la notion de « cloud computing » semble floue et la distinction avec une plateforme de virtualisation semble mince voire inexistante.

L’open source a un rôle à jouer sur ce type de nuages mais l’état actuel des choses ne le facilite pas. L’automatisation d’une plateforme Xen ou KVM nécessite un travail de développement conséquent même si des outils tels que le Xen Cloud Platform vont dans le bon sens. VMWare est désormais très présent sur le marché avec ses produits d’administration et d’automatisation VSphere et Virtual Center.

Le nuage privé-public

Le nuage privé-public est un nuage privé inséré dans une plateforme public. Ce type d’offre est encore relativement rare car le concept est plutôt récent.

Cette notion semble relativement équivalente à la notion de nuage privé placé dans le cadre d’une offre d’infogérance. Bien que les offres placées sous la dénomination « nuage privé-public » sont rares, les plateformes de virtualisation infogérées sont monnaie courante aujourd’hui.

Au final, je pense avoir fait le tour des différentes configurations de « cloud computing » que l’on peut retrouver aujourd’hui. Je pense également que toutes ces offres ne sont pas réellement révolutionnaires contrairement à ce que bon nombre de commerciaux souhaiteraient nous faire croire.

Dans cet article, je parlerais uniquement de BIND car il s’agit de la référence en terme de serveurs DNS. Je supposerais également que vous utilisez Linux. Et oui, BIND ça fonctionne également sous Windows. Je l’ai même déjà en production sur du Windows… Cela fait un petit pincement au coeur je vous assure.

dig

Le premier outil totalement indispensable est la commande dig. Elle permet d’interroger sélectivement des serveurs DNS. De plus, elle affiche une bonne quantité d’information quant à la requête effectuée. Cette commande sera donc particulièrement utile pour vérifier le bon fonctionnement de votre serveur DNS.

antoine@ks:~$ dig @ns0.infoclip.fr www.infoclip.fr
; <<>> DiG 9.3.4-P1.2 <<>> @ns0.infoclip.fr www.infoclip.fr
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47195
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; QUESTION SECTION:
;www.infoclip.fr.               IN      A
;; ANSWER SECTION:
www.infoclip.fr.        86400   IN      A       217.25.177.18
;; AUTHORITY SECTION:
infoclip.fr.            86400   IN      NS      ns0.infoclip.fr.
infoclip.fr.            86400   IN      NS      ns1.infoclip.fr.
;; ADDITIONAL SECTION:
ns0.infoclip.fr.        86400   IN      A       217.25.176.28
ns0.infoclip.fr.        86400   IN      AAAA    2001:1650:0:1001::2
ns1.infoclip.fr.        86400   IN      A       194.29.206.67
;; Query time: 5 msec
;; SERVER: 217.25.176.28#53(217.25.176.28)
;; WHEN: Fri Feb 12 10:23:54 2010
;; MSG SIZE  rcvd: 145

host

La commande host est un outil particulièrement utile pour créer des scripts utilisant des informations DNS. Elle permet d’afficher très simplement des informations en rapport avec un nom de domaine telles que les serveurs DNS d’autorité, les MX ou le SOA.

antoine@ks:~$ host -t MX lemonde.fr

lemonde.fr mail is handled by 5 smtp0.lemonde.fr.

lemonde.fr mail is handled by 10 smtp1.lemonde.fr.

antoine@ks:~$ host -t ns lemonde.fr

lemonde.fr name server nsc.bookmyname.com.

lemonde.fr name server nsa.bookmyname.com.

lemonde.fr name server nsb.bookmyname.com.

antoine@ks:~$ host -t soa lemonde.fr

lemonde.fr has SOA record nsa.bookmyname.com. hostmaster.bookmyname.com. 1265963399 43200 3600 604800 3600

named-checkconf

L’outil named-checkconf est fourni avec BIND par défaut mais semble relativement peu connu. Cet utilitaire permet de vérifier la syntaxe d’un fichier de configuration. En sachant que BIND est assez peu tolérant des erreurs, cet outil vous évitera quelques mauvaises surprises.

named-checkconf /etc/named.conf

named-checkzone

Une fois que la configuration de BIND est correcte, il est intéressant de vérifier les zones. Je pense que cette vérification doit être périodique car les erreurs passent facilement inaperçue dans les zones. Cet utilitaire va vérifier la syntaxe de vos zones.

named-checkzone domaine.tld /var/named/domaine.tld

Au final, je pense que ces quelques outils devraient vous permettre de pouvoir mieux diagnostiquer d’éventuels soucis de résolutions de noms de domaine.

Je me rends compte qu’il est nécessaire de modifier le fichiers de VirtualHost de tous les sites web du serveur Apache. Les Virtualhost sont les fichiers de configuration de site d’Apache. Au lieu de mettre « <Virtualhost IP> », il est nécessaire de mettre « <Virtualhost IP:port> ». Il n’était pas question de tout modifier à la main, il y a plus de 200 fichiers. Par sécurité, j’ai effectué une sauvegarde du répertoire sites-enabled. Dans ce cas, un script était nécessaire. Je code cela rapidement :

for i in `ls -1 .`; do cat $i | sed ’s/<Virtualhost IP>/<Virtualhost IP:port>/g’ > $i; done

Et là, c’est le drame.

Ce petit script est, hélas, syntaxiquement correct. Il remplace bien les deux chaines de caractère comme je souhaitais qu’il le fasse. Il a été exécuté en root car je travaille toujours en root par simplicité. Si vous regardez de plus près, vous remarquerez qu’il écrit dans le même fichier qu’il lit. Erreur fatale. Ceci signifie la suppression de tous les fichiers du répertoire courant. Tous. Tous les Virtualhost disparus. Quant à la sauvegarde du répertoire sites-enabled ? Inutile car ce sont des liens symboliques.

Houston, we have a problem.

Quelques minutes suffisent pour se rendre compte de l’erreur commise par ce script en apparence anodin. Les sauvegardes, me diriez-vous. J’apprends qu’elles sont en erreur depuis longtemps. Par chance, une copie de la machine virtuelle était présente sur l’ancien serveur VMWare duquelle elle avait été migré avant-hier. La récupération d’une bonne partie des Virtualhost a été possible jusqu’à ce point. Sauf que nous avions transféré 120 sites hier. Cette erreur n’a pas créé d’indisponibilité car Apache mémorise la configuration. Un restart serait par contre fatal.

Il ne reste plus qu’une solution : créer un script à partir de la configuration de l’ancien serveur pour recréer tous les Virtualhost créés hier. Deux heures de développement d’un script pas si simple dans un des langages les plus moches sur Terre : Bash. Une heure de debug du script. Après trois heures de stress intense et d’activité cérébrale, les Virtualhost avaient été recréés. Quelques Virtualhost ont du être récréés à la main car le script n’avait pas fonctionné avec.

Finalement, Apache accepte les Virtualhost créés par mon script. Je suis sauvé.

Je pense qu’il est important de tirer les enseignements de ses erreurs. Dans ce cas, il va falloir que j’apprenne à utiliser sed et à ne plus jamais scripter sur un serveur de production. Nous faisons tous des erreurs et nous devons donc nous assurer que ces erreurs seront inoffensives. Dans ce cas, la protection face à l’erreur a été inutile à cause d’un élément technique dont j’avais parfaitement conscience. Un petit moment d’inattention a suffit pour tout faire basculer.

Au final, il y a deux types d’administrateurs système : ceux qui ont déjà tout cassé à cause d’une erreur de script et ceux qui vont le faire.

A défaut de réussir à définir conceptuellement le cloud computing, nous allons essayer de le définir technologiquement. Cet exercice devrait être largement plus simple que le précédent car les ressources abondent sur ce plan. Comme vous vous en doutez déjà, il existe de nombreux types d’infrastructures physiques et applicatives placées sous la dénomination de cloud computing. Nous essayerons de faire une sélection des technologies réccurentes.

La virtualisation

Lorsqu’est évoqué la notion de cloud computing, la notion de virtualisation n’est pas bien loin. La montée en popularité du cloud computing coïncide largement avec la monte en popularité des plate-formes de virtualisation. Bien qu’il existe de nombreux types de virtualisation, la virtualisation de systèmes d’exploitation est la plus fréquente, de loin. Nous pouvons affirmer de manière relativement sûre que la base essentielle du cloud computing est la virtualisation de systèmes d’exploitation.

La virtualisation de système d’exploitation n’est cependant pas un phénomène récent. Les premières applications de VMWare datent de 1998. L’amélioration des processeurs x86 n’est certainement pas étranger à ce phénomène avec la multiplication et la densification des coeurs de calcul. La montée du cloud computing est sans aucun doute liée avec la montée en puissance des applications d’automatisation des plate-formes de virtualisation. Cette automatisation permet une flexibilité exceptionnelle et une réactivité dans l’évolution du cloud.

La place de l’open source

Alors que l’on pourrait croire que l’acteur le plus populaire dans ce domaine est VMWare, la réalité ne confirme pas cette intuition. L’open source joue un rôle essentiel dans le domaine du cloud computing à travers l’hyperviseur Xen. Le cloud publique d’Amazon est basé sur le projet Xen tout comme l’offre de serveur virtuel privé de Gandi. Cette adoption massive peut probablement s’expliquer par la nature open source de l’hyperviseur ayant permis le développement des outils d’automatisation mais aussi par la faible perte de performance. Bien que le projet KVM ait été intégré dans le noyau Linux et choisi par différentes distributions, ceci signifie en aucun cas la fin du projet Xen.

Dans le cas du déploiement de grands clouds publiques, l’utilisation des plate-formes de virtualisation propriétaires telles que VMWare ou Hyper-V ne semblent pas viables financièrement. Les licences VMWare sont exceptionnellement coûteuses, de même pour les licences Windows 2008 Server. Un grand cloud public basé sur ces technologies rendrait l’offre particulièrement peu compétitive. De plus, l’hébergeur dépendrait totalement de l’éditeur pour les fonctionnalités qu’il peut implémenter et n’aura que peu de marge pour innover. L’utilisation des outils propriétaires peut être viable financièrement dans le cadre de clouds privés de taille modeste bien que la gratuité de XenServer de Citrix ne facilite pas l’adoption.

La mise en réseau du stockage

Tandis que les deux premières technologies sont visibles par les utilisateurs des clouds, le troisième l’est nettement moins. Traditionnellement, les unités de stockage de masse sont connectées directement sur les serveurs. Concrètement, cela se traduit par la connexion des disques dur directement sur le bus ATA ou SCSI de chaque serveur. Cette forme de stockage a comme avantage d’être particulièrement simple mais a comme désavantage d’être très peu flexible.

La mise en réseau des éléments de stockage à travers le SAN (Storage Area Network) a permis de s’affranchir de nombreuses contraintes. Cette flexibilité exceptionnelle a permis aux clouds de pouvoir s’automatiser rapidement avec notament l’utilisation des techniques de snapshots ou de déduplication. De plus, le réseau de stockage a permis d’augmenter massivement les performances des IO permettant de pouvoir centraliser les données. Cette centralisation a rendu possible les techniques de migration automatique à chaud et de répartition de charge dynamique entre différents hyerviseurs.

Au final, les technologies du cloud computing sont plus simples à cibler que le concept global. J’aurais l’occasion d’évoquer et de traiter les réseaux de stockage en détail ultérieurement. Ces trois technologies sont des technologies « centrales » autour desquelles peuvent en orbiter de nombreuses autres.

Pour rappel, OpenVPN est une application qui permet de créer des tunnels VPN chiffrés afin d’y faire passser du trafic IP. Cette application est relativement simple à utiliser une fois qu’on a réussi à comprendre rapidement son fonctionnement. Je vous en avais déjà parlé à travers l’article sur Viscosity, client VPN pour MacOS. Si vous êtes intéressés par un tutoriel d’installation sous Linux, je vous renverrais vers l’excellent tutoriel écrit par Smurf.

Pré-requis

Afin de pouvoir installer OpenVPN sur OpenSolaris, il va vous falloir une installation fonctionnelle d’OpenSolaris. Logique, non ? Nous allons ensuite travailler avec les packages fournis par Blastwave. Il s’agit d’un dépot de paquets spécifiques de manière similaire au dépots Sun. L’avantage de Blastwave est que les paquets sont plus nombreux et plus récents. Le nom des paquets Blastwave commencent par CSW au lieu de SUNW pour les paquets Sun. Afin de pouvoir installer facilement des paquets Blastwave, il est nécessaire de récupérer et installer l’utilitaire d’installation pkgutil (sorte d’équivalent à apt-get).

# wget ftp://ftp.belnet.be/packages/blastwave.org/pkgutil_1.6.1_i386.pkg

# pkgadd -d pkgutil_1.6.1_i386.pkg

Une fois cette utilitaire installé, nous allons pouvoir installer le reste beaucoup plus simplement.

Installation

Tout d’abord, nous allons devoir récupérer et installer les modules tun et tap nécessaires pour le fonctionnement d’OpenVPN. Une fois que ces modules seront installés, nous allons pouvoir nous occuper d’OpenVPN. De manière similaire à apt-get, la récupération des binaires et leur installation est automatique.

# /opt/csw/bin/pkgutil -i tun tap
# /opt/csw/bin/pkgutil -i openvpn

L’installation de tous ces paquets se fait toute seule. Il sera juste peut être nécessaire de confirmer l’installation en tapant un simple « y ».

Génération des certificats

Une fois l’installation initiale des paquets terminée, nous allons nous attaquer à la génération des certificats. Nous allons tout d’abord créer le certificat racine de notre serveur OpenVPN. Le certificat racine est le certificat d’origine qui servira à signer tous les certifications délégués aux utilisateurs de notre concentrateur VPN.

# cd /etc/csw/openvpn/easy-rsa
# source vars
NOTE: when you run ./clean-all, I will be doing a rm -rf on /etc/csw/openvpn/easy-rsa/keys
# ./clean-all
# ./build-ca
Generating a 1024 bit RSA private key
.++++++
………..++++++
writing new private key to ‘ca.key’

Un certain nombre de questions vous seront ensuite posées. Les réponses à ces questions permettront de pouvoir identifier plus clairement votre certificat racine. Rassurez-vous, il n’y a donc pas de mauvaise réponse. Une fois que vous aurez fini, vous remarquerez que deux nouveaux fichiers ont été créés : ca.crt et ca.key. Le fichier ca.key est à garder précieusement car c’est ce dernier qui permet de signer et de créer de nouveaux certificats donnant accès à votre concentrateur VPN. Nous allons ensuite créer le jeu de clés du serveur OpenVPN.

# ./build-key-server server
Generating a 1024 bit RSA private key
………………………………………………++++++
………………..++++++
writing new private key to ’server.key’

Une fois le certificat du serveur créé, vous retrouverez les fichiers server.key et server.crt. Nous allons ensuite pouvoir créer les certificats de nos utilisateurs. Des informations vous seront également demandées sur l’utilisateur pour la création de certificat. Ces informations permettent d’identifier vos utilisateurs, vous avez donc tout intérêt à les remplir précisément.

# ./build-key antoine
# ./build-key jeanmarc

Afin d’achever la génération des certificats, nous allons devoir créer le paramètre de Diffie-Hellman. La génération peut prendre du temps surtout sur un processeur peu occupé.

/etc/csw/openvpn/easy-rsa# ./build-dh
Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time

Configuration d’OpenVPN

Tout d’abord, nous allons devoir rendre accessible au service les différents certificats dont il va avoir besoin.

# cd /etc/csw/openvpn
# /etc/csw/openvpn# cp openvpn.conf.CSW openvpn.conf
# /etc/csw/openvpn# ln -s easy-rsa/keys/dh1024.pem
# /etc/csw/openvpn# ln -s easy-rsa/keys/server.crt
# /etc/csw/openvpn# ln -s easy-rsa/keys/server.key
# /etc/csw/openvpn# ln -s easy-rsa/keys/ca.crt

Il est nécessaire ensuite de renseigner les différentes informations dans le fichier de configuration d’OpenVPN. Je ne parlerais pas de ce fichier en détail ici car d’autres sites le font déjà et bien mieux que moi. Les lignes importantes sont les suivantes. L’utilisation de TCP pour un VPN est sous-optimal mais permet de contourner une bonne partie des firewalls associé avec le port 443 (HTTPS).

port 443
proto tcp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 172.19.0.0 255.255.255.0

Ensuite, vous allez pouvoir tester votre paramétrage en exécutant le service OpenVPN.

# ifconfig tun0 unplumb
# /opt/csw/sbin/openvpn /etc/csw/openvpn/openvpn.conf

L’affichage des logs sera fera directement sur votre écran ce qui vous permettra de diagnostiquer d’éventuelles erreurs de configurations ou de connexion. Et ensuite, pour lancer définitivement le démon :

# ifconfig tun0 unplumb && /etc/init.d/openvpn start

Au final, ce petit tutoriel vous permettra de créer un tunnel OpenVPN afin de pouvoir communiquer avec votre serveur de manière sécurisée. Je ferais un autre billet expliquant les manipulations supplémentaires pour passer toute sa connexion Internet dans ce même VPN. Ce tutoriel est largement inspiré d’un autre tutoriel en anglais.

L’objectif de cet article est de présenter les différentes définitions du cloud computing que l’on peut trouver sur le web et de les comparer. Afin d’avoir un premier élément de définition, nous pouvons nous rendre sur Wikipedia qui définit le cloud computing comme suit.

L’informatique dans les nuages (en anglais, cloud computing) est un concept majeur faisant référence à l’utilisation de la mémoire et des capacités de calcul des ordinateurs et des serveurs répartis dans le monde entier et liés par un réseau, tel Internet (principe de la grille informatique).

Tout d’abord, Wikipedia France traduit cloud computing par le terme informatique dans les nuages. Cette traduction est une traduction très littérale qui, selon moi, s’adapte relativement mal en Français. A défaut d’une meilleure traduction, je continuerais à utiliser le terme anglais beaucoup plus répandu.

Ensuite, intéressons-nous à la définition proposée par Wikipedia. Cette définition ressemble beaucoup plus à un slogan marketing qu’à une véritable définition d’un concept informatique. Elle commence par préciser qu’il s’agit d’un concept majeur. Cette affirmation est soutenue par un rapport Gartner cité en bas de page. Sans questionner le point de vue de ces analystes, cette définition s’attache en premier lieu à définir la taille de ce concept avant même d’avoir précisé de quoi il s’agissait.

De plus, l’utilisation de capacités de calcul et de mémoire d’ordinateurs via Internet est loin d’être quelque chose de récent ni de propre au cloud computing. Une application web est une utilisation de capacité de calcul via Internet et ce n’est pas pour autant qu’il s’agit d’une nouveauté ou bien même de cloud computing. La fin de la définition fait allusion au grid computing qui est une technique bien différente du cloud computing du fait qu’elle soit conçue pour effectuer du calcul distribué.

Nous pouvon ensuite nous tourner vers la définition proposée par Wikipedia en Anglais en espérant obtenir un résultat plus probant.

In concept, it is a paradigm shift whereby details are abstracted from the users who no longer need knowledge of, expertise in, or control over the technology infrastructure « in the cloud » that supports them. Cloud computing describes a new supplement, consumption and delivery model for IT services based on Internet, and it typically involves the provision of dynamically scalable and often virtualized resources as a service over the Internet.

Pour les francophones, voici la traduction « best effort » que je propose de cette définition.

Conceptuellement, il s’agit d’un changement fondamental se traduisant par une abstraction de l’infrastructure technologique désormais transposée « dans les nuages ». Ce changement fondamental implique que les utilisateurs n’aient plus besoin d’une connaissance ou d’une maitrise de l’infrastructure technologique. Le cloud computing est un technique basée sur un nouveau modèle de consommation et d’utilisation des TIC basées sur Internet. Typiquement, cela inclut la mise à disposition de ressources extensible à la volée et, souvent, virtualisées par le biais d’Internet.

Cette définition semble convenir bien mieux à l’idée du cloud computing qui est traitée régulièrement sur Internet. Je trouve que cela décrit beaucoup mieux le concept et la pratique du cloud computing. Nous remarquons également que la page Wikipedia en Anglais sur le cloud computing précise bien que ce n’est pas la même chose que le grid computing. Promis, je ne l’avais pas vu avant.

Au final, la définition du cloud computing est relativement compliquée à poser étant donné la jeunesse de la technique. De plus, le succès de cette technique incite tous les vendeurs de solutions informatiques à se mettre à l’heure du cloud computing moyennant une définition approximative de ce concept. Dans un prochain article, nous essayerons de trouver une définition plus pratique du cloud computing.