Pellerin Cédric

Avoir son propre serveur, sa propre production, ses propres baies… Bien souvent, cela est juste nécessaire pour la continuité de service et c’est un des métiers clés de l’informatique contemporaine. Sauf que voilà, posséder sa baie à la maison ou dans l’entreprise n’est plus depuis longtemps la meilleure façon de faire. Et la mode des clouds (du « nuagique » en français) nous a même expliqué que tout cela était dépassé, has been, remisé aux poubelles de l’Histoire. Mais alors, quand on a besoin de ses propres serveurs (et pas de services clés en main) et de continuité de services, comment fait-on ? Allons voir ensemble ce que recouvre la notion d’hébergement.

Avoir son propre serveur de mails bien à soi est le rêve de beaucoup d’utilisateurs GNU/Linux. Cependant, depuis quelque temps, les principaux acteurs du net exigent que nous montrions patte blanche avant de transférer ou d'accepter nos courriels. Voyons donc comment faire.

Cela fait environ cinq ans que les demandes de « DevOps » sont de plus en plus nombreuses dans le milieu professionnel. Souvent, lors des entretiens, on s'aperçoit que chaque client, ou presque, a sa propre définition du mot. Nous allons essayer de donner ici notre vision, tirée de notre expérience de terrain, de cette fonction.

La présentation de LXC faite dans le précédent numéro [1] nous a permis de mettre en œuvre les fonctionnalités de base et de créer rapidement des conteneurs fonctionnels. Cependant, les capacités de LXC ne s’arrêtent pas là et nous allons pouvoir étudier ici plusieurs options bien utiles en production.

Depuis quelques années, la « star » des conteneurs s’appelle Docker. Tout le monde l'utilise pour presque tout et n'importe quoi. Cependant, il ne faut pas oublier que Docker n'est pas la seule solution de conteneurs disponible pour Linux et qu'il est même arrivé bien tard dans le paysage. Nous allons ici étudier celui qui fut à l'origine, j'ai nommé LXC.

Lorsque l'on utilise le mode bridge d'OpenVPN et donc les interfaces de type tap, les paquets ne passent pas par le firewall Linux, mais sont traités directement par le serveur qui fait office de switch. Une fonction méconnue et peu documentée permet quand même de filtrer un minimum les communications de client à client, et ce dynamiquement.

Comme de nombreux logiciels dignes de ce nom, OpenVPN est capable d'accepter des plugins écrits en C et disponibles sous la forme de bibliothèques partagées. Regardons comment écrire les nôtres.

L'utilisation d'OpenVPN n'est nullement limitée aux systèmes open source comme on a pu le voir précédemment. Chaque système a son mode de configuration bien à lui et nous allons en passer en revue quelques-uns.

Au cours des trois dernières décennies, la progression de l'informatique et surtout la nécessité grandissante de devoir garantir une interconnexion des machines ont donné lieu à de nombreuses évolutions logicielles comme matérielles. Les premiers réseaux locaux étaient relativement lents ; avec 1 Mbps pour du 3+Open, 4Mbps pour du Token-Ring voire 10Mbps pour de l'Ethernet, nous sommes bien loin des 10Gbps qui commencent à être disponibles aux particuliers. De plus ces réseaux transportaient simultanément plusieurs protocoles, NetBIOS, IPX/SPX ou TCP/IP pour ne nommer que les plus répandus.