{% extends "/meta/master.html" %}

{% block main %}
  <h1 class="title">
    Logiciels
  </h1>
  <h2 class="subtitle">
    Architecture générale
  </h2>
  <p>
    Si l'architecture matérielle de Katzei est fortement liée à son côté auto-hébergé. Son architecture logicielle est, à l'inverse, beaucoup plus classique. Tous les services publiques étant rendus via le protocole HTTP(S), un serveur proxy reçoit toutes les requêtes destinées aux ports 80 et 443 et les redirige vers les services concernés. Les autres ports redirigent directement sur les machines gérant les services rendus sur ce port.
  </p>
  <p>
    Par mesure de sécurité, afin de réduire les risques liés à de mauvaises manipulations, et pour réduire les temps d’interruption, chaque service est isolé dans une <a href="https://fr.wikipedia.org/wiki/Machine_virtuelle">machine virtuelle</a> qui lui est dédiée. Les services hébergés par Katzei ne sont pas tous directement utilisables par le public, certains peuvent aussi être internes  pour assurer le bon fonctionnement des services. Par exemple nous gérons des services de DNS ou de mail qui ne sont pas proposés au public.
  </p>
  <h2 class="subtitle">
    Système d'exploitation
  </h2>
  <p>
    Pour le choix du système d'exploitation qui allait être installé sur nos machines, il fallait répondre à un cahier des charges classique :
    <ul>
      <li>
        <b>Libre </b>: Katzei n'utilisant que des logiciels libres, le système d'exploitation ne doit pas y faire exception.
      </li>
      <li>
        <b>Léger </b>: Comme nous utilisons beaucoup de machines virtuelles (une machine, un système d'exploitation), chacune d'entre elles doit être la plus légère possible.
      </li>
      <li>
        <b>Stable </b>: Les administrateurs travaillant sur katzei sur leur temps libre, il ne faut pas utiliser un système d'exploitation qui casse souvent oui qui change en profondeur régulièrement.
      </li>
    </ul>
  </p>
  <p>
    Un certain nombre de distributions Linux ou BSD répondent à ce cahier des charges, et le choix parmi celles-ci relèce plus d'une affaire de goûts que de réelle supériorité de l'une ou de l'autre. Nous avons choisi <a href="https://debian.org">Debian</a> qui est relativement léger (il s'installe et tourne très confortablement avec moins de 1Go de RAM) et extrêmement stable (certaines mauvaises langues diront même immobile), chaque version étant maintenue 2 ans puis continuant à recevoir des correctifs de sécurité pendant 2 à 4 ans supplémentaires. Le prix à payer pour cette stabilité est de n'avoir que rarement des logiciels à jour (même si les correctifs de sécurité sont bien entendu portés sur les anciennes versions) et, quand une version de logiciel comporte un problème, il est courant que ce problème ne soit pas corrigé avant la version suivante de Debian.
  </p>
  <p>
    D'autres distributions Linux auraient pu être utilisées comme <a href="https://www.centos.org/">CentOs</a> (une recompilation gratuite des sources de <a href="https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux">Red Hat Enterprise Linux</a>), <a href="https://ubuntu.com/server">Ubuntu Server</a> ou encore des versions de <a href="https://fr.wikipedia.org/wiki/Berkeley_Software_Distribution">BSD</a> (comme <a href="https://www.freebsd.org/fr/">FreeBSD</a>).
  <h2 class="subtitle">
    Hyperviseur
  </h2>
  <p>
    Un hyperviseur est un logiciel permettant de gérer et d'héberger une ou plusieurs machines virtuelles (<em>guest</em> ou invité) sur une même machine physique (<em>host</em> ou hôte).
  </p>
  <p>
    Nous utilisons l'hyperviseur <a href="https://www.proxmox.com/en/proxmox-ve">Proxmox-ve</a> (en général, simplement désigné par "Proxmox") pour gérer le gros de l'infrastructure de Katzei. Cette distribution Linux est très proche de Debian et se contente d'y rajouter quelque paquets. Proxmox fournit une interface graphique via un serveur web simple permettant de faire toutes les opérations courantes.
  </p>
  <h2 class="subtitle">
    Supervision
  </h2>
  <p>
    Quand on essaye de construire une infrastructure stable à destination du public, il est indispensable de pouvoir être mis au courant quand un problème survient sur celle-ci. C'est ce qu'on appelle la supervision.
  </p>
  <p>
    Il existe beaucoup de systèmes de supervision comme <a href="https://www.nagios.org" >Nagios</a>, le système historique, ou des systèmes très modernes comme <a href="https://https://prometheus.io/">Prometheus</a>, permettant de récolter des centaines de paramètres sur les machines et de les agréger dans le temps. Notre infrastructure restant très simple, nous n'avons pas besoin de quelque chose d'aussi puissant que Prometheus et, vu le nombre de paramètres remontés, le configurer correctement pour nos besoins aurait été bien trop long. Nous avons finalement choisi d'utiliser <a href="https://icinga.com/">Icinga2</a>, un dérivé (complètement réécrit depuis) de Nagios, simple à configurer et avec une jolie interface.
  </p>
  <h2 class="subtitle">
    Mail
  </h2>
  <p>
    Même si Katzei ne fournit pas d'adresse mail à ses utilisateurs, il est indispensable de pouvoir envoyer des mails pour les services ou pour la supervision et de pouvoir en recevoir (au moins pour respecter les obligations légales). Katzei étant auto-hébergé, notre adresse IP est automatiquement rejetée par les gros hébergeurs de mail. Pour contourner ce blocage, nous sommes obligés de passer par le relais de Free. Nous perdons donc un peu d'indépendance sur ce point mais c'est, malheureusement, le seul moyen pour envoyer des mails en restant auto-hébergé chez un opérateur grand public.
  </p>
  <p>
    Même s'il existe un grand nombre de logiciels pour envoyer et recevoir des mails, le couple <a href="http://www.postfix.org/">Postfix</a>/<a href="https://www.dovecot.org/">Dovecot</a> est le plus courant. C'est donc logiquement celui que nous avons choisi. Même s'il existe de nombreux tutoriels et une grosse documentation sur le sujet, la configuration de Postfix reste compliquée et peu intuitive. Si vous voulez vous lancer dans l'aventure, prévoyez au moins quelque jours pour réussir à le faire marcher convenablement (et avoir une configuration acceptable) !
  </p>
  <h2 class="subtitle">
    Domain Name Systeme (DNS)
  </h2>
  <p>
    Dans une vision (très) simplifiée, le DNS est l'annuaire qui permet d'associer un nom de domaine (par exemple "katzei.fr") à une adresse IP. Il existe deux type de serveurs DNS :
    <ul>
      <li>
        <b>Les serveurs faisant autorité </b>: Ces serveur sont ceux détenant la vérité et la partageant avec les autres. Ils font référence sur le réseau et tout résolveur donnant une réponse en contradiction avec les serveurs faisant autorité est considéré comme menteur.
      </li>
      <li>
        <b>Les résolveurs DNS </b>: ces serveurs sont ceux que vous contactez pour connaître l'adresse d'un site. Ils contacteront les différents serveurs faisant autorité jusqu’à trouver l'adresse que vous cherchez. En général, vous utiliserez le résolveur DNS de votre fournisseur d’accès à Internet.
      </li>
    </ul>
  </p>
  <p>
    Le fait que Katzei soit auto-hébergé rend assez absurde le fait d'héberger nous-mêmes les serveurs faisant autorité pour katzei.fr. Nous utilisons donc les serveurs du bureau d'enregistrement à qui nous louons le domaine, à savoir OVH. 
  </p>
  <p>
    Comme pour n'importe quelle infrastructure un peu compliquée, nous avons besoin de définir un grand nombre de sous-domaines pour les adresses des différentes machines. Pour ce faire, nous utilisons un résolveur DNS menteur qui, au lieu de nous renvoyer les adresses publiques des services (la réponse que vous obtenez quand vous contactez un résolveur DNS public), nous renvoie les adresses privées (et inaccessibles de l’extérieur) des services. Pour ce résolveur, nous utilisons <a href="https://nlnetlabs.nl/projects/unbound/about/">Unbound</a> qui a l'avantage d'être simple à configurer pour cette tâche.
  </p>
{% endblock %}
