- Historique
- Comment ça marche ?
- Comment faire ?
- Au premier jour était le Néant puis vint le premier BOFH qui créa le premier bit. Il vit que c'était bon.
- Au deuxième jour le BOFH sépara les hosts des VM.
- Au troisième jour le BOFH installa Slackware que lui avait donné le plus saint de tous les BOFH, Pat the Man, sur toutes les VM et vit que c'était la meilleure idée de tous les temps.
- Au quatrième jour le BOFH créa les lusers pour qu'ils puissent utiliser les VM.
- Au cinquième jour le BOFH configura toutes les VM afin que le peuple des lusers puisse pleinement profiter des services.
- Au sixième jour le BOFH sélectionna quelques lusers qu'il nomma BOFH à leurs tours.
- Au septième jour le BOFH but une bière pour se reposer de tout ce travail.
Le socle Bash est une version allégée d'un ensemble de bibliothèques et fonctions écrit en grande partie par Emmanuel Confrère, émminent DBA Calédonien qui nous a autorisé à l'utiliser au sein du Tetalab, et dont l'utilité est d'assurer la cohérence des scripts qui s'appuient dessus.
Ce socle Bash est fiable et robuste. Il peut sans aucun doute être utilisé en production à la condition que l'ensemble des conseils listés dans la documentation soient respectés.
Entre autres fonctionalités ce socle Bash permet aux scripts qui s'appuient dessus:
- La gestion de l'historique d'exécution
- La gestion des logs
- La gestion des fichiers temporaires
- La gestion des options et arguments
- La gestion des erreurs
- La standadisation de l'affichage
- ...
Le socle Bash et sa documentation sont disponibles ici.
Vous devez impérativement utiliser le socle Bash lorsque vous écrivez un script Bash qui sera utilisé sur l'infrastructure du Tetalab.
Par ailleurs et afin de faciliter leur déploiement, les scripts écrits avec le socle Bash doivent être intégrés dans le répertoire /bin du dépot git des scripts de gestion de l'infrastructure.
N'hésitez pas à prendre exemple sur les scripts fournis par le socle Bash pour rédiger vos propres scripts.
Ajout de scripts, mise à jour des scripts et des fichiers de configuration des scripts
Le seul moyen d'ajouter un script aux scripts de gestion de l'infrastructure est de l'ajouter via son dépôt git dont l'url est la suivante:
git clone ssh://git@tetalab.org:2213/tetalab/archilab_scripts
Vous devez faire partie des BOFH pour pouvoir cloner/pousser une modification sur ce dépôt.
Si vous n'avez pas les droits en écriture sur le dépot git des scripts de gestion de l'infrastructure, faites une demande à un BOFH
Si vous voulez que votre modification soit immédiatement prise en compte sur toutes les VM de l'infrastructure, connectez vous sur sousetsuken et exécutez la commande suivante:
sudo -u asr sys_refresh_tetalab_scripts.sh
Dans tous les cas le script sys_refresh_tetalab_scripts.sh est exécuté une fois par jour à 00H20 (cf. les cronjobs)
Sur chacune des machines qui compose l'infrastructure du Tetalab les utilisateurs disposent de variables d'environnement spécifiques:
| Variable | Valeur | Utilité |
|---|---|---|
| TETALABPATH | /usr/local/bin/tetalab | Chemin vers les exécutables spécifiques au Tetalab |
| TETALABLIB | /usr/local/lib/tetalab | Chemin vers les bibliothèques spécifiques au Tetalab |
| TETALABETC | /usr/local/etc/tetalab | Chemin vers les fichiers de configuration des exécutables spécifiques au Tetalab |
| TETALABSHARE | /usr/local/share/tetalab | Chemin vers les documents/modèles/docs spécifiques au Tetalab |
| TETALABTMP | /tmp/tetalab | Répertoire temporaire spécifique au Tetalab pour y déposer des cacas bien mous |
La variable ${TETALABPATH} est ajoutée au PATH de l'utilisateur.
Ces répertoires ne contiennent PAS les exécutables, fichiers de configuration, etc, des paquets installés sur l'infrastructure.
En revanche ils contiennent les exécutables, leurs fichiers de configuration, les bibliothèques, etc, des développements spécifiques à l'infrastructure du Tetalab (Typiquement, les programmes de gestion et maintenance développés par l'équipe des BOFH).
Ces variables ne sont PAS utilisées par le socle Bash qui utilise ces propres variables
Par ailleurs, les scripts Bash s'appuyant sur le socle Bash sont installés dans le répertoire ${NC_EXPL_BIN} de ce socle Bash.
Ce socle Bash défini également un ensemble de variables d'environnement. Pour plus d'information voir la documentation associée au socle Bash.
Les BOFH (Bastard Operator From Hell) sont les administrateurs système et réseaux du Tetalab.
À ce jour ils sont essentiellement au nombre de un:
- Doug (Redatomiste, slackiste pervers et sud-pacifiste bêlant au BFG9000 ultra-sensible)
La vie n'étant pas assez difficile pour lui, Schmod777 (Topologue rétro-claviste, blowfishiste convaincu) a décidé de finir sa période d'apprentissage avec un boulet supplémentaire au pied: FreeBSD.
Fatalerrors et Mika sont également des BOFH mais ils préfèrent jouer dans la cour de Mix'art-Myrys et ce n'est PAS une raison pour leur jetter des cailloux.
Les BOFH font tous partie du groupe wheel de chacune des VM de l'infrastructure du Tetalab.
De ce fait, ils font tous partie des sudoers et via sudo disposent des mêmes droits que l'utilisateur root.
Leurs pouvoirs sur l'infrastructure informatique du Tetalab sont donc très importants, leurs responsabilités également.
Devenir BOFH n'est pas chose facile. Il vous sera demandé:
- Une forte implication au sein du Tetalab
- Une très bonne connaissance des systèmes *nix
- Des connaissances réseaux et/ou en sécurité informatique sont un plus non négligeable
Si vous pensez être à la hauteur des responsabilités qu'impliquent d'être un BOFH, n'hésitez pas à demander un accès à Doug via IRC ou faire une demande sur le gestionnaire de tickets.
Les BOFH disposent d'une liste de diffusion secrète à laquelle vous n'avez PAS accès.
Cependant, dans leur grande mansuétude, les BOFH ont mis en place un outil fabuleux à destination des lusers afin que
leur soient remontés les éventuels problèmes constatés sur l'infrastructure du Tetalab.
Cet outil est joignable à l'URL suivante: https://bofh.tetalab.org.
Chacun des tickets créés dans cet outil générera un mail à destination de la liste de diffusion secrète des BOFH, vous assurant ainsi
qu'au moins un BOFH a bien lu votre demande.
L'incident de mai 2019 ayant eu raison du système de gestion des incidents (!), vous pouvez dorénavant contacter les BOFH directement sur leur ML à l'adresse suivante: bofh@tetalab.org.
L'utilisateur asr (administrateur système et réseau) est un utilisateur qui permet d'exécuter des tâches de maintenances sur les différentes VM.
C'est un BOFH virtuel et comme les autres BOFH, il fait partie du groupe wheel et dispose de droits étendus à travers de la commande sudo.
Vous ne devez PAS (MUST NOT) vous connecter avec cet utilisateur. Par contre vous pouvez utilisez sudo -u asr pour exécuter certains scripts qui lui sont réservés.
Cet utilisateur dispose d'une paire de clefs pour se connecter à l'ensemble des VM et sert à exécuter les tâches automatisées (cron jobs, ansible playbooks, etc).
La clef privée de l'utilisateur asr se trouve dans son homedir sur sousetsuken.local.tetalab.org.
Cette clef NE DOIT EN AUCUN CAS être déplacée ou divulgée. Si cette clef s'avérait être corrompue, déplacée ou divulguée, renouvellez la paire de clef dans les plus brefs délais et déployez la clef publique sur l'ensemble des VM ainsi que le Nuc.
L'ensemble des tâches de maintenance et gestion à exécuter sur les VM sont exécutées par l'utilisateur asr via SSH à partir de sousetsuken.local.tetalab.org.
Ces tâches de maintenance sont gérées via cronjob, sauf problème particulier vous n'avez pas à interagir avec ces tâches.
Une liste automagiquement maintenue à jour des cron jobs est disponible ici
Les sauvegardes sont gérées par le script sys_backup_all_vm.sh qui se charge de sauvegarder l'ensemble des fichiers de configuration et des données de l'infrastructure sur l'infrastructure de fatalerrors (qu'il en soit remercié).
Ce script est exécuté quotidiennement par un cron job de l'utilisateur asr sur sousetsuken.
La procédure de restauration des sauvegardes se trouve dans le fichier README.RESTAURATION_VM incluse dans le dépôt Git archilab.wiki.
git clone ssh://git@tetalab.org:2213/tetalab/archilab.wiki.git
Vous devez faire partie des BOFH pour accéder à de dépôt.
Dehydrated est une implémentation de ACME (Automated Certificate Management Environment), un client Let's encrypt qui permet de récupérer des certificats SSL signés par une autorité reconnue.
Dehydrated est installé sur Bobby et est périodiquement exécuté par un cronjob.
Les certificats SSL sont tous installés et distribués par le ReverseProxy qui se charge ensuite de diriger le trafic vers la VM correspondante à la requète.
Aucun certificat n'est installé sur les VM qui hébergent les sites.
La liste des sites pour lesquels réclamer un certificat est automatiquement mise à jour par le script create_http_site.sh (voir Les scripts spécifiques à l'infrastructure du Tetalab)
- Fichier de configuration: /etc/dehydrated/config
- Liste des domaines pour lesquels réclamer un certificat: /etc/dehydrated/domains.txt
- Répertoire de stockage des certificats: /etc/dehydrated/certs
- Répertoire des challenges: /var/www/html/.well-known/acme-challenge
- Commande pour renouveler tous les certificats: dehydrated -c -x (Cette commande n'a pas besoin d'être exécutée manuellement. Voir les cronjobs)
Les scripts Bash spécifiques à l'infrastructure du Tetalab reposent tous et doivent tous reposer sur le socle Bash disponible ici:
git clone ssh://git@tetalab.org:2213/tetalab/socle_bash
Les scripts pouvant contenir des informations sensibles, ils disposent d'un dépôt git spécifique archilab_scripts:
git clone ssh://git@tetalab.org:2213/tetalab/archilab_scripts
Il vous faudra faire partie des BOFH pour accéder à ce dernier dépôt.
Tous les scripts Bash disposent d'une option -h qui affiche l'aide complète qui:
- Explique le fonctionnement du script
- Donne un exemple d'utilisation
- Répertorie l'ensemble des options proposées par le script
Lire le code source des scripts est également riche d'enseignements.
Quelle que soit la VM, ils doivent tous être rangés dans le répertoire /opt/tetalab/bin
Les scripts écrits dans d'autres langages doivent être déposés dans le répertoire /usr/local/bin/tetalab (voir Les variables d'environnements spécifiques à l'infra du Tetalab
Liste des scripts de gestion et de maintenance de l'infrastructure du Tetalab
La liste des scripts dispose sur ce référentiel d'une section spécifique automagiquement mise à jour.
Seuls les BOFH peuvent se connecter via SSH sur l'une des VM de l'infrastructure du Tetalab.
- VM hôte: Toutes
- Script de démarrage: /etc/rc.d/rc.sshd
- Fichiers de configuration: /etc/ssh/sshd_config
- Détails: Les VM du Tetalab sont toutes accessibles via SSH à partir du nom de domaine tetalab.org
- Ports d'écoute:
- sousetsuken.local.tetalab.org: tetalab.org:2242
- bobby.local.tetalab.org: tetalab.org:2226
- jimmy.local.tetalab.org: tetalab.org:2213
- billy.local.tetalab.org: tetalab.org:2237
- marian.local.tetalab.org: tetalab.org:2269
- sonny.local.tetalab.org: tetalab.org:2223
- Ports d'écoute:
Ex. Pour se connecter en SSH à sousetsuken
$ ssh -l <user> tetalab.org -p 2242
- VM hôte: sousetsuken.local.tetalab.org (192.168.122.42)
- Script de démarrage: /usr/local/bin/slackmirror.sh
- Fichiers de configuration: N/A (Voir variables déclarées dans le script)
- Détails:
- Le script /usr/local/bin/slackmirror.sh est lancé tous les jours par un cronjob.
- Toutes les VM de l'infrastructure sont configurées pour récupérer leur paquet Slackware à partir de l'URL suivante accessible uniquement depuis le réseau local: http://sousetsuken.local.tetalab.org:8080/slackware.
- VM hôte: jimmy.local.tetalab.org (192.168.122.13)
- Script de démarrage: /etc/rc.d/rc.grafana
- Fichiers de configuration: /opt/grafana/defaults.ini
- Port d'écoute: TCP/3000
- URL: https://monitoring.tetalab.org
- User: contact@tetalab.org
- Pass: wemakeporn
- Détails:
- L'instance Grafana du Tetalab n'a pas survécu à l'incident de mai 2019.
Grafana est l'application de surveillance système de l'infrastructure du Tetalab.Cette application affiche les données qui sont enregistrées dans la base de données InfluxDB installées sur sonny.local.tetalab.orgLa base de données InfluxDB est alimentée par les démons collectd installés sur chacune des VM.
- VM hôte: Toutes
- Script de démarrage: /etc/rc.d/rc.collectd
- Fichiers de configuration: /etc/collectd.conf
- Détails:
- VM hôte: bobby.local.tetalab.org (192.168.122.26)
- Script de démarrage: /etc/rc.d/rc.bind
- Fichiers de configuration: /etc/named.conf
- Fichiers de zones: /var/named/zones/*.db
- Détails:
- Les zones tetalab.org et thsf.net sont accessibles à tous, y compris et surtout à l'extérieur.
- La zone local.tetalab.org est accessible uniquement au reseau local (192.168.122.0/24)
- VM hôte: bobby.local.tetalab.org (192.168.122.26)
- Script de démarrage: /etc/rc.d/rc.ntpd
- Fichiers de configuration: /etc/ntp.conf
- Détails:
- Le serveur NTP local se synchronise sur une selection de serveurs universitaires ou institutionnels français.
- Toutes les VM de l'infrastructure viennent s'y synchroniser.
- Sur chaque VM les mêmes scripts de démarrage et fichiers de configuration existent, seules les configurations changent.
- VM hôte: billy.local.tetalab.org (192.168.122.37)
- Script de démarrage: /etc/rc.d/rc.postfix
- Fichier de configuration:
- /etc/postfix/main.cf
- /etc/postfix/master.cf
- Particularité:
- Les alias autres que ceux de mailman sont gérés par postfixadmin
- SpamAssassin est branché sur Postfix via le script /usr/local/bin/tetalab/spamchk (voir /etc/postfix/master.cf)
- VM hôte: billy.local.tetalab.org (192.168.122.37)
- Script de démarrage: /etc/rc.d/rc.mailman
- Répertoire d'installation: /opt/mailman/
- Utilisateur applicatif: mailman
- Fichier de configuration: /opt/mailman/Mailman/mm_cfg.py
- Emplacement des listes: /opt/mailman/var/mailman/lists
- Emplacement des aliases: /opt/mailman/var/mailman/data/
- Configuration Apache: /etc/httpd/sites_available/lists.tetalab.org
GitLab étant une application misérable, à la stabilité douteuse, écrite avec les pieds et documentée avec des mouffles, l'instance du Tetalab a avantageusement été remplacée par une instance Gitea après avoir vécu 3 années de bonheur avec Gitolite.
- VM hôte: jimmy.local.tetalab.org (192.168.122.13)
- Documentation: Doc officielle
- Canal IRC: Le canal IRC officiel de Gitolite est freenode.net#gitea.
- Application:
- Serveur:Port: Jimmy:3000
- Type d'installation:
- Répertoire d'installation des dépôts:
- /var/lib/gitea/data
- Utilisateur applicatif: git
- Configuration:
- La configuration de Gitea se fait à partir du fichier de configuration /etc/gitea/gitea.conf situé sur jimmy.
- Pour ajouter un utilisateur, connectez-vous avec le compte administrateur (vous devez faire partie des BOFH) sur le serveur Git.
- La gestion des clefs SSH des utilisateurs se fait par les utilisateurs eux mêmes.
- Base de données:
- Serveur:Port: Sonny:5432
- Type: Postgresql
- Nom de la base: gitea
- Script de démarrage:
- /etc/rc.d/rc.gitea
- Fichiers de log:
- /var/log/gitea/*.log
- Application:
- Serveur:Port: Jimmy:9001
- Type d'installation:
- Utilisateur applicatif: etherpad
- Base de données:
- Serveur:Port: Sonny:5432
- Type: Postgresql
- Nom de la base: etherpad
- Script de démarrage:
- /etc/rc.d/rc.etherpad-lite
- Fichier de configuration:
- /etc/etherpad-lite/settings.json
- Fichiers de log:
- /var/log/etherpad/*.log
- Particularité:
- etherpad-lite utilise iojs et non pas NodeJS.
- Le service est accessible par l'extérieur à partir de l'URL https://pad.tetalab.org
- Le service postegresql installé sur sonny doit être démarré avant de démarrer etherpad-lite
- La majeure partie des modules NodeJS nécessaires sont installés dans le ${HOME} de l'utilisateur applicatif (/home/etherpad/node_modules/)
- Le script de démarrage doit être lancé par l'utilisateur applicatif "etherpad"
- L'échange de mot de passe pour l'accès de la base données doit se faire en clair !
- Application:
- Serveur:Port: Jimmy:8000
- Type d'installation:
- Utilisateur applicatif: root
- Base de données:
- Serveur:Port: jimmy:6379
- Type: Redis
- Nom de la base: N/A
- Script de démarrage:
- /etc/rc.d/rc.ethercalc
- Fichier de configuration:
- ???
- Fichiers de log:
- /var/log/ethercalc.log
- Particularité:
- ethercalc utilise NodeJS.
- Le service est accessible par l'extérieur à partir de l'URL https://calc.tetalab.org
- Le service Redis installé sur jimmy doit être démarré avant de démarrer ethercalc
- VM hôte: bobby.local.tetalab.org (192.168.122.26)
- Script de démarrage: /etc/rc.d/rc.httpd
- Fichiers de configuration: /etc/httpd.conf et pour chaque site /etc/httpd/site-availabe/<FQDN>.conf
- Détails:
- La configuration de base du ReverseProxy se fait dans /etc/httpd.conf.
- Vous ne devez PAS (MUST NOT) modifer ce fichier.
- Pour faire prendre en charge un nouveau site par le ReverseProxy, vous devez (MUST) utilisez le script sys_create_vhost.sh prévu à cet effet qui ajoutera le VirtualHost et créera la redirection adapatée.
- Le ReverseProxy distribue les certificats SSL (voir Dehydrated)
Modèle de fichier de configuration d'un site sur le ReverseProxy utilisé par le script sys_create_vhost.sh:
<VirtualHost 192.168.122.26:80>
# ReverseProxy with https redirect template
#
# Written by Doug Le Tough
#
# Usage:
# sed -s 's/SITE_NAME/example.com/g' site_template.conf > example.org.conf
# sed -i 's/SITE_HOST/hostname.local.tetalab.org/g' example.org.conf
#
Define FQDN SITE_NAME
Define HOST SITE_HOST
Define HOST_PORT SITE_PORT
ServerName ${FQDN}
### All HTTP requests are converted to HTTPS requests
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</IfModule>
ErrorLog "/var/log/httpd/${FQDN}_error.log"
CustomLog "/var/log/httpd/${FQDN}_access.log" Combined
</VirtualHost>
<VirtualHost 192.168.122.26:443>
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
ServerName ${FQDN}
ProxyPreserveHost On
SSLEngine on
SSLCertificateFile /etc/dehydrated/certs/${FQDN}/cert.pem
SSLCertificateKeyFile /etc/dehydrated/certs/${FQDN}/privkey.pem
SSLCertificateChainFile /etc/dehydrated/certs/${FQDN}/fullchain.pem
RequestHeader set X_FORWARDED_PROTO 'https'
ProxyPass / http://${HOST}:${HOST_PORT}/
ProxyPassReverse / http://${HOST}:${HOST_PORT}/
ErrorLog "/var/log/httpd/${FQDN}_error.log"
CustomLog "/var/log/httpd/${FQDN}_access.log" Combined
</VirtualHost>
Chacune des VM suivantes dispose d'un serveur HTTP (Apache) susceptible d'héberger un ou plusieurs sites.
La configuration de ces sites se fait UNIQUEMENT à partir de la VM sousetsuken.local.tetalab.org et du script sys_create_vhost.sh qui créera la configuration du ReverseProxy adaptée et la fichier de configuration du site sur la VM hôte concernée.
VM concernées:
- jimmy.local.tetalab.org (192.168.122.13)
- billy.local.tetalab.org (192.168.122.37)
- marian.local.tetalab.org (192.168.122.69)
Configuration de base
- VM hôte: jimmy.local.tetalab.org, billy.local.tetalab.org, marian.local.tetalab.org
- Script de démarrage: /etc/rc.d/rc.httpd
- Fichier de configuration:
- /etc/httpd.conf
- Pour chaque site hébergé par la VM: /etc/httpd/site-availabe/<FQDN>.conf
Modèle de fichier de configuration d'un VirtualHost sur l'hôte destinataire utilisé par le script sys_create_vhost.sh:
<VirtualHost SITE_IP:SITE_PORT>
ServerName SITE_NAME
ServerAdmin bofh@tetalab.org
DocumentRoot /var/www/SITE_NAME
RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy 192.168.122.0/24
<Directory /var/www/SITE_NAME>
AllowOverride All
Require all granted
</Directory>
ErrorLog /var/log/httpd/SITE_NAME.error.log
CustomLog /var/log/httpd/SITE_NAME.access.log combined
</VirtualHost>
Les certificats sont gérés via dehydrated qui est une implémentation ACME (Automated Certificate Management Environment) bien moins bloatée que certbot.
Dehydrated est lancé tous les 23 du mois par un cronjob.
Les certificats SSL sont tous installés et distribués par le ReverseProxy qui se charge ensuite de diriger le trafic vers la VM correspondante à la requète.
Aucun certificat n'est installé sur les VM qui hébergent les sites.
Les services HTTP de l'infrastructure sont vérifiés par le script ctl_all_nrpe.sh installés sur sousetsuken
Les statistiques d'accès aux différents sites sont mises à disposition par une instance AWStats installée sur bobby.
Les URL d'accès sont dépendantes du nom complet (FQDN) du site.
Pour des raisons techniques certains sites ne disposent pas de statistiques d'accès. C'est normal !
Le schema de l'URL d'accès pour un site est le suivant:
https://stats.tetalab.org/awstats/awstats.pl?config=<FQDN>
Exemples
https://stats.tetalab.org/awstats/awstats.pl?config=www.tetalab.org https://stats.tetalab.org/awstats/awstats.pl?config=www.thsf.net https://stats.tetalab.org/awstats/awstats.pl?config=git.tetalab.org
Configuration:
- VM hôte: bobby.local.tetalab.org
- Répertoire des fichiers de configuration: /etc/awstats
- Répertoire d'installation: /var/www/stats.tetalab.org
- Configuration Apache:
- /etc/httpd/sites-available/awstats.tetalab.org.conf
- /etc/httpd/sites-available/stats.tetalab.org.conf (configuration reverse proxy)
Particularités:
- Un cronjob de l'utilisateur root met quotidiennement à jour les statistiques de chacun des sites
- Le site https://stats.tetalab.org est directement installé sur le reverse proxy (bobby)
- VM hôte: sonny.local.tetalab.org (192.168.122.23)
- Script de démarrage: /etc/rc.d/rc.postegresql
- Fichier de configuration des accès aux la bases de données:
- /var/lib/pgsql/9.6/data/pg_hba.conf
- Port d'écoute: 5432/TCP
- Bases de données:
- postfix
- flyspray
- etherpad
- galette
- Particularités:
- SBo build option: PG_EXTENSIONS=ALL
- VM hôte: sonny.local.tetalab.org (192.168.122.23)
- Script de démarrage: /etc/rc.d/rc.mysqld
- Fichier de configuration:
- Port d'écoute: 3306/TCP
- Base de données:
- N/A
- Particularités:
- Ce serveur de base de données n'est plus utilisé par aucun site/application
- Le service MySQL est désactivé
- VM hôte: jimmy.local.tetalab.org (192.168.122.13)
- Script de démarrage: /etc/rc.d/rc.redis
- Fichier de configuration: /etc/redis/redis.conf
- Port d'écoute: 6379/TCP
- Particularités:
- Ce serveur de base de données est uilisé exclusivement par Ethercalc
- Pour des raisons d'efficacité et de performances Redis est installé sur le serveur applicatif jimmy.local.tetalab.org
- Redis est un serveur NoSQL
- VM hôte: sonny.local.tetalab.org (192.168.122.23)
- Script de démarrage: /etc/rc.d/rc.mongodb
- Fichier de configuration: /etc/mongodb.conf
- Port d'écoute: 27017/TCP
- Particularités:
- Ce serveur de base de données est actuellement uilisé par aucun service
- MongoDB ets un serveur NoSQL
L'ensemble des procédures qui suivent sont à la destination exclusive des BOFH.
Sauf mention contraire l'ensemble des commandes à exécuter lors de l'application de ces procédures doit être éxécutées à partir de votre compte sur la VM sousetsuken.tetalab.org.
Documentation en cours de rédaction
À l'heure actuelle le plus simple est de faire une demande sur le gestionnaire de tickets des BOFH.
- Se connecter sur l'interface d'administration des listes à l'adresse suivante: https://lists.tetalab.org/mailman/admin/
- Cliquer sur 'create a new mailing list'
- Remplir les champs
- Attention le nom de la liste n'est PAS modifiable.
- Le champs 'Initial list owner address' doit contenir votre adresse mail
- Décocher 'English (USA)' et cocher 'French' si vous souhaitez que la liste soit en Français
- Dans le champs 'List creator's (authentication) password:', saisissez le mot de passe d'administrateur de Mailman
- Cliquer sur 'Create list'
- Mettre la base de données des aliases de Mailman à jour:
- Se connecter sur billy.local.tetalab.org
- Ajouter les éléments suivants au fichier /opt/mailman/var/mailman/data/aliases (Remplacer <LISTE>
par le nom de votre nouvelle liste
<LISTE>: "|/opt/mailman/mail/mailman post <LISTE>" <LISTE>-admin: "|/opt/mailman/mail/mailman admin <LISTE>" <LISTE>-bounces: "|/opt/mailman/mail/mailman bounces <LISTE>" <LISTE>-confirm: "|/opt/mailman/mail/mailman confirm <LISTE>" <LISTE>-join: "|/opt/mailman/mail/mailman join <LISTE>" <LISTE>-leave: "|/opt/mailman/mail/mailman leave <LISTE>" <LISTE>-owner: "|/opt/mailman/mail/mailman owner <LISTE>" <LISTE>-request: "|/opt/mailman/mail/mailman request <LISTE>" <LISTE>-subscribe: "|/opt/mailman/mail/mailman subscribe <LISTE>" <LISTE>-unsubscribe: "|/opt/mailman/mail/mailman unsubscribe <LISTE>" - Éxécuter la commande suivante:
sudo /usr/sbin/postalias /opt/mailman/var/mailman/data/aliases
L'ajout d'un site Internet sur l'infrastructure est automatisée en grande partie.
Vous devez impérativement utiliser ces automatismes pour garantir la cohérence de l'infrastructure. Si vous ne respectez pas la procédure décrite ci dessous, ce référentiel contiendra des informations partielles ou erronées et surtout vous prenez le risque qu'il ne soit plus mis à jour de manière automatique.
La procédure si dessous vous permettra de mettre en place le site Internet fictif https://example.tetalab.org.
Cette procédure vous donnera l'occasion de:
- Ajouter un enregistrement DNS à la zone .tetalab.org
- Créer et mettre en place la configuration du reverse-proxy
- Créer et mettre en place la configuration du backend
- Générer les certificats SSL
- Redémarrer le reverse-proxy
- Redémarrer le backend
La première étape consiste donc à collecter les informations nécessaires à l'ensemble des opérations. Vous devez apporter les réponses aux 3 questions suivantes:
- Quel nom de domaine pour ce site ? Réponse: example.tetalab.org
- Quelle VM hébergera ce site ? Réponse: marian.local.tetalab.org (à moins que votre site soit une application gourmande en ressources, utilisez systématiquement marian.local.tetalab.org)
- Par quel port le reverse-proxy communiquera t-il avec le backend: 80 (Sauf besoin spécifique, utilisez systématiquement le port 80)
Le nom de domaine va nous permettre de déclarer l'enregistrement DNS:
- Connectez-vous sur bobby et avec modifiez le fichier de zone avec la commande suivante:
@bobby:~$ sudo vim /var/named/zones/db.tetalab.org
201707260 ; serial
201707261 ; serial
example.tetalab.org. IN CNAME sousetsuken.tetalab.org.
@bobby:~$ sudo /etc/rc.d/rc.bind reload
Attention à bien faire pointer votre nom de domaine vers le reverse-proxy bobby.tetalab.org
Une fois le nom de domaine enregistré et le serveur Bind redémarré, connectez vous sur sousetsuken et lancez le script de création des fichiers de configuration avec la commande suivante:
@sousetsuken:~$ sudo -u asr sys_create_vhost.sh \
-domain example.tetalab.org \
-backend_host marian.local.tetalab.org \
-backend_port 80
Si vous avez exécuté ce script avec de mauvais paramètres, vous pouvez l'exécuter une seconde fois. Les fchiers de configuration seront écrasés par leur nouvelle version.
Ce script automatise les opérations suivantes:
- Création du fichier de configuration de reverse-proxy
- Création du fichier de configuration du backend
- Création du répertoire d'accueil du backend (document_root)
- Enregistrement du nom de domaine dans la liste des domaines gérés par Dehydrated
Le site n'est pas encore actif. Pour le rendre actif il faut encore créer plusieurs lien symbolique:
Pour activer la configuration sur le reverse-proxy, lancez la comande suivante
@sousetsuken:~$ sudo -u asr ssh bobby.local.tetalab.org \
sudo ln -s /etc/httpd/sites-available/example.tetalab.org \
/etc/httpd/sites-enabled/
Pour activer la configuration sur le backend lancez la comande suivante
@sousetsuken:~$ sudo -u asr ssh marian.local.tetalab.org \
sudo ln -s /etc/httpd/sites-available/example.tetalab.org \
/etc/httpd/sites-enabled/
À ce stade il ne vous reste plus qu'à déposer vos fichiers dans le répertoire /var/www/example.tetalab.org sur marian.local.tetalab.org avant de rédémarrer le reverse-proxy et le backend en exécutant les commandes suivantes:
- Redémarrage du backend
@sousetsuken:~$ sudo -u asr ssh marian.local.tetalab.org \ sudo /etc/rc.d/rc.httpd restart
Maintenant que tout est prêt pour recevoir les requètes des clients, vous pouvez lancer la génération des certifcats SSL avec la commande suivante:
@sousetsuken:~$ sudo -u asr \
ssh bobby.local.tetalab.org sudo -u dehydrated -c
Cette commande lira le fichier qui contient la liste des domaines gérés par Dehydrated et renouvellera le certificat pour chacun d'entre eux s'il a moins de 30 jours. Dans votre cas le certificat n'existant pas, il sera simplement créé.
- Finalement, redémarrage du reverse-proxy
@sousetsuken:~$ sudo -u asr ssh bobby.local.tetalab.org \ sudo /etc/rc.d/rc.httpd restart
Si tout c'est bien passé, votre site devrait être maintenant joignable à partir de l'URL suivante:
https://example.tetalab.org
Si ce n'est pas le cas, relisez intégralement ce tutoriel et recommencez les étapes que vous avez survolées un peu trop rapidement.
Si vous n'arrivez vraiment pas à vous en sortir ou si vous pensez que cette procédure est à revoir, ouvrez un ticket sur le gestionnaire de tickets des BOFH du Tetalab.
Les dépôts Git sont gérés par Gitolite qui permet la gestion des dépôts à partir d'un... dépôt Git !
Ne jouez pas à l'apprenti sorcier au risque de rendre publics des dépôts qui ne sont pas les vôtres et qui peuvent être sensibles ou critiques.
Si vous ne vous sentez pas en mesure de suivre cette procédure faites vous assister par quelqu'un qui dispose des connaissances nécessaires et qui peut vous apprendre ou faites une demande de création de dépôt sur le gestionnaire de tickets du Tetalab.
Si vous êtes BOFH, vous avez donc les droits suffisants pour cloner sur votre machine personnelle le dépôt d'administration de Gitolite avec la commande suivante
git clone ssh://git@tetalab.org:2213/gitolite-admin.git
Une fois le dépot cloné sur votre machine personnelle, commencez par créer l'utilisateur (toto dans cet exemple) en ajoutant sa clef publique dans le répertoire keydir.
Cette clef doit être au format [UTILISATEUR].pub, dans notre exemple cette clef doit donc avoir pour nom toto.pub
gitolite-admin$ cp clef_publique_nouvel_utilisateur.pub ./keydir/toto.pub
Une fois que vous avez ajouté la clef de votre utilisateur poussez vos modifications afin que l'utilisateur soit créé. L'opération de création de l'utilisateur doit être séparée de et antérieure à l'opération de création du dépôt.
gitolite-admin$ git pull origin master
gitolite-admin$ git add .
gitolite-admin$ git commit -m "Ajout de l'utilisateur toto"
gitolite-admin$ git push origin master
La création et la configuration du dépôt se fait à partir du fichier conf/gitolite.conf.
Pour ajouter un dépôt il suffit créer une liste de dépôts pour votre utilisateur toto (si cet utlisateur dispose déjà d'autres dépôts, ajouter simplement ce nouveau dépot à sa liste)
# Repos toto
@repos_toto = projet_toto
Ensuite ajoutez simplement ses autorisations d'écriture à la liste des ACL qui se trouvent plus bas dans le fichier.
repo @repos_toto
RW+ = toto
Si vous voulez rendre ce dépôt accessible en écriture aux membres du Tetalab, ajoutez les autorisations suivantes
repo @repos_toto
RW+ = toto
RW = tetalab_core_members
RW = tetalab_members
Pour que ce dépôt soit créé, poussez vos modifications
gitolite-admin$ git pull origin master
gitolite-admin$ git add .
gitolite-admin$ git commit -m "Ajout du depot projet_toto"
gitolite-admin$ git push origin master
Si tout c'est déroulé correctement, le dépôt devrait apparaître dans la liste des dépôts accessibles sur GitWeb.
Si vous ne voulez pas que ce dépôt apparaisse dans la liste des dépôts accessibles sur GitWeb, connectez vous sur jimmy.tetalab.org et modifiez les permissions sur le dossier qui contient le dépôt
@jimmy: ~$ sudo -u git chmod g-rx -R /var/lib/gitolite/repositories/projet_toto.git
À ce stade le dépôt est créé selon vos désirs et il ne reste plus qu'à gérer le coté client sur la machine personnelle de Toto
Dans le répertoire qui servira de copie locale du dépôt sur la machine de Toto, initialisez le dépot Git
~$ git init
~$ git remote add origin ssh://git@tetalab.org:2213/projet_toto
Ne reste plus à Toto qu'à ajouter des fichiers sur sa copie locale de son dépôt et de les pousser
~$ git add .
~$ git commit -m "Initial commit"
~$ git push origin master
Il est parfois utile de copier des fichiers entre deux VM. Pour faciliter la vie des BOFH, un script permettant de réaliser cette facilement cette opération est mis à disposition: exp_transfert_dir.sh.
Ce script doit être exécuté par l'utilisateur asr. Il nécessite également plusieurs paramètres pour pouvoir fonctionner correctement:
- -src_host [VM source]
- -dst_host [VM de destination]
- -src_dir [Répertoire source]
- -dst_dir [Répertoire de destination]
- -create [true|false] (false par défaut)
- -dst_user [utilisateur auquel appartiendra le répertoire de destination]
- -dst_mode [Permissions du répertoire de destination]
Comme tous les scripts basés sur le socle Bash, l'option -h affichera l'aide.
Exemple d'utilisation:
~$ sudo -u asr exp_transfert_dir.sh \
-src_host marian.local.tetalab.org \
-dst_host jimmy.local.tetalab.org \
-src_dir /etc/httpd \
-dst_dir /home/doug/httpd \
-create true \
-dst_user doug \
-dst_group wheel \
-dst_mode 644
Cette commande transferera le contenu du répertoire /etc/httpd de la VM marian.local.tetalab.org dans le répertoire /home/doug de la VM jimmy.local.tetalab.org qui sera créé si nécessaire et auquel les droits seront positionnés à doug:wheel et les permissions positionnées à 644.
Je répète: Les droits et permissions seront appliqués récursivement sur le répertoire /home/doug de la VM jimmy.local.tetalab.org
Attention: Ce script peut modifier les droits et permissions du répertoire de destination.
Dans cet exemple le répertoire /home/doug/httpd verra ses droits et/ou permissions changés de manière récursive avec toutes les conséquences facheuses que cela peut avoir.
Faites particulièrement attention à l'utilisation de ce script sur des répertoires système !