Compare commits

..

4 Commits

44 changed files with 866 additions and 711 deletions

4
.gitignore vendored
View File

@ -20,6 +20,4 @@ tags
[._]*.un~
# File created by runing the playbook locally
*.retry
hosts
site.retry

3
.gitmodules vendored
View File

@ -1,3 +0,0 @@
[submodule "roles"]
path = roles
url = https://codeberg.org/southerntofu/ansible-selfhosted

319
README.md
View File

@ -1,112 +1,283 @@
**ATTENTION:** Tout ce qui suit ci-dessous n'est plus d'actualité. La documentation de nos recettes est disponible [ici](https://codeberg.org/southerntofu/ansible-selfhosted).
Bienvenue sur le dépôt de la configuration système de ~fr !
Bienvenue sur le dépôt de la configuration système de ~fr !
On écrit des recettes [Ansible](https://fr.wikipedia.org/wiki/Ansible_(logiciel)) pour décrire les étapes à suivre pour configurer notre serveur basé sur Debian 10 Buster (stable). Pour l'instant, on gère:
On écrit des playbooks [Ansible](https://fr.wikipedia.org/wiki/Ansible_(logiciel)) 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](https://fr.wikipedia.org/wiki/.onion) pour les pages perso
- des serveurs de noms primaires/secondaires
- des comptes mail utilisables @localhost
Nous mettons à disposition un [guide utilisateurice](docs/utilisateurice.md) et un [guide administrateurice](docs/administrateurice.md). 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.
# Guide utilisateurice
Nos recettes visent à configurer tout un système d'hébergement mutualisé à partir d'un fichier de configuration central: [config.yml](https://tildegit.org/tilde-fr/infra/src/branch/master/config.yml). En suivant des principes [déclaratifs](https://fr.wikipedia.org/wiki/Programmation_d%C3%A9clarative), nous espérons obtenir des recettes robustes et interchangeables.
Bienvenue sur le serveur ~fr ! Ici, tu trouveras peut-être des réponses à tes questions.
**ATTENTION:** Tout ce qui suit ci-dessous n'est plus d'actualité. La documentation de nos recettes est disponible [ici](https://codeberg.org/southerntofu/ansible-selfhosted).
## Configurer ton client SSH
# Configuration déclarative
Si tu n'es pas encore connectéE au serveur, tu as peut-être besoin d'un petit coup de pouce !
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.
### Générer une paire de clés
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é ?
Pour se connecter, on utilise des clés SSH. Ces clés vont par paire, une clé publique et une clé privée. La clé privée, tu la garde sur ta machine: elle te permet grâce à un mot de passe, de t'authentifier auprès de n'importe qui connaît ta clé publique. Du coup, pour créer un compte, faut nous envoyer ta clé publique.
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](https://github.com/YunoHost/issues/issues/1614).
# 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:
Quand tu génères une paire de clés avec la commande ssh-keygen, cela génère dans ton dossier ~/.ssh un fichier sans extension (la clé privée), et un fichier du même nom avec une extension .pub. Pour avoir une connexion sécurisée sans pomper trop de ressources, on utilise des clés de type ed25519 en passant le paramètre `-t ed25519` à la commande :
```
$ rm roles/webserver
$ ln -s roles/nginx roles/webserver
$ ssh-keygen -t ed25519
Generating public/private rsa key pair.
Enter file in which to save the key (/home/tonutilisateurice/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/tonutilisateurice/.ssh/id_rsa.
Your public key has been saved in /home/tonutilisateurice/.ssh/id_rsa.pub.
The key fingerprint is:
f6:61:38:25:25:df:4d:4b:13:11:70:cf:4c:c8:a0:22 tonutilisateurice@tamachine
```
## 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](https://www.npmjs.com/), [cargo](https://doc.rust-lang.org/cargo/) ou encore [apt](https://en.wikipedia.org/wiki/APT_(Debian)).
Interface :
La commande te demande où stocker la clé (le paramètre par défaut est très bien pour commencer), puis te demande de renseigner une phrase de passe qui protègera l'utilisation de ta clé privée si jamais tu te la fais dérober. Après avoir reconfirmé ta phrase de passe, hop ta clé est crée ! On peut maintenant la lire, par exemple avec la commande cat :
```
packages:
x: [ packageA, packageB ]
y: [ packageC, packageD ]
$ cat .ssh/id_ed25519.pub
ssh-ed25519 BLABLABLA tonutilisateurice@tamachine
```
Gestionnaires de paquets implémentés :
Pour qu'on puisse te créer un compte, c'est cette clé publique qu'il faut nous transmettre. Le dernier bout, par contre n'est pas obligatoire et peut t'empêcher de te connecter depuis une autre machine en copiant simplement ta clé ailleurs, parce que le nom de ta machine ou ton nom d'utilisateurice aura changé.
- [x] apt (appelé `debian`)
- [x] cargo (appelé `rust`)
- [ ] npm
### Se connecter
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 :
- [x] 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 :
Une fois que ton compte aura été activé, tu peux maintenant te connecter au serveur avec SSH :
```
webserver:
vhosts:
- hostname: example.org
aliases: [ www.example.org ]
root: /var/www/example.org
- hostname: thepiratebay.example.org
proxy: [ https://thepiratebay.org ]
$ ssh utilisateurice@fr.tild3.org
Enter passphrase for key '/home/tonutilisateurice/.ssh/id_ed25519':
```
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](https://en.wikipedia.org/wiki/Well-known_URIs) sont configurées directement par d'autres services, comme ceci:
### Configurer SSH pour raccourcir la commande
C'est long à taper. Vite, comment configurer des Hosts!
TODO
### Gérer plusieurs clés SSH
Ton client SSH peut gérer plusieurs paires de clés à la fois. Si tu as besoin d'en créer d'autres, tu peux leur donner des petits noms avec le paramètre `-f ~/.ssh/taclé` de ssh-keygen, ou bien en renseignant un autre emplacement pour stocker la clé quand le programme te le demande. Ces clés peuvent être stockées plus ou moins n'importe où sur ta machine, mais en général on trouve ça plutôt pratique de les garder dans le dossier ~/.ssh.
Pour te connecter à un serveur en utilisant une clé spécifique, on utilise `ssh -i ~/.ssh/taclé utilisateurice@fr.tild3.org`. Si ça devient un peu long à tout taper, le fichier de configuration de ton client SSH a une option `IdentityFile` dans le Host qui te permet de spécifier la clé à utiliser pour ce serveur :
```
webserver:
vhosts:
- hostname: example.org
well-known:
regex: ^/~(.+?)(/.*)?$
alias: /home/$1/public/html/tilde/$2
autoindex: on|off
Host fr
IdentityFile ~/.ssh/taclé
...
```
C'est ainsi que sont activées les pages perso sur le domaine principal du serveur. (TODO: ce n'est pas encore le cas!)
Comme tu sais maintenant configurer ton client SSH, il y a une option pratique pour gérer plusieurs clés. Un Host dans le fichier de configuration SSH
# Mutualisation
### Se connecter en passant par Tor
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](https://yunohost.org/), [AlternC](https://alternc.com/), [ISPConfig](https://www.ispconfig.org/), ou encore [Freedombone](https://freedombone.net/).
Pour se connecter au serveur en passant pas le réseau Tor, il suffit d'ajouter les paramètres suivants à la configuration du Host correspondant :
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.
```
...
ProxyCommand connect -4 -S localhost:9050 $(tor-resolve %h localhost:9050) %p
CheckHostIP no
...
```
# Écrire des recettes
Bien sûr cela ne fonctionne que si tor est installé et fonctionnelle sur ta machine. Sur Debian GNU/Linux, il te suffit d'installer le paquet tor (apt install tor) et tout marche.
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](https://guix.gnu.org/blog/2020/securing-updates/).
## Configurer tes pages perso
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.
Nous proposons de l'hébergement de pages/fichiers statiques sur le web. Si ton nom d'utilisateurice est `username`, alors tu contrôles les addresses username.fr.tild3.org et fr.tild3.org/~username. En plus de cela, une adresse en .onion est générée pour toi à la création de ton compte, et te permet de fournir un accès sécurisé et anonymes à tes pages perso.
# Sécurité
Par défaut, ces trois adresses servent le même contenu, que tu trouveras dans ~/public_html/ c'est à dire le dossier public_html dans ton dossier personnel. Si tu veux rajouter du contenu sur ton site, il suffit de le verser dans ce dossier.
**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 !
TODO: Si tu souhaites avoir des sites différents sur ces trois adresses, pas de problème! En réalité, chaque site est servi par un dossier différents dans le dossier public/ de ton compte. Mais pour te simplifier la vie, à la création de ton compte, ces trois dossiers sont par défaut reliés à ton dossier ~/public_html avec des liens symboliques, pour éviter de perdre la tête.
Maintenant, si tu supprimes un de ces liens symboliques, tu peux le remplacer par un dossier qui sert du contenu spécifique à cette adresse :
```
$ rm ~/public/utilisateurice
$ mkdir ~/public/utilisateurice
$ echo "Bienvenue sur mon sous-domaine perso!" > ~/public/utilisateurice/index.html
# Et ce fichier est désormais accessible sur le web
$ curl https://utilisateurice.fr.tild3.org/
Bienvenue sur mon sous-domaine perso!
```
Ces trois dossiers sont disponibles:
- ~/public/tilde: le contenu servi à l'adresse fr.tild3.org/~utilisateurice
- ~/public/utilisateurice: le contenu servi à l'adresse utilisateurice.fr.tild3.org
- ~/public/onion: le contenu servi à l'adresse en .onion (à trouver dans ~/onion)
## Envoyer des fichiers sur le serveur
Si tu as fait un petit site web en local que tu veux publier sur le serveur, ou que tu veux stocker des trucs sur ton compte, cela se passe directement avec tes identifiants SSH! Pas besoin de configurer un client FTP ou Dropbox, tu peux simplement taper dans ta console (sur ta machine, pas sur le serveur) :
```
# Envoie un fichier au serveur dans le dossier personnel
$ scp monfichier username@fr.tild3.org:~
# Envoie mon dossier dans le fichier personnel
$ scp -r Documents username@fr.tild3.org:~
# La partie derrière les : indique dans quel dossier envoyer
$ scp -r mon_site/* username@fr.tild3.org:~/public_html
```
Si cela te ferait plaisir, on peut activer rsync aussi.
# Administration du serveur
Les principaux paramètres du serveur sont configurés dans le fichier `host_vars/127.0.0.1.yml`. Ensuite, le dossier roles abrite des recettes pour le système de base (common), pour le serveur web et les utilitaires associés (webserver) et pour le DNS (nameserver). Ces recettes sont appelées dans `site.yml` qui définit leurs paramètres spécifiques.
## Gestion des utilisateurices
Pour créer un nouveau compte utilisateurice, il faut le déclarer dans la configuration du serveur:
```
- name: username
(- sudo: true)
- key: "clé publique SSH (format ~/.ssh/authorized_keys)"
```
## Configuration
Les principales directives de configuration du serveur sont expliquées dans cette section.
### hostname
Définit le nom de domaine principal associé au serveur.
```
hostname: fr.tild3.org
```
### users
Définit une liste d'utilisateurices configuréEs sur la machine. Chaque utilisateurice est un dictionnaire comprenant une clé 'name' portant son pseudonyme, une clé 'key' portant sa clé publique, et une clé optionnelle sudo contenant un booléen (true/false) pour définir si l'utilisateurice doit pouvoir exécuter des commandes admin.
```
users:
- name: user1
key: "-- REMPLACEZ MOI PAR UNE CLÉ SSH --"
- name: new_admin
sudo: true
key: "-- REPLACEZ MOI PAR UNE CLÉ SSH --"
```
### peers
Définit les serveurs amis, et nous permet de stocker des informations à leur propos et notamment des clés publiques. Chaque peer est un dictionnaire contenant les clés suivantes :
```
peers:
- name: ns1.tildeverse.org
key: "-- REMPLACEZ MOI PAR UNE CLÉ SSH --"
fingerprint: "-- REMPLACEZ MOI PAR UNE FINGERPRINT SSH --"
```
La clé SSH définie ici ouvre automatiquement un accès SSH chrooté aux serveurs pairs, pour leur permettre de mettre à jour leurs secrets sur notre serveur. Ce processus est notamment utilisé par le rôle nameserver pour échanger de façon sécurisée les clés (symmétriques) TSIG afin de sécuriser les mises à jour des zones DNS.
L'empreinte de clé définie dans la clé fingerprint correspond à la clé publique du serveur SSH du serveur pair. Cela nous permet de vérifier qu'une tierce personne n'est pas en train d'extirper nos secrets.
# Rôles
Le playbook sur ce dépôt contient un certain nombre de rôles. Ils sont expliqué plus en détail dans cette section.
## common
TODO
## webserver
variables: une liste de sites avec leur utilisateurice correspondantE et un template de vhost associé
TODO
## nameserver
Le rôle nameserver est une recette pour une configuration opinionée et moderne de bind9. Tout est fait pour faciliter la maintenance de serveurs de noms primaires et secondaires, et encourager la coopération entre serveurs. À ce propos :
- les serveurs secondaires vers lesquels sont propagées les mises à jour des zones sont déclarés pour le serveur entier (c'est à dire toutes les zones)
- les serveurs primaires correspondant à une zone secondaire sont déclarés par zone
Cette approche permet à chaque serveur de choisir en qui placer sa confiance pour agir comme serveur de noms secondaire, tout en lui permettant de lui-même agir pour n'importe qui en tant que serveur de noms secondaire.
Certaines zones sont stockées directement dans ce dépot, tandis que d'autres sont chargées dynamiquement directement sur le serveur. En effet, s'il est pratique de garder ici la zone du serveur, il peut être utile de permettre à certainEs utilisateurices de modifier certaines zones dynamiquement. Il faut alors faire attention à inclure ces zones dans les backups.
Cela permet notamment à unE utilisateurice de gérer sa propre zone au-sein de celle du serveur, car utilisateurice.fr.tild3.org lui est délégué, et la zone correspondante stockée dans son dossier ~/.dns/zones/. Additionnellement, une clé TSIG est générée pour chaque utilisateurice dans ~/.dns/tsig.key afin de lui permettre de recharger sa zone dynamiquement à l'aide de la commande `rndc reload`.
### Déclarer des zones
Les zones administrées par le serveur sont déclarées dans la variables primary. Chaque entrée prend une clé name contenant un nom de domaine, et une optionnelle clé template indiquant à partir de quel fichier de configuration générer la zone. Si aucun template n'est proposé, le fichier /etc/bind/zones/ZONE.db sera chargé.
```
- role: nameserver
variables:
primary:
- name: fr.tild3.org
file: ../files/fr.tild3.org.db
```
### Redondance sociale
Le but principal de ce role est de rendre la coopération entre opérateurices de serveurs de noms particulièrement simple. Chaque serveur de noms avec lequel on entretient des relations doit être déclaré dans les [peers](#peers) de notre serveurs.
Ainsi, pour déclarer des serveurs pairs pour lesquels on se porte serveur de noms secondaire, on utilise la variable secondary :
```
...
secondary:
- ns1.tildeverse.org
```
Pour définir les serveurs pairs qui nous servent de serveurs secondaires, on utilise la variable send_to_secondary :
```
...
send_to_secondary:
- emmagoldman.example.com
```
Pour chacun des serveurs pairs, un compte SSH est créé sur notre machine lui autorisant l'accès avec sa clé publique. Son accès est toutefois restreint à un chroot, et idéalement on aimerait bien que seul SFTP soit autorisé. Cela permet aux serveurs de s'échanger des secrets, et notamment les clés TSIG qui servent à sécuriser les échanges entre serveurs DNS.
Si le serveur ne trouve pas une clé TSIG qui lui aurait déjà été communiquée, alors il en génère une et l'envoie au serveur pair selon le processus décrit [plus loin](#scripter-des-trucs).
### Zone catalogue
Si tu as déjà administré un serveur de noms par le passé, tu dois te dire que tout n'est pas si simple. En effet, comment puis-je découvrir qu'une personne pour qui je suis serveur secondaire vient de créer une nouvelle zone ? En fait, on utilise pour cela une zone spéciale qu'on appelle zone catalogue. Cette zone contient la liste de tous les noms de domaine pour lesquels on est serveur primaire.
Cette zone a un nom fixé à l'avance (fr.tild3.org.catalog) qui nous permet de découvrir toutes les zones hébergées par un serveur, et de les ajouter automatiquement en tant que serveur secondaires.
### Scripter des trucs
Par défaut, pour un serveur pair.example.com le rôle crée un lien symbolique de /etc/bind9/keys/pair.example.com vers /home/peers/pair.example.com/.dns/tsig.key. Le système de serveurs pairs de ce playbook a déjà créé l'utilisateurice sur la machine, avec la clé SSH correspondante. Si la clé TSIG pour le pair n'existe pas encore, elle sera crée et on va tenter d'envoyer la clé sur le serveur distant.
Par exemple, si fr.tild3.org est serveur secondaire pour ns1.tildeverse.org, peer@fr.tild3.org va essayer de se connecter à fr.tild3.org@ns1.tildeverse.org avec sa clé SSH, générer une clé TSIG, et la placer dans ~/.dns/tsig.key.
Ainsi, même si tu n'utilises pas ce rôle pour gérer tes zones, tu peux scripter un système compatible avec le nôtre !
### DNSSEC
TODO
# TODO
- Services
- [x] Serveur web avec pages perso en user.fr.tild3.org
- [ ] Support du HTTP2 sur le serveur web
- [ ] Un onion pour le serveur
- [ ] Plein d'onions pour les pages perso
- [ ] Authentification centralisée (Single Sign-On)
- [x] Plateforme de blogging depuis le shell (ttbp)
- Expérience utilisateurice (UX)
- [ ] Script d'accueil pour choisir son shell, définir un MDP
- [ ] MOTD accueillant avec quelques exemples de commandes sympathiques
- [ ] byobu préconfiguré ?
- [ ] definir la locale
- Meta
- [ ] Rendre le playbook bootstrappable (ajouter des étapes intermédiaires pour éviter que nginx et certbot se mordent la queue sur une nouvelle install)
- [ ] Traduire tout le playbook en français
- [x] Hostname paramétrable (pour pouvoir forker)
- [ ] Certaines tâches devraient tourner seulement quand unE user est ajoutéE
- [ ] Un playbook pour les updates? apt + cargo
- [ ] Documenter le playbook

View File

@ -1,9 +0,0 @@
hostname: mondomaine.net
roles: [ webserver ]
packages:
debian: [ htop, tmux, vim, emacs, mutt, mosh ]
rust: [ lsd ]
users:
- name: utilisateurice
sudo: true
key: "ssh-ed25519 BLABLABLA"

View File

@ -1,130 +0,0 @@
hostname: "fr.tild3.org"
contact: "root@fr.tild3.org"
services:
- ".common"
- "webserver"
- "peering"
- "unix_users"
- "chatbridge"
#- "mucbridge"
- "simpleweb_peertube"
webserver:
vhosts:
- host: "fr.tild3.org"
template: "zola"
git: "https://tildegit.org/tilde-fr/site"
irc_announce:
chan: "#fr"
# TODO: reimplement peering with new recipes
simpleweb_peertube:
vhosts:
- host: "tube.fr.tild3.org"
accounts: [ "submedia@kolektiva.media", "contrainfo@kolektiva.media", "enough14@kolektiva.media" ]
channels: [ "mooc.chatons.1@framatube.org", "mobilizon@framatube.org", "bf54d359-cfad-4935-9d45-9d6be93f63e8@framatube.org" ]
- host: "tubetest.fr.tild3.org"
mucbridge:
chans:
# List of JIDs to bridge together, carefully following cheogram-muc-bridge settings
- [ { jid: "#joinjabber-fr%irc.tilde.chat@irc.localhost", tag: "~", nickChars: "Some \"a-zA-Z0-9`|^_{}[]\\\\-\"", nickLength: "Some 32" }, { jid: "fr@joinjabber.org", tag: "jabberFR", nickChars: "None Text", nickLength: "None Natural" } ]
#- [ { jid: "#whereiseveryone%irc.libera.chat@irc.localhost", tag: "libera", nickChars: "Some \"a-zA-Z0-9`|^_{}[]\\\\-\"", nickLength: "Some 32" }, { jid: "guix@rooms.dismail.de", tag: "dismail", nickChars: "None Text", nickLength: "None Natural" } ]
# Mappings of server to channel name
#- { tildechat: "#foo", jj: "foo" }
# mappings defined in settings.profiles.jjworkinggroups
#disroot: [ "anarchism", "federation" ]
#jfr: [ "anarchisme", "fédération" ]
jfr: [ "fédération" ]
disroot: [ "federation" ]
jjworkinggroups: [ "privacy", "bridging", "abuse", "translations", "sysadmin", "website" ]
settings:
host: "bridge.fr.tild3.org"
nick: "fr-bridge2"
gateway_irc: "irc.localhost" # Optional (defaults to irc.localhost + biboumi setup
accounts:
#tildechat: { host: "irc.tilde.chat", type: "irc" } # Soon we can remove tag on XMPP side, but not yet
tildechat: { host: "irc.tilde.chat", type: "irc", tag: "~chat" }
jj: { host: "joinjabber.org", tag: "jj" }
disroot: { host: "chat.disroot.org", tag: "disroot" }
jfr: { host: "chat.jabberfr.org", tag: "jfr" }
profiles:
# Profiles are mapping of profile name to a mapping of server name to chatroom name format
jjworkinggroups: { tildechat: "#joinjabber-$room", jj: "$room" }
jfr: { tildechat: "#$room", jfr: "$room" }
disroot: { tildechat: "#$room", disroot: "$room" }
chatbridge:
tilde:
- "fr"
jabberfr:
- anarchisme
#- tilde-fr
#- fédération
# disroot: #
# - anarchism # #anarchism is now relayed by matterbridge operated by anelki on muse.edist.ro
# #- federation
settings:
accounts:
- name: "jabberfr"
type: "xmpp"
login: "matrixbot@jabber.fr"
server: "chat.jabberfr.org"
- name: "disroot"
type: "xmpp"
login: "matrixbot@jabber.fr"
server: "chat.disroot.org"
- name: "joinjabber"
type: "xmpp"
login: "matrixbot@jabber.fr"
server: "joinjabber.org"
- name: "tildechat"
type: "irc"
login: "bridge"
server: "irc.tilde.chat"
profiles:
jabberfr:
tildechat: "#$room"
jabberfr: "$room"
joinjabber: "test-$room"
tilde:
tildechat: "#$room"
jabberfr: "tilde-$room"
# disroot:
# tildechat: "#$room"
# disroot: "$room"
# joinjabber: "test-$room"
peers:
- name: tilde.netlib.re
client_key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEHsVZvvVX3VPj2sWxrb8LJrn3650aoLAZgbY7+CB+NU"
server_key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHUAIuwEhFXTDfOEG+hQ2d/xeUwsgPJQF7oeNYr1ZXnG"
packages:
debian: [ subversion, mercurial, htop, tmux, vim, emacs, mutt, weechat, elinks, rsync, dnsutils, make, g++, libssl-dev, mosh, gopher, sl, jq ]
rust: [ lsd ]
users:
- name: tofu
sudo: true
key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIG4bKe9LSA3/AY4gCB20eyJVPW+zOg07/b3A4QC0Z6XC"
- name: kumquat
key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFZ5FBnDlBIGlJ4TI0babTTmS5ECPM3yuDP1AhnNQUDZ"
- name: mspe
sudo: true
key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICZAs76kQJ0/Et2NGzhxurK2wE0VhYsG9wl85iCmR9xH"
- name: merry
key: |
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFxPbGSCW0KOOreD0FZGu3PFKMNIEi5VrJHzub8+poVs
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMGEuG1axFQBefQ+nCCj3VihcJWR+izHVnhYM+gXNxAf
- name: von
key: "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDBl15MKr9LqpJrohoQ/JBg95o2dFTOx6zEmdVO3peAt4FyrH8IfGj8H8DfOu4FQ9cay17X+/tV6znnW0D3XJro8fEavXWfNmpJ20EYwS2FeJ67lgL/7t4vUA4QGo/QR2vzxrLzP41bE5Bb3a4Rh1wJwvB06e0QCETyZNurxlLJ7E/IS0Axjcc+GTmFuR+I0Tj1dzRBn/DS8EVgRxCpx5eYUrh+uzLIyhKJEq6tGaQzIbSgNYFSorXcdf1IAkWRsV29VCTH8narzFfc8fuwetWhBc60WyRAyzGm4K7m+YNBj1JmWXvCeYGsRdaQQrOqY44fxo0WdVWbjLbQKTZMgPB3Ag34egI/RM4hQqQeOSPjzZM9t2yfSp1Uv5W5gBI6hg71CpVicz0ZkXaBNONxX6RRyav4Dmk62I87R2RrY4YkgwWyX3KrzdOuCV7IZZWWUIolaXpQxXhIA6svQ8/Gs+wwq+o1gPvBife9j4V19UnUxl4gtUwVcnSNfzNJgGYDyvOszz+hjxqVj1jD30UCzjnxe+vuxxY+mgr8RNSyjDvcruBAOGk0VXU292zdtYM9Wi0va5sxnhItgsabxlmjmUr2y1S3mDxnf8HC7yZQ7xMueksqDEavqxpWA1e11BPedWL9W38ZlnDpunx9lg1SClqLGCmYBVPOSMzl2WOxYGjivw== von"
- name: h30x
key: "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDVwgt0+qgrRVVT6Je9JHD2IBIt7pbfeRovGecOtP8H8q5pOOxTmvWwTkLVeOVVWJsWrCso2IQo95z4pUg1yUuXlvassHVCU5oWXlkE2Ax19M/ZjcLZ4eoGwtEJRlcibZwJK/8dD4SffNzd5cmFk+Bs6+hbCvFRG5/tAxdBZnAazB/mK8hUlmQbB0KCcaGXUEB3RYw15Kij7X9+vMAwhyYmYRyQeZmy/mMr0lc49WPQSGWl0oh9B6+rUsV1o8v7OEu3yincnEzUm86RAdgPbFVKMtYX9CEoram6M15Ca5/0fpgIST5ZB3lKc03dSk/cq+yMzLtzmD1XW0u8WHhTnlf2vNMgxOlDH7K1zsZSQkCeJtkOSHff6JFuPqH2zmfMxKWnvnRgIf3J4yZSCImI/Cv4DzRQUE3QS7XNlBKWuIfhaJ67bpwYjyWuFip9BGvBMdYv+htEgSpiSaeIozI55HDVU+zLp0ZpnAKt49/dXdX1OPW9w9GH1/XVuPLYsifrDhs="
- name: vaurora
key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIM0mpVI7iWm1pQ9Kl7Bjn9ItgVlBn+EX1yv8MCyxwyau"
- name: omz
key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIElh8AfX6EQsMjrZPcD5hwAvWlP1Bo6S1CWWUVVASrdM"
- name: bogusoverflow
key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAu2hTNKdHe/UjY479VvL5/HdcjYlnA2bOXA0wN6yjNU"
- name: val
key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIjJoY4XBTTNsxLVF/sUKBI4WGR2AIiR9qfMdspnsRfJ "
- name: dsx
key: "ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAm12PbmQ64+BZx2VUUrcVnHUh21zOcp3mC7ZXHMz5u6rQmBwM7c4UJJ39dJBcN1mFKrz4EL7n0AMf/po+fpz+gUj1sB6LKVugN1AOaB75gY2+wSbipu+zFOOVS68lv/VvRppdPNDptOLj+60QshK+Z5QtbDoWBwTvIrDVhdscAmNMUlRpo6syIdS1LiPOHBTVmfXRWrJHSq+0nYalJ219l9vvn/yn9O5r0/u6gHSDVO+++KO9jrGGRjxeNIeO2lZop/qS0DJDir2s/9aWb946+/cSJYeLS2QfziYsYJ5tymab+nacN2iBVamH3vBOsGIenhGvH5y9yQqp3lSDmXMnRQ=="
- name: sebbu
key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILPIE7uFg+Kua9B2EgxD2N0F3Ang31iSDK0KH6UUVRe5"
- name: kaliko
key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF9GKMSkGcE4n5pOuO8DwEbV18H47L6hvRwGEuJolrni"

View File

@ -1,82 +1,10 @@
#!/bin/bash
CMD="ANSIBLE_RETRY_FILES_ENABLED=0 ansible-playbook -e @config.yml roles/main.yml"
DEPS=("ansible-playbook" "grep")
REMOTE=false
doc_admin() {
echo " Pour plus d'information sur l'installation/configuration du serveur, se référer au manuel d'administration."
echo " ~~> docs/administrateurice.md"
}
# Vérifier que les dépendances sont installées, des fois qu'une personne n'aurait pas lu la doc
for dep in ${DEPS[*]}; do
which "$dep" > /dev/null
if [[ $? != 0 ]]; then
echo "ERREUR: La commande $dep n'existe pas dans mon \$PATH."
echo " Notre recette a besoin des programmes suivants: $DEPS"
doc_admin
exit 2
fi
done
for arg in "$@"; do
if [[ $arg = "remote" ]]; then
REMOTE=true
CMD="$CMD -i hosts"
fi
if [[ $arg = "check" ]]; then
CMD="$CMD --syntax-check"
fi
if [[ $arg = "debug" ]] || [[ $arg = "-vvv" ]]; then
CMD="$CMD -vvv"
fi
if [[ $arg = "verbose" ]] || [[ $arg = "-v" ]]; then
CMD="$CMD -v"
fi
done
if [[ $REMOTE = false ]]; then
# Vérifier que la distribution est bien Debian buster, sinon on risque de tout casser
grep "Debian GNU/Linux 10" /etc/issue > /dev/null
if [[ $? != 0 ]]; then
echo "ERREUR: Cette recette ne fonctionne que sur Debian 10 Buster! /etc/issue n'indique pas qu'on est sur buster."
doc_admin
exit 3
fi
# Sécurité pour empêcher une personne d'appliquer par erreur le playbook de ~fr sur son propre serveur
# Si le hostname dans config.yml est configuré pour fr.tild3.org mais que /etc/hostname n'est pas "fr",
# alors on ne fait rien... sauf bien sûr en mode remote.
grep -E "^hostname:.*?fr.tild3.org.*?$" config.yml > /dev/null
FR=$?
cur_host="$(cat /etc/hostname)"
if [[ "$cur_host" != "fr" ]] && [[ $FR = 0 ]]; then
echo "ERREUR DE CONFIGURATION"
echo " Tu essayes d'appliquer la recette avec la configuration du serveur ~fr (hostname: fr.tild3.org), pourtant il semble que ce serveur n'est pas ~fr (/etc/hostname = $cur_host)."
echo " Pour configurer ton serveur de zéro, tu peux partir du fichier d'exemple config.default.yml."
doc_admin
exit 1
fi
# Vérifier qu'on exécute le playbook en root, sinon on a pas assez de privilèges et ça ne sert à rien!
if [[ "$EUID" != 0 ]]; then
echo "ERREUR: Ce script doit être exécuté en root si exécuté localement."
echo " Tu veux que je configure quoi pour toi si j'ai pas les permissions? ;)"
exit 2
fi
CMD="$CMD --connection=local --inventory 127.0.0.1, --limit 127.0.0.1"
if [[ $1 = "test" ]]; then
ansible-playbook --check -i hosts site.yml
elif [[ $1 = "local" ]]; then
ansible-playbook --connection=local --inventory 127.0.0.1, --limit 127.0.0.1 \
site.yml -i hosts
else
# Running remotely, ensure there's a hosts file
if [ ! -f ./hosts ]; then
echo "ERREUR: On a besoin d'un fichier hosts pour appliquer la recette à distance."
doc_admin
exit 4
fi
CMD="$CMD -i hosts"
ansible-playbook -i hosts site.yml
fi
eval $CMD

View File

@ -1,113 +0,0 @@
# Administration du serveur
⚠ Si tu veux installer ton propre serveur, tu peux sauter à la section [Installation](#installation).
Les principaux paramètres du serveur sont configurés dans le fichier `host_vars/127.0.0.1.yml`. Ensuite, le dossier roles abrite des recettes pour le système de base (common), pour le serveur web et les utilitaires associés (webserver) et pour le DNS (nameserver). Ces recettes sont appelées dans `site.yml` qui définit leurs paramètres spécifiques.
## Gestion des utilisateurices
Pour créer un nouveau compte utilisateurice, il faut le déclarer dans la configuration du serveur:
```
- name: username
(- sudo: true)
- key: "clé publique SSH (format ~/.ssh/authorized_keys)"
```
## Configuration
Les principales directives de configuration du serveur sont expliquées dans cette section.
### hostname
Définit le nom de domaine principal associé au serveur.
```
hostname: fr.tild3.org
```
### users
Définit une liste d'utilisateurices configuréEs sur la machine. Chaque utilisateurice est un dictionnaire comprenant une clé 'name' portant son pseudonyme, une clé 'key' portant sa clé publique, et une clé optionnelle sudo contenant un booléen (true/false) pour définir si l'utilisateurice doit pouvoir exécuter des commandes admin.
```
users:
- name: user1
key: "-- REMPLACEZ MOI PAR UNE CLÉ SSH --"
- name: new_admin
sudo: true
key: "-- REPLACEZ MOI PAR UNE CLÉ SSH --"
```
### peers
Définit les serveurs amis, et nous permet de stocker des informations à leur propos et notamment des clés publiques. Chaque peer est un dictionnaire contenant les clés suivantes :
```
peers:
- name: ns1.tildeverse.org
key: "-- REMPLACEZ MOI PAR UNE CLÉ SSH --"
fingerprint: "-- REMPLACEZ MOI PAR UNE FINGERPRINT SSH --"
```
La clé SSH définie ici ouvre automatiquement un accès SSH chrooté aux serveurs pairs, pour leur permettre de mettre à jour leurs secrets sur notre serveur. Ce processus est notamment utilisé par le rôle nameserver pour échanger de façon sécurisée les clés (symmétriques) TSIG afin de sécuriser les mises à jour des zones DNS.
L'empreinte de clé définie dans la clé fingerprint correspond à la clé publique du serveur SSH du serveur pair. Cela nous permet de vérifier qu'une tierce personne n'est pas en train d'extirper nos secrets.
## Installation
Alors tu veux monter ton petit serveur? Chouette, on espère que tu vas trouver ici des recettes pour te permettre d'avancer. Pour appliquer notre recette, il te faut un serveur sous Debian 10 (buster). Comme on utilise Ansible, on peut soit appliquer les recettes à distance par SSH, soit en local en installant ansible directement sur le serveur.
### Installation à distance
Pour pouvoir appliquer la recette à distance, il faut que le serveur ait SSH d'installé et configuré. Il faut que tu puisses te connecter au serveur en tant que root, et il est conseillé d'utiliser l'authentification par clé publique.
Ensuite, il faut créer un fichier `hosts` à la racine du dépot pour qu'Ansible trouve le serveur auquel se connecter:
```
nomDuServeur ansible_host=monserveur.example.com ansible_user=root
```
👍 Si tu souhaites utiliser Tor pour configurer ton serveur, il te suffit de [configurer ton client SSH](utilisateurice.md#se-connecter-par-tor) pour passer par Tor. Ansible ne fait rien d'autre qu'exécuter des commandes en SSH. En pratique, c'est suffisamment lent pour te donner envie de faire une installation locale.
### Installation locale
Pour appliquer la recette localement, il faut que ton serveur ait ansible d'installé. Si tu dois cloner le dépot directement sur le serveur, alors il faut aussi installer git.
Par exemple:
```
root@server:~ # apt install ansible git
...
root@server:~ # git clone https://tildegit.org/tilde-fr/infra
```
### Appliquer la recette
Pour pouvoir appliquer la recette, il faut modifier le fichier de configuration config.yml. Celui fourni dans le dépot est le fichier de configuration de ~fr, mais il y a un fichier de config par défaut qu'il suffit de copie à la place :
```
$ cp config.default.yml config.yml
```
Pour une configuration minimale, il faut au moins changer le hostname (en mettant ton nom de domaine) et la clé SSH (voire le nom) de l'utilisateurice. Le reste de la configuration est décrit dans la section [Configuration](#configuration).
Enfin, pour appliquer les changements, il faut lancer le playbook ansible. On utilise pour cela le script deploy.sh. Par défaut, la recette est appliquée localement et il faut donc la lancer en root. Si un argument "remote" est trouvé, alors la recette est exécuté sur le serveur défini dans le fichier hosts.
```
# Exécuter la recette à distance
user@client:~/infra $ ./deploy.sh remote
...
# Appliquer la recette localement
root@server:~/infra $ ./deploy.sh
```
Additionnellement, deploy.sh accepte un argument `check` qui déclenche une simple vérification de la syntaxe Ansible. Enfin, la commande accepte également un argument "debug" ou "-vvv" qui envoie "-vvv" à Ansible, et un argument "verbose" ou "-b" qui envoie "-v" à ansible. En résumé :
```
deploy.sh [remote|check|debug(-vvv)|verbose(-v)] ..
check: vérifie la syntaxe ansible
remote: applique la recette sur un serveur distant (défini dans ./hosts)
debug: active le mode debug de ansible (afficher TOUT)
verbose: active le mode verbose (afficher les résultats des tâches modifiées)
```

View File

@ -1,115 +0,0 @@
# Guide utilisateurice
Bienvenue sur le serveur ~fr ! Ici, tu trouveras peut-être des réponses à tes questions.
## Configurer ton client SSH
Si tu n'es pas encore connectéE au serveur, tu as peut-être besoin d'un petit coup de pouce !
### Générer une paire de clés
Pour se connecter, on utilise des clés SSH. Ces clés vont par paire, une clé publique et une clé privée. La clé privée, tu la garde sur ta machine: elle te permet grâce à un mot de passe, de t'authentifier auprès de n'importe qui connaît ta clé publique. Du coup, pour créer un compte, faut nous envoyer ta clé publique.
Quand tu génères une paire de clés avec la commande ssh-keygen, cela génère dans ton dossier ~/.ssh un fichier sans extension (la clé privée), et un fichier du même nom avec une extension .pub. Pour avoir une connexion sécurisée sans pomper trop de ressources, on utilise des clés de type ed25519 en passant le paramètre `-t ed25519` à la commande :
```
$ ssh-keygen -t ed25519
Generating public/private rsa key pair.
Enter file in which to save the key (/home/tonutilisateurice/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/tonutilisateurice/.ssh/id_rsa.
Your public key has been saved in /home/tonutilisateurice/.ssh/id_rsa.pub.
The key fingerprint is:
f6:61:38:25:25:df:4d:4b:13:11:70:cf:4c:c8:a0:22 tonutilisateurice@tamachine
```
La commande te demande où stocker la clé (le paramètre par défaut est très bien pour commencer), puis te demande de renseigner une phrase de passe qui protègera l'utilisation de ta clé privée si jamais tu te la fais dérober. Après avoir reconfirmé ta phrase de passe, hop ta clé est crée ! On peut maintenant la lire, par exemple avec la commande cat :
```
$ cat .ssh/id_ed25519.pub
ssh-ed25519 BLABLABLA tonutilisateurice@tamachine
```
Pour qu'on puisse te créer un compte, c'est cette clé publique qu'il faut nous transmettre. Le dernier bout, par contre n'est pas obligatoire et peut t'empêcher de te connecter depuis une autre machine en copiant simplement ta clé ailleurs, parce que le nom de ta machine ou ton nom d'utilisateurice aura changé.
### Se connecter
Une fois que ton compte aura été activé, tu peux maintenant te connecter au serveur avec SSH :
```
$ ssh utilisateurice@fr.tild3.org
Enter passphrase for key '/home/tonutilisateurice/.ssh/id_ed25519':
```
### Configurer SSH pour raccourcir la commande
C'est long à taper. Vite, comment configurer des Hosts!
TODO
### Gérer plusieurs clés SSH
Ton client SSH peut gérer plusieurs paires de clés à la fois. Si tu as besoin d'en créer d'autres, tu peux leur donner des petits noms avec le paramètre `-f ~/.ssh/taclé` de ssh-keygen, ou bien en renseignant un autre emplacement pour stocker la clé quand le programme te le demande. Ces clés peuvent être stockées plus ou moins n'importe où sur ta machine, mais en général on trouve ça plutôt pratique de les garder dans le dossier ~/.ssh.
Pour te connecter à un serveur en utilisant une clé spécifique, on utilise `ssh -i ~/.ssh/taclé utilisateurice@fr.tild3.org`. Si ça devient un peu long à tout taper, le fichier de configuration de ton client SSH a une option `IdentityFile` dans le Host qui te permet de spécifier la clé à utiliser pour ce serveur :
```
Host fr
IdentityFile ~/.ssh/taclé
...
```
Comme tu sais maintenant configurer ton client SSH, il y a une option pratique pour gérer plusieurs clés. Un Host dans le fichier de configuration SSH
### Se connecter en passant par Tor
Pour se connecter au serveur en passant pas le réseau Tor, il suffit d'ajouter les paramètres suivants à la configuration du Host correspondant :
```
...
ProxyCommand connect -4 -S localhost:9050 $(tor-resolve %h localhost:9050) %p
CheckHostIP no
...
```
Bien sûr cela ne fonctionne que si tor est installé et fonctionnelle sur ta machine. Sur Debian GNU/Linux, il te suffit d'installer le paquet tor (apt install tor) et tout marche.
## Configurer tes pages perso
Nous proposons de l'hébergement de pages/fichiers statiques sur le web. Si ton nom d'utilisateurice est `username`, alors tu contrôles les addresses username.fr.tild3.org et fr.tild3.org/~username. En plus de cela, une adresse en .onion est générée pour toi à la création de ton compte, et te permet de fournir un accès sécurisé et anonymes à tes pages perso.
Par défaut, ces trois adresses servent le même contenu, que tu trouveras dans ~/public_html/ c'est à dire le dossier public_html dans ton dossier personnel. Si tu veux rajouter du contenu sur ton site, il suffit de le verser dans ce dossier.
TODO: Si tu souhaites avoir des sites différents sur ces trois adresses, pas de problème! En réalité, chaque site est servi par un dossier différents dans le dossier public/ de ton compte. Mais pour te simplifier la vie, à la création de ton compte, ces trois dossiers sont par défaut reliés à ton dossier ~/public_html avec des liens symboliques, pour éviter de perdre la tête.
Maintenant, si tu supprimes un de ces liens symboliques, tu peux le remplacer par un dossier qui sert du contenu spécifique à cette adresse :
```
$ rm ~/public/utilisateurice
$ mkdir ~/public/utilisateurice
$ echo "Bienvenue sur mon sous-domaine perso!" > ~/public/utilisateurice/index.html
# Et ce fichier est désormais accessible sur le web
$ curl https://utilisateurice.fr.tild3.org/
Bienvenue sur mon sous-domaine perso!
```
Ces trois dossiers sont disponibles:
- ~/public/tilde: le contenu servi à l'adresse fr.tild3.org/~utilisateurice
- ~/public/utilisateurice: le contenu servi à l'adresse utilisateurice.fr.tild3.org
- ~/public/onion: le contenu servi à l'adresse en .onion (à trouver dans ~/onion)
## Envoyer des fichiers sur le serveur
Si tu as fait un petit site web en local que tu veux publier sur le serveur, ou que tu veux stocker des trucs sur ton compte, cela se passe directement avec tes identifiants SSH! Pas besoin de configurer un client FTP ou Dropbox, tu peux simplement taper dans ta console (sur ta machine, pas sur le serveur) :
```
# Envoie un fichier au serveur dans le dossier personnel
$ scp monfichier username@fr.tild3.org:~
# Envoie mon dossier dans le fichier personnel
$ scp -r Documents username@fr.tild3.org:~
# La partie derrière les : indique dans quel dossier envoyer
$ scp -r mon_site/* username@fr.tild3.org:~/public_html
```
Si cela te ferait plaisir, on peut activer rsync aussi.

1
host_vars/127.0.0.1.yml Symbolic link
View File

@ -0,0 +1 @@
fr.yml

15
host_vars/fr.yml Normal file
View File

@ -0,0 +1,15 @@
hostname: fr.tild3.org
peers:
- name: tilde.netlib.re
client_key: "SSH key"
server_key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHUAIuwEhFXTDfOEG+hQ2d/xeUwsgPJQF7oeNYr1ZXnG"
users:
- name: tofu
sudo: true
key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIG4bKe9LSA3/AY4gCB20eyJVPW+zOg07/b3A4QC0Z6XC"
- name: kumquat
key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFZ5FBnDlBIGlJ4TI0babTTmS5ECPM3yuDP1AhnNQUDZ"
- name: mspe
key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICZAs76kQJ0/Et2NGzhxurK2wE0VhYsG9wl85iCmR9xH"
- name: merry
key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFxPbGSCW0KOOreD0FZGu3PFKMNIEi5VrJHzub8+poVs"

1
hosts Normal file
View File

@ -0,0 +1 @@
fr ansible_host=fr.tild3.org ansible_user=root

View File

@ -1,93 +0,0 @@
task: Task
handler: Handler
SUMMARY: SUMMARY
Gathering Facts: Gather facts
changed: changed
ok: ok
ignored: ignored
failed: failed
unreachable: unreachable
#### roles/.common
# roles/.common/tasks/main.yml
common-backports: Enable backports
common-base-pkg: Install base packages
common-certbot-setup: Configure certbot with the contact email
common-users-gen: Generate user accounts
common-peering: Setup peering with friendly servers
common-additional-packages: Install additional packages
common-roles: Apply roles defined in config
# roles/.common/tasks/packages.yml
common-package-managers: Start package managers
# roles/.common/tasks/tor.yml
common-tor-create: Create /etc/tor/onions/ for tor config
common-tor-config: Load onions from /etc/tor/onions
# roles/.common/tasks/peering/main.yml
common-peering-home: Create /home/peers
common-peering-remote: Configure peer server
# roles/.common/tasks/peering/setup_local.yml
common-peering-local-account: Create account peer
common-peering-local-ln: Create symbolic link to the local peer
common-peering-local-genkey: Generate SSH key for local peer
common-peering-local-confkey: Force SSH as ed25519 for local peer
# roles/.common/tasks/peering/setup_peer.yml
common-peering-remote-account: Create account for peer server
common-peering-remote-key: Configure SSH key for peer
common-peering-remote-known: Declare key for peer server on account peer
# roles/.common/tasks/users/main.yml
common-users-tor-reload: Reload tor to generate new onions
common-users-tor-wait: Wait for onions to be generated
# roles/.common/tasks/users/setup_user.yml
common-users-setup-account: Create account for new user
common-users-setup-sudo: Give admin powers to new user
common-users-setup-key: Authorize associated SSH key
common-users-setup-onion: Generate a personal onion
common-users-setup-irc: Welcome the user on IRC
common-users-tor-wait: Wait for onions to be generated
#### roles/webserver
# roles/webserver/handlers/main.yml
webserver-reload-nginx: Restart web server
# roles/webserver/tasks/certbot.yml
webserver-certbot-main: Generate main certificate
webserver-certbot-users: Generate user certificates
# roles/webserver/tasks/nginx.yml
webserver-default-config: Generate config for default site
webserver-default-symlink: Enable config for default site
webserver-tls-config: Configure webserver TLS settings
webserver-personal-pages: Setup personal pages
webserver-bucket-size: Configure webserver for long domain names (onions)
# roles/webserver/tasks/onions_perso.yml
webserver-onion-hostname: Read personal onion
webserver-onion-giveuser: Tell user about their onion address
webserver-onion-config: Configure personal onion page
webserver-onion-symlink: Enable personal onion page config
# roles/webserver/tasks/packages.yml
webserver-pkg: Setup packages for the webserver
# roles/webserver/tasks/pages_perso.yml
webserver-perso-config: Configure personal pages for webserver
webserver-perso-symlink: Enable personal pages config
webserver-perso-publichtml: Create public_html folder in skel
webserver-perso-onions: Prepare personal pages on onions
webserver-perso-multisite: Enable multisite support by linking to ~/public_html
# roles/webserver/tasks/multisite.yml
webserver-multisite-check: Verify that ~/public/html exists
webserver-multisite-folder: Create ~/public/html
webserver-multisite-symlink: Create symlinks to ~/public_html
#### .debian
# roles/.debian/tasks/main.yml
debian-pkg: Setup Debian packaged défined in config
#### .rust
# roles/.rust/tasks/main.yml
rust-setup: Setup rust and cargo
rust-user: Create a rust account to compile packages
rust-cargo-folder: Create folder for cargo
rust-bin-ownership: Give rust ownership over local bin directory
rust-bin-symlink: Create symbolic link from cargo to local bin directory
rust-pkg: Setup rust packages defined in config
#### .custom
# roles/.custom/tasks/zola/main.yml
custom-zola-setup: Setup zola static site generator (SSG)
# roles/.custom/tasks/ttbp/main.yml
custom-ttbp-source: Download ttbp source
custom-ttbp-pkg: Setup ttbp dependencies
custom-ttbp-setup: Setup Tilde Team Blogging Platform (ttbp)
custom-ttbp-tmp: Delete ttbp temporary files

View File

@ -1,92 +0,0 @@
task: Tâche
handler: Gestionnaire
SUMMARY: RÉSUMÉ
Gathering Facts: Rassembler les faits
changed: changéE
ok: ok
ignored: ignoré
failed: échoué
unreachable: injoignable
#### roles/.common
# roles/.common/tasks/main.yml
common-backports: Activer les backports
common-base-pkg: Installer les paquets de base
common-certbot-setup: Configurer certbot avec le mail de contact
common-users-gen: Générer les comptes des utilisateurices
common-peering: Mettre en place le peering avec les serveurs amis
common-additional-packages: Installer les paquets supplémentaires
common-roles: Appliquer les rôles définis dans la config
# roles/.common/tasks/packages.yml
common-package-managers: Exécuter les gestionnaires de paquets
# roles/.common/tasks/tor.yml
common-tor-create: Créer /etc/tor/onions pour la config Tor
common-tor-config: Charger les onions tor depuis /etc/tor/onions
# roles/.common/tasks/peering/main.yml
common-peering-home: Créer /home/peers
common-peering-remote: Configurer le serveur pair
# roles/.common/tasks/peering/setup_local.yml
common-peering-local-account: Créer un compte peer
common-peering-local-ln: Créer un lien symbolique vers le pair local
common-peering-local-genkey: Créer une clé SSH pour le compte peer
common-peering-local-confkey: Forcer SSH en ed25519 sur le compte peer
# roles/.common/tasks/peering/setup_peer.yml
common-peering-remote-account: Créer un compte pour le serveur pair
common-peering-remote-key: Configurer la clé SSH autorisée pour le pair
common-peering-remote-known: Déclarer la clé du pair sur le compte peer
# roles/.common/tasks/users/main.yml
common-users-tor-reload: Redémarrer tor pour générer les nouveaux onions
common-users-tor-wait: Attendre que les onions soient générés
# roles/.common/tasks/users/setup_user.yml
common-users-setup-account: Créer le nouveau compte
common-users-setup-sudo: Donner les droits d'admin au nouveau compte
common-users-setup-key: Autoriser la clé SSH associée
common-users-setup-onion: Générer un onion perso
common-users-setup-irc: Accueillir l'utilisateurice sur IRC
#### roles/webserver
# roles/webserver/handlers/main.yml
webserver-reload-nginx: Redémarrer le serveur web
# roles/webserver/tasks/certbot.yml
webserver-certbot-main: Générer le certificat principal
webserver-certbot-users: Générer les certificats perso
# roles/webserver/tasks/nginx.yml
webserver-default-config: Générer la configuration du site par défaut
webserver-default-symlink: Activer la config du site par défaut
webserver-tls-config: Paramétrer TLS pour le serveur web
webserver-personal-pages: Mettre en place les pages perso
webserver-bucket-size: Configurer le serveur web pour les longs domaines (.onion)
# roles/webserver/tasks/onions_perso.yml
webserver-onion-hostname: Récupérer l'onion perso
webserver-onion-giveuser: Indiquer à l'utilisateurice l'adresse de son onion
webserver-onion-config: Configurer les pages perso en onion
webserver-onion-symlink: Activer la configuration des pages perso en onion
# roles/webserver/tasks/packages.yml
webserver-pkg: Installer les paquets pour le serveur web
# roles/webserver/tasks/pages_perso.yml
webserver-perso-config: Configurer les pages perso
webserver-perso-symlink: Activer la configuration des pages perso
webserver-perso-publichtml: Créer le dossier public_html dans /etc/skel
webserver-perso-multisite: Activer le multi-site en pointant vers ~/public_html
webserver-perso-onions: Préparer les pages perso en onion
# roles/webserver/tasks/multisite.yml
webserver-multisite-check: Vérifier si ~/public/html existe
webserver-multisite-folder: Créer ~/public/html/
webserver-multisite-symlink: Créer les liens symboliques vers ~/public_html
#### .debian
# roles/.debian/tasks/main.yml
debian-pkg: Installer les paquets Debian définis dans la config
#### .rust
# roles/.rust/tasks/main.yml
rust-setup: Installer rust et cargo
rust-user: Créer un compte rust pour compiler les paquets
rust-cargo-folder: Créer le dossier pour cargo
rust-bin-ownership: Donner à rust la gestion des exécutables locaux
rust-bin-symlink: Créer un lien symbolique de cargo vers les exécutables locaux
rust-pkg: Installer les paquets rust qui nous intéressent
#### .custom
# roles/.custom/tasks/zola/main.yml
custom-zola-setup: Installer le générateur de sites statiquse (SSG) zola
# roles/.custom/tasks/ttbp/main.yml
custom-ttbp-source: Télécharger la source de ttbp
custom-ttbp-pkg: Installer les dépendances de ttbp
custom-ttbp-setup: Installer Tilde Team Blogging Platform (ttbp)
custom-ttbp-tmp: Supprimer les fichiers temporaires de ttbp

1
roles

@ -1 +0,0 @@
Subproject commit 42c4547358504d25275eede195b25e9e50095ffa

View File

@ -0,0 +1,5 @@
# Because we are using logrotate for greater flexibility, disable the
# internal certbot logrotation.
max-log-backups = 0
rsa-key-size = 4096
email = southerntofu@thunix.net

View File

@ -0,0 +1,3 @@
HiddenServiceDir /var/lib/tor/{{ item.name }}
HiddenServiceVersion 3
HiddenServicePort 80 127.0.0.1:80

View File

@ -0,0 +1,4 @@
Host *
HostKeyAlgorithms ssh-ed25519
PubkeyAcceptedKeyTypes ssh-ed25519
PasswordAuthentication no

View File

@ -0,0 +1,4 @@
- name: reload tor
service:
name: tor
state: restarted

View File

@ -0,0 +1,90 @@
- name: Activer les backports
lineinfile:
path: /etc/apt/sources.list.d/backports.list
line: deb http://ftp.debian.org/debian buster-backports main contrib
create: yes
state: present
- name: Installer les paquets de base
apt:
state: present
name: "{{ packages }}"
update_cache: yes
vars:
packages:
- git
- subversion
- mercurial
- htop
- tmux
- vim
- emacs
- certbot
- mutt
- weechat
- elinks
- rustc
- cargo
- cargo-doc
- rsync
- dnsutils
- make
- g++
- libssl-dev
- mosh
- tor
- sudo
- name: setup certbot with contact email
copy:
src: ../files/letsencrypt_cli.ini
dest: /etc/letsencrypt/cli.ini
- include: tor.yml
- include: rust_packages.yml
- include: users.yml
- name: Créer le dossier /home/peers
file:
path: "/home/peers"
state: directory
- name: Créer un compte peer pour se connecter avec d'autres serveurs
user:
name: "peer"
state: present
skeleton: /etc/skel
shell: /bin/bash
system: no
createhome: yes
home: "/home/peers/{{ hostname }}"
- name: Créer un lien symbolique /home/peers/self
file:
dest: /home/peers/self
src: "/home/peers/{{ hostname }}"
state: link
- file:
path: /home/peers/self/.ssh
owner: peer
group: peer
state: directory
- name: Générer une clé SSH pour le compte peer
become: yes
become_user: peer
command:
creates: /home/peers/self/.ssh/id_ed25519.pub
cmd: ssh-keygen -t ed25519 -f /home/peers/self/.ssh/id_ed25519 -N ""
- name: Configurer SSH en ed25519 depuis le compte peer
copy:
src: ../files/ssh_config
dest: /home/peers/self/.ssh/config
- name: Générer les comptes
include: peers.yml
loop: "{{ peers }}"

View File

@ -0,0 +1,23 @@
- name: Créer un compte pour le serveur pair
user:
name: "{{ item.name }}"
state: present
skeleton: /etc/skel
shell: /bin/bash
system: no
createhome: yes
home: "/home/peers/{{ item.name }}"
- name: Configurer la clé autorisée pour le serveur pair
lineinfile:
path: "/home/peers/{{ item.name }}/.ssh/authorized_keys"
line: "{{ item.client_key }}"
create: yes
# TODO: dans authorized_keys pour restreindre le compte à SCP
# no-port-forwarding,no-pty,command="scp source target" ssh-dss ...
# TODO: chroot
- name: Configurer le known_hosts du compte peer pour le serveur pair
lineinfile:
path: /home/peers/self/.ssh/known_hosts
create: yes
line: "{{ item.name }} {{ item.server_key }}"

View File

@ -0,0 +1,56 @@
- name: Installer rust et cargo
apt:
state: present
name: "{{ packages }}"
update_cache: yes
vars:
packages:
- rustc
- cargo
- cargo-doc
- name: Créer unE user rust pour compiler les crates
user:
name: "rust"
state: present
skeleton: /etc/skel
shell: /bin/bash
system: no
createhome: yes
home: "/home/rust"
- name: Créer le dossier pour cargo
file:
path: /home/rust/.cargo
state: directory
owner: rust
group: rust
- name: Transférer les permissions de /usr/local/bin à rust
file:
path: /usr/local/bin
state: directory
owner: rust
group: rust
mode: 0755
recurse: yes
- name: Créer un symlink de ~rust/.cargo/bin vers /usr/local/bin
file:
dest: /home/rust/.cargo/bin
src: /usr/local/bin
force: yes
follow: no
state: link
- name: Installer les paquets rust qui nous intéresse
become:
become_user: rust
command:
cmd: "cargo install {{ item }}"
creates: "/usr/local/bin/{{ item }}"
loop: "{{ crates }}"
vars:
crates:
- lsd

View File

@ -0,0 +1,26 @@
- name: Register users
user:
name: "{{ item.name }}"
state: present
skeleton: /etc/skel
shell: /bin/bash
system: no
createhome: yes
home: "/home/{{ item.name }}"
- name: Make admins sudo
user:
name: "{{ item.name }}"
group: sudo
when: item.sudo|default(false) == true
- name: Publish SSH keys
authorized_key:
user: "{{ item.name }}"
state: present
key: "{{ item.key }}"
- name: Génerer un onion pour l'utilisateurice
template:
src: ../files/onion.conf.j2
dest: "/etc/tor/onions/{{ item.name }}.conf"

View File

@ -0,0 +1,14 @@
- name: Tor charge les onions depuis /etc/tor/onions/
lineinfile:
path: /etc/tor/torrc
line: "%include /etc/tor/onions"
state: present
notify: reload tor
- name: On crée le dossier pour les onions
file:
path: /etc/tor/onions
state: directory
owner: debian-tor
group: debian-tor
mode: '0740'

View File

@ -0,0 +1,12 @@
- include_tasks: setup_user.yml
loop: "{{ users }}"
- name: Redémarrer le démon tor pour générer les onions
service:
name: tor
state: restarted
- name: Attendre que les onion perso soient générés
wait_for:
path: "/var/lib/tor/{{ item.name }}/hostname"
loop: "{{ users }}"

View File

@ -0,0 +1,17 @@
$TTL 3600
$ORIGIN {{ hostname }}.
@ SOA {{ hostname }}. root.{{ hostname }}. (
2020041200 ; serial
86400 ; refresh (1 day)
7200 ; retry (2 hours)
3600000 ; expire (5 weeks 6 days 16 hours)
172800 ; minimum (2 days)
)
NS {{ hostname }}.
NS myimaginaryfriend.example.com
A 192.95.3.24
AAAA 2607:5300:203:5fd5::24
MX 1 {{ hostname }}.
TXT "v=spf1 mx -all"
* A 192.95.3.24
AAAA 2607:5300:203:5fd5::24

View File

@ -0,0 +1,5 @@
zone "{{ item.domain }}" {
type master;
update-policy local;
file "zones/primary/{{ item.domain }}.db";
}

View File

@ -0,0 +1,19 @@
# TODO update-policy for primary zones
{% for zone in primary %}
zone {{ zone.name }} {
type master;
file "/etc/bind/zones/{{ zone.name }}.db";
};
{% endfor %}
{% if secondary is defined %}{% for ns in secondary %}
zone {{ ns }}.catalog {
type slave;
file "/etc/bind/zones/.{{ ns }}.catalog.db";
};
{% endfor %}{% endif %}

View File

@ -0,0 +1,27 @@
# TODO TSIG keys
# TODO DNSSEC
# TODO also-notify our secondary servers
options {
directory "/var/cache/bind";
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-validation auto;
listen-on-v6 { any; };
recursion no;
{% if secondary is defined %}
catalog-zones {
in-memory no;
zone-directory /etc/bind/peers;
{% for ns in secondary %}
zone "{{ ns }}.catalog";
{% endfor %}
}
{% endif %}
};

View File

@ -0,0 +1,5 @@
zone "{{ item.domain }}" {
type master;
update-policy local;
file "zones/primary/{{ item.domain }}.db";
}

View File

@ -0,0 +1,4 @@
- name: reload bind
service:
name: bind9
state: restarted

View File

@ -0,0 +1,23 @@
- name: Installer bind9
apt:
name: bind9
state: present
- name: Créer les dossiers /etc/bind/{zones,catalog}
file:
path: "/etc/bind/{{ item }}"
owner: bind
group: bind
state: directory
loop: [ "zones", "catalog" ]
- name: Générer la config du serveur
template:
src: ../files/named.conf.local.j2
dest: /etc/bind/named.conf.local
notify: reload bind
- name: Configuration de la zone principale
template:
src: ../files/main.zone.j2
dest: "/etc/bind/zones/{{ hostname }}.db"

BIN
roles/webserver/files/bin/zola Executable file

Binary file not shown.

View File

@ -0,0 +1,37 @@
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
root /var/www/html;
location /.well-known/acme-challenge {
try_files $uri $uri/ =404;
}
location / {
return 302 https://$host$request_uri;
}
}
server {
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
ssl_certificate /etc/letsencrypt/live/{{ hostname }}/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/{{ hostname }}/privkey.pem;
server_name _;
root /var/www/html;
index index.html;
location ~ ^/~(.+?)(/.*)?$ {
alias /home/$1/public_html/$2;
autoindex on;
#try_files $2 $2/ = 404;
}
location / {
try_files $uri $uri/ =404;
}
}

View File

@ -0,0 +1,12 @@
server {
listen 80;
listen [::]:80;
server_name {{ web_onion.stdout }};
root /home/{{ item.name }}/public_html;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}

View File

@ -0,0 +1,16 @@
# Taken from https://raw.githubusercontent.com/certbot/certbot/master/certbot-nginx/certbot_nginx/_internal/tls_configs/options-ssl-nginx.conf
# This file contains important security parameters. If you modify this file
# manually, Certbot will be unable to automatically provide future security
# updates. Instead, Certbot will print and log an error message with a path to
# the up-to-date file that you will need to refer to when manually updating
# this file.
ssl_session_cache shared:le_nginx_SSL:10m;
ssl_session_timeout 1440m;
ssl_session_tickets off;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";

View File

@ -0,0 +1,16 @@
{% for user in users %}
server {
listen 443 ssl;
listen [::]:443 ssl;
ssl_certificate /etc/letsencrypt/live/{{ user.name }}.{{ hostname }}/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/{{ user.name }}.{{ hostname }}/privkey.pem;
server_name {{ user.name }}.{{ hostname }};
root /home/{{ user.name }}/public_html;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}
{% endfor %}

View File

@ -0,0 +1,2 @@
- name: reload nginx
service: name=nginx state=restarted

View File

@ -0,0 +1,10 @@
- name: Generate main certificate
command:
creates: /etc/letsencrypt/live/{{ hostname }}/fullchain.pem
cmd: certbot certonly --non-interactive --agree-tos --webroot -w /var/www/html -d {{ hostname }} -d www.{{ hostname }}
- name: Generate user certificates
command:
creates: "/etc/letsencrypt/live/{{ item.name }}.{{ hostname }}/fullchain.pem"
cmd: "certbot certonly --non-interactive --agree-tos --webroot -w /var/www/html -d {{ item.name }}.{{ hostname }}"
loop: "{{ users }}"

View File

@ -0,0 +1,7 @@
---
# This playbook contains all of the www config
- include: packages.yml
# TODO: Some certbot is needed before we can load the whole nginx config so we need some intermediary step (bootstrapping process)
- include: nginx.yml
- include: certbot.yml

View File

@ -0,0 +1,27 @@
- name: Deploy default site configuration
template:
src: ../files/default-site.conf.j2
dest: /etc/nginx/sites-available/default-site.conf
notify: reload nginx
- name: Prepare symlink for default site
file:
src: /etc/nginx/sites-available/default-site.conf
dest: /etc/nginx/sites-enabled/default-site.conf
state: link
- name: Deploy TLS config
copy:
src: ../files/ssl.conf
dest: /etc/nginx/conf.d/ssl.conf
notify: reload nginx
- name: Déployer les pages perso
include: pages_perso.yml
- name: Configurer nginx pour les noms de domaine longs
lineinfile:
path: /etc/nginx/nginx.conf
line: "server_names_hash_bucket_size 128;"
insertafter: "^http {"
notify: reload nginx

View File

@ -0,0 +1,15 @@
- name: Récupérer le hostname en onion
command: "cat /var/lib/tor/{{ item.name }}/hostname"
register: web_onion
- name: Configurer l'onion pour les pages perso de l'utilisateurice
template:
src: ../files/onion.conf.j2
dest: "/etc/nginx/sites-available/{{ item.name }}.onion.conf"
notify: reload nginx
- name: Activer la configuration nginx
file:
src: "/etc/nginx/sites-available/{{ item.name }}.onion.conf"
dest: "/etc/nginx/sites-enabled/{{ item.name }}.onion.conf"
state: link

View File

@ -0,0 +1,75 @@
# Install apache and accoutrements www, irrespective of what role they might have
---
- name: Install packages for webserver
apt:
name: "{{ packages }}"
state: present
update_cache: yes
vars:
packages:
- nginx
- php-fpm
- php-curl
- php-gd
- php-intl
- php-sqlite3
- php-mbstring
# Malheureusement zola compile pas sur debian buster (rustc v1.34 contre 1.36 requis)
# Donc on copie un binaire que j'ai compilé avec amour
- name: Installer le générateur de site statique zola
copy:
src: ../files/bin/zola
dest: /usr/local/bin/zola
mode: 0755
# - stat:
# path: /usr/local/bin/zola
# register: zola
#
# - name: Télécharger la source de zola
# git:
# dest: /tmp/zola
# repo: https://github.com/getzola/zola
# version: "v0.10.1"
# when: not zola.stat.exists
#
# Zola a besoin de make, g++, libssl-dev et libsass-dev qui sont installés dans main.yml
#
# - name: Compiler zola
# command: "cargo install --path /tmp/zola"
# when: not zola.stat.exists
#
# - name: Supprimer les fichiers temporaires de zola
# file:
# path: /tmp/zola
# state: absent
# when: not zola.stat.exists
- stat:
path: /usr/local/bin/ttbp
register: ttbp
- name: Télécharger la source de ttbp
git:
repo: https://tildegit.org/envs/ttbp.git
dest: /tmp/ttbp
when: not ttbp.stat.exists
- name: ttbp a des dépendances non installées dans main.yml
apt:
name: "python-setuptools"
state: present
- name: Compiler ttbp
command:
cmd: "python /tmp/ttbp/setup.py install"
chdir: /tmp/ttbp
when: not ttbp.stat.exists
- name: Supprimer les fichiers temporaires de ttbp
file:
path: /tmp/ttbp
state: absent
when: not ttbp.stat.exists

View File

@ -0,0 +1,21 @@
- name: Créer les liens symboliques pour la config des sites
file:
src: /etc/nginx/sites-available/users-site.conf
dest: /etc/nginx/sites-enabled/users-site.conf
force: yes
follow: no
state: link
- name: Configurer les pages perso pour nginx
template:
src: ../files/users.conf.j2
dest: /etc/nginx/sites-available/users-site.conf
- name: Ajouter un dossier public_html dans le squelette
file:
path: /etc/skel/public_html
state: directory
- name: Configurer les pages perso en onion
include: onions_perso.yml
loop: "{{ users }}"

22
site.yml Normal file
View File

@ -0,0 +1,22 @@
- name: Setup common utilities
hosts: all
roles:
- common
- name: Setup web server
hosts: all
roles:
- webserver
- name: installer le serveur de noms
hosts: all
roles:
- nameserver
vars:
primary:
- name: fr.tild3.org
file: ../files/fr.tild3.org.zone
# secondary:
# - ns1.tildeverse.org
send_to_secondary:
- myimaginaryfriend.example.com