Configuration système de fr.tild3.org
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
southerntofu 713a001f71 C'est bon c'est corrigé simpleweb_peertube 4 months ago
docs Mise à jour de la doc deploy.sh 2 years ago
i18n Chaque utilisateurice sait trouver son onion (closes #5) 2 years ago
roles@2d81e21632 C'est bon c'est corrigé simpleweb_peertube 4 months ago
.gitignore deploy.sh: le hosts file n'est oligatoire qu'en mode remote 2 years ago
.gitmodules On a mergé avec joinjabber.org ! \o/ 5 months ago
LICENSE Initial commit 2 years ago
README.md On a mergé avec joinjabber.org ! \o/ 5 months ago
config.default.yml Les rôles actifs sont définis dans la config 2 years ago
config.yml Euh c'est une expérience cassée de simpleweb_peertube 4 months ago
deploy.sh On a mergé avec joinjabber.org ! \o/ 5 months ago

README.md

ATTENTION: Tout ce qui suit ci-dessous n'est plus d'actualité. La documentation de nos recettes est disponible ici.

Bienvenue sur le dépôt de la configuration système de ~fr !

On écrit des recettes Ansible pour décrire les étapes à suivre pour configurer notre serveur basé sur Debian 10 Buster (stable). Pour l'instant, on gère:

  • des comptes shell avec authentification par clé SSH
  • des sites web (avec nginx) et des pages perso pour nos utilisateurices
  • des .onion pour les pages perso

Nous mettons à disposition un guide utilisateurice et un guide administrateurice. Nous essayons de rendre notre système compréhensible et reproductible. Si quelque chose n'est pas clair, ou que ça ne fonctionne pas chez toi, c'est un bug alors n'hésite pas à le signaler.

Nos recettes visent à configurer tout un système d'hébergement mutualisé à partir d'un fichier de configuration central: config.yml. En suivant des principes déclaratifs, nous espérons obtenir des recettes robustes et interchangeables.

ATTENTION: Tout ce qui suit ci-dessous n'est plus d'actualité. La documentation de nos recettes est disponible ici.

Configuration déclarative

La mise en place d'un système de configuration déclarative nous force à nous concentrer sur les fonctionnalités et services que nous voulons mettre en place (qui sont communes à de nombreux hébergeurs), sans nous soucier précisément de comment faire.

Plus précisément, cette approche nous donne de la marge de manoeuvre pour expérimenter plusieurs approches pour implémenter une fonctionnalité. Par exemple, les pages personnelles de nos utilisateurices peuvent être servies par différents serveurs web.. pourquoi devrait-on toujours réécrire des recettes spécifiquement conçues pour notre système et notre serveur web préféré ?

Nous prenons l'approche inverse : nous décrivons les fonctionnalités que nous voulons obtenir dans la configuration, et laissons le champ libre à différents roles d'implémenter l'interface de configuration correspondante pour les mettre en oeuvre concrètement. Cela nous permettrait par exemple de remplacer un serveur web par un autre de façon entièrement transparente pour les sysadmin.

De plus, cette approche facilite les nouvelles implémentations. En effet, chaque logiciel a ses spécificités et écrire des recettes génériques pour un service peut être complexe. Une fois le champ des besoins étudié et délimité, la standardisation d'une interface de configuration permet aux futures implémentations d'avoir un aperçu clair des concepts et fonctionnalités en jeu.

Bref, notre système est actuellement basé sur des recettes Ansible. Mais le but est de concevoir un système qui permettent à d'autres implémentations d'être compatibles avec nos configurations, qu'elles soient écrites en bash, en Nix, en Guix... Le projet Yunohost considère actuellement de migrer progressivement vers un modèle déclaratif.

Services

L'architecture de nos recettes reposent sur la distinction entre services et roles. Un service est une référence qui définit une interface de configuration. Un role est une implémentation spécifique d'un service.

Par exemple, webserver est un service, qui est implémenté par un rôle apache, nginx, ou lighttpd. Pour passer de apache à nginx, on peut simplement faire:

$ rm roles/webserver
$ ln -s roles/nginx roles/webserver

Gestionnaires de paquets

Les gestionnaires de paquets sont des rôles chargés de l'installation de paquets additionnels sur le système. Parmi ceux-ci, on retrouve npm, cargo ou encore apt.

Interface :

packages:
  x: [ packageA, packageB ]
  y: [ packageC, packageD ]

Gestionnaires de paquets implémentés :

  • apt (appelé debian)
  • cargo (appelé rust)
  • npm

De plus, un gestionnaire de paquets custom permet de définir des recettes personnalisées pour des logiciels qui ne sont pas packagés autrement.

Fonctionnalités implémentées :

  • liste de paquets
  • sources tierces
  • paramètres de compilation

Actuellement, tous les gestionnaires de paquets dans roles/ ont un nom commençant par .. Dans le futur, ce préfixe sera probablement renommé pkg-, de telle façon qu'un gestionnaire de paquets x soit situé dans roles/pkg-x.

Webserver

Le serveur web est un service qui permet de servir des pages et applications web.

Interface :

webserver:
  vhosts:
    - hostname: example.org
      aliases: [ www.example.org ]
      root: /var/www/example.org
    - hostname: thepiratebay.example.org
      proxy: [ https://thepiratebay.org ]

En plus de cette interface de configuration, le service webserver peut être appelé par d'autres services avec des paramètres additionnels. Par exemple, les pages well-known sont configurées directement par d'autres services, comme ceci:

webserver:
  vhosts:
    - hostname: example.org
      well-known:
        regex: ^/~(.+?)(/.*)?$
        alias: /home/$1/public/html/tilde/$2
        autoindex: on|off

C'est ainsi que sont activées les pages perso sur le domaine principal du serveur. (TODO: ce n'est pas encore le cas!)

Mutualisation

Le but de ce projet est de mutualiser des recettes d'administration système afin d'encourager les bonnes pratiques et de faciliter la mise en oeuvre de services autohébergés. En cela, notre projet est similaire à Yunohost, AlternC, ISPConfig, ou encore Freedombone.

Pourtant, nous faisons des choix techniques radicalement différents afin d'explorer ce que la configuration déclarative pourrait apporter aux solutions d'autohébergement.

Écrire des recettes

Pour l'instant, toutes les recettes sont contenues dans ce dépôt. Pourtant, il est possible d'utiliser des recettes tierces via des sous-modules git. Cela pose des questions de sécurité, qui ont très bien été étudiées par le projet Guix.

Note: pour le moment, ces recettes ne sont pas spécifiquement articulées pour pouvoir facilement remplacer des bouts. Cela va demander du taf en plus mais ça avance.

Sécurité

ATTENTION: les recettes présentées ici sont dévelopées avec amateurisme et ne présentent aucune garantie de fiabilité ou de sécurité. Ne nous fais pas confiance, mais viens participer au projet pour l'améliorer !