This commit is contained in:
parent
069f52efc3
commit
6e89379cd2
3 changed files with 88 additions and 7 deletions
|
|
@ -9,11 +9,12 @@ Pour mon infrastructure de backups, j'utilise depuis plusieurs années [BorgBack
|
|||
Les besoins sont simple : les utilisateurs ayant un compte sur mon service de SSO devraient pouvoir se connecter sur un service, créer une clé dédiée à une application, puis utiliser cette clé pour backup une machine, serveur ou PC, et envoyer les données sur mon serveur central. Les backups créés devraient être chiffrés, dédupliqués, et avec une gestion des droits pour ne pas permettre à un utilisateur d'écraser ou de modifier les backups des autres (tout étant chiffré, l'accès en lecture est moins critique). Si possible, le service devrait pouvoir définir des quotas par utilisateur ; malheureusement, la solution que j'ai trouvée ne le permet pas.
|
||||
|
||||
> Les différentes étapes de l'article sont :
|
||||
> - [Installer restic et écrire un script pour le lancer](#faire-ses-backups-simplement)
|
||||
> - [Installer MinIO, et tester que restic fonctionne avec MinIO](#stocker-ses-backups-quelque-part)
|
||||
> - [Configurer restic pour fonctionner avec MinIO en SSO](#et-ma-sso-dans-tout-ça-)
|
||||
> - [Installer restic et écrire un script pour le lancer](#restic)
|
||||
> - [Installer MinIO, et tester que restic fonctionne avec MinIO](#minio)
|
||||
> - [Configurer restic pour fonctionner avec MinIO en SSO](#sso)
|
||||
|
||||
## Faire ses backups simplement
|
||||
{: #restic}
|
||||
|
||||
[Restic](https://restic.net/) est une excellente alternative à BorgBackup, implémentée en Go. Il permet l'utilisation de plusieurs types de backend de stockage, dont du SFTP, une API REST, ou divers protocols cloud comme AWS S3 et l'équivalent chez la concurrence, au prix d'une compression moindre et d'un plus gros usage en ressources, notamment en RAM, que BorgBackup.
|
||||
|
||||
|
|
@ -70,6 +71,7 @@ $ chmod +x backup.sh
|
|||
Le fichier `.env`, qui contient les informations de connexion au backend de stockage, sera créé par la suite. Il est justement temps de choisir ce backend.
|
||||
|
||||
## Stocker ses backups quelque part
|
||||
{: #minio}
|
||||
|
||||
Parmi les différents backends possible, j'ai fait le choix d'utiliser [MinIO](https://min.io/). Ce n'est pas un outil que j'aime beaucoup utiliser, mais sa compatibilité à l'API S3 le rend très pratique, et je voulais construire une solution entièrement auto-hébergée.
|
||||
|
||||
|
|
@ -128,6 +130,7 @@ Une fois que tout fonctionne, on peut créer un cron pour lancer automatiquement
|
|||
> Techniquement, un Timer Systemd est mieux et a plus de fonctionnalités, mais la force de l'habitude est forte.
|
||||
|
||||
## Et ma SSO dans tout ça ?
|
||||
{: #sso}
|
||||
|
||||
Une fois un service de SSO configuré sur MinIO (laissé à titre d'exercice au lecteur),
|
||||
|
||||
|
|
|
|||
|
|
@ -9,12 +9,13 @@ Tout le monde aujourd'hui a, dans sa famille, une conversation Whatsapp/Telegram
|
|||
XMPP est un protocol décentralisé d'échange de données en temps réel. Plus simplement, c'est un très bon protocol pour construire des systèmes fédérés de discussion instantannée, ce qui est exactement ce que l'on va faire. Le protocol est défini via quelques RFC, et définit également des extensions à travers des [XEP](https://xmpp.org/extensions/). Plusieurs de ces XEP sont aujourd'hui très standard et sont installées et activées par défaut (comme la [XEP-0012](https://xmpp.org/extensions/xep-0012.html)). Enfin, XMPP propose aujourd'hui du chiffrement bout-en-bout mature et automatique ([XEP-0384](https://xmpp.org/extensions/xep-0384.html)).
|
||||
|
||||
> Les différentes étapes de cet article sont :
|
||||
> - [Une description de l'environnement dans lequel le serveur XMPP va être déployé](#environnement)
|
||||
> - [L'installation et la configuration du serveur XMPP en lui-même](#installation-et-configuration-initiale)
|
||||
> - [La configuration de quelques fonctionnalités supplémentaires (partage de fichier et rooms)](#file-sharing-et-muc)
|
||||
> - [La configuration finale du serveur](#fichier-de-configuration-final)
|
||||
> - [Une description de l'environnement dans lequel le serveur XMPP va être déployé](#env)
|
||||
> - [L'installation et la configuration du serveur XMPP en lui-même](#install)
|
||||
> - [La configuration de quelques fonctionnalités supplémentaires (partage de fichier et rooms)](#file)
|
||||
> - [La configuration finale du serveur](#config)
|
||||
|
||||
## Environnement
|
||||
{: #env}
|
||||
|
||||
Pour monter un serveur XMPP, il est nécessaire d'avoir au moins un nom de domaine public, et si possible plusieurs sous-domaines dédiés au projet. Il est également nécessaire d'avoir une ip publique, avec a minima les ports tcp 5222 et 5269 accessibles.
|
||||
|
||||
|
|
@ -25,6 +26,7 @@ Pour monter un serveur XMPP, il est nécessaire d'avoir au moins un nom de domai
|
|||
Pour installer Prosody, j'utilise un serveur Debian 11, avec 2 vCPU, 2Go de ram et 32Go de disque (à titre purement indicatif, je n'ai pas fait de benchmark pour vérifier la pertinence de ces ressources).
|
||||
|
||||
## Installation et configuration initiale
|
||||
{: #install}
|
||||
|
||||
L'installation sous debian se fait via le repo officiel de Prosody :
|
||||
|
||||
|
|
@ -88,6 +90,7 @@ $ prosodyctl adduser user@chat.example.org
|
|||
```
|
||||
|
||||
## File sharing et MUC
|
||||
{: #file}
|
||||
|
||||
Afin de rajouter quelques fonctionnalités à notre serveur, nous allons rajouter un vrai service de partage de fichier (actuellement, le partage de fichiers fonctionne, mais uniquement en peer-to-peer), ainsi que la possibilité de créer des rooms de discussion.
|
||||
|
||||
|
|
@ -139,6 +142,7 @@ services.nginx."file.example.org" = {
|
|||
```
|
||||
|
||||
## Fichier de configuration final
|
||||
{: #config}
|
||||
|
||||
```lua
|
||||
external_addresses = { "198.51.100.5" }
|
||||
|
|
|
|||
74
_posts/2024-09-08-blog-workflow.md
Normal file
74
_posts/2024-09-08-blog-workflow.md
Normal file
|
|
@ -0,0 +1,74 @@
|
|||
---
|
||||
layout: post
|
||||
title: Workflow de déploiement de mon blog avec Forgejo Actions
|
||||
tags: [ sysadmin, mainpage ]
|
||||
---
|
||||
|
||||
Ce blog est un blog statique, construit à partir de [Jekyll](https://jekyllrb.com/). Il peut donc être construit à l'avance, afin de générer des fichiers entièrement statiques, qui seront déployés sur un serveur web qui les servira sur internet. C'est donc une excellente occasion pour mettre en place une CI avec [Forgejo Actions](https://forgejo.org/docs/latest/user/actions/), afin d'automatiser le build de ce blog.
|
||||
|
||||
> Je ne fais ici que de la CI, pas de CD (je ne déploie pas automatiquement sur mon serveur web), car j'utilise NixOS pour mon serveur web, et je préfère donc définir manuellement le commit exact du blog que je déploie.
|
||||
|
||||
Je travaille avec deux dépots de code : [blog](https://git.chapoline.me/chapeau/blog), qui contient les sources du blog, et [blog-static](https://git.chapoline.me/chapeau/blog-static), qui contient le résultat du build du blog (et qui est concrètement ce qui est servi par mon serveur web). La CI a donc pour but de récupérer les sources, compiler le blog, et push le résultat sur le deuxième dépot.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
# .forgejo/workflows/main.yml
|
||||
|
||||
# We execute this workflow on each commit pushed
|
||||
on:
|
||||
push:
|
||||
|
||||
jobs:
|
||||
build:
|
||||
runs-on: docker
|
||||
container:
|
||||
# the Checkout Action needs node to run
|
||||
image: node:bookworm
|
||||
|
||||
steps:
|
||||
# First, clone the source repo
|
||||
- name: Clone repo
|
||||
uses: actions/checkout@v4
|
||||
|
||||
# Then, clone the static repo on the build output path
|
||||
- name: Clone static repo
|
||||
uses: actions/checkout@v4
|
||||
with:
|
||||
repository: chapeau/blog-static
|
||||
path: _site
|
||||
# This repo needs a token because we will push on it later
|
||||
token: ${{ secrets.GH_PAT }}
|
||||
ref: main
|
||||
|
||||
- name: Setup
|
||||
env:
|
||||
MAIL: ${{ secrets.MAIL }}
|
||||
shell: bash
|
||||
run: |
|
||||
# Install some dependencies for the blog
|
||||
apt update
|
||||
apt install -y bundler git apt-utils
|
||||
|
||||
# This configuration is mandatory to make commits
|
||||
git config --global user.email "$MAIL"
|
||||
git config --global user.name "CI Builder"
|
||||
|
||||
# Install ruby dependencies
|
||||
bundle install
|
||||
|
||||
# Build the blog
|
||||
bundle exec jekyll build
|
||||
|
||||
# Commit and push
|
||||
cd _site
|
||||
git add --all
|
||||
git commit -m "Build"
|
||||
git push -u origin main
|
||||
```
|
||||
{% endraw %}
|
||||
|
||||
Pour utiliser ce workflow, deux choses sont nécessaires : un runner Forgejo bien sur, et quelques secrets.
|
||||
|
||||
J'utilise un simple runner docker, installé en suivant la [documentation officielle](https://forgejo.org/docs/latest/admin/actions/#forgejo-runner).
|
||||
|
||||
Les secrets se définissent dans l'interface web de Forgejo, pour le projet, dans `Paramètres -> Actions -> Secrets`. Deux sont nécessaires pour ce workflow : `MAIL`, qui contient simplement l'adresse mail utilisée pour les commits, et `GH_PAT`, qui contient un token d'authentification associé à votre compte, avec des droits d'accès en écriture sur les dépots. Pour le générer, allez dans `Configuration -> Applications`.
|
||||
Loading…
Add table
Reference in a new issue