Compare commits
32
Commits
1ee2f3a8ac
...
wip
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
0f9b039e11 | ||
|
|
12242579a0 | ||
|
|
2d1865f0e0 | ||
|
|
7c89513b5b | ||
|
|
62d4fe4ec2 | ||
|
|
c90cd781d3 | ||
|
|
a59966006b | ||
|
|
1a1e4418bb | ||
|
|
154cd0c66b | ||
|
|
66f7b78efd | ||
|
|
28c26dc488 | ||
|
|
18abf487a7 | ||
|
|
064d8f1576 | ||
|
|
db30198450 | ||
|
|
de3498fa65 | ||
|
|
f49f1409b9 | ||
|
|
9c4b8a756e | ||
|
|
aa43d51c42 | ||
|
|
6ee8277205 | ||
|
|
14d910b267 | ||
|
|
1f68655314 | ||
|
|
0450a78478 | ||
|
|
991b0c356e | ||
|
|
be4b79026b | ||
|
|
2fa42ad3aa | ||
|
|
67d593cb73 | ||
|
|
eff68287f2 | ||
|
|
a4c386e438 | ||
|
|
328aa31600 | ||
|
|
fbc33a5ff4 | ||
|
|
a470377d4f | ||
|
|
6447916039 |
@@ -42,3 +42,4 @@ __pycache__
|
||||
|
||||
# Scratch/demo files (not part of the site)
|
||||
scratch
|
||||
.screenshot
|
||||
|
||||
@@ -7,7 +7,7 @@ description: Learn how NAT, port forwarding, and DHCP work on a home router. Con
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
|
||||
|
||||

|
||||

|
||||
|
||||
## What is a "port"?
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ When you browse a website or use an app, requests are made to one or more domain
|
||||
|
||||
The DNS zone is like a registry with signposts that direct your requests to the correct destination.
|
||||
|
||||

|
||||

|
||||
|
||||
## The DNS Zone
|
||||
|
||||
|
||||
@@ -30,7 +30,7 @@ RAID is not a backup system but a service continuity system! It only allows hot-
|
||||
### No RAID
|
||||
|
||||
<div style="display: flex; align-items: center;">
|
||||
<img src="/img/global/no-raid.svg" alt="Image" style="max-width: 30%; max-height:230px; margin-right: 20px;">
|
||||
<img src="/img/global/no-raid.svg" alt="Disks with no RAID redundancy" style="max-width: 30%; max-height:230px; margin-right: 20px;">
|
||||
<ul>
|
||||
<li>Just your disks, without RAID. Data is stored disk by disk.</li>
|
||||
<li>If you lose a disk, only its data is lost.</li>
|
||||
@@ -43,7 +43,7 @@ Use your disks without RAID when you're not afraid of data loss and can tolerate
|
||||
### RAID 0
|
||||
|
||||
<div style="display: flex; align-items: center;">
|
||||
<img src="/img/global/raid0.svg" alt="Image" style="max-width: 30%; max-height:230px; margin-right: 20px;">
|
||||
<img src="/img/global/raid0.svg" alt="RAID 0 striping data across disks" style="max-width: 30%; max-height:230px; margin-right: 20px;">
|
||||
<ul>
|
||||
<li>OS sees 1 drive.</li>
|
||||
<li>Data is striped across all disks.</li>
|
||||
@@ -59,7 +59,7 @@ Use RAID 0 when you prioritize performance and are not concerned about data loss
|
||||
### RAID 1
|
||||
|
||||
<div style="display: flex; align-items: center;">
|
||||
<img src="/img/global/raid1.svg" alt="Image" style="max-width: 30%; max-height:230px; margin-right: 20px;">
|
||||
<img src="/img/global/raid1.svg" alt="RAID 1 mirroring data across disks" style="max-width: 30%; max-height:230px; margin-right: 20px;">
|
||||
<ul>
|
||||
<li>OS sees 1 drive.</li>
|
||||
<li>All disks contain identical data.</li>
|
||||
@@ -78,7 +78,7 @@ Use RAID 1 for strong redundancy. Each disk contains all data, so performance re
|
||||
|
||||
### RAID 5
|
||||
<p align="center">
|
||||
<img src="/img/global/raid5.svg" alt="Image" style="max-width: 40%; margin-right: 20px;">
|
||||
<img src="/img/global/raid5.svg" alt="RAID 5 with distributed parity" style="max-width: 40%; margin-right: 20px;">
|
||||
</p>
|
||||
|
||||
- OS sees 1 drive.
|
||||
@@ -92,7 +92,7 @@ Use RAID 5 when you want reliable storage with 3 to 5 disks and minimal space lo
|
||||
|
||||
### RAID 6
|
||||
<p align="center">
|
||||
<img src="/img/global/raid6.svg" alt="Image" style="max-width: 50%; margin-right: 20px;">
|
||||
<img src="/img/global/raid6.svg" alt="RAID 6 with double distributed parity" style="max-width: 50%; margin-right: 20px;">
|
||||
</p>
|
||||
|
||||
- OS sees 1 drive.
|
||||
@@ -102,7 +102,7 @@ Use RAID 5 when you want reliable storage with 3 to 5 disks and minimal space lo
|
||||
- Total capacity is the sum of all disks minus two (e.g., 4×10TB = 20TB).
|
||||
- Minimum of 4 disks (6 recommended to minimize space loss).
|
||||
|
||||
Use RAID 6 in similar situations as RAID 5, especially with 6 or more disks. More disks mean higher failure risk. RAID 6 offers peace of mind by tolerating two simultaneous failures.
|
||||
Use RAID 6 in similar situations as RAID 5, especially with 6 or more disks. More disks mean higher failure risk. RAID 6 offers peace of mind by tolerating two simultaneous failures. There's nothing more frustrating than losing a second disk while the array is still rebuilding from replacing the first.
|
||||
|
||||
## Software RAID
|
||||
(coming soon)
|
||||
|
||||
@@ -24,7 +24,7 @@ Here’s what we’re most interested in:
|
||||
- Its robust error notifications and monitoring.
|
||||
|
||||
## Structure
|
||||

|
||||

|
||||
|
||||
ZFS has a unique structure:
|
||||
|
||||
|
||||
@@ -31,7 +31,7 @@ Larger boards generally offer more ports and features. Pre-built systems might u
|
||||
|
||||
## CPU
|
||||
<div style="display: flex; align-items: center;">
|
||||
<img src="/img/global/cpu.svg" alt="Image" style="max-width: 25%; max-height:230px; margin-right: 20px;">
|
||||
<img src="/img/global/cpu.svg" alt="CPU icon" style="max-width: 25%; max-height:230px; margin-right: 20px;">
|
||||
<p>The <strong>CPU</strong> (Central Processing Unit) is the computer's calculator. It processes most software tasks. Modern CPUs have multiple cores, often with virtual threads, to better handle workloads. They need to be cooled using either an active cooler (with a fan) or a passive one (fanless), depending on power consumption (watts). Choose your CPU based on how you plan to use the server.</p>
|
||||
</div>
|
||||
|
||||
@@ -51,7 +51,7 @@ For low-power home servers or NAS (non-intensive computing), consider Intel N100
|
||||
## RAM
|
||||
|
||||
<p align="center">
|
||||
<img src="/img/global/ram.svg" alt="Image" style="max-width: 65%;">
|
||||
<img src="/img/global/ram.svg" alt="RAM icon" style="max-width: 65%;">
|
||||
</p>
|
||||
|
||||
__RAM__ (Random Access Memory) is fast, temporary memory used by the CPU (and iGPU if applicable) for quick access during execution. It clears periodically and when the machine powers down. Better RAM = better CPU performance.
|
||||
@@ -67,7 +67,7 @@ Depending on the required performance, one can choose between a dedicated GPU wi
|
||||
## HDD(s)
|
||||
|
||||
<p align="center">
|
||||
<img src="/img/global/hdd.svg" alt="Image" style="max-width: 50%; margin-right: 20px;">
|
||||
<img src="/img/global/hdd.svg" alt="Hard disk drive icon" style="max-width: 50%; margin-right: 20px;">
|
||||
</p>
|
||||
|
||||
An __HDD__ (Hard Disk Drive), or hard drive, is a component used to store data. It was once the standard storage device in computers. HDDs consist of one or more stacked platters and read/write heads, somewhat like a vinyl record player.
|
||||
@@ -85,7 +85,7 @@ Comes in 3.5" and 2.5" formats; servers usually favor the more reliable 3.5".
|
||||
## SSD(s)
|
||||
|
||||
<p align="center">
|
||||
<img src="/img/global/nvme.svg" alt="Image" style="max-width: 50%; margin-right: 20px;">
|
||||
<img src="/img/global/nvme.svg" alt="NVMe SSD icon" style="max-width: 50%; margin-right: 20px;">
|
||||
</p>
|
||||
|
||||
An __SSD__ (Solid State Drive) is a small circuit board with memory chips soldered onto it, used to store information. Unlike RAM, these chips retain data even when not powered, meaning the information is preserved after a reboot. SSDs are generally used as the main storage medium for your server.
|
||||
@@ -144,7 +144,7 @@ To choose the right PSU, a common rule of thumb is to estimate your system’s p
|
||||
## Case
|
||||
|
||||
<div style="display: flex; align-items: center;">
|
||||
<img src="/img/global/case.svg" alt="Image" style="max-width: 25%; max-height:230px; margin-right: 20px;">
|
||||
<img src="/img/global/case.svg" alt="Computer case icon" style="max-width: 25%; max-height:230px; margin-right: 20px;">
|
||||
<p>The <strong>case</strong> is also an essential component of your machine. It plays a key role in cooling, through its fans and airflow design, and it determines the form factor compatibility for your motherboard, power supply, and any dedicated GPU you may install.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
@@ -18,9 +18,9 @@ It’s **objectively inexpensive**, and anyone with a bit of curiosity can get s
|
||||
|
||||
A mini PC for $100 + a USB dock for $50 that holds multiple hard drives = a complete platform for $150, versus **$350–1200** for branded NAS systems.
|
||||
|
||||
That’s all a **ProloNAS** is. It’s then up to you to scale your storage capacity according to your needs.
|
||||
That’s all a **ProloNAS** is: a NAS anyone can afford. The name is a French pun, *prolo* (slang for "working-class") plus *NAS*, a home server for the rest of us, not just people who can drop $1000 on a branded box. It’s then up to you to scale your storage capacity according to your needs.
|
||||
|
||||

|
||||

|
||||
|
||||
## Example Hardware
|
||||
|
||||
@@ -36,7 +36,7 @@ A **NAS** (Network Attached Storage) is a machine centered around storage, desig
|
||||
|
||||
### But why not just use a mini PC with an external hard drive?
|
||||
|
||||
Sure, a simple mini PC with 1–2 TB of storage will do for most people.And your movie collection might fit on an external drive of a few extra terabytes. But that’s **neither reliable nor scalable** a single shock or hardware failure could permanently destroy your data.
|
||||
Sure, a simple mini PC with 1–2 TB of storage will do for most people. And your movie collection might fit on an external drive of a few extra terabytes. But that’s **neither reliable nor scalable**: a single shock or hardware failure could permanently destroy your data.
|
||||
|
||||
A real NAS is built around **storage reliability**. It uses redundancy strategies like [RAID](/general/storage/raid) to protect against drive failure, and snapshot systems like [ZFS](/general/storage/zfs) to guard against corruption.
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ Options change how a command behaves. They come in two flavours, and most comman
|
||||
- **Short**, a single dash and a single letter: `ls -a`. They can be stacked, so `ls -l -a -h` is usually written `ls -lah`.
|
||||
- **Long**, two dashes and a whole word: `ls --all`. Longer to type, but you can still tell what it does six months later, which is why they're the better choice in a script.
|
||||
|
||||
Some options expect a value right after them: `ssh-keygen -t ed25519` (`-t` for type), `rsync --exclude @eaDir`. And case matters, always. In `ls`, `-r` reverses the sort order while `-R` walks into subfolders. Two different things, one letter apart.
|
||||
Some options expect a value right after them: `ssh-keygen -t ed25519` (`-t` for type), `rsync --exclude @eaDir`. And case matters, always. In `ls`, `-r` reverses the sort order while `-R` walks into subfolders. Same letter, different case.
|
||||
|
||||
### Arguments and paths
|
||||
|
||||
@@ -49,7 +49,9 @@ When the target is a place on the disk, you write it as a path, and there are a
|
||||
| `/var/log` | an **absolute** path, same result from anywhere |
|
||||
| `logs/today` | a **relative** path, understood from where you currently stand |
|
||||
|
||||
Which folder holds what is a subject of its own, covered in [folders and partitions](/general/linux/filesystem).
|
||||
::note{to="/general/linux/filesystem"}
|
||||
Which folder holds what is a subject of its own, covered in **folders and partitions**.
|
||||
::
|
||||
|
||||
The prompt itself tells you where you are: in `username@serveex:~/docker$`, you're logged in as `username` on the machine named `serveex`, inside the `docker` folder of your home. That final `$` means a normal user. If it ever shows `#`, you're root and every typo counts double.
|
||||
|
||||
@@ -241,7 +243,7 @@ The ones worth keeping at hand, and where their names come from.
|
||||
| `chmod` | change mode | Changes a file's permissions |
|
||||
| `chown` | change owner | Changes who owns a file |
|
||||
| `sudo` | substitute user do | Runs one command as administrator |
|
||||
| `apt` | advanced package tool | Installs, updates and removes packages |
|
||||
| `apt` | Advanced Package Tool | Installs, updates and removes packages |
|
||||
| `systemctl` | control systemd | Starts, stops and enables services |
|
||||
| `ssh` | secure shell | Opens a session on a remote machine |
|
||||
| `scp` | secure copy | Copies files over SSH |
|
||||
|
||||
@@ -203,7 +203,7 @@ Being outside `apt` also means it won't be updated by `apt full-upgrade`. Repeat
|
||||
|
||||
## `ufw`, a firewall you can actually read
|
||||
|
||||
Debian's firewall (`iptables`/`nftables` under the hood) is powerful and unreadable directly. `ufw`, *uncomplicated firewall*, is a thin layer on top that turns it into short, plain-English rules, block everything by default and open only what you actually expose.
|
||||
Debian's firewall (`iptables`/`nftables` under the hood) is powerful and unreadable directly. `ufw`, *uncomplicated firewall*, is a thin layer on top that turns it into short, plain-English rules: block everything by default and open only what you actually expose.
|
||||
|
||||
::steps{level="4"}
|
||||
#### Install it
|
||||
|
||||
@@ -9,7 +9,7 @@ navigation:
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
## A Home Lab by a Beginner, for Beginners
|
||||
|
||||

|
||||

|
||||
|
||||
**Serveex** is primarily a personal project aimed at hosting as many everyday services as possible at home, without relying on proprietary platforms (Google, Apple, Netflix, etc.). The goal was to experiment, learn, and document every step along the way. This is purely a scientific project and is not intended for production use.
|
||||
|
||||
@@ -47,7 +47,7 @@ Install Docker
|
||||
---
|
||||
icon: i-carbon-container-registry
|
||||
title: Container manager
|
||||
to: "/serveex/core/docker#installer-dockge-pour-gérer-et-déployer-les-conteneurs"
|
||||
to: "/serveex/core/docker#install-dockge-to-manage-and-deploy-containers"
|
||||
ui:
|
||||
icon: text-[#74C2FF]
|
||||
---
|
||||
@@ -62,7 +62,7 @@ to: /serveex/core/wireguard
|
||||
ui:
|
||||
icon: text-[#88171A]
|
||||
---
|
||||
Install and deploy Wireguard
|
||||
Install and deploy WireGuard
|
||||
::
|
||||
|
||||
::card{icon="i-noto-globe-showing-americas" title="Reverse Proxy" to="/serveex/core/swag"}
|
||||
@@ -174,7 +174,7 @@ to: /serveex/media/qbittorrent
|
||||
ui:
|
||||
icon: text-[#2F67BA]
|
||||
---
|
||||
Install and deploy Qbittorrent
|
||||
Install and deploy qBittorrent
|
||||
::
|
||||
|
||||
::card
|
||||
@@ -284,7 +284,7 @@ to: /serveex/apps/adguard
|
||||
ui:
|
||||
icon: text-[#68BC71]
|
||||
---
|
||||
Install and deploy Adguard Home
|
||||
Install and deploy AdGuard Home
|
||||
::
|
||||
|
||||
::card
|
||||
@@ -296,6 +296,8 @@ ui:
|
||||
icon: text-[#175DDC]
|
||||
---
|
||||
Install and deploy Vaultwarden
|
||||
::
|
||||
|
||||
::
|
||||
::
|
||||
|
||||
@@ -313,6 +315,14 @@ Install and deploy Authentik
|
||||
::card{icon="i-noto-crystal-ball" title="Multi-host Docker manager" to="/serveex/advanced/arcane"}
|
||||
Install and deploy Arcane
|
||||
::
|
||||
|
||||
::card{icon="i-lucide-database-backup" title="3-2-1 Backups" to="/serveex/advanced/backrest"}
|
||||
Install and deploy Backrest
|
||||
::
|
||||
|
||||
::card{icon="i-lucide-rotate-ccw" title="Instant Rollback" to="/serveex/advanced/btrfs-snapshots"}
|
||||
Set up BTRFS snapshots
|
||||
::
|
||||
::
|
||||
|
||||
## Coming Soon
|
||||
|
||||
@@ -8,9 +8,9 @@ description: Step-by-step guide to install Debian 13 on a home server and set up
|
||||
|
||||
[Debian 13 "Trixie"](https://www.debian.org/) is the base this whole guide sits on. It's a plain, boring, stable Linux, and for a homelab that's exactly the point: package versions stay frozen for the life of the release, security patches keep coming for about five years counting LTS, so the machine keeps running for years instead of needing a rebuild every few months.
|
||||
|
||||
The other reason is that it stays out of your way. Appliance systems like Unraid, TrueNAS or Synology's DSM put their own layer on top of Docker, and the day you need something their interface doesn't expose, you're stuck working around it. Debian is just a server: you install what you want, where you want, and nothing is hidden behind someone else's UI. It also happens to be what most self-hosted projects target first, so their docs hand you `apt` commands that work as-is, Docker publishes an official Debian repository, and any error message you paste into a search engine already has years of answers behind it. A minimal install is light enough to leave nearly all the RAM and CPU of a small N100 box to your containers.
|
||||
The other reason is that it stays out of your way. Appliance systems like Unraid, TrueNAS or Synology's DSM put their own layer on top of Linux, and the day you need something their interface doesn't expose, you're stuck working around it. Debian is just a server: you install what you want, where you want, and nothing is hidden behind someone else's UI. It also happens to be what most self-hosted projects target first, so their docs hand you `apt` commands that work as-is, Docker publishes an official Debian repository, and any error message you paste into a search engine already has years of answers behind it. A minimal install is light enough to leave nearly all the RAM and CPU of a small N100 box to your containers.
|
||||
|
||||

|
||||

|
||||
|
||||
## Installation
|
||||
|
||||
@@ -89,6 +89,10 @@ Confirm the timezone guessed from your country.
|
||||
|
||||
*Guided, use entire disk* on the system drive, then *All files in one partition*, which gives you one big `/` plus a swap partition. Separate `/home` or `/var` partitions buy you very little here and mostly guarantee that one fills up while the others sit half empty. Pick LVM only if you already know you want snapshots or to grow volumes later. Your data disks are not touched at this stage, you'll mount them afterwards.
|
||||
|
||||
::warning{to="/serveex/advanced/btrfs-snapshots"}
|
||||
__For advanced users:__ this is the moment to decide, not later. Picking *Manual* here instead of *Guided* lets you format the root partition as Btrfs instead of ext4, unlocking instant, near-free snapshots you can roll back to before a risky update or config change. Once this step is done and Debian is installed on ext4, switching to Btrfs isn't possible without wiping the disk and starting over. See **BTRFS snapshots** if you want to set it up, it's not a replacement for real backups either, a snapshot lives on the same disk.
|
||||
::
|
||||
|
||||
Finish with *Finish partitioning and write changes to disk*, then confirm with *Yes*: this is the point of no return for that disk.
|
||||
|
||||

|
||||
@@ -216,7 +220,7 @@ The door is now closed for every other machine too, including the next one you'l
|
||||
|
||||
A machine that runs 24/7 for two hours of actual use burns power, spins fans and wears drives for nothing. Wake on LAN lets you shut it down properly when you're done and bring it back in a few seconds without walking to it: the network card stays powered in standby, listening for one specific broadcast (the *magic packet*) carrying the server's MAC address, and switches the machine on when it sees it. Handy for a backup target you only need at night, or a media server nobody watches during the day.
|
||||
|
||||
Two conditions before you start: the machine has to be wired to ethernet, WiFi cards almost never support this, and the packet has to be sent from the same local network, since a broadcast doesn't cross a router. The BIOS side was covered in [BIOS setup](#bios-setup), here is the Debian side.
|
||||
Two conditions before you start: the machine has to be wired to ethernet, WiFi cards almost never support this, and the packet has to be sent from the same local network, since a broadcast doesn't cross a router, unless you use a dedicated app and port-forwarding rules on your router. The BIOS side was covered in [BIOS setup](#bios-setup), here is the Debian side.
|
||||
|
||||
::steps{level="4"}
|
||||
#### Find the interface and its MAC address
|
||||
|
||||
@@ -12,7 +12,7 @@ A **container** sidesteps the problem: it packages an app together with everythi
|
||||
|
||||
**Docker** is the tool that builds, starts and manages these containers. Point it at an *image*, a ready-made snapshot of an app maintained by its developers, and it downloads it and runs it in one command. The rest of Serveex is built entirely on it: every app from here on is one Docker container, or a handful of them working together.
|
||||
|
||||

|
||||

|
||||
|
||||
## Install Docker
|
||||
::steps{level="3"}
|
||||
@@ -53,7 +53,7 @@ sudo mkdir /srv/docker
|
||||
## Install [Dockge](https://github.com/louislam/dockge) to manage and deploy containers
|
||||
[Dockge](https://github.com/louislam/dockge) is a web tool to create, configure, launch, and manage Docker containers. It's a simple, intuitive interface that’s lighter and easier for beginners than using the CLI or Portainer.
|
||||
|
||||

|
||||

|
||||
|
||||
### Configuration
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Wireguard
|
||||
title: WireGuard
|
||||
description: Install and configure WireGuard VPN to securely access your homelab from anywhere and connect all your devices to your private network.
|
||||
---
|
||||
|
||||
@@ -9,10 +9,10 @@ description: Install and configure WireGuard VPN to securely access your homelab
|
||||
## Introduction
|
||||
Using a VPN allows remote access to a server’s local resources without exposing them to the internet. It’s a clean and secure way to access services like SSH without exposing the port publicly. With a VPN, you can securely connect to your network from anywhere and make devices on different networks communicate.
|
||||
|
||||
Here we will use [Wireguard](https://www.wireguard.com/), a secure and high-performance VPN server, using containers:
|
||||
Here we will use [WireGuard](https://www.wireguard.com/), a secure and high-performance VPN server, using containers:
|
||||
|
||||
- [wg-easy](https://github.com/wg-easy/wg-easy) as the server, providing a very simple web UI to manage connections and download config files (including QR codes for phones)
|
||||
- [Wireguard](https://docs.linuxserver.io/images/docker-wireguard/?h=wireguard) as the client for Linux systems
|
||||
- [WireGuard](https://docs.linuxserver.io/images/docker-wireguard/?h=wireguard) as the client for Linux systems
|
||||
|
||||
Clients are also available for Windows, macOS, iOS, and Android.
|
||||
|
||||
@@ -27,7 +27,7 @@ To achieve this, we’ll create a **Virtual Private Network** (VPN), i.e., a sec
|
||||
|
||||
Additionally, you can add your phone, laptop, or other devices to the VPN and securely access your server resources wherever you are.
|
||||
|
||||

|
||||

|
||||
|
||||
In this diagram, machine 1 is part of two networks:
|
||||
|
||||
@@ -276,4 +276,4 @@ Repeat this setup for each client.
|
||||
|
||||
And here’s the final setup overview:
|
||||
|
||||

|
||||

|
||||
|
||||
@@ -6,18 +6,18 @@ description: Set up SWAG as a reverse proxy with automatic SSL, expose your serv
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
|
||||
[Swag](https://docs.linuxserver.io/general/swag/) is the core of this homelab. It’s a powerful reverse proxy that allows you to expose services on the internet using domain names, handling SSL certificate issuance (for encrypted connections), request routing, and access security (via HTTP auth or SSO like Authelia or Authentik). All the necessary documentation is [available here](https://docs.linuxserver.io/general/swag).
|
||||
[SWAG](https://docs.linuxserver.io/general/swag/) is the core of this homelab. It’s a powerful reverse proxy that allows you to expose services on the internet using domain names, handling SSL certificate issuance (for encrypted connections), request routing, and access security (via HTTP auth or SSO like Authelia or Authentik). All the necessary documentation is [available here](https://docs.linuxserver.io/general/swag).
|
||||
|
||||
::warning{to="/serveex/core/wireguard"}
|
||||
|
||||
SWAG is only useful for exposing your services to the internet, i.e. accessing them via a public URL like `https://service.mydomain.com`. If you don’t want to expose your services and prefer to always use a VPN to connect remotely, you can go **here instead**.
|
||||
::
|
||||
|
||||
Below is an example exposing Dockge. We will install SWAG along with the dbip mod for geolocation-based blocking, and the dashboard mod for managing swag, fail2ban, and geolocation.
|
||||
Below is an example exposing Dockge. We will install SWAG along with the dbip mod for geolocation-based blocking, the dashboard mod for managing swag, fail2ban, and geolocation, and the auto-reload mod, which automatically reloads nginx whenever a config file changes, without having to restart the container.
|
||||
|
||||
**Reverse proxy principle and its application in our case:**
|
||||
|
||||

|
||||

|
||||
|
||||
## Installation
|
||||
|
||||
@@ -161,7 +161,7 @@ Save with :kbd{value="Ctrl+O"}, then :kbd{value="Enter"}, and exit with :kbd{val
|
||||
|
||||
### Enable DBIP in nginx.conf
|
||||
|
||||
Now configure swag to access DBIP, the geolocation-based access control module. Open the `nginx.conf` file:
|
||||
Now configure SWAG to access DBIP, the geolocation-based access control module. Open the `nginx.conf` file:
|
||||
|
||||
```bash [Terminal]
|
||||
sudo nano /srv/docker/swag/config/nginx/nginx.conf
|
||||
@@ -182,7 +182,7 @@ Restart the stack in Dockge. This time, the SSL certificate should be successful
|
||||
Access the dashboard locally by going to `http://yourserverip:81`
|
||||
On the left, you'll see a list of currently "proxied" services (none yet). On the right, the list of banned IPs. Below, various indicators. For more details, [click here](https://www.linuxserver.io/blog/introducing-swag-dashboard).
|
||||
|
||||

|
||||

|
||||
|
||||
## DBIP
|
||||
DBIP allows you to block connections based on countries. It relies on the configuration file named `dbip.conf` located in `/srv/docker/swag/config/nginx`. [More info here](https://virtualize.link/secure/).
|
||||
@@ -290,7 +290,7 @@ Now it's time to expose Dockge on the internet so you can access and manage your
|
||||
|
||||
::warning
|
||||
|
||||
Dockge does not support multi-factor authentication. Exposing it online could compromise all connected machines. Only do this if you're using an MFA solution like [TinyAuth](/serveex/security/tinyauth) or [Authentik](/serveex/advanced/authentik/). Otherwise, don’t expose it with SWAG. Use a VPN like [Wireguard](/serveex/core/wireguard) instead.
|
||||
Dockge does not support multi-factor authentication. Exposing it online could compromise all connected machines. Only do this if you're using an MFA solution like [TinyAuth](/serveex/security/tinyauth) or [Authentik](/serveex/advanced/authentik/). Otherwise, don’t expose it with SWAG. Use a VPN like [WireGuard](/serveex/core/wireguard) instead.
|
||||
::
|
||||
|
||||
::steps{level="3"}
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
---
|
||||
title: TinyAuth
|
||||
description: Install TinyAuth, a lightweight forward-auth proxy, and pair it with Pocket ID to add SSO login in front of your self-hosted apps. Protect your app behind Swag with forward-auth.
|
||||
description: Install TinyAuth, a lightweight forward-auth proxy, and pair it with Pocket ID to add SSO login in front of your self-hosted apps. Protect your app behind SWAG with forward-auth.
|
||||
---
|
||||
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
|
||||
[TinyAuth](https://tinyauth.app) is a small forward-auth proxy: a single login page that Swag can insert in front of any app before letting a request through, checking whether a visitor is authenticated before forwarding them on.
|
||||
[TinyAuth](https://tinyauth.app) is a small forward-auth proxy: a single login page that SWAG can insert in front of any app before letting a request through, checking whether a visitor is authenticated before forwarding them on.
|
||||
|
||||

|
||||
|
||||
@@ -15,6 +15,8 @@ It supports a simple local username/password login out of the box, which is what
|
||||
- [TinyAuth documentation](https://tinyauth.app/docs/getting-started)
|
||||
- [TinyAuth on GitHub](https://github.com/tinyauthapp/tinyauth)
|
||||
|
||||

|
||||
|
||||
## Installation
|
||||
|
||||
::file-tree
|
||||
@@ -135,7 +137,7 @@ It re-prompts for the username, password, and current 6-digit code.
|
||||
|
||||
From now on, that user needs both their password and a valid code from their authenticator app to log in.
|
||||
|
||||
## Exposing TinyAuth with Swag
|
||||
## Exposing TinyAuth with SWAG
|
||||
TinyAuth needs its own subdomain: it's the page users land on before being forwarded to the app they actually want.
|
||||
|
||||
::note
|
||||
@@ -174,7 +176,7 @@ Here we assume the TinyAuth network name is `tinyauth_default`. You can check th
|
||||
|
||||
### Create the subdomain.conf file
|
||||
|
||||
In the Swag folders, create the file `tinyauth.subdomain.conf`:
|
||||
In the SWAG folders, create the file `tinyauth.subdomain.conf`:
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
✨ __Tip:__ Use **File Browser Quantum** to navigate and edit files instead of using terminal commands.
|
||||
@@ -225,7 +227,7 @@ __If it fails:__ check your firewall rules.
|
||||
::
|
||||
|
||||
## Protecting an app via reverse proxy
|
||||
Swag doesn't ship a ready-made include file for TinyAuth, so we'll add the forward-auth check directly to the app's own `*.subdomain.conf`. We'll use Dockge as an example.
|
||||
SWAG doesn't ship a ready-made include file for TinyAuth, so we'll add the forward-auth check directly to the app's own `*.subdomain.conf`. We'll use Dockge as an example.
|
||||
|
||||
::steps{level="3"}
|
||||
### Open the app's subdomain.conf file
|
||||
|
||||
@@ -15,6 +15,8 @@ This makes it a good fit if you just need a simple, fast SSO backend, for exampl
|
||||
- [Pocket ID documentation](https://pocket-id.org/docs)
|
||||
- [Pocket ID on GitHub](https://github.com/pocket-id/pocket-id)
|
||||
|
||||

|
||||
|
||||
## Installation
|
||||
|
||||
::file-tree
|
||||
@@ -96,7 +98,7 @@ TRUST_PROXY=true
|
||||
|----------|-------|---------|
|
||||
| `APP_URL`{lang=properties} | The public URL you'll use to reach Pocket ID (see exposure below) | `https://id.mydomain.com` |
|
||||
| `ENCRYPTION_KEY`{lang=properties} | The key generated above | `Q2pVEqsTNRkJSO9SkJzU3KZ2...` |
|
||||
| `TRUST_PROXY`{lang=properties} | Required since Pocket ID sits behind Swag | `true` |
|
||||
| `TRUST_PROXY`{lang=properties} | Required since Pocket ID sits behind SWAG | `true` |
|
||||
|
||||
Deploy the stack. The local interface is available at `http://yourserverip:1411`.
|
||||
|
||||
@@ -114,7 +116,7 @@ Pocket ID doesn't use passwords: your first account is created with a **passkey*
|
||||
Passkeys require a secure context: HTTPS, or `localhost`. Registering one from `http://yourserverip:1411` on another machine will be refused by the browser, since that's plain HTTP to a non-`localhost` address. If setup doesn't complete locally, expose Pocket ID first (see below) and finish setup over HTTPS instead.
|
||||
::
|
||||
|
||||
## Exposing Pocket ID with Swag
|
||||
## Exposing Pocket ID with SWAG
|
||||
Other apps need to reach Pocket ID over HTTPS to complete the OIDC login flow, so it must be exposed even if you only use it from home.
|
||||
|
||||
::note
|
||||
@@ -153,7 +155,7 @@ Here we assume the Pocket ID network name is `pocket-id_default`. You can check
|
||||
|
||||
### Create the subdomain.conf file
|
||||
|
||||
In the Swag folders, create the file `id.subdomain.conf`:
|
||||
In the SWAG folders, create the file `id.subdomain.conf`:
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
✨ __Tip:__ Use **File Browser Quantum** to navigate and edit files instead of using terminal commands.
|
||||
@@ -230,6 +232,8 @@ Save, then copy the generated __Client ID__ and __Client Secret__. You'll need t
|
||||
## Connecting Pocket ID to TinyAuth
|
||||
[TinyAuth](/serveex/security/tinyauth) can delegate its login to Pocket ID instead of (or alongside) its local username/password, so anyone visiting a protected app authenticates with a passkey and gets forwarded through.
|
||||
|
||||

|
||||
|
||||
::steps{level="3"}
|
||||
### Register TinyAuth as an OIDC client
|
||||
|
||||
|
||||
@@ -6,7 +6,9 @@ description: Install Uptime-Kuma to monitor your self-hosted services uptime, se
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
|
||||

|
||||
[Uptime-Kuma](https://github.com/louislam/uptime-kuma) is a self-hosted monitoring tool that regularly checks whether your other services and sites are up and reachable, and alerts you the moment one goes down. It can also build a public status page to share your services' health with others.
|
||||
|
||||

|
||||
|
||||
## Installation
|
||||
|
||||
@@ -65,7 +67,7 @@ __If it fails:__ check your firewall rules.
|
||||
### Done!
|
||||
::
|
||||
|
||||
## Expose with Swag
|
||||
## Expose with SWAG
|
||||
::note{icon=""}
|
||||
📋 __Before you begin:__
|
||||
<br/><br/>
|
||||
@@ -74,13 +76,13 @@ We assume you have the subdomain `stats.mydomain.com` with a `CNAME` pointing to
|
||||
|
||||
::warning
|
||||
|
||||
Uptime-Kuma does not use multi-factor authentication. Exposing Uptime-Kuma on the internet could compromise the machines it monitors. Only do this if you're using an MFA system like [TinyAuth](/serveex/security/tinyauth) or [Authentik](/serveex/advanced/authentik/). Otherwise, don’t expose it with SWAG; use a VPN like [Wireguard](/serveex/core/wireguard) instead.
|
||||
Uptime-Kuma does not use multi-factor authentication. Exposing Uptime-Kuma on the internet could compromise the machines it monitors. Only do this if you're using an MFA system like [TinyAuth](/serveex/security/tinyauth) or [Authentik](/serveex/advanced/authentik/). Otherwise, don’t expose it with SWAG; use a VPN like [WireGuard](/serveex/core/wireguard) instead.
|
||||
::
|
||||
|
||||
::steps{level="3"}
|
||||
### Create the subdomain.conf file
|
||||
|
||||
In the Swag folders, create the `stats.subdomain.conf` file.
|
||||
In the SWAG folders, create the `stats.subdomain.conf` file.
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
✨ __Tip for those who dislike the terminal:__
|
||||
@@ -190,7 +192,7 @@ sudo nano /srv/docker/swag/config/nginx/proxy-confs/stats.subdomain.conf
|
||||
|
||||
### Add the forward-auth check and public paths
|
||||
|
||||
Replace the file's content with the following. The `location ~ ^/(...)` block matches Uptime-Kuma's public status page and its assets, and is served directly, without ever reaching the `auth_request` check in `location /`:
|
||||
Replace the file's content with the following. The `location ~ ^/(...)` block matches Uptime-Kuma's public status page and its assets, and is served directly, without ever reaching the `auth_request` check in `location /`. Only `api/status-page` is left public, not all of `/api`, since the rest of Uptime-Kuma's API is meant to stay behind authentication; `/metrics` (Uptime-Kuma's Prometheus endpoint) is left out of the regex entirely for the same reason:
|
||||
|
||||
```nginx [stats.subdomain.conf]{9-16,32-33}
|
||||
server {
|
||||
@@ -201,7 +203,7 @@ server {
|
||||
|
||||
include /config/nginx/ssl.conf;
|
||||
|
||||
location ~ ^/(status|assets|icon\.svg|api|upload|metrics) {
|
||||
location ~ ^/(status|assets|icon\.svg|api/status-page|upload) {
|
||||
include /config/nginx/proxy.conf;
|
||||
include /config/nginx/resolver.conf;
|
||||
set $upstream_app uptime-kuma;
|
||||
|
||||
@@ -39,6 +39,8 @@ services:
|
||||
image: amir20/dozzle:latest
|
||||
ports:
|
||||
- 9135:8080
|
||||
volumes:
|
||||
- /docker/dozzle/data:/data
|
||||
env_file:
|
||||
- .env
|
||||
environment:
|
||||
@@ -104,14 +106,14 @@ Deploy the container. Go to `http://yourserverip:9135`. Voilà, your Dozzle web
|
||||
### Done!
|
||||
::
|
||||
|
||||
## Exposing Dozzle with Swag
|
||||
## Exposing Dozzle with SWAG
|
||||
|
||||
::warning
|
||||
|
||||
Dozzle does not use multi-factor authentication. Exposing Dozzle to the internet could compromise the connected machines. Only do this if you use a multi-factor authentication system like [TinyAuth](/serveex/security/tinyauth) or [Authentik](/serveex/advanced/authentik/). Otherwise, do not expose it with SWAG and instead use a VPN like [Wireguard](/serveex/core/wireguard).
|
||||
Dozzle does not use multi-factor authentication. Exposing Dozzle to the internet could compromise the connected machines. Only do this if you use a multi-factor authentication system like [TinyAuth](/serveex/security/tinyauth) or [Authentik](/serveex/advanced/authentik/). Otherwise, do not expose it with SWAG and instead use a VPN like [WireGuard](/serveex/core/wireguard).
|
||||
::
|
||||
|
||||
You may want to access Dozzle remotely and on all your devices. To do so, we’ll expose Dozzle via Swag.
|
||||
You may want to access Dozzle remotely and on all your devices. To do so, we’ll expose Dozzle via SWAG.
|
||||
|
||||
::note{icon=""}
|
||||
📋 __Before you begin:__
|
||||
@@ -150,7 +152,7 @@ We assume the Dozzle network name is `dozzle_default`. You can verify the connec
|
||||
|
||||
### Create the subdomain.conf file
|
||||
|
||||
In the Swag folder, create the `dozzle.subdomain.conf` file.
|
||||
In the SWAG folder, create the `dozzle.subdomain.conf` file.
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
✨ __Tip:__ You can use **File Browser Quantum** to browse and edit files instead of using terminal commands.
|
||||
|
||||
@@ -56,7 +56,7 @@ services:
|
||||
- ${PORT}:80
|
||||
environment:
|
||||
- PUID=${PUID}
|
||||
- PGID=${GUID}
|
||||
- PGID=${PGID}
|
||||
- TZ=Europe/Paris
|
||||
- APP_KEY=${API_KEY}
|
||||
- DB_CONNECTION=sqlite
|
||||
@@ -67,19 +67,19 @@ services:
|
||||
|
||||
### Set your environment variables
|
||||
|
||||
Find your `PUID` and `GUID` by running the following command:
|
||||
Find your `PUID` and `PGID` by running the following command:
|
||||
|
||||
```bash [Terminal]
|
||||
id yourusername
|
||||
```
|
||||
|
||||
In the `.env` file, set the variable `API_KEY` with the key you generated and add a cron-style test schedule, as well as your `PUID` and `GUID`, for example:
|
||||
In the `.env` file, set the variable `API_KEY` with the key you generated and add a cron-style test schedule, as well as your `PUID` and `PGID`, for example:
|
||||
|
||||
```properties [.env]
|
||||
SCHEDULE=15 */6 * * * # every 6 hours
|
||||
API_KEY=base64:zihejehkj8_nzhY/OjeieR= # your key
|
||||
PUID=1000
|
||||
GUID=1000
|
||||
PGID=1000
|
||||
PORT=3225 # port to access the web UI
|
||||
```
|
||||
|
||||
@@ -87,7 +87,7 @@ PORT=3225 # port to access the web UI
|
||||
✨ **Tip:** You can configure additional environment variables by referring to the **official documentation**.
|
||||
::
|
||||
|
||||
Deploy the container and go to `http://yourserverip:3225`. Log in with the account `admin@exemple.com` and the password `password`. Don’t forget to change your ID and password once logged in!
|
||||
Deploy the container and go to `http://yourserverip:3225`. Log in with the account `admin@example.com` and the password `password`. Don’t forget to change your ID and password once logged in!
|
||||
|
||||
### Done!
|
||||
::
|
||||
@@ -102,7 +102,7 @@ Now we want to expose Speedtest Tracker to the internet so you can access it rem
|
||||
|
||||
::warning
|
||||
|
||||
Speedtest Tracker does not use multi-factor authentication. Exposing it on the internet could compromise connected devices. Do so only if you use a multi-factor system like [TinyAuth](/serveex/security/tinyauth) or [Authentik](/serveex/advanced/authentik/). Otherwise, avoid using SWAG and prefer a VPN like [Wireguard](/serveex/core/wireguard).
|
||||
Speedtest Tracker does not use multi-factor authentication. Exposing it on the internet could compromise connected devices. Do so only if you use a multi-factor system like [TinyAuth](/serveex/security/tinyauth) or [Authentik](/serveex/advanced/authentik/). Otherwise, avoid using SWAG and prefer a VPN like [WireGuard](/serveex/core/wireguard).
|
||||
::
|
||||
|
||||
::steps{level="3"}
|
||||
|
||||
@@ -182,14 +182,14 @@ Deploy the stack on the remote server. Data will begin flowing into the web UI a
|
||||
__If it fails:__ check your firewall rules.
|
||||
::
|
||||
|
||||
## Expose Beszel with Swag
|
||||
## Expose Beszel with SWAG
|
||||
|
||||
::warning
|
||||
|
||||
Beszel does not support multi-factor authentication. Exposing it on the internet could compromise connected machines. Only do this if you're using a system like [TinyAuth](/serveex/security/tinyauth) or [Authentik](/serveex/advanced/authentik/). Otherwise, do not expose with SWAG. Use a VPN like [Wireguard](/serveex/core/wireguard) instead.
|
||||
Beszel does not support multi-factor authentication. Exposing it on the internet could compromise connected machines. Only do this if you're using a system like [TinyAuth](/serveex/security/tinyauth) or [Authentik](/serveex/advanced/authentik/). Otherwise, do not expose with SWAG. Use a VPN like [WireGuard](/serveex/core/wireguard) instead.
|
||||
::
|
||||
|
||||
If you want to access Beszel remotely from all your devices, expose it using Swag.
|
||||
If you want to access Beszel remotely from all your devices, expose it using SWAG.
|
||||
|
||||
::note{icon="" to="/general/networking/nat"}
|
||||
📋 __Prerequisite:__
|
||||
@@ -200,7 +200,7 @@ You must have created a DNS subdomain like `beszel.mydomain.com` with a `CNAME`
|
||||
::steps{level="3"}
|
||||
### Add Beszel's network to SWAG
|
||||
|
||||
In Dockge, edit Swag's compose file and add Beszel’s network:
|
||||
In Dockge, edit SWAG's compose file and add Beszel’s network:
|
||||
|
||||
```yaml [compose.yaml]
|
||||
---
|
||||
@@ -219,16 +219,16 @@ networks:
|
||||
external: true
|
||||
```
|
||||
|
||||
Redeploy the stack and wait for Swag to become fully operational.
|
||||
Redeploy the stack and wait for SWAG to become fully operational.
|
||||
|
||||
::note
|
||||
|
||||
We assume the network name is `beszel_default`. You can check connectivity by visiting Swag's dashboard at `http://yourserverip:81`.
|
||||
We assume the network name is `beszel_default`. You can check connectivity by visiting SWAG's dashboard at `http://yourserverip:81`.
|
||||
::
|
||||
|
||||
### Create the subdomain.conf file
|
||||
|
||||
In Swag’s config folders, create `beszel.subdomain.conf`.
|
||||
In SWAG’s config folders, create `beszel.subdomain.conf`.
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
✨ __Tip:__ Use **File Browser Quantum** to browse and edit files instead of terminal commands.
|
||||
|
||||
@@ -8,7 +8,7 @@ description: Install UpSnap to remotely wake up machines on your local network v
|
||||
|
||||
[UpSnap](https://github.com/seriousm4x/UpSnap) is a container that allows you to remotely power on, shut down, or put your machines to sleep. It mainly uses Wake-On-Lan (WoL) over the network and offers advanced features.
|
||||
|
||||

|
||||

|
||||
|
||||
## Installation
|
||||
|
||||
@@ -85,14 +85,14 @@ Deploy the container and go to `http://yourserverip:8095`. Just follow the steps
|
||||
__If it fails:__ check your firewall rules.
|
||||
::
|
||||
|
||||
## Exposing UpSnap with Swag
|
||||
## Exposing UpSnap with SWAG
|
||||
|
||||
::warning
|
||||
|
||||
UpSnap does not support multi-factor authentication. Exposing it on the internet could compromise connected machines. Do this only if you're using a multi-factor authentication system like [TinyAuth](/serveex/security/tinyauth) or [Authentik](/serveex/advanced/authentik/). Otherwise, avoid exposing it with SWAG and use a VPN like [Wireguard](/serveex/core/wireguard) instead.
|
||||
UpSnap does not support multi-factor authentication. Exposing it on the internet could compromise connected machines. Do this only if you're using a multi-factor authentication system like [TinyAuth](/serveex/security/tinyauth) or [Authentik](/serveex/advanced/authentik/). Otherwise, avoid exposing it with SWAG and use a VPN like [WireGuard](/serveex/core/wireguard) instead.
|
||||
::
|
||||
|
||||
You may want to access it remotely from all your devices. To do so, we'll expose UpSnap via Swag.
|
||||
You may want to access it remotely from all your devices. To do so, we'll expose UpSnap via SWAG.
|
||||
|
||||
::note{icon=""}
|
||||
📋 __Beforehand:__
|
||||
@@ -101,9 +101,9 @@ We assume you've created a subdomain in your [DNS zone](/general/networking/dns)
|
||||
::
|
||||
|
||||
::steps{level="3"}
|
||||
### Add UpSnap's network to SWAG
|
||||
### Make the host reachable from SWAG
|
||||
|
||||
Go to Dockge, and edit the SWAG compose by adding the UpSnap network:
|
||||
UpSnap runs with `network_mode: host` (needed for Wake-on-LAN broadcasts and network scanning to work reliably), so it never joins a Docker network SWAG could attach to like other stacks. Instead, give SWAG a way to reach the host itself:
|
||||
|
||||
```yaml [compose.yaml]
|
||||
---
|
||||
@@ -111,27 +111,20 @@ services:
|
||||
swag:
|
||||
container_name: # ...
|
||||
# ...
|
||||
networks: # Connects the container to the custom network
|
||||
# ...
|
||||
- upsnap # Network name declared in the stack
|
||||
|
||||
networks: # Defines the custom network
|
||||
# ...
|
||||
upsnap: # Network name declared in the stack
|
||||
name: upsnap_default # Actual name of the external network
|
||||
external: true # Indicates it's an external network
|
||||
extra_hosts:
|
||||
- "host.docker.internal:host-gateway" # resolves to the Docker host's own IP
|
||||
```
|
||||
|
||||
Restart the stack by clicking "deploy" and wait for SWAG to be fully operational.
|
||||
|
||||
::note
|
||||
|
||||
Here we assume the network name for upsnap is `upsnap_default`. You can check the connection in the SWAG dashboard at `http://yourserverip:81`.
|
||||
`host-gateway` is a special value Docker resolves to the host machine's IP automatically, so this works regardless of your server's actual address.
|
||||
::
|
||||
|
||||
### Create the subdomain.conf file
|
||||
|
||||
In the Swag folders, create the file `upsnap.subdomain.conf`.
|
||||
In the SWAG folders, create the file `upsnap.subdomain.conf`.
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
✨ __Tip:__ You can use **File Browser Quantum** to navigate your files and edit documents instead of using terminal commands.
|
||||
@@ -184,7 +177,7 @@ server {
|
||||
|
||||
include /config/nginx/proxy.conf;
|
||||
include /config/nginx/resolver.conf;
|
||||
set $upstream_app upsnap;
|
||||
set $upstream_app host.docker.internal;
|
||||
set $upstream_port 8095;
|
||||
set $upstream_proto http;
|
||||
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
|
||||
@@ -262,7 +255,7 @@ server {
|
||||
|
||||
include /config/nginx/proxy.conf;
|
||||
include /config/nginx/resolver.conf;
|
||||
set $upstream_app upsnap;
|
||||
set $upstream_app host.docker.internal;
|
||||
set $upstream_port 8095;
|
||||
set $upstream_proto http;
|
||||
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
|
||||
|
||||
@@ -16,7 +16,7 @@ As always, we'll use the [linuxserver.io image](https://docs.linuxserver.io/imag
|
||||
|
||||
::note{to="/serveex/core/wireguard"}
|
||||
|
||||
Unlike Plex, Jellyfin has no cloud relay: to access your server outside your local network, you must expose it yourself (see below), or use a VPN like **Wireguard**.
|
||||
Unlike Plex, Jellyfin has no cloud relay: to access your server outside your local network, you must expose it yourself (see below), or use a VPN like **WireGuard**.
|
||||
::
|
||||
|
||||
## Install Jellyfin
|
||||
@@ -44,7 +44,7 @@ tree:
|
||||
Create the `movies`, `tvseries`, and `library` folders in `/media`:
|
||||
|
||||
```bash [Terminal]
|
||||
mkdir -p /media/movies /media/library /media/tvseries
|
||||
mkdir -p /media/movies /media/tvseries /media/library
|
||||
```
|
||||
|
||||
### Deploy the stack
|
||||
@@ -59,7 +59,7 @@ services:
|
||||
container_name: jellyfin
|
||||
environment:
|
||||
- PUID=${PUID}
|
||||
- PGID=${GUID}
|
||||
- PGID=${PGID}
|
||||
- TZ=Europe/Paris
|
||||
volumes:
|
||||
- /srv/docker/jellyfin/config:/config
|
||||
@@ -86,7 +86,7 @@ services:
|
||||
|
||||
### Set your environment variables
|
||||
|
||||
Find your PUID and GUID by running:
|
||||
Find your PUID and PGID by running:
|
||||
|
||||
```bash [Terminal]
|
||||
id username
|
||||
@@ -96,7 +96,7 @@ Fill in your `.env` file with the retrieved values, for example:
|
||||
|
||||
```properties [.env]
|
||||
PUID=1000
|
||||
GUID=1000
|
||||
PGID=1000
|
||||
```
|
||||
|
||||
Deploy the stack. The local interface is available at `http://yourserverip:8096`.
|
||||
|
||||
@@ -1,24 +1,24 @@
|
||||
---
|
||||
title: Qbittorrent
|
||||
title: qBittorrent
|
||||
description: Install qBittorrent with Gluetun and ProtonVPN to download torrents securely behind a VPN on your self-hosted server.
|
||||
---
|
||||
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
|
||||

|
||||

|
||||
|
||||
To safely download your favorite media, we'll build a system using:
|
||||
|
||||
- [Qbittorrent](https://github.com/linuxserver/docker-qbittorrent) as the BitTorrent client
|
||||
- [qBittorrent](https://github.com/linuxserver/docker-qbittorrent) as the BitTorrent client
|
||||
- [Proton VPN Plus](https://protonvpn.com/torrenting), a VPN to secure your traffic. You need a subscription (promos available) to access the BitTorrent protocol. You can also use another VPN as long as it supports BitTorrent.
|
||||
- [Gluetun](https://github.com/qdm12/gluetun)
|
||||
- [Qbittorrent port update](https://codeberg.org/TechnoSam/qbittorrent-gluetun-port-update) to automatically update the VPN port (which changes regularly).
|
||||
- [qBittorrent port update](https://codeberg.org/TechnoSam/qbittorrent-gluetun-port-update) to automatically update the VPN port (which changes regularly).
|
||||
- The [VueTorrent](https://github.com/gabe565/linuxserver-mod-vuetorrent) mod for a modern and intuitive UI.
|
||||
|
||||
Here’s the system we’ll set up:
|
||||
|
||||

|
||||

|
||||
|
||||
## Configuration
|
||||
|
||||
@@ -34,7 +34,7 @@ tree:
|
||||
- gluetun/
|
||||
- compose.yaml
|
||||
- .env
|
||||
- "media # linked to Jellyfin and Qbittorrent":
|
||||
- "media # linked to Jellyfin and qBittorrent":
|
||||
- "downloads/ # generic downloads, selected in settings"
|
||||
- "movies/ # used for downloading movies"
|
||||
- "tvseries/ # used for downloading TV shows"
|
||||
@@ -47,7 +47,7 @@ tree:
|
||||
If not already done, create the `downloads` folder under `/media`:
|
||||
|
||||
```bash [Terminal]
|
||||
mkdir -P /media/downloads
|
||||
mkdir -p /media/downloads
|
||||
```
|
||||
|
||||
### Deploy the stack
|
||||
@@ -67,7 +67,7 @@ services:
|
||||
- DOCKER_MODS=ghcr.io/gabe565/linuxserver-mod-vuetorrent|ghcr.io/t-anc/gsp-qbittorent-gluetun-sync-port-mod:main
|
||||
- TZ=Europe/Paris
|
||||
- PUID=${PUID}
|
||||
- PGID=${GUID}
|
||||
- PGID=${PGID}
|
||||
- WEBUI_PORT=${UI_PORT}
|
||||
- GSP_GTN_API_KEY=${GSP_KEY}
|
||||
- GSP_QBT_USERNAME=${ID}
|
||||
@@ -88,7 +88,7 @@ services:
|
||||
devices:
|
||||
- /dev/net/tun:/dev/net/tun
|
||||
ports:
|
||||
- ${UI_PORT}:5695 # Port de la web-ui
|
||||
- ${UI_PORT}:${UI_PORT} # Port de la web-ui
|
||||
- 8000:8000 # Port de controle de Gluetun
|
||||
cap_add:
|
||||
- NET_ADMIN
|
||||
@@ -122,7 +122,7 @@ services:
|
||||
|
||||
### Configure the download port update
|
||||
|
||||
Before editing the `.env` in Dockge, let's configure the download port update. Proton and most VPNs rotate the forwarding port, which must be communicated to Qbittorrent.
|
||||
Before editing the `.env` in Dockge, let's configure the download port update. Proton and most VPNs rotate the forwarding port, which must be communicated to qBittorrent.
|
||||
|
||||
We’ve added the mod `ghcr.io/t-anc/gsp-qbittorent-gluetun-sync-port-mod` to the container.
|
||||
|
||||
@@ -164,7 +164,7 @@ In Dockge, fill in the variables in `.env`:
|
||||
|
||||
```properties [.env]
|
||||
PUID=
|
||||
GUID=
|
||||
PGID=
|
||||
UI_PORT=
|
||||
PR_KEY=
|
||||
GSP_KEY= # the key you generated and entered in config.toml
|
||||
@@ -177,12 +177,12 @@ Detailed info:
|
||||
| Variable | Description | Example |
|
||||
|------------|-------------|---------|
|
||||
| `PUID` | User ID (`id yourusername`) | `1000` |
|
||||
| `GUID` | Group ID (`id yourusername`) | `1000` |
|
||||
| `PGID` | Group ID (`id yourusername`) | `1000` |
|
||||
| `UI_PORT` | Port for accessing the web UI | `5695` |
|
||||
| `PR_KEY` | Private key from Proton | `buKsjNHLyzKMM1qYnzOy4s7SHfly` |
|
||||
| `GSP_KEY` | Key you generated for port update | `MnBa47MeVmk7xiv` |
|
||||
| `ID` | Qbittorrent UI login username | `user` |
|
||||
| `PW` | Qbittorrent UI password | `password` |
|
||||
| `ID` | qBittorrent UI login username | `user` |
|
||||
| `PW` | qBittorrent UI password | `password` |
|
||||
|
||||
### Done!
|
||||
::
|
||||
@@ -194,7 +194,7 @@ Detailed info:
|
||||
|
||||
Once done, deploy the container.
|
||||
|
||||
::note{to="/serveex/core/docker/#dockge"}
|
||||
::note{to="/serveex/core/docker#install-dockge-to-manage-and-deploy-containers"}
|
||||
|
||||
**Startup logs will show a temporary password for `admin` user.**
|
||||
See logs in **Dockge** to retrieve it, or type this command in a terminal:
|
||||
@@ -217,7 +217,7 @@ Change your username and password in the "webui" settings.
|
||||
### Done!
|
||||
::
|
||||
|
||||
You're done! In Qbittorrent settings, under "Downloads", set `/media/downloads` as the default folder.
|
||||
You're done! In qBittorrent settings, under "Downloads", set `/media/downloads` as the default folder.
|
||||
|
||||
When adding a download, remember to select the proper directory so Jellyfin can sync correctly (`/media/movies` or `/media/tvseries`). You can also automate this with categories and folders.
|
||||
|
||||
@@ -225,10 +225,10 @@ When adding a download, remember to select the proper directory so Jellyfin can
|
||||
|
||||
::warning
|
||||
|
||||
Qbittorrent does not support multi-factor authentication. Exposing it to the internet may put your system at risk. Only do this if you use MFA via [TinyAuth](/serveex/security/tinyauth) or [Authentik](/serveex/advanced/authentik/). Otherwise, don’t expose it with SWAG. Use a VPN like [Wireguard](/serveex/core/wireguard) instead.
|
||||
qBittorrent does not support multi-factor authentication. Exposing it to the internet may put your system at risk. Only do this if you use MFA via [TinyAuth](/serveex/security/tinyauth) or [Authentik](/serveex/advanced/authentik/). Otherwise, don’t expose it with SWAG. Use a VPN like [WireGuard](/serveex/core/wireguard) instead.
|
||||
::
|
||||
|
||||
To start downloads from outside your home, without a VPN, you can expose the Qbittorrent web UI.
|
||||
To start downloads from outside your home, without a VPN, you can expose the qBittorrent web UI.
|
||||
|
||||
::note
|
||||
|
||||
@@ -321,7 +321,7 @@ server {
|
||||
include /config/nginx/proxy.conf;
|
||||
include /config/nginx/resolver.conf;
|
||||
set $upstream_app gluetun;
|
||||
set $upstream_port 5555;
|
||||
set $upstream_port 5695;
|
||||
set $upstream_proto http;
|
||||
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
|
||||
|
||||
@@ -334,9 +334,9 @@ Press :kbd{value="Ctrl+O"}, then :kbd{value="Enter"} to save, and :kbd{value="Ct
|
||||
### Done!
|
||||
::
|
||||
|
||||
Wait a few minutes, then go to `https://seedbox.mydomain.com`. You should land on the Qbittorrent interface.
|
||||
Wait a few minutes, then go to `https://seedbox.mydomain.com`. You should land on the qBittorrent interface.
|
||||
|
||||
## Protecting Qbittorrent with TinyAuth
|
||||
## Protecting qBittorrent with TinyAuth
|
||||
Add [TinyAuth](/serveex/security/tinyauth)'s forward-auth check directly to `seedbox.subdomain.conf`, the same way as [the TinyAuth guide](/serveex/security/tinyauth#protecting-an-app-via-reverse-proxy):
|
||||
|
||||
```nginx [seedbox.subdomain.conf]{26-38,41-42}
|
||||
@@ -399,7 +399,7 @@ server {
|
||||
include /config/nginx/proxy.conf;
|
||||
include /config/nginx/resolver.conf;
|
||||
set $upstream_app gluetun;
|
||||
set $upstream_port 5555;
|
||||
set $upstream_port 5695;
|
||||
set $upstream_proto http;
|
||||
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
|
||||
|
||||
@@ -418,4 +418,4 @@ The `location /tinyauth` block runs inside SWAG's own container, so SWAG needs t
|
||||
|
||||
And that’s it! You now have a ready-to-use media center.
|
||||
|
||||

|
||||

|
||||
|
||||
@@ -49,7 +49,7 @@ tree:
|
||||
|
||||
::warning
|
||||
|
||||
__Warning:__ Make sure to follow this file structure carefully, especially the `media` folder. This folder must be mounted **exactly the same way** in both the _Qbittorrent_ compose file (`/your/path/media:/media`) and the _arr_ applications. If not, the _arr_ apps may not recognize the path provided by Qbittorrent and will fail to create _hardlinks_. Without hardlinks, the _arr_ apps will copy the files instead, **doubling the space used** on your storage.
|
||||
__Warning:__ Make sure to follow this file structure carefully, especially the `media` folder. This folder must be mounted **exactly the same way** in both the _Qbittorrent_ compose file (`/your/path/media:/media`) and the _arr_ applications. If not, the _arr_ apps may not recognize the path provided by qBittorrent and will fail to create _hardlinks_. Without hardlinks, the _arr_ apps will copy the files instead, **doubling the space used** on your storage.
|
||||
::
|
||||
|
||||
::steps{level="3"}
|
||||
@@ -133,8 +133,8 @@ services:
|
||||
container_name: bazarr
|
||||
restart: unless-stopped
|
||||
environment:
|
||||
- PUID=1000
|
||||
- PGID=1000
|
||||
- PUID=${PUID}
|
||||
- PGID=${PGID}
|
||||
- TZ=Europe/Paris
|
||||
volumes:
|
||||
- /srv/docker/bazarr/config:/config
|
||||
@@ -170,7 +170,7 @@ MEDIA_PATH=
|
||||
|----------------|-------------------------------------------------------------------------------------------------|-------------|
|
||||
| `PUID` | Set using your user info (check with `id yourusername`) | `1000` |
|
||||
| `PGID` | Same as above | `1000` |
|
||||
| `MEDIA_PATH` | Path to your media folder, here: `/media`. It must match the one used by Qbittorrent. | `/media` |
|
||||
| `MEDIA_PATH` | Path to your media folder, here: `/media`. It must match the one used by qBittorrent. | `/media` |
|
||||
|
||||
::note
|
||||
|
||||
@@ -207,7 +207,7 @@ Create an account and choose *forms login*.
|
||||
|
||||
::warning
|
||||
|
||||
__Warning:__ If you already have movies in `movies` from Qbittorrent, do not let Radarr add them. Radarr might modify them, which could stop seeding in Qbittorrent.
|
||||
__Warning:__ If you already have movies in `movies` from qBittorrent, do not let Radarr add them. Radarr might modify them, which could stop seeding in qBittorrent.
|
||||
::
|
||||
|
||||
#### Configure Profiles
|
||||
@@ -216,12 +216,12 @@ Go to *Settings > Profiles*. These are your default quality profiles. When you m
|
||||
|
||||

|
||||
|
||||
#### Add Qbittorrent
|
||||
#### Add qBittorrent
|
||||
|
||||
In *Settings > Download Clients*, add Qbittorrent.
|
||||
In *Settings > Download Clients*, add qBittorrent.
|
||||
|
||||
- Use your server IP as *Host* and port `5695` if following this guide.
|
||||
- Provide your Qbittorrent *Username* and *Password*.
|
||||
- Provide your qBittorrent *Username* and *Password*.
|
||||
- Click *Test*.
|
||||
- If successful, click *Save*.
|
||||
|
||||
@@ -389,12 +389,12 @@ It can be useful to expose Seerr if you want to send requests from outside your
|
||||
|
||||
::warning
|
||||
|
||||
Seerr has no built-in two-factor authentication. Only expose it if you're using a secure authentication solution like [TinyAuth](/serveex/security/tinyauth) or [Authentik](/serveex/advanced/authentik). Otherwise, don't expose it with SWAG, use a VPN like [Wireguard](/serveex/core/wireguard) instead.
|
||||
Seerr has no built-in two-factor authentication. Only expose it if you're using a secure authentication solution like [TinyAuth](/serveex/security/tinyauth) or [Authentik](/serveex/advanced/authentik). Otherwise, don't expose it with SWAG, use a VPN like [WireGuard](/serveex/core/wireguard) instead.
|
||||
::
|
||||
|
||||
::note
|
||||
|
||||
We assume you have the subdomain `films.mydomain.com` with a `CNAME` pointing to `films.fr` in your [DNS zone](/general/networking/dns). And that [unless you’re using Cloudflare Zero Trust](/serveex/security/cloudflare), port `443` on your router is forwarded to port `443` on your server via [NAT rules](/general/networking/nat).
|
||||
We assume you have the subdomain `films.mydomain.com` with a `CNAME` pointing to `mydomain.com` in your [DNS zone](/general/networking/dns). And that [unless you’re using Cloudflare Zero Trust](/serveex/security/cloudflare), port `443` on your router is forwarded to port `443` on your server via [NAT rules](/general/networking/nat).
|
||||
::
|
||||
|
||||
::steps{level="3"}
|
||||
|
||||
@@ -8,7 +8,7 @@ description: Install Immich, a self-hosted alternative to Google Photos and iClo
|
||||
|
||||
[Immich](https://immich.app/docs/overview/introduction) is a self-hosted photo and video management solution that replaces cloud services like Google Photos or iCloud. It offers powerful features like face recognition and geolocation.
|
||||
|
||||

|
||||

|
||||
|
||||
## Installation
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ description: Install Nextcloud to self-host your files, photos, and calendar, a
|
||||
|
||||
[Nextcloud](https://nextcloud.com/) is a self-hosted solution that allows you to access and synchronize your data across all your devices. It also includes collaboration features, calendar, and more. It’s a great alternative to services like Google Drive, iCloud, or OneDrive.
|
||||
|
||||

|
||||

|
||||
|
||||
## Installation
|
||||
::note{to="https://docs.linuxserver.io/images/docker-nextcloud/"}
|
||||
@@ -43,7 +43,7 @@ services:
|
||||
container_name: nextcloud
|
||||
environment:
|
||||
- PUID=${PUID}
|
||||
- PGID=${GUID}
|
||||
- PGID=${PGID}
|
||||
- TZ=Etc/UTC
|
||||
volumes:
|
||||
- /srv/docker/nextcloud/config:/config
|
||||
@@ -60,7 +60,7 @@ If you’re using a NAS or network-shared drive via **Samba**, replace `/srv/doc
|
||||
|
||||
### Set your environment variables
|
||||
|
||||
Find your `PUID` and `GUID` by running the following command:
|
||||
Find your `PUID` and `PGID` by running the following command:
|
||||
|
||||
```bash [Terminal]
|
||||
id username
|
||||
@@ -70,7 +70,7 @@ Then fill out the `.env` file with your preferred port and the values found abov
|
||||
|
||||
```properties [.env]
|
||||
PUID=1000
|
||||
GUID=1000
|
||||
PGID=1000
|
||||
PORT=4545
|
||||
```
|
||||
|
||||
@@ -84,8 +84,8 @@ Deploy the stack and visit `http://yourserverip:4545` to complete the setup.
|
||||
__If it fails:__ check your firewall rules.
|
||||
::
|
||||
|
||||
## Exposing Nextcloud with Swag
|
||||
The goal of this setup is to access Nextcloud remotely from all your devices. We’ll use Swag to expose the app.
|
||||
## Exposing Nextcloud with SWAG
|
||||
The goal of this setup is to access Nextcloud remotely from all your devices. We’ll use SWAG to expose the app.
|
||||
|
||||
::note
|
||||
|
||||
@@ -155,7 +155,7 @@ Press :kbd{value="Ctrl+O"}, then :kbd{value="Enter"} to save, and :kbd{value="Ct
|
||||
|
||||
### Create the subdomain.conf file
|
||||
|
||||
In Swag’s folders, create the file `nextcloud.subdomain.conf`:
|
||||
In SWAG’s folders, create the file `nextcloud.subdomain.conf`:
|
||||
|
||||
```bash [Terminal]
|
||||
sudo nano /srv/docker/swag/config/nginx/proxy-confs/nextcloud.subdomain.conf
|
||||
|
||||
@@ -89,7 +89,6 @@ Mount every folder you listed under `sources` in `config.yaml` at the same path
|
||||
filebrowser-quantum:
|
||||
#...
|
||||
labels:
|
||||
|
||||
- com.centurylinklabs.watchtower.enable=true
|
||||
```
|
||||
::
|
||||
@@ -104,14 +103,14 @@ Deploy the container and go to `http://yourserverip:8020`. Log in with the defau
|
||||
__If it doesn't work:__ check your firewall rules.
|
||||
::
|
||||
|
||||
## Exposing File Browser Quantum with Swag
|
||||
## Exposing File Browser Quantum with SWAG
|
||||
|
||||
::warning
|
||||
|
||||
File Browser Quantum does not support multi-factor authentication. Exposing it publicly could put your systems at risk. Only do this if you're using a secure authentication solution like [TinyAuth](/serveex/security/tinyauth) or [Authentik](/serveex/advanced/authentik/). Otherwise, don't expose it with SWAG. Use a VPN like [Wireguard](/serveex/core/wireguard) instead.
|
||||
File Browser Quantum does not support multi-factor authentication. Exposing it publicly could put your systems at risk. Only do this if you're using a secure authentication solution like [TinyAuth](/serveex/security/tinyauth) or [Authentik](/serveex/advanced/authentik/). Otherwise, don't expose it with SWAG. Use a VPN like [WireGuard](/serveex/core/wireguard) instead.
|
||||
::
|
||||
|
||||
You may want to access File Browser Quantum remotely from all your devices. To do that, we'll expose it through Swag.
|
||||
You may want to access File Browser Quantum remotely from all your devices. To do that, we'll expose it through SWAG.
|
||||
|
||||
::note{icon=""}
|
||||
|
||||
@@ -149,7 +148,7 @@ Restart the stack by clicking "deploy" and wait for SWAG to fully initialize.
|
||||
|
||||
### Create the subdomain.conf file
|
||||
|
||||
In the Swag folders, create the file `fbq.subdomain.conf`.
|
||||
In the SWAG folders, create the file `fbq.subdomain.conf`.
|
||||
|
||||
```bash [Terminal]
|
||||
sudo nano /srv/docker/swag/config/nginx/proxy-confs/fbq.subdomain.conf
|
||||
|
||||
@@ -8,7 +8,7 @@ description: Install Pingvin Share, a self-hosted file sharing platform to send
|
||||
|
||||
[Pingvin](https://github.com/stonith404/pingvin-share) is a tool for quickly sharing files, similar to WeTransfer. Its many sharing options (password, expiration time, custom link, etc.) make it the ideal tool for sharing files quickly. Pingvin can also create _upload requests_, i.e. a shareable link you can send to someone so they can upload their files for you to retrieve.
|
||||
|
||||

|
||||

|
||||
|
||||
## Installation
|
||||
|
||||
@@ -42,7 +42,7 @@ services:
|
||||
```
|
||||
::note
|
||||
|
||||
From here on, we assume the network name for Swag is `swag_default`.
|
||||
From here on, we assume the network name for SWAG is `swag_default`.
|
||||
::
|
||||
|
||||
::tip{icon=""}
|
||||
@@ -53,13 +53,11 @@ From here on, we assume the network name for Swag is `swag_default`.
|
||||
pingvin-share:
|
||||
#...
|
||||
labels:
|
||||
|
||||
- com.centurylinklabs.watchtower.enable=true
|
||||
|
||||
clamav:
|
||||
#...
|
||||
labels:
|
||||
|
||||
- com.centurylinklabs.watchtower.enable=true
|
||||
```
|
||||
::
|
||||
@@ -74,8 +72,8 @@ Deploy the container and go to `http://yourserverip:3600`. That's it! Your Pingv
|
||||
__If it fails:__ check your firewall rules.
|
||||
::
|
||||
|
||||
## Exposing Pingvin with Swag
|
||||
The whole point of a solution like this is being able to access it remotely, from all your devices. To do this, we'll expose Pingvin through Swag.
|
||||
## Exposing Pingvin with SWAG
|
||||
The whole point of a solution like this is being able to access it remotely, from all your devices. To do this, we'll expose Pingvin through SWAG.
|
||||
|
||||
::note{icon=""}
|
||||
📋 __Prerequisite:__ <br/><br/>
|
||||
@@ -113,7 +111,7 @@ Redeploy the stack by clicking "deploy" and wait for SWAG to be fully up.
|
||||
|
||||
### Create the subdomain.conf file
|
||||
|
||||
In the Swag folders, create the `pingvin.subdomain.conf` file.
|
||||
In the SWAG folders, create the `pingvin.subdomain.conf` file.
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
|
||||
@@ -224,15 +222,15 @@ In your Authentik admin area, create an OAuth2/OpenID provider.
|
||||
|
||||
Fill in each section as follows, replacing `mydomain.com` with your own domain. Copy the `Client ID` and `Client Secret` fields somewhere safe.
|
||||
|
||||

|
||||

|
||||

|
||||

|
||||

|
||||

|
||||
|
||||
#### Create the application
|
||||
|
||||
Save and create a `pingvin` application as follows.
|
||||
|
||||

|
||||

|
||||
|
||||
#### Add the provider to your outpost
|
||||
|
||||
|
||||
@@ -43,7 +43,7 @@ services:
|
||||
container_name: code-server
|
||||
environment:
|
||||
- PUID=${PUID}
|
||||
- PGID=${GUID}
|
||||
- PGID=${PGID}
|
||||
- TZ=Etc/UTC
|
||||
- HASHED_PASSWORD=${PW}
|
||||
volumes:
|
||||
@@ -63,7 +63,6 @@ services:
|
||||
code-server:
|
||||
#...
|
||||
labels:
|
||||
|
||||
- com.centurylinklabs.watchtower.enable=true
|
||||
```
|
||||
::
|
||||
@@ -76,7 +75,7 @@ Choose a password and generate its hash:
|
||||
echo -n "yourpassword" | npx argon2-cli -e
|
||||
```
|
||||
|
||||
Save the result carefully. Find your PUID and GUID with:
|
||||
Save the result carefully. Find your PUID and PGID with:
|
||||
|
||||
```bash [Terminal]
|
||||
id yourusername
|
||||
@@ -87,7 +86,7 @@ Fill in the `.env` file with the values you found, for example:
|
||||
```properties [.env]
|
||||
PW='$argon2i$v=19$m=4096,t=3,p=1$wST5QhBgk2lu1ih4DMuxvg$LS1alrVdIWtvZHwnzCM1DUGg+5DTO3Dt1d5v9XtLws4'
|
||||
PUID=1000
|
||||
GUID=1000
|
||||
PGID=1000
|
||||
```
|
||||
|
||||
::warning
|
||||
@@ -118,8 +117,8 @@ services:
|
||||
```
|
||||
Once inside VS Code, you'll have access to the mounted folder.
|
||||
|
||||
## Expose code-server with Swag
|
||||
The whole point of such a solution is to access it remotely from any device. To do this, we’ll expose code-server via Swag.
|
||||
## Expose code-server with SWAG
|
||||
The whole point of such a solution is to access it remotely from any device. To do this, we’ll expose code-server via SWAG.
|
||||
|
||||
::note
|
||||
|
||||
@@ -144,7 +143,7 @@ services:
|
||||
networks: # Defines the custom network
|
||||
# ...
|
||||
code-server: # Name of the network defined in the stack
|
||||
name: code-serveur # Actual name of the external network
|
||||
name: code-server_default # Actual name of the external network
|
||||
external: true # Indicates it’s an external network
|
||||
```
|
||||
|
||||
@@ -157,7 +156,7 @@ Redeploy the stack by clicking “deploy” and wait until SWAG is fully operati
|
||||
|
||||
### Create the subdomain.conf file
|
||||
|
||||
Inside the Swag config folders, create the file `code.subdomain.conf`.
|
||||
Inside the SWAG config folders, create the file `code.subdomain.conf`.
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
✨ __Tip:__ You can use **File Browser Quantum** to navigate and edit your files instead of using terminal commands.
|
||||
|
||||
@@ -73,8 +73,8 @@ Deploy the container and go to `http://yourserverip:3333`. Your Forgejo instance
|
||||
__If it fails:__ check your firewall rules.
|
||||
::
|
||||
|
||||
## Exposing Forgejo with Swag
|
||||
The benefit of this setup is being able to access it remotely from any of your devices. To do so, we’ll expose Forgejo through Swag.
|
||||
## Exposing Forgejo with SWAG
|
||||
The benefit of this setup is being able to access it remotely from any of your devices. To do so, we’ll expose Forgejo through SWAG.
|
||||
|
||||
::note
|
||||
|
||||
@@ -112,7 +112,7 @@ Redeploy the stack by clicking "Deploy" and wait until SWAG is fully operational
|
||||
|
||||
### Create the subdomain.conf file
|
||||
|
||||
Inside the Swag folders, create the file `forgejo.subdomain.conf`.
|
||||
Inside the SWAG folders, create the file `forgejo.subdomain.conf`.
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
✨ __Tip:__ You can use **File Browser Quantum** to navigate and edit your files instead of using terminal commands.
|
||||
|
||||
@@ -36,7 +36,6 @@ services:
|
||||
it-tools:
|
||||
#...
|
||||
labels:
|
||||
|
||||
- com.centurylinklabs.watchtower.enable=true
|
||||
```
|
||||
::
|
||||
@@ -51,8 +50,8 @@ Deploy the container and visit `http://yourserverip:3222`. That’s it, your IT
|
||||
__If it fails:__ check your firewall rules.
|
||||
::
|
||||
|
||||
## Expose IT Tools with Swag
|
||||
You might want to access it remotely on all your devices. To do that, we'll expose IT Tools using Swag.
|
||||
## Expose IT Tools with SWAG
|
||||
You might want to access it remotely on all your devices. To do that, we'll expose IT Tools using SWAG.
|
||||
|
||||
::note
|
||||
|
||||
@@ -95,7 +94,7 @@ Restart the stack by clicking "deploy" and wait for SWAG to be fully operational
|
||||
|
||||
### Create the subdomain.conf file
|
||||
|
||||
Inside the Swag folders, create the file `tools.subdomain.conf`.
|
||||
Inside the SWAG folders, create the file `tools.subdomain.conf`.
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
✨ __Tip:__ You can use **File Browser Quantum** to navigate and edit your files instead of using terminal commands.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Adguard Home
|
||||
title: AdGuard Home
|
||||
description: Install AdGuard Home for network-wide ad and tracker blocking with DNS-over-HTTPS, client management, and custom filtering rules.
|
||||
---
|
||||
|
||||
@@ -10,9 +10,9 @@ description: Install AdGuard Home for network-wide ad and tracker blocking with
|
||||
|
||||
It works as a DNS server that redirects tracking domains to a “black hole,” preventing your devices from connecting to them.
|
||||
|
||||
In practice, once it's in place, all you need to do is set your devices to use Adguard as their DNS server.
|
||||
In practice, once it's in place, all you need to do is set your devices to use AdGuard as their DNS server.
|
||||
|
||||

|
||||

|
||||
|
||||
**Quick reminder of how DNS works:**
|
||||
|
||||
@@ -20,14 +20,14 @@ When you visit a site or use an app, it makes requests to various domains to loa
|
||||
|
||||
By default, your device uses your ISP's DNS server, which is usually configured in your router or, for mobile devices, at the carrier’s CGNAT level. You can change this in your browser settings, your device’s system settings, or even directly in your router, depending on your ISP.
|
||||
|
||||
Adguard will act as a middleman between your device and the upstream DNS servers. If you configure your devices to use Adguard:
|
||||
AdGuard will act as a middleman between your device and the upstream DNS servers. If you configure your devices to use AdGuard:
|
||||
|
||||
- If the domain is not in a blocklist, Adguard queries the upstream DNS servers and returns the correct IP to your device.
|
||||
- If the domain *is* in a blocklist, Adguard will block the request and return nothing, so the associated content won’t load.
|
||||
- If the domain is not in a blocklist, AdGuard queries the upstream DNS servers and returns the correct IP to your device.
|
||||
- If the domain *is* in a blocklist, AdGuard will block the request and return nothing, so the associated content won’t load.
|
||||
|
||||
This is how ads and malicious domains are blocked: Adguard blocks only the bad domains, allowing the rest of the page to load normally.
|
||||
This is how ads and malicious domains are blocked: AdGuard blocks only the bad domains, allowing the rest of the page to load normally.
|
||||
|
||||

|
||||

|
||||
|
||||
## Installation
|
||||
|
||||
@@ -47,7 +47,7 @@ tree:
|
||||
|
||||
::note
|
||||
|
||||
We will also mount the `/srv/docker/swag/config/etc/letsencrypt` folder to access Swag's SSL certificate.
|
||||
We will also mount the `/srv/docker/swag/config/etc/letsencrypt` folder to access SWAG's SSL certificate.
|
||||
::
|
||||
|
||||
::steps{level="3"}
|
||||
@@ -102,7 +102,7 @@ The setup wizard asks you to pick an admin interface port. Keep it at `3000`: th
|
||||
### Done!
|
||||
::
|
||||
|
||||
That’s it! Adguard is deployed.
|
||||
That’s it! AdGuard is deployed.
|
||||
|
||||
## Exposing AdGuard with SWAG
|
||||
To make AdGuard usable from outside your home network, you need to expose it.
|
||||
@@ -363,7 +363,7 @@ To configure encryption:
|
||||
- Go to _Settings_ then _Encryption_.
|
||||
- Set the options as follows:
|
||||
|
||||

|
||||

|
||||
|
||||
- Below, in the _Certificates_ section, check _Use file path for certificate_
|
||||
- In the input field, enter `/swag-ssl/live/mydomain.com/fullchain.pem`, replacing `mydomain.com` with your actual domain.
|
||||
|
||||
@@ -247,7 +247,7 @@ Press :kbd{value="Ctrl+O"}, then :kbd{value="Enter"} to save, and :kbd{value="Ct
|
||||
### Done!
|
||||
::
|
||||
|
||||
And there you go! Vaultwarden is now exposed! Visit `https://vault.yourdomain.com/admin` to access the admin panel and paste the password you specified when generatique the `ADMIN_TOKEN`. For more information, see the [Bitwarden documentation](https://bitwarden.com/help/).
|
||||
And there you go! Vaultwarden is now exposed! Visit `https://vault.yourdomain.com/admin` to access the admin panel and paste the password you specified when generating the `ADMIN_TOKEN`. For more information, see the [Bitwarden documentation](https://bitwarden.com/help/).
|
||||
|
||||
Don't forget to install Bitwarden browser extensions (they work with Vaultwarden) for [Chrome](https://chromewebstore.google.com/detail/gestionnaire-de-mots-de-p/nngceckbapebfimnlniiiahkandclblb) and [Firefox](https://addons.mozilla.org/fr/firefox/addon/bitwarden-password-manager/), as well as [iOS](https://apps.apple.com/fr/app/bitwarden/id1137397744) and [Android](https://play.google.com/store/apps/details?id=com.x8bit.bitwarden&hl=fr) apps to sync your passwords.
|
||||
|
||||
|
||||
@@ -25,11 +25,11 @@ There are two main modes you should know:
|
||||
|
||||
- The first allows apps with native support for OpenID-compatible SSO to connect directly to Authentik. This is the preferred method, as the app itself decides what’s public and what’s protected.
|
||||
|
||||

|
||||

|
||||
|
||||
- The second method injects Authentik authentication through SWAG before reaching the target service.
|
||||
|
||||

|
||||

|
||||
|
||||
Both modes can be configured on a per-application basis.
|
||||
|
||||
@@ -374,15 +374,15 @@ Why do this when Dockge already has authentication? Because Dockge uses weak HTT
|
||||
- Select _Applications_ then _Create with wizard_
|
||||
- Fill in the fields as shown:
|
||||
|
||||

|
||||

|
||||
|
||||
- At the next step, choose "Forward authentication (single application)" and configure it as shown (flows are important):
|
||||
|
||||

|
||||

|
||||
|
||||
- Next, go to the _Outposts_ menu on the left and edit _authentik Embedded Outpost_:
|
||||
|
||||

|
||||

|
||||
|
||||
- Add the `dockge` application by moving it to the right column and save.
|
||||
|
||||
@@ -414,7 +414,7 @@ Repeat this process for each app you want to protect (unless it has native integ
|
||||
|
||||
Your new architecture looks like this:
|
||||
|
||||

|
||||

|
||||
|
||||
## Protecting a Remote Server Service
|
||||
For a [native application](/serveex/advanced/authentik/#protecting-a-native-app) (via OAuth 2.0 or other), nothing changes.
|
||||
@@ -428,7 +428,7 @@ Prerequisites:
|
||||
- If the app has no native integration, use a compatible reverse proxy. We will use [SWAG](/serveex/core/swag) here.
|
||||
::
|
||||
|
||||
This container will forward requests to your main [Authentik](/serveex/advanced/authentik#authentik) instance over the internet (or your local network). The server will perform checks and respond to the Outpost, which will allow or block access accordingly.
|
||||
This container will forward requests to your main [Authentik](/serveex/advanced/authentik) instance over the internet (or your local network). The server will perform checks and respond to the Outpost, which will allow or block access accordingly.
|
||||
|
||||

|
||||
|
||||
@@ -459,7 +459,6 @@ authentik_host_insecure: false
|
||||
container_image:
|
||||
docker_network: null
|
||||
docker_map_ports: true
|
||||
docker_labels: null
|
||||
```
|
||||
|
||||
Save with :kbd{value="Ctrl+O"}, then :kbd{value="Enter"}, and exit with :kbd{value="Ctrl+X"}.
|
||||
@@ -475,7 +474,7 @@ On your remote machine, use [Dockge](/serveex/core/docker/#install-dockge-to-man
|
||||
If you haven’t installed [Dockge](/serveex/core/docker/#install-dockge-to-manage-and-deploy-containers), create a folder `/srv/docker/authentik-outpost`, or directly via command line:
|
||||
|
||||
```bash [Terminal]
|
||||
sudo mkdir -P /srv/docker/authentik-outpost
|
||||
sudo mkdir -p /srv/docker/authentik-outpost
|
||||
```
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
@@ -492,7 +491,7 @@ Via command line:
|
||||
```bash [Terminal]
|
||||
sudo nano /srv/docker/authentik-outpost/compose.yaml
|
||||
```
|
||||
Paste the following configuration, updating the version in `{AUTHENTIK_TAG:proxy:2024.2.3}`{lang=properties} to match your Authentik server version.
|
||||
Paste the following configuration, updating the version in `ghcr.io/goauthentik/proxy:2026.2`{lang=properties} to match your Authentik server version.
|
||||
|
||||
```yaml [compose.yaml]
|
||||
---
|
||||
@@ -500,7 +499,7 @@ version: "3.5"
|
||||
services:
|
||||
authentik_proxy:
|
||||
container_name: authentik-outpost
|
||||
image: ghcr.io/goauthentik/proxy:2024.2.3
|
||||
image: ghcr.io/goauthentik/proxy:2026.2
|
||||
# Optionally specify which networks the container should be
|
||||
# might be needed to reach the core authentik server
|
||||
restart: unless-stopped
|
||||
|
||||
@@ -155,7 +155,7 @@ The main benefit of this setup is being able to access Arcane remotely from all
|
||||
|
||||
::warning
|
||||
|
||||
Arcane's own local login has no multi-factor authentication. Only expose it if you're using [Pocket ID](/serveex/security/pocket-id) (see below) or [Authentik](/serveex/advanced/authentik) for login. Otherwise, don't expose it with SWAG. Use a VPN like [Wireguard](/serveex/core/wireguard) instead, especially given the level of access Arcane has over your host.
|
||||
Arcane's own local login has no multi-factor authentication. Only expose it if you're using [Pocket ID](/serveex/security/pocket-id) (see below) or [Authentik](/serveex/advanced/authentik) for login. Otherwise, don't expose it with SWAG. Use a VPN like [WireGuard](/serveex/core/wireguard) instead, especially given the level of access Arcane has over your host.
|
||||
::
|
||||
|
||||
::note
|
||||
@@ -194,7 +194,7 @@ Here we assume the Arcane network name is `arcane_default`. You can check the co
|
||||
|
||||
### Create the subdomain.conf file
|
||||
|
||||
In the Swag folders, create the file `arcane.subdomain.conf`:
|
||||
In the SWAG folders, create the file `arcane.subdomain.conf`:
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
✨ __Tip:__ Use **File Browser Quantum** to navigate and edit files instead of using terminal commands.
|
||||
|
||||
@@ -0,0 +1,253 @@
|
||||
---
|
||||
title: Backrest
|
||||
description: Install Backrest, a friendly web UI for restic, and back up your server properly following the 3-2-1 rule, to a local disk, another server, S3, or Backblaze B2.
|
||||
---
|
||||
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
|
||||
Let's be honest for a second: "backup strategy" for most homelabbers means copying a few folders to a USB stick that one time in 2019, then hoping for the best. [Backrest](https://github.com/garethgeorge/backrest) is here to fix that, without making you learn a scary command-line tool first.
|
||||
|
||||
Under the hood, Backrest is a clean web interface on top of [restic](https://restic.net/), a battle-tested, open-source backup engine. Restic does the actual work (encrypting, deduplicating, and shipping your data wherever you tell it to); Backrest gives you buttons and forms instead of a wall of flags to memorize.
|
||||
|
||||

|
||||
|
||||
## The 3-2-1 rule, or why one backup is not a backup
|
||||
|
||||
Before installing anything, let's talk about the rule that actually matters here, because a backup done wrong gives you false confidence, which is worse than no backup at all.
|
||||
|
||||
The **3-2-1 rule** says:
|
||||
|
||||
- **3** copies of your data: the original, plus at least two backups.
|
||||
- **2** different types of storage: not two copies sitting on the same disk, or on two disks in the same machine.
|
||||
- **1** copy offsite: physically somewhere else, not in the same room, house, or building as the original.
|
||||
|
||||
Each number closes a specific failure scenario:
|
||||
|
||||
- Only **1** backup? A single mistake (a bad `rm -rf`, a botched restore, a corrupted file silently copied over the good one) can take out your only safety net at the same time as the original.
|
||||
- Backups on the **same type of storage** (say, a second internal drive in the same server)? A power surge, a firmware bug, or a cheap PSU dying can very well take out every disk in the box at once.
|
||||
- No **offsite** copy? Fire, flood, theft, or "I unplugged the wrong power strip" don't care how many drives you have, if they're all in the same room.
|
||||
|
||||
This is also exactly why [RAID is not a backup](/general/storage/raid): RAID keeps a service running when a disk dies, it does nothing against ransomware encrypting every file it can reach, a fat-fingered delete, or your house catching fire. Backrest, pointed at a destination outside your server, is what actually covers those cases.
|
||||
|
||||
## What Backrest actually backs up, and where
|
||||
|
||||
Two concepts to know before clicking around:
|
||||
|
||||
- A **repository** is the destination: an encrypted, deduplicated storage location. This is your "2" and your "1" from the rule above, an external disk, another server, or cloud storage.
|
||||
- A **plan** is the rule you define: which folders to back up, into which repository, on what schedule, and how many old snapshots to keep around.
|
||||
|
||||
You can have several plans backing up to several repositories at once, which is exactly how you'd build a real 3-2-1 setup: one plan to a local repository for quick restores, another plan to an offsite repository for the "my house is on fire" scenario.
|
||||
|
||||
## Installation
|
||||
|
||||
::file-tree
|
||||
---
|
||||
tree:
|
||||
/:
|
||||
- srv:
|
||||
- docker:
|
||||
- backrest:
|
||||
- data/
|
||||
- config/
|
||||
- cache/
|
||||
- compose.yaml
|
||||
---
|
||||
::
|
||||
|
||||
::steps{level="3"}
|
||||
### Deploy the stack
|
||||
|
||||
Open Dockge, click `compose`, name the stack `backrest`, and paste the following:
|
||||
|
||||
```yaml [compose.yaml]
|
||||
---
|
||||
services:
|
||||
backrest:
|
||||
image: garethgeorge/backrest:latest
|
||||
container_name: backrest
|
||||
restart: unless-stopped
|
||||
ports:
|
||||
- 9898:9898
|
||||
volumes:
|
||||
- ./data:/data
|
||||
- ./config:/config
|
||||
- ./cache:/cache
|
||||
# Whatever you want Backrest to be able to back up has to be
|
||||
# mounted here too: this stack only sees what it's given.
|
||||
- /srv/docker:/userdata/docker:ro
|
||||
- /etc:/userdata/etc:ro
|
||||
- /home:/userdata/home:ro
|
||||
environment:
|
||||
- BACKREST_DATA=/data
|
||||
- BACKREST_CONFIG=/config/config.json
|
||||
- XDG_CACHE_HOME=/cache
|
||||
- TZ=Europe/Paris
|
||||
```
|
||||
|
||||
The `/srv/docker`, `/etc` and `/home` lines above cover what's actually worth an off-site backup on a homelab server, per [folders and partitions](/general/linux/filesystem): `/srv/docker` holds every stack's config and data (databases, uploaded files, Vaultwarden's vault, Pocket ID's users, and so on), `/etc` holds your system configuration (the SSH hardening from the [installation guide](/serveex/core/installation#close-the-door-behind-you), your SWAG `.subdomain.conf` files, systemd units), and `/home` holds your own scripts and notes. All three are mounted read-only, a backup tool has no business writing to what it's backing up.
|
||||
|
||||
What's usually **not** worth it: a big media library or a torrent download folder sitting on a separate data disk. It's often huge, replaceable, and rarely worth paying for cloud storage or SSH bandwidth to protect.
|
||||
|
||||
::tip{icon=""}
|
||||
✨ __Tip:__ Add the Watchtower label to automate updates
|
||||
```yaml [compose.yaml]
|
||||
services:
|
||||
backrest:
|
||||
#...
|
||||
labels:
|
||||
- com.centurylinklabs.watchtower.enable=true
|
||||
```
|
||||
::
|
||||
|
||||
Deploy the container, then open `http://yourserverip:9898`. The first visit asks you to set an admin username and password: do it immediately, Backrest has no account by default and the setup screen is wide open until you do.
|
||||
|
||||
### Done!
|
||||
::
|
||||
|
||||
## Creating your first repository
|
||||
|
||||

|
||||
|
||||
In Backrest, go to **Add Repo**. The form is split into a few sections, here's what each field actually does:
|
||||
|
||||
- **Repo Name**: whatever helps you recognize it later, `usb-key` or `offsite-vps` for instance. You can't rename it afterwards, so pick something you won't regret.
|
||||
- **Auto Unlock**: leave this off unless you understand what it does. Restic locks a repository while it's working on it, so a second process doesn't corrupt things by writing at the same time. Auto Unlock removes that lock automatically on startup, which is convenient if Backrest crashed mid-backup and left a stale lock behind, but genuinely unsafe if two machines ever write to the same repository at once. For the single-server homelab setup this article covers, it's a minor convenience; leave it off if in doubt.
|
||||
- **Shared**: only relevant to Backrest's multihost feature (several of your machines managing the same repo config). Ignore it for a single server.
|
||||
- **Repository URI**: where the data actually lives. This is the field that changes for every destination below.
|
||||
- **Password**: the encryption password for this repository, click **Generate** for a strong random one. **Save it somewhere outside this server**, a password manager, a note on your phone, anywhere but a text file sitting next to the backups it protects. Lose it, and every single backup becomes an expensive pile of unreadable noise, no exceptions, not even for the developers of restic.
|
||||
- **Env Vars**: where you'll paste credentials for destinations that need them (S3 and B2 below). Local disks and SFTP don't need any.
|
||||
|
||||
::note
|
||||
The **Scheduling**, **Hooks**, and **Advanced** tabs of this form configure repository-wide maintenance (pruning old data, verifying integrity, notifications) rather than anything destination-specific. They're covered at the end of this article, once you've got a repository actually working.
|
||||
::
|
||||
|
||||
### Backing up to a local disk or USB key
|
||||
|
||||
The simplest possible offsite copy is a drive you physically move somewhere else after each backup, or a second machine's disk reached over the network. Either way, from Backrest's point of view it's just a folder, so the setup is identical: plug in the drive (or mount the remote share) on the host, add it to the compose file's volumes the same way you did for `/srv/docker` above, then in the Repository URI field, use the path as it appears **inside the container**:
|
||||
|
||||
```text
|
||||
/userdata/backup-drive
|
||||
```
|
||||
|
||||
That's it, no credentials, no Env Vars. This is the fastest repository to restore from too, since there's no network round-trip involved, which makes it a great pick for your "quick recovery" copy, paired with a proper offsite one below for the "my house is on fire" scenario.
|
||||
|
||||
::caution
|
||||
__If it fails:__ the path has to exist and be writable by the container before you submit the form. An empty folder is fine, restic initializes the repository structure itself on first use.
|
||||
::
|
||||
|
||||
### Backing up to another server
|
||||
|
||||
No cloud account, no problem: if you have SSH access to another machine, a friend's server, a cheap VPS, a Raspberry Pi at a relative's house, that's a perfectly valid offsite repository, and it costs whatever that machine already costs you.
|
||||
|
||||
First, make sure this server can SSH into the other one without typing a password every time:
|
||||
|
||||
```bash [Terminal]
|
||||
ssh-keygen -t ed25519 -f /srv/docker/backrest/config/id_ed25519 -N ""
|
||||
ssh-copy-id -i /srv/docker/backrest/config/id_ed25519.pub youruser@theotherserver
|
||||
```
|
||||
|
||||
Mount that key into the container by adding it to the compose file's volumes:
|
||||
|
||||
```yaml [compose.yaml]
|
||||
volumes:
|
||||
# ...
|
||||
- ./config/id_ed25519:/root/.ssh/id_ed25519:ro
|
||||
```
|
||||
|
||||
Redeploy the stack, then in Backrest use:
|
||||
|
||||
```text
|
||||
sftp:youruser@theotherserver:/path/to/backups
|
||||
```
|
||||
|
||||
::caution
|
||||
__If it fails:__ the target folder (`/path/to/backups` above) has to already exist on the other server, and that user needs write access to it. SSH there once by hand first (`ssh youruser@theotherserver`) to confirm the connection works and accept the host key, Backrest running inside a container won't get the interactive prompt for that.
|
||||
::
|
||||
|
||||
## Advanced: cloud object storage
|
||||
|
||||
A local drive or a friend's spare server covers the 3-2-1 rule perfectly well, and costs nothing beyond what you already own. Cloud object storage is the other classic option, worth it once you want an offsite copy that doesn't depend on anyone's spare hardware staying online, at the cost of a few cents to a few euros a month depending on how much you back up.
|
||||
|
||||
### Backblaze B2
|
||||
|
||||
[Backblaze B2](https://www.backblaze.com/cloud-storage) is object storage built with exactly this use case in mind, and it's usually the cheapest option for the "write often, read rarely" pattern a backup is.
|
||||
|
||||
Create a bucket in your Backblaze account, then generate an **application key** scoped to it. In Backrest, use:
|
||||
|
||||
```text
|
||||
b2:your-bucket-name:backrest
|
||||
```
|
||||
|
||||
With the following Env Vars:
|
||||
|
||||
| Variable | Value |
|
||||
|----------|-------|
|
||||
| `B2_ACCOUNT_ID` | The application key ID |
|
||||
| `B2_ACCOUNT_KEY` | The application key itself |
|
||||
|
||||
### S3-compatible storage
|
||||
|
||||
S3 isn't just an Amazon thing, it's a storage protocol that most cloud providers speak (OVH, Scaleway, MinIO if you self-host your own, and plenty of others), which makes it a solid, portable choice if you'd rather not depend on one specific provider.
|
||||
|
||||
Create a bucket with your provider of choice, then in Backrest's Repository URI field, use:
|
||||
|
||||
```text
|
||||
s3:https://s3.your-provider.com/your-bucket-name/backrest
|
||||
```
|
||||
|
||||
For actual AWS S3, drop the custom endpoint:
|
||||
|
||||
```text
|
||||
s3:s3.amazonaws.com/your-bucket-name/backrest
|
||||
```
|
||||
|
||||
With the following Env Vars:
|
||||
|
||||
| Variable | Value |
|
||||
|----------|-------|
|
||||
| `AWS_ACCESS_KEY_ID` | The access key from your provider |
|
||||
| `AWS_SECRET_ACCESS_KEY` | The secret key from your provider |
|
||||
|
||||
::note
|
||||
Generate these from your provider's dashboard, usually under something like "API keys" or "S3 credentials", scoped to that one bucket only if the provider allows it. There's no reason for a backup job's key to be able to touch anything else on your account.
|
||||
::
|
||||
|
||||
### Repository maintenance (optional, but worth setting up once)
|
||||
|
||||
Back in the **Scheduling** tab, three policies keep a repository healthy over time. None of them are required to start backing up, restic works fine without ever touching them, but they're worth understanding once your repository has been running for a while:
|
||||
|
||||
:::collapsible{name="the three maintenance policies"}
|
||||
- **Prune Policy**: deletes data that's no longer referenced by any snapshot (because old snapshots holding it were forgotten, see the retention policy in the next section). This is the only operation that actually frees up space on your storage. It's slow and reads a lot of data, so schedule it rarely, once a month is Backrest's own suggestion. **Max Unused After Prune** controls how thorough it is: a higher percentage leaves more unused data behind but finishes faster and copies less.
|
||||
- **Check Policy**: verifies your repository isn't silently corrupted. **Read Data %** controls how much of the actual backed-up data gets re-read and checksummed, not just the repository's internal structure. 100% means a full re-read of everything, which uses real bandwidth and time; a smaller percentage checks a random sample instead. Once a month is, again, a reasonable default.
|
||||
- **Forget Policy**: an optional repository-wide retention rule, applied across every plan writing to this repository instead of per-plan. Leave this disabled unless you specifically want one retention policy shared by multiple plans, it disables each plan's own retention policy the moment you turn it on.
|
||||
|
||||
Every one of these has a **Schedule Type**: `Disabled`, a plain `Interval` in hours or days, or a `Cron Expression` for anything more specific, plus a **Reference Clock** (your server's local time, UTC, or relative to the last time it ran) to anchor that schedule against.
|
||||
:::
|
||||
|
||||
## Creating a backup plan
|
||||
|
||||
Back in Backrest, go to **Add Plan**. This form covers what to back up and when, as opposed to the repository form above, which only covers where:
|
||||
|
||||
- **Plan Name**: same rule as the repo name, pick something clear, you can't change it later.
|
||||
- **Repository**: the one you just created above.
|
||||
- **Paths**: click **Add** to add a row, then type in the container-side path for whatever you mounted above, it's a plain text field, but it autocompletes real paths from the container's filesystem as you type, handy to confirm a mount actually landed where you think. `/userdata/docker` for your stacks, `/userdata/etc` for your system config, `/userdata/home` for your own files. Click **Add** again for each additional folder, the small `-` button removes a row you don't need.
|
||||
- **Excludes** and **Excludes (Case Insensitive)**: patterns to skip within those paths, handy for cache folders or anything genuinely disposable that would otherwise bloat every snapshot for no reason.
|
||||
- **Schedule Type**: same three choices as the repository's own schedules above, `Disabled`, an `Interval`, or a `Cron Expression`. A nightly cron like `0 3 * * *` (every day at 3 AM) is a reasonable default for a homelab.
|
||||
- **Retention Policy**: how many snapshots to keep, and for how long. **By Time Period** lets you say "keep 7 daily, 4 weekly, 6 monthly" independently, which gives you plenty of restore points spread over time without the repository growing forever, since restic deduplicates unchanged data between snapshots anyway. **By Count** instead just keeps the last N snapshots regardless of age. **Latest (Count)** on top of either mode guarantees a minimum number of recent snapshots always survive, whatever the rest of the policy says.
|
||||
- **Advanced**: **Backup Flags** let you pass extra options straight to the underlying `restic backup` command for anything this form doesn't expose; **Hooks** run scripts or send notifications on backup events, the same mechanism as the repository's own Hooks tab, just scoped to this one plan instead of every plan using the repository.
|
||||
|
||||
That retention policy is your real defense against ransomware, by the way: if something starts encrypting your files at 2 AM, tonight's backup is compromised, but last week's snapshot isn't, and restic lets you restore from any of them.
|
||||
|
||||
::tip{icon="" to="/nonsense/bash/backrest-docker-stop"}
|
||||
✨ __Going further:__ if some of what you're backing up includes a live database, stopping its container for the few seconds a backup takes is safer than backing it up while it's being written to. See **Backrest Docker Stop** for a script that does exactly that, triggered automatically by Backrest itself.
|
||||
::
|
||||
|
||||
## Restoring a backup
|
||||
A backup you've never tried restoring is a guess, not a plan, so it's worth doing once before you actually need it. Open the plan, click into a snapshot, expand **Snapshot Browser** down to whatever you need, then click the **...** menu next to it and pick **Restore to path**.
|
||||
|
||||
Leave the path field empty and Backrest streams it straight to your browser's downloads instead, the simplest option for grabbing a single file. Type a path and Backrest writes the restored data inside the container at that location instead, and it pre-fills a scratch folder like `/userdata-backrest-restore-<snapshot id>`, deliberately not your original mount.
|
||||
|
||||
That default isn't an accident: `/srv/docker`, `/etc` and `/home` are mounted `:ro`, so restic can't write back into them, restoring straight into `/userdata/docker` fails with a read-only filesystem error. Restore to that suggested scratch path (or download instead), check what you got, then copy the files into their real place yourself with `sudo cp -a`, from the host, outside of Backrest entirely. It's one extra step, but it also means a restore can never silently clobber live data by accident, exactly the caution you want mid-incident.
|
||||
|
||||
And that's it, you now have an actual backup strategy instead of a folder called `backup_final_v2_REAL`.
|
||||
@@ -0,0 +1,169 @@
|
||||
---
|
||||
title: BTRFS Snapshots
|
||||
description: Format Debian's root filesystem with BTRFS and use Snapper to instantly roll back a risky update or config change, as a local complement to Backrest's off-site 3-2-1 backups.
|
||||
---
|
||||
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
|
||||
[BTRFS](https://btrfs.readthedocs.io/) is a Linux filesystem with one killer feature for a homelab: **snapshots**. A snapshot freezes the exact state of a filesystem in an instant, at essentially zero cost, without copying a single byte of data upfront. Break something ten minutes after an `apt full-upgrade`, or overwrite the wrong `.env` file, and you can go back to exactly how things were before, without touching a backup at all.
|
||||
|
||||
This is not what [Backrest and the 3-2-1 rule](/serveex/advanced/backrest) are for, so it's worth being precise about the difference before setting anything up.
|
||||
|
||||
## Snapshots are not backups
|
||||
A snapshot lives on the exact same disk as the data it protects. It's instant, needs no network, and it's perfect for undoing a mistake you just made, but it does nothing at all the day that disk itself dies, gets stolen, or your server burns down. That's what a real [3-2-1 backup](/serveex/advanced/backrest) is for: a copy on different media, ideally off-site.
|
||||
|
||||
Think of it this way:
|
||||
|
||||
- **Snapshot** = an undo button. Instant, local, cheap, only useful while the disk is alive.
|
||||
- **Backup** = insurance. Slower, off-site, the only thing that survives the disk itself failing.
|
||||
|
||||
Keep both. Snapshots make you fearless about updates and experiments, backups make sure a dead drive stays an inconvenience instead of a catastrophe.
|
||||
|
||||
::note{to="/serveex/core/installation#partitioning"}
|
||||
|
||||
This guide assumes the root partition was formatted with Btrfs during [Debian's installation](/serveex/core/installation#partitioning). Btrfs can't be safely bolted onto an existing ext4 root after the fact, so this is a choice you make once, at install time.
|
||||
::
|
||||
|
||||
## Formatting the root partition with BTRFS
|
||||
Debian's *Guided* partitioning only ever offers ext4. To get Btrfs, pick *Manual* partitioning instead, at the same step [the main install guide](/serveex/core/installation#partitioning) describes:
|
||||
|
||||
::steps{level="3"}
|
||||
### Select Manual partitioning
|
||||
|
||||
At the partitioning method screen, choose *Manual* instead of *Guided - use entire disk*.
|
||||
|
||||
### Create a partition table
|
||||
|
||||
Select the disk, confirm creating a new empty partition table, then select the resulting *FREE SPACE* and choose *Create a new partition*.
|
||||
|
||||
### Set the partition size and type
|
||||
|
||||
Give the partition the rest of the disk (minus a small EFI partition if you're on UEFI, handled the same way as a Guided install), and set *Use as* to __Btrfs journaling file system__, with the mount point `/`.
|
||||
|
||||
### Finish partitioning
|
||||
|
||||
*Finish partitioning and write changes to disk*, then confirm with *Yes*.
|
||||
|
||||
### Done!
|
||||
::
|
||||
|
||||
Everything else in the [installer](/serveex/core/installation#install-debian) stays the same.
|
||||
|
||||
## Installing Snapper
|
||||
Rather than juggling raw `btrfs subvolume` commands by hand, [Snapper](https://github.com/openSUSE/snapper) is a small tool that manages the whole snapshot lifecycle: creating them, storing them tidily, pruning old ones, and automatically bracketing every `apt` operation with a snapshot pair.
|
||||
|
||||
```bash [Terminal]
|
||||
sudo apt install snapper
|
||||
sudo snapper -c root create-config /
|
||||
```
|
||||
|
||||
`create-config` registers a config named `root` for the `/` filesystem, and creates a dedicated `.snapshots` subvolume under it to store every snapshot, locked down to root. No `@`/`@home` subvolume split needed, this works fine on the plain single-subvolume layout the manual partitioning above just created.
|
||||
|
||||
Turn the config on by editing `/etc/default/snapper`:
|
||||
|
||||
```properties [/etc/default/snapper]
|
||||
SNAPPER_CONFIGS="root"
|
||||
```
|
||||
|
||||
Then enable the timers that run Snapper's periodic snapshots and cleanup:
|
||||
|
||||
```bash [Terminal]
|
||||
sudo systemctl enable --now snapper-timeline.timer snapper-cleanup.timer
|
||||
```
|
||||
|
||||
`snapper-timeline.timer` fires **every hour** by default, that's fixed by the unit itself, not by a config option. Each run takes one snapshot and files it under the appropriate bucket (hourly, daily, monthly, yearly); the `TIMELINE_LIMIT_*` settings covered further down only control how many of each bucket survive, not how often a snapshot is taken. `snapper-cleanup.timer` runs once a day (plus once 10 minutes after boot) to enforce those limits.
|
||||
|
||||
::tip
|
||||
✨ To take timeline snapshots at a different frequency, for example every 6 hours instead of every hour, override the timer instead of editing the package's unit file directly:
|
||||
|
||||
```bash [Terminal]
|
||||
sudo systemctl edit snapper-timeline.timer
|
||||
```
|
||||
|
||||
```ini [override.conf]
|
||||
[Timer]
|
||||
OnCalendar=
|
||||
OnCalendar=*-*-* 0/6:00:00
|
||||
```
|
||||
|
||||
The empty `OnCalendar=` line clears the packaged `hourly` value first, since systemd otherwise adds new `OnCalendar` lines to the existing ones instead of replacing them. Apply it with `sudo systemctl daemon-reload && sudo systemctl restart snapper-timeline.timer`.
|
||||
::
|
||||
|
||||
::note
|
||||
|
||||
Debian's package also ships an APT hook (`/etc/apt/apt.conf.d/80snapper`) that kicks in the moment a config is listed in `SNAPPER_CONFIGS`: from now on, every `apt install`, `apt upgrade` or `apt full-upgrade` automatically gets a snapshot right before and right after it runs, with zero extra effort on your part.
|
||||
::
|
||||
|
||||
## Taking a snapshot
|
||||
For anything outside apt, like editing a systemd unit or a Docker Compose file, take one yourself with a description that will actually mean something later:
|
||||
|
||||
```bash [Terminal]
|
||||
sudo snapper create --description "before compose change on swag"
|
||||
```
|
||||
|
||||
List every snapshot with:
|
||||
|
||||
```bash [Terminal]
|
||||
sudo snapper list
|
||||
```
|
||||
|
||||
```console [Output]
|
||||
# | Type | Pre # | Date | Description
|
||||
---+--------+-------+--------------------------+---------------------------------
|
||||
0 | single | | | current
|
||||
1 | single | | Tue 09 Sep 2026 18:30:00 | before compose change on swag
|
||||
2 | pre | | Tue 09 Sep 2026 19:00:01 | apt install unattended-upgrades
|
||||
3 | post | 2 | Tue 09 Sep 2026 19:00:14 | apt install unattended-upgrades
|
||||
```
|
||||
|
||||
## Restoring files from a snapshot
|
||||
Snapper keeps the full state of the filesystem at snapshot time under `/.snapshots/<number>/snapshot`, browsable like any other folder:
|
||||
|
||||
```bash [Terminal]
|
||||
ls /.snapshots/1/snapshot/etc/ssh/
|
||||
```
|
||||
|
||||
To see exactly what changed between a snapshot and the live system (`0` always means "current") before touching anything:
|
||||
|
||||
```bash [Terminal]
|
||||
sudo snapper status 1..0
|
||||
```
|
||||
|
||||
That prints every file created, modified or deleted since. To undo those changes automatically:
|
||||
|
||||
```bash [Terminal]
|
||||
sudo snapper undochange 1..0
|
||||
```
|
||||
|
||||
Or restore a single file by hand, which is often the safer, more surgical choice:
|
||||
|
||||
```bash [Terminal]
|
||||
sudo cp -a /.snapshots/1/snapshot/etc/ssh/sshd_config /etc/ssh/sshd_config
|
||||
```
|
||||
|
||||
::note
|
||||
|
||||
This covers the vast majority of real homelab accidents: a bad config, a deleted file, a package upgrade that broke one thing. Snapper can also `rollback` the entire root filesystem to an earlier snapshot (it creates a new default subvolume and boots into it on the next restart), for a system in a genuinely bad state rather than just missing one file. It's a more delicate, less common operation, worth testing once on a machine you don't mind rebooting before you actually need it for real. And if the disk itself is the problem, that's exactly the scenario your off-site [Backrest](/serveex/advanced/backrest) backup is for anyway.
|
||||
::
|
||||
|
||||
## Managing and pruning snapshots
|
||||
Snapshots are cheap, not free: the moment the live filesystem diverges from one, the old blocks it still references stick around. Left unchecked, months of snapshots on a server that changes a lot (container images, logs) can quietly eat real disk space.
|
||||
|
||||
The `snapper-cleanup.timer` enabled above already prunes automatically, based on the config at `/etc/snapper/configs/root`:
|
||||
|
||||
| Setting | Default | What it does |
|
||||
|---------|---------|---------------|
|
||||
| `TIMELINE_LIMIT_HOURLY` / `_DAILY` / `_MONTHLY` / `_YEARLY` | `10` | How many timeline snapshots of each granularity to keep |
|
||||
| `TIMELINE_LIMIT_WEEKLY` | `0` | Off by default |
|
||||
| `NUMBER_LIMIT` | `50` | How many manual (`single`) snapshots to keep |
|
||||
|
||||
Adjust these to taste, then delete one immediately by hand if you need the space back right now:
|
||||
|
||||
```bash [Terminal]
|
||||
sudo snapper delete 1
|
||||
```
|
||||
|
||||
Check actual disk usage with `df -h /`: the numbers above only cap how many snapshots exist, not the space a very active server can still burn through between cleanups.
|
||||
|
||||
That's it: a rolling, automatic undo button for your server, quietly bracketing every update and pruning itself, running alongside the real backups Backrest is already taking off-site.
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Introduction
|
||||
title: Stockeex
|
||||
description: Introduction to Stockeex, a personal project for stock and inventory management. Documentation coming soon.
|
||||
navigation:
|
||||
icon: i-lucide-bookmark
|
||||
@@ -15,5 +15,5 @@ currently writing, come back later...
|
||||
--
|
||||
```
|
||||
<div align="center">
|
||||
<img src="/img/stockeex/stockeex-raid.svg" alt="Image" style="max-width: 60%;">
|
||||
<img src="/img/stockeex/stockeex-raid.svg" alt="Diagram of a RAID array" style="max-width: 60%;">
|
||||
</div>
|
||||
|
||||
@@ -32,7 +32,7 @@ Discord alerts for GPU stock availability
|
||||
::card
|
||||
---
|
||||
icon: i-cbi-adguard
|
||||
title: Adguard CIDRE
|
||||
title: AdGuard CIDRE
|
||||
to: /nonsense/python/adguard-cidre
|
||||
ui:
|
||||
icon: text-[#68BC71]
|
||||
|
||||
@@ -1,33 +1,33 @@
|
||||
---
|
||||
title: Adguard CIDRE
|
||||
title: AdGuard CIDRE
|
||||
description: A Python script to sync AdGuard Home CIDR allowlists automatically, securing your self-hosted DNS server exposed to the internet.
|
||||
---
|
||||
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
|
||||
Adguard Home is a fantastic solution for DNS-level ad blocking and rewriting requests, perfect for removing ISP DNS trackers or intrusive ads.
|
||||
AdGuard Home is a fantastic solution for DNS-level ad blocking and rewriting requests, perfect for removing ISP DNS trackers or intrusive ads.
|
||||
|
||||
It works great locally, but if you want all your devices (even on the go) to benefit, you’ll need to expose Adguard to the internet. Unfortunately, that means anyone can use it, potentially overloading your €1/month remote VPS.
|
||||
It works great locally, but if you want all your devices (even on the go) to benefit, you’ll need to expose AdGuard to the internet. Unfortunately, that means anyone can use it, potentially overloading your €1/month remote VPS.
|
||||
|
||||
Adguard allows whitelisting or blacklisting clients. The problem? To whitelist a client, you need their IP, but for mobile phones, that IP changes often. Instead of trying to whitelist ever-changing IPs, the better approach is to block broader IP ranges by region.
|
||||
AdGuard allows whitelisting or blacklisting clients. The problem? To whitelist a client, you need their IP, but for mobile phones, that IP changes often. Instead of trying to whitelist ever-changing IPs, the better approach is to block broader IP ranges by region.
|
||||
|
||||
CIDRE is a tool that syncs geo-targeted IP ranges with firewalls. Instead of running CIDRE with a full firewall stack on the remote server, I figured I could just import those regularly updated IP ranges into Adguard’s blocklist.
|
||||
CIDRE is a tool that syncs geo-targeted IP ranges with firewalls. Instead of running CIDRE with a full firewall stack on the remote server, I figured I could just import those regularly updated IP ranges into AdGuard’s blocklist.
|
||||
|
||||
Thus, Adguard CIDRE Sync was born: a container that syncs Adguard’s blocklist with CIDRE’s updated IP ranges on a schedule of your choosing.
|
||||
Thus, AdGuard CIDRE Sync was born: a container that syncs AdGuard’s blocklist with CIDRE’s updated IP ranges on a schedule of your choosing.
|
||||
|
||||
The idea is to:
|
||||
|
||||
- Backup Adguard’s config file on first run (original untouched version saved)
|
||||
- Backup AdGuard’s config file on first run (original untouched version saved)
|
||||
- Download selected country IP ranges via an environment variable
|
||||
- Let you manually add custom IPs via a file
|
||||
- Concatenate, backup the config again (as the updated version), and inject the list into the correct blocklist section
|
||||
- Reload Adguard by restarting the container (using Docker socket proxy for limited permissions)
|
||||
- Reload AdGuard by restarting the container (using Docker socket proxy for limited permissions)
|
||||
|
||||
All fully autonomous, with frequency set via environment variable in the `docker-compose` config.
|
||||
|
||||
More info directly on the repo:
|
||||
|
||||
::card{title="🐋 __Adguard CIDRE Sync__" to="https://git.djeex.fr/Djeex/adguard-cidre" target="_blank"}
|
||||
Adguard blocklist sync bot
|
||||
::card{title="🐋 __AdGuard CIDRE Sync__" to="https://git.djeex.fr/Djeex/adguard-cidre" target="_blank"}
|
||||
AdGuard blocklist sync bot
|
||||
::
|
||||
|
||||
@@ -6,13 +6,13 @@ description: Lumeex is a static photo gallery site generator built with Python,
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
<div align="center">
|
||||
<img src="https://git.djeex.fr/Djeex/lumeex/raw/branch/main/illustration/logo.svg" alt="Lumeex Screenshot" width="300"/>
|
||||
<img src="/img/nonsense/lumeex-logo.svg" alt="Lumeex logo" width="300"/>
|
||||
</div>
|
||||
<div align="center">
|
||||
<p>Yet another minimalist, lightweight photo gallery static site generator.</p>
|
||||
</div>
|
||||
<div align="center">
|
||||
<img src="https://git.djeex.fr/Djeex/lumeex/raw/branch/main/illustration/lumeex.png" alt="Lumeex Screenshot" />
|
||||
<img src="/img/nonsense/lumeex.png" alt="Lumeex gallery homepage" />
|
||||
</div>
|
||||
|
||||
---
|
||||
@@ -28,7 +28,7 @@ Eventually, after getting good results, I figured I might as well go all the way
|
||||
That’s how **Lum[eex]{style="color: #1ad6ff"}** was born.
|
||||
|
||||
<div align="center">
|
||||
<img src="https://git.djeex.fr/Djeex/lumeex/raw/branch/main/illustration/lumeex-webui.png" alt="Lumeex Screenshot" />
|
||||
<img src="/img/nonsense/lumeex-webui.png" alt="Lumeex configuration web UI" />
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
@@ -6,13 +6,13 @@ description: Instameex is a Docker-based tool to merge SDR and HDR photo exports
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
<div align="center">
|
||||
<img src="https://git.djeex.fr/Djeex/instameex/raw/branch/main/src/assets/img/logo-long.svg" alt="Instameex Screenshot" width="300"/>
|
||||
<img src="/img/nonsense/instameex-logo-long.svg" alt="Instameex logo" width="300"/>
|
||||
</div>
|
||||
<div align="center">
|
||||
<p>Mix your SDR and HDR exports into an Instagram-ready HDR photo.</p>
|
||||
</div>
|
||||
<div align="center">
|
||||
<img src="https://git.djeex.fr/Djeex/instameex/raw/branch/main/illustration/instameex-illustration.png" width="640" alt="Instameex Screenshot" />
|
||||
<img src="/img/nonsense/instameex-illustration.png" width="640" alt="Instameex illustration" />
|
||||
</div>
|
||||
---
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ description: A bash script to detect and fix duplicate media files in Sonarr and
|
||||
|
||||
Six months after downloading terabytes of media, I realized that Sonarr and Radarr were copying them into my Plex library instead of creating hardlinks. This happens due to a counterintuitive mechanism: if you mount multiple folders in Sonarr/Radarr, it sees them as different filesystems and thus cannot create hardlinks. That’s why you should mount only one parent folder containing all child folders (like `downloads`, `movies`, `tvseries` inside a `media` parent folder).
|
||||
|
||||
So I restructured my directories, manually updated every path in Qbittorrent, Plex, and others. The last challenge was finding a way to detect existing duplicates, delete them, and automatically create hardlinks instead, to save space.
|
||||
So I restructured my directories, manually updated every path in qBittorrent, Plex, and others. The last challenge was finding a way to detect existing duplicates, delete them, and automatically create hardlinks instead, to save space.
|
||||
|
||||
::file-tree
|
||||
---
|
||||
|
||||
@@ -23,7 +23,7 @@ With this setup, Docker Socket Proxy communicates with Socat Proxy in their isol
|
||||
|
||||
In short:
|
||||
|
||||

|
||||

|
||||
|
||||
For example, with Beszel, the configuration would look like this:
|
||||
|
||||
@@ -77,6 +77,6 @@ services:
|
||||
|
||||
More information is available on the repository:
|
||||
|
||||
::card{title="🐋 **Socat Proxy**" to="https://git.djeex.fr/Djeex/socat-proxy" target="_blank"}
|
||||
::card{title="🐋 __Socat Proxy__" to="https://git.djeex.fr/Djeex/socat-proxy" target="_blank"}
|
||||
A lightweight bind-mount socket proxy
|
||||
::
|
||||
|
||||
@@ -6,7 +6,7 @@ description: A bash script that stops Docker containers before a Backrest backup
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
|
||||
[Backrest](https://github.com/garethgeorge/backrest) is a fantastic backup tool. In the case of [Serveex](https://docu.djeex.fr/en/serveex/introduction), most of the data that needs to be backed up consists of containers, and those containers often include databases.
|
||||
[Backrest](https://github.com/garethgeorge/backrest) is a fantastic backup tool. In the case of [Serveex](/serveex/introduction), most of the data that needs to be backed up consists of containers, and those containers often include databases.
|
||||
|
||||
The problem? You can’t safely back up a database while it’s running. There are plenty of complex solutions involving database dumps, but often the simplest method is to stop the containers, perform the backup, and then restart them.
|
||||
|
||||
|
||||
@@ -21,7 +21,7 @@ Not every article stays current forever. This section keeps two kinds of leftove
|
||||
::card
|
||||
---
|
||||
icon: i-simple-icons-wireguard
|
||||
title: Wireguard 14
|
||||
title: WireGuard 14
|
||||
to: /recycled/deprecated/wireguard-14
|
||||
ui:
|
||||
icon: text-[#88171A]
|
||||
@@ -55,7 +55,7 @@ The paid-tier alternative to Jellyfin
|
||||
::card
|
||||
---
|
||||
icon: i-cbi-qbittorrent
|
||||
title: Qbittorrent for Plex
|
||||
title: qBittorrent for Plex
|
||||
to: /recycled/alternatives/qbittorrent-for-plex
|
||||
ui:
|
||||
icon: text-[#2F67BA]
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Wireguard 14
|
||||
title: WireGuard 14
|
||||
description: Archived guide to installing WireGuard VPN using linuxserver.io's older wireguard image, kept for reference only.
|
||||
---
|
||||
|
||||
@@ -14,10 +14,10 @@ wg-easy 15 got a lot more complicated, "not so easy" anymore, arguably. That's e
|
||||
## Introduction
|
||||
Using a VPN allows remote access to a server’s local resources without exposing them to the internet. It’s a clean and secure way to access services like SSH without exposing the port publicly. With a VPN, you can securely connect to your network from anywhere and make devices on different networks communicate.
|
||||
|
||||
Here we will use [Wireguard](https://www.wireguard.com/), a secure and high-performance VPN server, using containers:
|
||||
Here we will use [WireGuard](https://www.wireguard.com/), a secure and high-performance VPN server, using containers:
|
||||
|
||||
- [wg-easy](https://github.com/wg-easy/wg-easy) as the server, providing a very simple web UI to manage connections and download config files (including QR codes for phones)
|
||||
- [Wireguard](https://docs.linuxserver.io/images/docker-wireguard/?h=wireguard) as the client for Linux systems
|
||||
- [WireGuard](https://docs.linuxserver.io/images/docker-wireguard/?h=wireguard) as the client for Linux systems
|
||||
|
||||
Clients are also available for Windows, macOS, iOS, and Android.
|
||||
|
||||
@@ -32,7 +32,7 @@ To achieve this, we’ll create a **Virtual Private Network** (VPN), i.e., a sec
|
||||
|
||||
Additionally, you can add your phone, laptop, or other devices to the VPN and securely access your server resources wherever you are.
|
||||
|
||||

|
||||

|
||||
|
||||
In this diagram, machine 1 is part of two networks:
|
||||
|
||||
@@ -156,7 +156,7 @@ sudo sysctl net.ipv4.conf.all.src_valid_mark=1
|
||||
|
||||
To configure clients, download the config files from the server:
|
||||
|
||||
- Visit `http://your-server-ip:51821`
|
||||
- Visit `http://yourserverip:51821`
|
||||
- Create a client
|
||||
- Download the config file
|
||||
- Rename it to `wg0.conf`
|
||||
@@ -257,15 +257,15 @@ Repeat for each client
|
||||
|
||||
## Other Devices
|
||||
|
||||
- **Phone:** Install Wireguard and scan the QR code from the web UI (`http://your-server-ip:51821`)
|
||||
- **PC:** Install the Wireguard client and import the config file
|
||||
- **Phone:** Install WireGuard and scan the QR code from the web UI (`http://yourserverip:51821`)
|
||||
- **PC:** Install the WireGuard client and import the config file
|
||||
|
||||
::warning
|
||||
|
||||
__Warning:__ If a client device is on the same LAN as the server, edit `wg0.conf` and change the endpoint to the local server IP:
|
||||
`Endpoint = your-server-ip:51820`
|
||||
`Endpoint = yourserverip:51820`
|
||||
::
|
||||
|
||||
And this is the result:
|
||||
|
||||

|
||||

|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: File Browser
|
||||
description: Install File Browser to browse and manage your server files from a web interface, exposed securely with SWAG.
|
||||
description: Archived guide to installing File Browser to browse and manage your server files, superseded by File Browser Quantum.
|
||||
---
|
||||
|
||||
|
||||
@@ -29,7 +29,7 @@ services:
|
||||
container_name: filebrowser
|
||||
volumes:
|
||||
- /srv/docker/filebrowser/config:/config/
|
||||
- /path/to/your/folders:/yourfolders #add your folders to browse as /srv/docker:/srv/docker for exemple
|
||||
- /path/to/your/folders:/yourfolders #add your folders to browse as /srv/docker:/srv/docker for example
|
||||
ports:
|
||||
- 8010:80
|
||||
image: filebrowser/filebrowser:s6
|
||||
@@ -58,14 +58,14 @@ Deploy the container and go to `http://yourserverip:8010`. That’s it! Your Fil
|
||||
__If it doesn’t work:__ check your firewall rules.
|
||||
::
|
||||
|
||||
## Exposing File Browser with Swag
|
||||
## Exposing File Browser with SWAG
|
||||
|
||||
::warning
|
||||
|
||||
File Browser does not support multi-factor authentication. Exposing it publicly could put your systems at risk. Only do this if you’re using a secure authentication solution like [TinyAuth](/serveex/security/tinyauth) or [Authentik](/serveex/advanced/authentik/). Otherwise, do not expose it with SWAG. Use a VPN like [Wireguard](/serveex/core/wireguard) instead.
|
||||
File Browser does not support multi-factor authentication. Exposing it publicly could put your systems at risk. Only do this if you’re using a secure authentication solution like [TinyAuth](/serveex/security/tinyauth) or [Authentik](/serveex/advanced/authentik/). Otherwise, do not expose it with SWAG. Use a VPN like [WireGuard](/serveex/core/wireguard) instead.
|
||||
::
|
||||
|
||||
You may want to access File Browser remotely from all your devices. To do that, we’ll expose it through Swag.
|
||||
You may want to access File Browser remotely from all your devices. To do that, we’ll expose it through SWAG.
|
||||
|
||||
::note
|
||||
|
||||
@@ -103,7 +103,7 @@ Restart the stack by clicking "deploy" and wait for SWAG to fully initialize.
|
||||
|
||||
### Create the subdomain.conf file
|
||||
|
||||
In the Swag folders, create the file `files.subdomain.conf`.
|
||||
In the SWAG folders, create the file `files.subdomain.conf`.
|
||||
|
||||
```bash [Terminal]
|
||||
sudo nano /srv/docker/swag/config/nginx/proxy-confs/files.subdomain.conf
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Plex
|
||||
description: Install Plex Media Server with Tautulli on your homelab to stream movies and TV shows from anywhere on all your devices.
|
||||
description: Archived guide to installing Plex Media Server with Tautulli, kept for reference — Serveex now recommends Jellyfin.
|
||||
---
|
||||
|
||||
|
||||
@@ -8,14 +8,14 @@ description: Install Plex Media Server with Tautulli on your homelab to stream m
|
||||
|
||||
::note{to="/serveex/media/jellyfin"}
|
||||
|
||||
This is an alternative to **Jellyfin**, kept here for reference. Plex isn't fully self-hosted: local playback still goes through Plex's own relay and requires a Plex account, and several features sit behind a Plex Pass paywall.
|
||||
This is an alternative to **Jellyfin**, kept here for reference. Plex isn't fully self-hosted: it requires a Plex account even for local playback, remote access can fall back to Plex's own relay when a direct connection fails, and several features sit behind a Plex Pass paywall.
|
||||
::
|
||||
|
||||
[Plex](https://www.plex.tv/fr/) is a self-hosted video streaming platform for managing your movie or TV show library and playing them locally or remotely. Plex has apps for TV, Android, iOS, Windows, and macOS, allowing you to stream your library just like Netflix.
|
||||
[Plex](https://www.plex.tv/) is a self-hosted video streaming platform for managing your movie or TV show library and playing them locally or remotely. Plex has apps for TV, Android, iOS, Windows, and macOS, allowing you to stream your library just like Netflix.
|
||||
|
||||
With *Plex Pass*, you can also organize and play your music content similar to Spotify, the difference being that it’s your content, hosted and streamed from your server.
|
||||
|
||||

|
||||

|
||||
|
||||
We'll also install [Tautulli](https://docs.linuxserver.io/images/docker-tautulli/), a tool that provides detailed stats about Plex. As always, we'll use linuxserver.io images where possible.
|
||||
|
||||
@@ -72,7 +72,7 @@ services:
|
||||
network_mode: host
|
||||
environment:
|
||||
- PUID=${PUID}
|
||||
- PGID=${GUID}
|
||||
- PGID=${PGID}
|
||||
- TZ=Europe/Paris
|
||||
- VERSION=docker
|
||||
volumes:
|
||||
@@ -90,7 +90,7 @@ services:
|
||||
container_name: tautulli
|
||||
environment:
|
||||
- PUID=${PUID}
|
||||
- PGID=${GUID}
|
||||
- PGID=${PGID}
|
||||
- TZ=Europe/Paris
|
||||
volumes:
|
||||
- /srv/docker/tautulli/config:/config
|
||||
@@ -119,7 +119,7 @@ services:
|
||||
|
||||
### Set your environment variables
|
||||
|
||||
Find your PUID and GUID by running:
|
||||
Find your PUID and PGID by running:
|
||||
|
||||
```bash [Terminal]
|
||||
id username
|
||||
@@ -129,7 +129,7 @@ Fill in your `.env` file with the retrieved values, for example:
|
||||
|
||||
```properties [.env]
|
||||
PUID=1000
|
||||
GUID=1000
|
||||
PGID=1000
|
||||
```
|
||||
|
||||
Deploy the stack.
|
||||
@@ -150,7 +150,7 @@ Plex offers a range of free movies/shows. After creating your account, I recomme
|
||||
|
||||
Then go to the _Remote Access_ section and manually select a port (we’ll use `1234`). It's best not to use the default port.
|
||||
|
||||

|
||||

|
||||
|
||||
- On your router, forward TCP port `1234` to port `32400` for your server’s IP using [NAT rules](/general/networking/nat).
|
||||
- Once done, return to Plex to verify that remote access is functional.
|
||||
@@ -173,7 +173,7 @@ Simply add your media to `/media/movies` and `/media/tvseries` on your server. Y
|
||||
If your media is stored on a network disk (e.g. NAS or external hard drive over the network), refer to the **Samba mount guide** so Plex can access it.
|
||||
::
|
||||
|
||||
## Expose Tautulli with Swag
|
||||
## Expose Tautulli with SWAG
|
||||
You don’t need to expose Plex, as it's accessible via your Plex account on plex.tv.
|
||||
|
||||
However, you may want to expose Tautulli so you can view stats from a simple URL when you're not home.
|
||||
|
||||
+24
-24
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Qbittorrent for Plex
|
||||
description: Install qBittorrent with Gluetun and ProtonVPN to download torrents securely behind a VPN on your self-hosted server.
|
||||
title: qBittorrent for Plex
|
||||
description: Archived guide to installing qBittorrent for a Plex setup, kept for reference — see the current qBittorrent guide instead.
|
||||
---
|
||||
|
||||
|
||||
@@ -8,22 +8,22 @@ description: Install qBittorrent with Gluetun and ProtonVPN to download torrents
|
||||
|
||||
::note{to="/serveex/media/qbittorrent"}
|
||||
|
||||
This is the seedbox setup paired with Plex rather than Jellyfin, kept here for reference. See **Qbittorrent** for the same setup paired with Jellyfin, the recommended alternative since Plex isn't fully self-hosted (its own relay, a required account) and gates features behind a Plex Pass paywall.
|
||||
This is the seedbox setup paired with Plex rather than Jellyfin, kept here for reference. See **qBittorrent** for the same setup paired with Jellyfin, the recommended alternative since Plex isn't fully self-hosted (its own relay, a required account) and gates features behind a Plex Pass paywall.
|
||||
::
|
||||
|
||||

|
||||

|
||||
|
||||
To safely download your favorite media, we'll build a system using:
|
||||
|
||||
- [Qbittorrent](https://github.com/linuxserver/docker-qbittorrent) as the BitTorrent client
|
||||
- [qBittorrent](https://github.com/linuxserver/docker-qbittorrent) as the BitTorrent client
|
||||
- [Proton VPN Plus](https://protonvpn.com/torrenting), a VPN to secure your traffic. You need a subscription (promos available) to access the BitTorrent protocol. You can also use another VPN as long as it supports BitTorrent.
|
||||
- [Gluetun](https://github.com/qdm12/gluetun)
|
||||
- [Qbittorrent port update](https://codeberg.org/TechnoSam/qbittorrent-gluetun-port-update) to automatically update the VPN port (which changes regularly).
|
||||
- [qBittorrent port update](https://codeberg.org/TechnoSam/qbittorrent-gluetun-port-update) to automatically update the VPN port (which changes regularly).
|
||||
- The [VueTorrent](https://github.com/gabe565/linuxserver-mod-vuetorrent) mod for a modern and intuitive UI.
|
||||
|
||||
Here’s the system we’ll set up:
|
||||
|
||||

|
||||

|
||||
|
||||
## Configuration
|
||||
|
||||
@@ -39,7 +39,7 @@ tree:
|
||||
- gluetun/
|
||||
- compose.yaml
|
||||
- .env
|
||||
- "media # linked to Plex and Qbittorrent":
|
||||
- "media # linked to Plex and qBittorrent":
|
||||
- "downloads/ # generic downloads, selected in settings"
|
||||
- "movies/ # used for downloading movies"
|
||||
- "tvseries/ # used for downloading TV shows"
|
||||
@@ -52,7 +52,7 @@ tree:
|
||||
If not already done, create the `downloads` folder under `/media`:
|
||||
|
||||
```bash [Terminal]
|
||||
mkdir -P /media/downloads
|
||||
mkdir -p /media/downloads
|
||||
```
|
||||
|
||||
### Deploy the stack
|
||||
@@ -72,7 +72,7 @@ services:
|
||||
- DOCKER_MODS=ghcr.io/gabe565/linuxserver-mod-vuetorrent|ghcr.io/t-anc/gsp-qbittorent-gluetun-sync-port-mod:main
|
||||
- TZ=Europe/Paris
|
||||
- PUID=${PUID}
|
||||
- PGID=${GUID}
|
||||
- PGID=${PGID}
|
||||
- WEBUI_PORT=${UI_PORT}
|
||||
- GSP_GTN_API_KEY=${GSP_KEY}
|
||||
- GSP_QBT_USERNAME=${ID}
|
||||
@@ -93,7 +93,7 @@ services:
|
||||
devices:
|
||||
- /dev/net/tun:/dev/net/tun
|
||||
ports:
|
||||
- ${UI_PORT}:5695 # Port de la web-ui
|
||||
- ${UI_PORT}:${UI_PORT} # Port de la web-ui
|
||||
- 8000:8000 # Port de controle de Gluetun
|
||||
cap_add:
|
||||
- NET_ADMIN
|
||||
@@ -127,7 +127,7 @@ services:
|
||||
|
||||
### Configure the port-forwarding sync
|
||||
|
||||
Before editing the `.env` in Dockge, let's configure the download port update. Proton and most VPNs rotate the forwarding port, which must be communicated to Qbittorrent.
|
||||
Before editing the `.env` in Dockge, let's configure the download port update. Proton and most VPNs rotate the forwarding port, which must be communicated to qBittorrent.
|
||||
|
||||
We’ve added the mod `ghcr.io/t-anc/gsp-qbittorent-gluetun-sync-port-mod` to the container.
|
||||
|
||||
@@ -169,7 +169,7 @@ In Dockge, fill in the variables in `.env`:
|
||||
|
||||
```properties [.env]
|
||||
PUID=
|
||||
GUID=
|
||||
PGID=
|
||||
UI_PORT=
|
||||
PR_KEY=
|
||||
GSP_KEY= # the key you generated and entered in config.toml
|
||||
@@ -182,12 +182,12 @@ Detailed info:
|
||||
| Variable | Description | Example |
|
||||
|------------|-------------|---------|
|
||||
| `PUID` | User ID (`id yourusername`) | `1000` |
|
||||
| `GUID` | Group ID (`id yourusername`) | `1000` |
|
||||
| `PGID` | Group ID (`id yourusername`) | `1000` |
|
||||
| `UI_PORT` | Port for accessing the web UI | `5695` |
|
||||
| `PR_KEY` | Private key from Proton | `buKsjNHLyzKMM1qYnzOy4s7SHfly` |
|
||||
| `GSP_KEY` | Key you generated for port update | `MnBa47MeVmk7xiv` |
|
||||
| `ID` | Qbittorrent UI login username | `user` |
|
||||
| `PW` | Qbittorrent UI password | `password` |
|
||||
| `ID` | qBittorrent UI login username | `user` |
|
||||
| `PW` | qBittorrent UI password | `password` |
|
||||
|
||||
### Done!
|
||||
::
|
||||
@@ -206,7 +206,7 @@ Once done, deploy the container.
|
||||
|
||||
### Log in and secure your account
|
||||
|
||||
Login at `http://server-ip:5695` (or the port you set).
|
||||
Login at `http://yourserverip:5695` (or the port you set).
|
||||
|
||||
::caution
|
||||
|
||||
@@ -218,7 +218,7 @@ Change your username and password in the "webui" settings.
|
||||
### Done!
|
||||
::
|
||||
|
||||
You're done! In Qbittorrent settings, under "Downloads", set `/media/downloads` as the default folder.
|
||||
You're done! In qBittorrent settings, under "Downloads", set `/media/downloads` as the default folder.
|
||||
|
||||
When adding a download, remember to select the proper directory so Plex can sync correctly (`/media/movies` or `/media/tvseries`). You can also automate this with categories and folders.
|
||||
|
||||
@@ -226,10 +226,10 @@ When adding a download, remember to select the proper directory so Plex can sync
|
||||
|
||||
::warning
|
||||
|
||||
Qbittorrent does not support multi-factor authentication. Exposing it to the internet may put your system at risk. Only do this if you use MFA via [Authentik](/serveex/advanced/authentik/). Otherwise, don’t expose it with SWAG. Use a VPN like [Wireguard](/serveex/core/wireguard) instead.
|
||||
qBittorrent does not support multi-factor authentication. Exposing it to the internet may put your system at risk. Only do this if you use MFA via [Authentik](/serveex/advanced/authentik/). Otherwise, don’t expose it with SWAG. Use a VPN like [WireGuard](/serveex/core/wireguard) instead.
|
||||
::
|
||||
|
||||
To start downloads from outside your home, without a VPN, you can expose the Qbittorrent web UI.
|
||||
To start downloads from outside your home, without a VPN, you can expose the qBittorrent web UI.
|
||||
|
||||
::note
|
||||
|
||||
@@ -262,7 +262,7 @@ Click "Deploy" and wait for SWAG to fully initialize.
|
||||
|
||||
::note
|
||||
|
||||
We assume the network name is `seedbox_default`. You can confirm by checking the SWAG dashboard at http://server-ip:81.
|
||||
We assume the network name is `seedbox_default`. You can confirm by checking the SWAG dashboard at http://yourserverip:81.
|
||||
::
|
||||
|
||||
### Create the subdomain.conf file
|
||||
@@ -322,7 +322,7 @@ server {
|
||||
include /config/nginx/proxy.conf;
|
||||
include /config/nginx/resolver.conf;
|
||||
set $upstream_app gluetun;
|
||||
set $upstream_port 5555;
|
||||
set $upstream_port 5695;
|
||||
set $upstream_proto http;
|
||||
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
|
||||
|
||||
@@ -339,8 +339,8 @@ Press :kbd{value="Ctrl+O"}, then :kbd{value="Enter"} to save, and :kbd{value="Ct
|
||||
### Done!
|
||||
::
|
||||
|
||||
Wait a few minutes, then go to `https://seedbox.mydomain.com`. You should land on the Qbittorrent interface.
|
||||
Wait a few minutes, then go to `https://seedbox.mydomain.com`. You should land on the qBittorrent interface.
|
||||
|
||||
And that’s it! You now have a ready-to-use media center.
|
||||
|
||||

|
||||

|
||||
+8
-8
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Servarr for Plex
|
||||
description: Automate media downloads with the Servarr stack, Radarr, Sonarr, Bazarr, Prowlarr, and Overseerr for movies and TV shows.
|
||||
description: Archived guide to the Servarr stack for a Plex setup, kept for reference — see the current Servarr guide instead.
|
||||
---
|
||||
|
||||
|
||||
@@ -57,7 +57,7 @@ tree:
|
||||
::warning
|
||||
|
||||
__Warning:__ Make sure to follow this file structure carefully, especially the `media` folder. This folder must be mounted **exactly the same way** in both the _Qbittorrent_ compose file (`/your/path/media:/media`) and the _arr_ applications.
|
||||
If not, the _arr_ apps may not recognize the path provided by Qbittorrent and will fail to create _hardlinks_.
|
||||
If not, the _arr_ apps may not recognize the path provided by qBittorrent and will fail to create _hardlinks_.
|
||||
Without hardlinks, the _arr_ apps will copy the files instead, **doubling the space used** on your storage.
|
||||
::
|
||||
|
||||
@@ -205,7 +205,7 @@ MEDIA_PATH=
|
||||
|----------------|-------------------------------------------------------------------------------------------------|-------------|
|
||||
| `PUID` | Set using your user info (check with `id yourusername`) | `1000` |
|
||||
| `PGID` | Same as above | `1000` |
|
||||
| `MEDIA_PATH` | Path to your media folder, here: `/media`. It must match the one used by Qbittorrent. | `/media` |
|
||||
| `MEDIA_PATH` | Path to your media folder, here: `/media`. It must match the one used by qBittorrent. | `/media` |
|
||||
|
||||
Deploy the stack.
|
||||
|
||||
@@ -233,7 +233,7 @@ Create an account and choose *forms login*.
|
||||
|
||||
::warning
|
||||
|
||||
__Warning:__ If you already have movies in `movies` from Qbittorrent, do not let Radarr add them. Radarr might modify them, which could stop seeding in Qbittorrent.
|
||||
__Warning:__ If you already have movies in `movies` from qBittorrent, do not let Radarr add them. Radarr might modify them, which could stop seeding in qBittorrent.
|
||||
::
|
||||
|
||||
#### Configure Profiles
|
||||
@@ -242,12 +242,12 @@ Go to *Settings > Profiles*. These are your default quality profiles. When you m
|
||||
|
||||

|
||||
|
||||
#### Add Qbittorrent
|
||||
#### Add qBittorrent
|
||||
|
||||
In *Settings > Download Clients*, add Qbittorrent.
|
||||
In *Settings > Download Clients*, add qBittorrent.
|
||||
|
||||
- Use your server IP as *Host* and port `5695` if following this guide.
|
||||
- Provide your Qbittorrent *Username* and *Password*.
|
||||
- Provide your qBittorrent *Username* and *Password*.
|
||||
- Click *Test*.
|
||||
- If successful, click *Save*.
|
||||
|
||||
@@ -415,7 +415,7 @@ It can be useful to expose Overseerr if you want to send requests from outside y
|
||||
|
||||
::note
|
||||
|
||||
We assume you have the subdomain `films.mydomain.com` with a `CNAME` pointing to `films.fr` in your [DNS zone](/general/networking/dns). And that [unless you’re using Cloudflare Zero Trust](/serveex/security/cloudflare), port `443` on your router is forwarded to port `443` on your server via [NAT rules](/general/networking/nat).
|
||||
We assume you have the subdomain `films.mydomain.com` with a `CNAME` pointing to `mydomain.com` in your [DNS zone](/general/networking/dns). And that [unless you’re using Cloudflare Zero Trust](/serveex/security/cloudflare), port `443` on your router is forwarded to port `443` on your server via [NAT rules](/general/networking/nat).
|
||||
::
|
||||
|
||||
::steps{level="3"}
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Gitea
|
||||
description: Install Gitea, a lightweight self-hosted Git service to manage your code repositories privately on your own server.
|
||||
description: Archived guide to installing Gitea, kept for reference — Serveex now recommends Forgejo.
|
||||
---
|
||||
|
||||
|
||||
@@ -75,8 +75,8 @@ Deploy the container and go to `http://yourserverip:3333`. Your Gitea instance i
|
||||
__If it fails:__ check your firewall rules.
|
||||
::
|
||||
|
||||
## Exposing Gitea with Swag
|
||||
The benefit of this setup is being able to access it remotely from any of your devices. To do so, we’ll expose Gitea through Swag.
|
||||
## Exposing Gitea with SWAG
|
||||
The benefit of this setup is being able to access it remotely from any of your devices. To do so, we’ll expose Gitea through SWAG.
|
||||
|
||||
::note
|
||||
|
||||
@@ -114,7 +114,7 @@ Redeploy the stack by clicking "Deploy" and wait until SWAG is fully operational
|
||||
|
||||
### Create the subdomain.conf file
|
||||
|
||||
Inside the Swag folders, create the file `gitea.subdomain.conf`.
|
||||
Inside the SWAG folders, create the file `gitea.subdomain.conf`.
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
✨ __Tip:__ You can use **File Browser** to navigate and edit your files instead of using terminal commands.
|
||||
@@ -209,5 +209,5 @@ Press :kbd{value="Ctrl+O"}, then :kbd{value="Enter"} to save, and :kbd{value="Ct
|
||||
And that’s it! Gitea is now exposed to the web.
|
||||
|
||||
::tip{icon=""}
|
||||
✨ __Tip:__ You can protect this app natively via OIDC with [Pocket ID](/serveex/security/pocket-id) (register it as an OIDC client), or with Authentik by [following these instructions](https://docs.goauthentik.io/integrations/services/gitea/).
|
||||
✨ __Tip:__ You can protect this app natively via OIDC with [Pocket ID](/serveex/security/pocket-id) (register it as an OIDC client), or with Authentik by [following these instructions](https://integrations.goauthentik.io/development/gitea/).
|
||||
::
|
||||
|
||||
+2
-2
@@ -17,7 +17,7 @@ seo:
|
||||
:::::
|
||||
|
||||
:::::div{class="my-6 pt-[25px] pb-[25px]"}
|
||||
{.w-full}
|
||||
{.w-full}
|
||||
:::::
|
||||
|
||||
:::::div{class="flex flex-col sm:flex-row sm:items-center gap-3"}
|
||||
@@ -43,7 +43,7 @@ Set up my homelab →
|
||||
::::
|
||||
|
||||
::::div{class="flex flex-col gap-5 justify-start self-start"}
|
||||
<h2 class="text-sm font-semibold text-muted uppercase tracking-wide mt-0 mb-0">And Other dumb things</h2>
|
||||
<h2 class="text-sm font-semibold text-muted uppercase tracking-wide mt-0 mb-0">And other dumb things</h2>
|
||||
|
||||
:::::card
|
||||
---
|
||||
|
||||
@@ -16,9 +16,9 @@ __Docu[·]{style="color: #1ad6ff"}djeex__ est le site regroupant la documentatio
|
||||
|
||||
## À propos de la documentation
|
||||
|
||||
La documentation fournie ici est distribuée à titre expérimentale, dans un esprit de partage d'expérience. Elle n'est en aucun cas faite pour construire une architecture de production ou pour de l'industrialisation. Il est possible qu'elle contienne des erreurs et/ou des approximations.
|
||||
La documentation fournie ici est distribuée à titre expérimental, dans un esprit de partage d'expérience. Elle n'est en aucun cas faite pour construire une architecture de production ou pour de l'industrialisation. Il est possible qu'elle contienne des erreurs et/ou des approximations.
|
||||
|
||||
Evidemment, l'usage de cette documentation doit strictement se limiter au cadre légal.
|
||||
Évidemment, l'usage de cette documentation doit strictement se limiter au cadre légal.
|
||||
|
||||
### Documentation disponible ou à venir
|
||||
|
||||
@@ -43,7 +43,7 @@ Votre homelab à déployer, pas à pas
|
||||
Scripts personnels et projets annexes
|
||||
::
|
||||
|
||||
::card{icon="i-noto-recycling-symbol" title="Poubelle" to="/recycled/deprecated/wireguard-14"}
|
||||
::card{icon="i-noto-recycling-symbol" title="Recyclage" to="/recycled/deprecated/wireguard-14"}
|
||||
Pages périmées, conservées pour archive ou alternatives
|
||||
::
|
||||
::
|
||||
|
||||
@@ -7,11 +7,11 @@ description: Comprendre le NAT, la redirection de ports et le DHCP sur un routeu
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
|
||||
|
||||

|
||||

|
||||
|
||||
## Qu'est-ce qu'un « port » ?
|
||||
|
||||
Les ports sont différents canaux par lesquels votre routeur envoie et reçoit des données, ce qui permet d'utiliser plusieurs services en meme temps. Lorsqu'il reçoit des données via un port, votre routeur transmet ensuite les données à la machine qui :
|
||||
Les ports sont différents canaux par lesquels votre routeur envoie et reçoit des données, ce qui permet d'utiliser plusieurs services en même temps. Lorsqu'il reçoit des données via un port, votre routeur transmet ensuite les données à la machine qui :
|
||||
|
||||
- soit a émis la requête de départ,
|
||||
- soit est configurée pour recevoir les données arrivant sur un port spécifique.
|
||||
|
||||
@@ -8,11 +8,11 @@ description: Comprendre le fonctionnement du DNS, lire et éditer une zone DNS,
|
||||
|
||||
## Introduction
|
||||
|
||||
Lorsque vous naviguez sur un site, ou une application, des requêtes sont émises vers un ou des domaines afin d'afficher le contenu de votre page. Votre appareil ne connait pas les adresses IP de ces serveurs à joindre. Pour les connaitre, il va contacter un _serveur de nom_ (Domain Name Server) qui lui va lui répondre avec l'adresse IP la plus à jour pour le domaine de la requête.
|
||||
Lorsque vous naviguez sur un site, ou une application, des requêtes sont émises vers un ou des domaines afin d'afficher le contenu de votre page. Votre appareil ne connait pas les adresses IP de ces serveurs à joindre. Pour les connaitre, il va contacter un _serveur de nom_ (Domain Name Server) qui va lui répondre avec l'adresse IP la plus à jour pour le domaine de la requête.
|
||||
|
||||
La zone DNS, c'est une sorte de registre avec des panneaux qui redirige vos requêtes vers la bonne destination.
|
||||
|
||||

|
||||

|
||||
|
||||
## La zone DNS
|
||||
|
||||
@@ -56,4 +56,4 @@ Et si vous ajoutez un sous-domaine qui doit pointer vers votre serveur, vous pou
|
||||
__Pourquoi ne pas utiliser un enregistrement `A` pour le sous-domaine ?__ Si votre sous domaine pointe sur le meme serveur que `mondomaine.fr`, il vaut mieux utiliser un enregistrement `CNAME` car en cas de changement d'IP du serveur, il n'y aura aucune autre manipulation à faire.
|
||||
::
|
||||
|
||||
La plupart des registrar proposent des interfaces plus lisbles pour modifier ces informations. Renseignez-vous auprès de la documentation de votre registrar.
|
||||
La plupart des registrar proposent des interfaces plus lisibles pour modifier ces informations. Renseignez-vous auprès de la documentation de votre registrar.
|
||||
|
||||
@@ -8,14 +8,14 @@ description: Configurer Samba sur Debian pour partager des dossiers sur votre r
|
||||
|
||||
Samba est une implémentation libre du protocole SMB/CIFS, permettant d'accèder à un dossier situé sur un disque réseau. Il peut être configuré sous Mac, Windows ou Linux.
|
||||
|
||||
De nombreux tutorials existent pour configurer Samba sous windows ou sur un NAS type Synology, ici nous nous concentrons sur Debian.
|
||||
De nombreux tutoriels existent pour configurer Samba sous Windows ou sur un NAS type Synology, ici nous nous concentrons sur Debian.
|
||||
|
||||

|
||||
|
||||
## Créer et configurer un dossier réseau partagé
|
||||
::note
|
||||
|
||||
Ici, nous allons partager le dossier `/video` d'une machine distant que nous appelerons `machine-distante`. Nous accéderons à ce dossier par la machine nommée `machine-locale`. L'utilisateur de connexion au disque réseau sera `sambauser`.
|
||||
Ici, nous allons partager le dossier `/video` d'une machine distante que nous appellerons `machine-distante`. Nous accéderons à ce dossier par la machine nommée `machine-locale`. L'utilisateur de connexion au disque réseau sera `sambauser`.
|
||||
::
|
||||
|
||||
::steps{level="3"}
|
||||
@@ -75,7 +75,7 @@ Comme nous avons configuré un partage sécurisé, nous allons devoir créer un
|
||||
sudo groupadd smbshare
|
||||
```
|
||||
|
||||
Nous allons maintenant permettre au groupe d'avoir le controle sur le dossier `/video`.
|
||||
Nous allons maintenant permettre au groupe d'avoir le contrôle sur le dossier `/video`.
|
||||
|
||||
```bash [Terminal]
|
||||
sudo chgrp -R smbshare /video
|
||||
@@ -88,7 +88,7 @@ sudo chmod 2775 /video
|
||||
```
|
||||
### Créer l'utilisateur
|
||||
|
||||
A présent nous allons ajouter un utilisateur nologin c'est à dire que cet utilisateur ne pourra pas se connecter sur le serveur pour faire des opérations, mais pourra tout de meme se connecter au service samba.
|
||||
A présent nous allons ajouter un utilisateur nologin c'est-à-dire que cet utilisateur ne pourra pas se connecter sur le serveur pour faire des opérations, mais pourra tout de même se connecter au service samba.
|
||||
|
||||
```bash [Terminal]
|
||||
sudo useradd -M -s /sbin/nologin sambauser
|
||||
@@ -126,7 +126,7 @@ sudo apt install cifs-utils
|
||||
|
||||
### Créer le dossier de destination
|
||||
|
||||
Nous allons créer un dossier sur notre serveur sur lequel sera monté le dossier partagé de notre `machine-distante`. C'est à dire que dans ce dossier nous retrouverons le contenu du dossier partagé de notre `machine-distante`. Ici nous appellerons ce dossier `/mnt/video`.
|
||||
Nous allons créer un dossier sur notre serveur sur lequel sera monté le dossier partagé de notre `machine-distante`. C'est-à-dire que dans ce dossier nous retrouverons le contenu du dossier partagé de notre `machine-distante`. Ici nous appellerons ce dossier `/mnt/video`.
|
||||
|
||||
```bash [Terminal]
|
||||
sudo mkdir /mnt/video
|
||||
@@ -155,7 +155,7 @@ password=motdepasse
|
||||
|
||||
Enregistrez avec :kbd{value="Ctrl+O"} puis :kbd{value="Entrée"}, puis quittez avec :kbd{value="Ctrl+X"}.
|
||||
|
||||
Nous allons modifier les permissions du dossier afin que seul le propriétaire puis lire et écrire dans ce fichier.
|
||||
Nous allons modifier les permissions du dossier afin que seul le propriétaire puisse lire et écrire dans ce fichier.
|
||||
|
||||
```bash [Terminal]
|
||||
sudo chmod 600 /smb/.credentials
|
||||
@@ -182,7 +182,7 @@ Vérifiez que cela a fonctionné en tapant :
|
||||
sudo mount -t cifs
|
||||
```
|
||||
|
||||
Vous verrez différentes informations qui confirmerons le succès du montage.
|
||||
Vous verrez différentes informations qui confirmeront le succès du montage.
|
||||
|
||||
Et voilà, à présent vous accédez au dossier /video de `votre machine-distante`, depuis votre `machine-locale` !
|
||||
|
||||
|
||||
@@ -30,7 +30,7 @@ Il existe plusieurs types de RAID, chacun ayant ses avantages et inconvénients.
|
||||
### Sans RAID
|
||||
|
||||
<div style="display: flex; align-items: center;">
|
||||
<img src="/img/global/no-raid.svg" alt="Image" style="max-width: 30%; max-height:230px; margin-right: 20px;">
|
||||
<img src="/img/global/no-raid.svg" alt="Disques sans redondance RAID" style="max-width: 30%; max-height:230px; margin-right: 20px;">
|
||||
<ul>
|
||||
<li>Vos disques sans RAID. Les données sont stockées disque par disque.</li>
|
||||
<li>Si vous perdez un disque, seules ses données sont perdues.</li>
|
||||
@@ -43,7 +43,7 @@ Utilisez vos disques sans RAID si vous n’avez pas peur de perdre des données
|
||||
### RAID 0
|
||||
|
||||
<div style="display: flex; align-items: center;">
|
||||
<img src="/img/global/raid0.svg" alt="Image" style="max-width: 30%; max-height:230px; margin-right: 20px;">
|
||||
<img src="/img/global/raid0.svg" alt="RAID 0 répartissant les données entre les disques" style="max-width: 30%; max-height:230px; margin-right: 20px;">
|
||||
<ul>
|
||||
<li>Le système voit un seul disque.</li>
|
||||
<li>Les données sont entrelacées entre tous les disques.</li>
|
||||
@@ -54,12 +54,12 @@ Utilisez vos disques sans RAID si vous n’avez pas peur de perdre des données
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
Utilisez RAID 0 si vous souhaitez privilégier la performance et que la perte de données n’est pas un problème. Idéal pour le stockage temporaire à haute vitesse (montage vidéo, IA, etc). Pas adapté au stockage à long terme.
|
||||
Utilisez RAID 0 si vous souhaitez privilégier la performance et que la perte de données n’est pas un problème. Idéal pour le stockage temporaire à haute vitesse (montage vidéo, IA, etc). Pas adapté au stockage à long terme, car la perte d'un seul disque entraîne la perte totale des données.
|
||||
|
||||
### RAID 1
|
||||
|
||||
<div style="display: flex; align-items: center;">
|
||||
<img src="/img/global/raid1.svg" alt="Image" style="max-width: 30%; max-height:230px; margin-right: 20px;">
|
||||
<img src="/img/global/raid1.svg" alt="RAID 1 dupliquant les données entre les disques" style="max-width: 30%; max-height:230px; margin-right: 20px;">
|
||||
<ul>
|
||||
<li>Le système voit un seul disque.</li>
|
||||
<li>Tous les disques contiennent les mêmes données.</li>
|
||||
@@ -78,7 +78,7 @@ Utilisez RAID 1 pour une redondance maximale. Chaque disque contient toutes les
|
||||
|
||||
### RAID 5
|
||||
<p align="center">
|
||||
<img src="/img/global/raid5.svg" alt="Image" style="max-width: 40%; margin-right: 20px;">
|
||||
<img src="/img/global/raid5.svg" alt="RAID 5 avec parité distribuée" style="max-width: 40%; margin-right: 20px;">
|
||||
</p>
|
||||
|
||||
- Le système voit un seul disque.
|
||||
@@ -92,7 +92,7 @@ Utilisez RAID 5 pour un stockage fiable avec 3 à 5 disques et une perte minimal
|
||||
|
||||
### RAID 6
|
||||
<p align="center">
|
||||
<img src="/img/global/raid6.svg" alt="Image" style="max-width: 50%; margin-right: 20px;">
|
||||
<img src="/img/global/raid6.svg" alt="RAID 6 avec double parité distribuée" style="max-width: 50%; margin-right: 20px;">
|
||||
</p>
|
||||
|
||||
- Le système voit un seul disque.
|
||||
|
||||
@@ -7,7 +7,7 @@ description: Introduction à ZFS, système de fichiers et gestionnaire de volume
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
|
||||
|
||||
ZFS est populaire dans le monde des serveurs, des NAS (comme FreeNAS / TrueNAS), de la virtualisation, et même chez les particuliers qui veulent un stockage résilient. C'est est un _système de fichier_ (à l'instar de NTFS pour windows, EXT4, FAT32 etc...) mais également un _gestionnaire de volume_ (comme LVM par exemple).
|
||||
ZFS est populaire dans le monde des serveurs, des NAS (comme FreeNAS / TrueNAS), de la virtualisation, et même chez les particuliers qui veulent un stockage résilient. C'est un _système de fichier_ (à l'instar de NTFS pour Windows, EXT4, FAT32 etc.) mais également un _gestionnaire de volume_ (comme LVM par exemple).
|
||||
|
||||
Pour le dire simplement :
|
||||
|
||||
@@ -17,26 +17,26 @@ Pour le dire simplement :
|
||||
ZFS dépasse largement les limites des autres systèmes de fichiers, que ce soit en termes de performance ou de fonctionnalités.
|
||||
Ce qui nous intéresse le plus :
|
||||
|
||||
- ses fonctionnalités de __gestion des instantanés__ (snaphsot), permettant de rapidement revenir en arrière en cas de problème
|
||||
- ses fonctionnalités de __gestion des instantanés__ (snapshot), permettant de rapidement revenir en arrière en cas de problème
|
||||
- sa gestion des grappes de disques et [__ses équivalent au RAID__](/general/storage/raid) (Z-Mirror, RAIDZ1, RAIDZ2, RAIDZ3)
|
||||
- sa __reconstruction automatique des données corrumpues__ (via le scrubbing)
|
||||
- sa __reconstruction automatique des données corrompues__ (via le scrubbing)
|
||||
- ses performance avec son cache RAM (ZFS ARC)
|
||||
- ses notifications en cas d'erreur
|
||||
|
||||
## Structure
|
||||

|
||||

|
||||
|
||||
ZFS dispose d'une structure particulière :
|
||||
|
||||
- __vdev__ (virtual device) : une grappe de disques (physiques ou virtuel)
|
||||
- __zpool__ : un ensemble de disques physiques ou virtuels en volume simple, Z-mirror ou RAIDZ. Un _zpool_ peut englober plusieurs _vdev_ mais pas l'inverse.
|
||||
- __dataset__ : un système de de donnée dans un _zpool_. Chaque dataset peut avoir ses propres options (compression, quotas, permissions, etc.).
|
||||
- __zpool__ : un ensemble de _vdev_ configuré comme un seul pool de stockage. Un _zpool_ peut englober plusieurs _vdev_ mais pas l'inverse.
|
||||
- __dataset__ : un conteneur logique de données dans un _zpool_. Chaque dataset peut avoir ses propres options (compression, quotas, permissions, etc.).
|
||||
|
||||
Il existe plusieurs types de dataset :
|
||||
|
||||
- __file system__ : un système de fichier, ZFS par défaut, monté comme un volume sans quota de stockage.
|
||||
- __zvol__ : un "disque virtuel" avec un quota d'espace, que vous pouvez formater/partitionner comme vous le souhaitez. Il sera utilisable comme un disque physique.
|
||||
- __snapshot__ : un état figé d’un autre dataset à un instant donné. Ils peuvent etre créés manuellement ou via des outils de sauvegarde. Ils peuvent etre montés pour parcourir les données dans leur état au moment du snapshot.
|
||||
- __snapshot__ : un état figé d’un autre dataset à un instant donné. Ils peuvent être créés manuellement ou via des outils de sauvegarde. Ils peuvent être montés pour parcourir les données dans leur état au moment du snapshot.
|
||||
|
||||
## Pourquoi ZFS vs les autres ?
|
||||
### Intégrité des données
|
||||
@@ -54,9 +54,9 @@ ZFS propose son propre système de gestion de volumes (vdev). Vous pouvez créer
|
||||
|
||||
ZFS gère cela directement, pas besoin de logiciel RAID externe.
|
||||
|
||||
::note
|
||||
::note{to="/general/storage/raid"}
|
||||
|
||||
Consultez [l'article sur le RAID](/general/storage/raid) pour en savoir plus sur la solution qui vous convient.
|
||||
Consultez l'**article sur le RAID** pour en savoir plus sur la solution qui vous convient.
|
||||
::
|
||||
|
||||
### Snapshots et clones
|
||||
|
||||
@@ -8,17 +8,17 @@ description: Les fondamentaux du matériel serveur. CPU, RAM, stockage et facteu
|
||||
|
||||

|
||||
|
||||
Un __serveur__ n'est rien d'autre qu'un ordinateur dédié à des taches particulières, ayant vocation à rester accessible en permanence. En soi, sa structure ne diffère pas d'un ordinateur classique, si ce n'est que selon l'usage cible, on fera évoluer certains composants dans un sens ou dans un autre. Dans cet article, vous trouverez un aide mémoire pour comprendre quels sont les composants essentiels d'un serveur et comprendre leur fonction selon vos usages.
|
||||
Un __serveur__ n'est rien d'autre qu'un ordinateur dédié à des tâches particulières, ayant vocation à rester accessible en permanence. En soi, sa structure ne diffère pas d'un ordinateur classique, si ce n'est que selon l'usage cible, on fera évoluer certains composants dans un sens ou dans un autre. Dans cet article, vous trouverez un aide mémoire pour comprendre quels sont les composants essentiels d'un serveur et comprendre leur fonction selon vos usages.
|
||||
|
||||
## La carte mère
|
||||
La __carte mère__ est le socle de votre machine. C'est le composant qui relie tous les autres composants. Elle sert à les faire communiquer et à interagir avec vos périphériques (clavier, souris, etc...). Il faut donc la choisir en fonction de vos besoins en terme d'entrées/sorties (I/O) comme le nombre de ports USB, de ports réseau, leur vitesse, etc... Mais il faut également veiller à sa compatibilité avec les autres composants que vous allez brancher dessus.
|
||||
La __carte mère__ est le socle de votre machine. C'est le composant qui relie tous les autres composants. Elle sert à les faire communiquer et à interagir avec vos périphériques (clavier, souris, etc.). Il faut donc la choisir en fonction de vos besoins en terme d'entrées/sorties (I/O) comme le nombre de ports USB, de ports réseau, leur vitesse, etc. Mais il faut également veiller à sa compatibilité avec les autres composants que vous allez brancher dessus.
|
||||
|
||||
Les composants importants à brancher dessus sont :
|
||||
|
||||
- le CPU
|
||||
- la RAM
|
||||
- le stockage (HDD et/ou SSD)
|
||||
- l'eventuel GPU dédié
|
||||
- l'éventuel GPU dédié
|
||||
|
||||
Il existe plusieurs formats de carte mère grand public :
|
||||
|
||||
@@ -31,50 +31,50 @@ Bien sûr, selon la taille, le nombre de ports et de fonctionnalité diffère. D
|
||||
|
||||
## Le CPU
|
||||
<div style="display: flex; align-items: center;">
|
||||
<img src="/img/global/cpu.svg" alt="Image" style="max-width: 25%; max-height:230px; margin-right: 20px;">
|
||||
<p>Le <strong>CPU</strong> (Central processor Unit) est la supercalculette de l’ordinateur. Il traite la plupart des tâches logicielles. Aujourd’hui les processeurs comportent plusieurs cœurs, parfois eux même divisé en deux de façon logicielle, afin de mieux répartir la charge de travail et optimiser son fonctionnement. Il nécessite d'etre refroidit avec un dissipateur actif (avec ventilateur) ou passif (sans ventilateur) selon la chaleur qu'iil dégage, et donc selon la puissance en Watt qu'il requiert. Dans le cadre d'un serveur, on veillera donc à le choisir selon les usages que l'on aura. </p>
|
||||
<img src="/img/global/cpu.svg" alt="Icône de CPU" style="max-width: 25%; max-height:230px; margin-right: 20px;">
|
||||
<p>Le <strong>CPU</strong> (Central Processing Unit) est la supercalculette de l’ordinateur. Il traite la plupart des tâches logicielles. Aujourd’hui les processeurs comportent plusieurs cœurs, parfois eux-mêmes divisés en deux de façon logicielle, afin de mieux répartir la charge de travail et optimiser son fonctionnement. Il nécessite d'être refroidi avec un dissipateur actif (avec ventilateur) ou passif (sans ventilateur) selon la chaleur qu'il dégage, et donc selon la puissance en Watt qu'il requiert. Dans le cadre d'un serveur, on veillera donc à le choisir selon les usages que l'on aura. </p>
|
||||
</div>
|
||||
|
||||
::warning
|
||||
|
||||
__Attention :__ N'oubliez pas que pour installer un dissipateur tiers, vous devez vous assurer qu'il soit compatible avec le socket de votre processeur, c'est à dire le socle sur lequel il est installé sur la carte mère, et que vous devez également appliquer de la pate thermique sur le CPU avant d'installer le dissipateur.
|
||||
__Attention :__ N'oubliez pas que pour installer un dissipateur tiers, vous devez vous assurer qu'il soit compatible avec le socket de votre processeur, c'est-à-dire le socle sur lequel il est installé sur la carte mère, et que vous devez également appliquer de la pâte thermique sur le CPU avant d'installer le dissipateur.
|
||||
::
|
||||
|
||||
Il faut les juger selon :
|
||||
|
||||
- Leur nombre de coeurs (plus ils en ont, plus il peuvent paralléliser les tâches)
|
||||
- La fréquence de ces coeurs en Giga Hertz _Ghz_
|
||||
- Leur nombre de cœurs (plus ils en ont, plus il peuvent paralléliser les tâches)
|
||||
- La fréquence de ces cœurs en Giga Hertz _GHz_
|
||||
- Leur consommation en Watt _W_
|
||||
|
||||
Dans le cadre d'un homelab/NAS sans calcul intensif, aujourd'hui on se dirigera facilement vers les Intel N100/150 (4 coeurs) et N305/N355 (8 coeurs) qui sont des processeurs performants à très faible consommation (rappelez vous que ces machines sont censées tourner H24).
|
||||
Dans le cadre d'un homelab/NAS sans calcul intensif, aujourd'hui on se dirigera facilement vers les Intel N100/150 (4 cœurs) et N305/N355 (8 cœurs) qui sont des processeurs performants à très faible consommation (rappelez vous que ces machines sont censées tourner H24).
|
||||
|
||||
## La RAM
|
||||
|
||||
<p align="center">
|
||||
<img src="/img/global/ram.svg" alt="Image" style="max-width: 65%; margin-right: 20px;">
|
||||
<img src="/img/global/ram.svg" alt="Icône de RAM" style="max-width: 65%; margin-right: 20px;">
|
||||
</p>
|
||||
|
||||
La __RAM__ (Random Access Memory), est une zone de stockage éphémère ultra rapide utilisée par le CPU (et l'iGPU le cas échéant) pour stocker des informations et calculs le temps de les éxecuter. Elle se vide régulièrement selon les sollicitation et se vide également à chaque extinction de la machine. Plus elle est performante, plus les calculs du processeur sont efficaces.
|
||||
La __RAM__ (Random Access Memory), est une zone de stockage éphémère ultra rapide utilisée par le CPU (et l'iGPU le cas échéant) pour stocker des informations et calculs le temps de les exécuter. Elle se vide régulièrement selon les sollicitations et se vide également à chaque extinction de la machine. Plus elle est performante, plus les calculs du processeur sont efficaces.
|
||||
|
||||
Elle prend généralement la forme de barettes, à brancher sur la carte mère. Il en existe plusieurs format selon le type de carte mère, et de plusieurs générations (DDR5 de nos jours).
|
||||
Elle prend généralement la forme de barrettes, à brancher sur la carte mère. Il en existe plusieurs format selon le type de carte mère, et de plusieurs générations (DDR5 de nos jours).
|
||||
|
||||
## Le GPU
|
||||
|
||||
Le __GPU__ (Graphical Processor Unit) est un processeur dédié aux calculs graphiques, vidéo, et parfois d'intelligence artificielle. Dans le cadre d'un serveur, il aura son utilité pour tout ce qui touche au media center (par exemple [Jellyfin](/serveex/media/jellyfin)), mais aussi en terme d'accélération matérielle pour les calculs d'IA comme la reconnaissance faciale ou la recherche sur des photos (comme via [Immich](/serveex/cloud/immich) par exemple).
|
||||
Le __GPU__ (Graphics Processing Unit) est un processeur dédié aux calculs graphiques, vidéo, et parfois d'intelligence artificielle. Dans le cadre d'un serveur, il aura son utilité pour tout ce qui touche au media center (par exemple [Jellyfin](/serveex/media/jellyfin)), mais aussi en terme d'accélération matérielle pour les calculs d'IA comme la reconnaissance faciale ou la recherche sur des photos (comme via [Immich](/serveex/cloud/immich) par exemple).
|
||||
|
||||
Selon la puissance requise, on choisira un GPU dédié avec sa propre VRAM (une carte graphique à brancher sur un port PCIe de la carte mère), ou un iGPU, c'est à dire un GPU compris dans le CPU (comme les N100/N150 et N305/N355), qui utilisera la RAM globale de la machine
|
||||
Selon la puissance requise, on choisira un GPU dédié avec sa propre VRAM (une carte graphique à brancher sur un port PCIe de la carte mère), ou un iGPU, c'est-à-dire un GPU compris dans le CPU (comme les N100/N150 et N305/N355), qui utilisera la RAM globale de la machine
|
||||
|
||||
## Le ou les HDD
|
||||
|
||||
<p align="center">
|
||||
<img src="/img/global/hdd.svg" alt="Image" style="max-width: 50%; margin-right: 20px;">
|
||||
<img src="/img/global/hdd.svg" alt="Icône de disque dur" style="max-width: 50%; margin-right: 20px;">
|
||||
</p>
|
||||
|
||||
Un __HDD__ (Hard Disk Drive) ou disque dur, est un composant servant à stocker des données. Autrefois, c'etait le stockage standard des machines informatiques. Ils sont constitués d'un ou plusieurs disques superposés en plateau, et de têtes de lecture, presque comme une platine vinyle.
|
||||
Un __HDD__ (Hard Disk Drive) ou disque dur, est un composant servant à stocker des données. Autrefois, c'était le stockage standard des machines informatiques. Ils sont constitués d'un ou plusieurs disques superposés en plateau, et de têtes de lecture, presque comme une platine vinyle.
|
||||
|
||||
Aujourd'hui, les HDD peuvent stocker des quantités extraordinaires de données (jusqu'à 30 To, soit 30 000 gigaoctets, pour les modèles grand public), mais ils restent limités en vitesse de lecture et d'écriture par leur nature mécanique. Ils sont également volumineux et très lourds.
|
||||
|
||||
De manière générale, on les privilégiera pour stocker des données qui ne servent pas à des calculs et ne nécessitent pas d'ecriture rapide, comme les media (videos, photos...) ou les cloud drive, stockage d'archives, etc. Ils sont performants dans ces scenario et surtout coutent beaucoup moins cher que des SSD à espace de stockage égal.
|
||||
De manière générale, on les privilégiera pour stocker des données qui ne servent pas à des calculs et ne nécessitent pas d'écriture rapide, comme les media (vidéos, photos...) ou les cloud drive, stockage d'archives, etc. Ils sont performants dans ces scénarios et surtout coûtent beaucoup moins cher que des SSD à espace de stockage égal.
|
||||
|
||||
::tip{icon="" to="/general/storage/raid"}
|
||||
✨ __Astuce :__ combinez plusieurs HDD en **RAID** pour améliorer les performances et la redondance.
|
||||
@@ -85,31 +85,31 @@ Il existe plusieurs formats de HDD : 3.5" et 2.5". De manière générale dans u
|
||||
## Le ou les SSD
|
||||
|
||||
<p align="center">
|
||||
<img src="/img/global/nvme.svg" alt="Image" style="max-width: 50%; margin-right: 20px;">
|
||||
<img src="/img/global/nvme.svg" alt="Icône de SSD NVMe" style="max-width: 50%; margin-right: 20px;">
|
||||
</p>
|
||||
|
||||
Un __SSD__ (Solid State Drive) est une petite carte sur laquelle sont soudées des puces de mémoires servant à stocker de l'information. Contrairement à la RAM, ces puces conservent les informations même lorsqu'elles ne sont pas alimentées et donc les conservent après un redémarrage. C'est ce qui sert globalement de stockage principal pour votre serveur.
|
||||
|
||||
Contrairement aux HDD, ils ne disposent pas de parties mécaniques, sont très miniaturisés et surtout extrêmement rapides, de l'ordre de plusieurs gigaoctets par seconde pour les plus performants.
|
||||
|
||||
On les trouve dans plusieurs formats, aujourd'hui on priviligiera les versions M.2 NVMe, car ce sont les plus petits et plus rapides, et sont devenu un standard sur les cartes mères.
|
||||
On les trouve dans plusieurs formats, aujourd'hui on privilégiera les versions M.2 NVMe, car ce sont les plus petits et plus rapides, et sont devenues un standard sur les cartes mères.
|
||||
|
||||
Ils sont en revanche beaucoup plus chers que les disque durs à capacité de stockage égale. Généralement, on y stockera au moins le système d'exploitation de la machine (Operating System ou OS) pour garantir une certaine rapidité d'execution. Dans le cadre d'un serveur, on y stockera aussi si possible les conteneurs type [docker](/serveex/core/docker) et les bases de données. De manière générale, toute données dont un a besoin régulièrement et rapidement pour des calculs (site web, applications, etc...).
|
||||
Ils sont en revanche beaucoup plus chers que les disque durs à capacité de stockage égale. Généralement, on y stockera au moins le système d'exploitation de la machine (Operating System ou OS) pour garantir une certaine rapidité d'exécution. Dans le cadre d'un serveur, on y stockera aussi si possible les conteneurs type [docker](/serveex/core/docker) et les bases de données. De manière générale, toutes les données dont on a besoin régulièrement et rapidement pour des calculs (site web, applications, etc.) devraient être stockées sur un SSD.
|
||||
|
||||
## La carte réseau
|
||||
|
||||
Une __carte réseau__ sert à faire communiquer votre machine avec votre réseau (dont internet). Elle est composée d'une puce de controle et d'un ou plusieurs port réseau. Ces ports peuvent dits _ports ethernet_ peuvent être dans plusieurs formats physique et dans plusieurs normes de débit :
|
||||
Une __carte réseau__ sert à faire communiquer votre machine avec votre réseau (dont internet). Elle est composée d'une puce de contrôle et d'un ou plusieurs port réseau. Ces ports, aussi appelés _ports ethernet_, existent dans plusieurs formats physiques et plusieurs normes de débit :
|
||||
|
||||
- RJ45 Gigabit ethernet 10/100/1000 : le format standard de prise RJ45 permettant de dialoguer à des débit allant de 10Mbps (soit 1,25Mo/s) à 1000Mbps (soit 125Mo/s)
|
||||
- RJ45 2.5G : Même prise, pouvant dialoguer jusqu'à 2,5Gpbs soit 2 500Mbps (donc 312,5Mo/s)
|
||||
- RJ45 5G : Même prise, pouvant dialoguer jusqu'à 5Gpbs (donc 625Mo/s)
|
||||
- RJ45 10G Base T : Même prise pouvant dialoguer jusqu'à 10Gbs (soit 1,25Go/s)
|
||||
- SFP 1G : Prise SFP, généralement utilisée pour la fibre optique, pouvant dialoguer jusqu'à 1Gpbs
|
||||
- SFP+ 10G : Prise SFP amélioriée, aussi utilisée pour la fibre optique, pouvant dialoguer jusqu'à 10Gbps.
|
||||
- RJ45 2.5G : Même prise, pouvant dialoguer jusqu'à 2,5Gbps soit 2 500Mbps (donc 312,5Mo/s)
|
||||
- RJ45 5G : Même prise, pouvant dialoguer jusqu'à 5Gbps (donc 625Mo/s)
|
||||
- RJ45 10G Base T : Même prise pouvant dialoguer jusqu'à 10Gbps (soit 1,25Go/s)
|
||||
- SFP 1G : Prise SFP, généralement utilisée pour la fibre optique, pouvant dialoguer jusqu'à 1Gbps
|
||||
- SFP+ 10G : Prise SFP améliorée, aussi utilisée pour la fibre optique, pouvant dialoguer jusqu'à 10Gbps.
|
||||
|
||||
::warning
|
||||
|
||||
__Attention :__ Pensez bien à dimensionner vos appareils réseaux (routeurs, switch, cables...) en fonction du débit que vous souhaitez entre vos appareils. D'autre part, il existe plusieurs normes de cables RJ45 selon la vitesse permise. On privilegiera dans la plupart des cas des cables RJ45 CAT5E, et au delà de 10Gbps, on privilégiera du CAT6A, bien que le CAT5E soit utilisable à ces vitesses à courte distance. Quant à la fibre, c'est tout un sujet (simplex, duplex, transceiver...).
|
||||
__Attention :__ Pensez bien à dimensionner vos appareils réseaux (routeurs, switch, câbles...) en fonction du débit que vous souhaitez entre vos appareils. D'autre part, il existe plusieurs normes de câbles RJ45 selon la vitesse permise. On privilégiera dans la plupart des cas des câbles RJ45 CAT5E, et au-delà de 10Gbps, on privilégiera du CAT6A, bien que le CAT5E soit utilisable à ces vitesses à courte distance. Quant à la fibre, c'est tout un sujet (simplex, duplex, transceiver...).
|
||||
::
|
||||
|
||||
La carte réseau est généralement directement intégrée à la carte mère, mais vous pouvez aussi utiliser des cartes réseau dédiées, par exemple en USB ou via un port d'extension PCIe.
|
||||
@@ -137,18 +137,18 @@ Une alimentation se caractérise par plusieurs éléments clés :
|
||||
- sa modularité (câbles fixes ou détachables),
|
||||
- son rendement (en pourcentage). Par exemple, une alimentation de 500W avec 80% de rendement tirera en réalité 625W au mur pour fournir 500W à la machine.
|
||||
|
||||
Un autre facteur important est le format. Il en existe plusieurs standard, comme ATX L pour les plus grandes jusqu'à SFX pour les plus petites. Il en existe aussi des spécifiques aux serveurs rackables, par définition assez plats.
|
||||
Un autre facteur important est le format. Il en existe plusieurs standards, comme ATX L pour les plus grandes jusqu'à SFX pour les plus petites. Il en existe aussi des spécifiques aux serveurs rackables, par définition assez plats.
|
||||
|
||||
Pour choisir votre alimentation, la convention est d'estimer la puissance electrique demandée par votre machine à usage et de multiplier par deux cette puissance. En effet, le rendement des alimentations se situe environ à 50% de sa charge totale.
|
||||
Pour choisir votre alimentation, la convention est d'estimer la puissance électrique demandée par votre machine à usage et de multiplier par deux cette puissance. En effet, le rendement des alimentations se situe environ à 50% de sa charge totale.
|
||||
|
||||
## Le boitier
|
||||
## Le boîtier
|
||||
|
||||
<div style="display: flex; align-items: center;">
|
||||
<img src="/img/global/case.svg" alt="Image" style="max-width: 25%; max-height:230px; margin-right: 20px;">
|
||||
<p>Le <strong>boitier</strong> est également un composant essentiel pour votre machine. Il joue un rôle clé dans le refroidissement, avec ses ventilateurs et sa conception des flux d'air, et il détermine la compatibilité de format de votre carte mère, de votre alimentation et de l'éventuel GPU dédié que vous installerez.
|
||||
<img src="/img/global/case.svg" alt="Icône de boîtier" style="max-width: 25%; max-height:230px; margin-right: 20px;">
|
||||
<p>Le <strong>boîtier</strong> est également un composant essentiel pour votre machine. Il joue un rôle clé dans le refroidissement, avec ses ventilateurs et sa conception des flux d'air, et il détermine la compatibilité de format de votre carte mère, de votre alimentation et de l'éventuel GPU dédié que vous installerez.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
Par ailleurs, le boitier détermine combien de HDD vous pouvez installer et quels formats ils acceptent. Certains boitiers sont rackables, c'est-à-dire qu'ils peuvent être installés dans des racks (baies serveurs).
|
||||
Par ailleurs, le boîtier détermine combien de HDD vous pouvez installer et quels formats ils acceptent. Certains boîtiers sont rackables, c'est-à-dire qu'ils peuvent être installés dans des racks (baies serveurs).
|
||||
|
||||
Choisissez votre boitier avec soin en fonction de vos besoins précis et du matériel que vous comptez utiliser.
|
||||
Choisissez votre boîtier avec soin en fonction de vos besoins précis et du matériel que vous comptez utiliser.
|
||||
|
||||
@@ -8,20 +8,20 @@ description: Aperçu du matériel réseau pour homelab. Switches, cartes réseau
|
||||
|
||||

|
||||
|
||||
Un réseau informatique est indissociable du matériel nécessaire à le mettre en place. Le matériel va conditionner les dimension du réseau, les vitesses de communication et les performances du réseau. Dans cet article, nous nous limiterons au réseau les plus simples, composant généralement ceux que l'on peut retrouver chez soi.
|
||||
Un réseau informatique est indissociable du matériel nécessaire à sa mise en place. Le matériel va conditionner les dimensions du réseau, les vitesses de communication et les performances du réseau. Dans cet article, nous nous limiterons aux réseaux les plus simples, ceux que l'on peut généralement retrouver chez soi.
|
||||
|
||||
## Le routeur
|
||||
Le __routeur__ est le point central de votre réseau. C'est lui qui dirige les __paquets__, c'est à dire les blocs d'informations qui transitent sur votre réseau, de l'émetteur vers le bon destinataire. Il permet à la fois de conditionner le routage de l'information au sein de votre réseau mais aussi vers ou depuis l'exterieur. Globalement, il fait communiquer les appareils entre eux et avec internet.
|
||||
Le __routeur__ est le point central de votre réseau. C'est lui qui dirige les __paquets__, c'est-à-dire les blocs d'informations qui transitent sur votre réseau, de l'émetteur vers le bon destinataire. Il permet à la fois de conditionner le routage de l'information au sein de votre réseau mais aussi vers ou depuis l'extérieur. Globalement, il fait communiquer les appareils entre eux et avec internet.
|
||||
|
||||
Vous avez tous un routeur chez vous, c'est la __box__ de votre _FAI_ (Fournisseur d'Accès à Internet).
|
||||
|
||||
Plus généralement, un routeur est composé :
|
||||
|
||||
- d'un port WAN (Wide Area Network) recevant les informations depuis l'internet (ou un réseau de hiérarchie supérieure). Par exemple un port recevant la fibre optique de votre opérateur, ou un port SFP+/RJ45 pour un routeur tiers.
|
||||
- d'un switch, c'est à dire d'un hub composé de plusieurs ports __LAN__ (Local Area Network) permettant de connecter plusieurs lignes et appareils à votre routeur. Ils peuvent etre RJ45 ou SFP/SFP+.
|
||||
- parfois d'un emetteur/recepteur WiFi
|
||||
- d'un switch, c'est-à-dire d'un hub composé de plusieurs ports __LAN__ (Local Area Network) permettant de connecter plusieurs lignes et appareils à votre routeur. Ils peuvent être RJ45 ou SFP/SFP+.
|
||||
- parfois d'un émetteur/récepteur WiFi
|
||||
|
||||
Le routeur peut posséder des capacité de _firewall_, c'est à dire de limiter le traffic d'appareils en particulier, et de _[NAT (Network Adress Translation)](/general/networking/nat)_, c'est à dire de redirection de port. Il possède aussi généralement un _[DHCP (Dynamic Host Configuration Protocol)](/general/networking/nat#le-dhcp)_, servant à attribuer dynamiquement des _adresses IP_ à votre matériel branché au réseau.
|
||||
Le routeur peut posséder des capacités de _firewall_, c'est-à-dire de limiter le trafic d'appareils en particulier, et de _[NAT (Network Address Translation)](/general/networking/nat)_, c'est-à-dire de redirection de port. Il possède aussi généralement un _[DHCP (Dynamic Host Configuration Protocol)](/general/networking/nat#le-dhcp)_, servant à attribuer dynamiquement des _adresses IP_ à votre matériel branché au réseau.
|
||||
|
||||
Le routeur conditionne directement la vitesse de communication entre vos appareils. En effet, le port WAN conditionne le débit qu'il peut recevoir de la part de votre FAI. Si vous avez un abonnement de 5 Gb/s, il vous faudra un port WAN d'au moins 5 Gb/s. Mais il conditionne également la vitesse de communication entre vos équipements. Si vous avez des appareils qui communiquent à 5 Gb/s, il faudra que la partie _switch_ du routeur disposent de ports 5 Gb/s. Enfin, si vous avez du matériel WiFi 7 et que vous souhaitez profiter de ces débits, il faudra également que votre routeur le supporte. Et dans le cas d'une borne Wifi tierce, n'oubliez pas que son port réseau doit disposer d'un débit au moins égale au WiFi qu'il diffuse, et le routeur également.
|
||||
|
||||
@@ -29,16 +29,16 @@ Débit internet, nombre d'équipements à brancher, débit WiFi, débit réseau,
|
||||
|
||||
::tip{icon=""}
|
||||
✨ __Astuce :__
|
||||
Vous pouvez utiliser sans difficulté un routeur tiers pour votre réseau qui remplacera la gestion de votre box internet si celle-ci surpporte le mode _Bridge_. En France seul l'opérateur Free le permet. C'est également possible avec les opérateurs ne disposant pas de ce mode, mais avec de grandes difficultés et sans toutes les fonctionnalités qu'un routeur tiers pourrait vous apporter.
|
||||
Vous pouvez utiliser sans difficulté un routeur tiers pour votre réseau qui remplacera la gestion de votre box internet si celle-ci supporte le mode _Bridge_. En France seul l'opérateur Free le permet. C'est également possible avec les opérateurs ne disposant pas de ce mode, mais avec de grandes difficultés et sans toutes les fonctionnalités qu'un routeur tiers pourrait vous apporter.
|
||||
::
|
||||
|
||||
## Le Switch
|
||||
|
||||
Le __switch__ ou commutateur, est un appareil qui permet de brancher plusieurs appareils au réseau. C'est littéralement un hub, qui se connecte directement au routeur ou à un autre switch, jusqu'au routeur. Il permet d'éviter de saturer toutes les prises switch du routeur, ou de délocaliser le matériel dans une autre pièce, sans tirer un cable par appareil vers le routeur. Un autre cas d'usage est de pouvoir séparer plusieurs réseaux gérés par un meme routeur.
|
||||
Le __switch__ ou commutateur, est un appareil qui permet de brancher plusieurs appareils au réseau. C'est littéralement un hub, qui se connecte directement au routeur ou à un autre switch, jusqu'au routeur. Il permet d'éviter de saturer toutes les prises switch du routeur, ou de délocaliser le matériel dans une autre pièce, sans tirer un câble par appareil vers le routeur. Un autre cas d'usage est de pouvoir séparer plusieurs réseaux gérés par un même routeur.
|
||||
|
||||
Il en existe globalement de deux types :
|
||||
|
||||
- Les switch non managés, les plus courants. Ils sont plug-n-play, c'est à dire que vous les branchez et tout est réglé tout seul.
|
||||
- Les switch non managés, les plus courants. Ils sont plug-n-play, c'est-à-dire que vous les branchez et tout est réglé tout seul.
|
||||
- Les switchs managés. Ils disposent d'une interface de configuration (en ligne de commande ou via une interface web), servant à affiner les règles de routages asservies au routeur. C'est très efficace pour séparer des réseaux virtuels entre vos appareils, mais généralement nécessite beaucoup de temps de configuration et sont moins pratiques à utiliser qu'un simple switch non managé.
|
||||
|
||||
::warning
|
||||
@@ -46,22 +46,22 @@ Il en existe globalement de deux types :
|
||||
__Attention :__ Veillez à bien utiliser un switch avec des ports disposant des débits cohérents avec le matériel de votre réseau
|
||||
::
|
||||
|
||||
## Les cables
|
||||
## Les câbles
|
||||
|
||||
Les cables sont des composants essentiels de votre réseau. Selon leur type et catégorie, ils limiteront le débit entre vos appareils et nécessitent donc d'etre dimensionnés de manière cohérente avec votre réseau. Ils doivent aussi être compatibles avec les ports de vos appareils.
|
||||
Les câbles sont des composants essentiels de votre réseau. Selon leur type et catégorie, ils limiteront le débit entre vos appareils et nécessitent donc d'être dimensionnés de manière cohérente avec votre réseau. Ils doivent aussi être compatibles avec les ports de vos appareils.
|
||||
|
||||
Voici un rappel des normes de cables et de ports les plus courantes :
|
||||
Voici un rappel des normes de câbles et de ports les plus courantes :
|
||||
|
||||
- **RJ45 Gigabit Ethernet 10/100/1000** : le format standard de prise RJ45 permettant de dialoguer à des débit allant de 10Mbps (soit 1,25Mo/s) à 1000Mbps (soit 125Mo/s)
|
||||
- **RJ45 2.5G** : Même prise, pouvant dialoguer jusqu'à 2,5Gpbs soit 2 500Mbps (donc 312,5Mo/s)
|
||||
- **RJ45 5G** : Même prise, pouvant dialoguer jusqu'à 5Gpbs (donc 625Mo/s)
|
||||
- **RJ45 2.5G** : Même prise, pouvant dialoguer jusqu'à 2,5Gbps soit 2 500Mbps (donc 312,5Mo/s)
|
||||
- **RJ45 5G** : Même prise, pouvant dialoguer jusqu'à 5Gbps (donc 625Mo/s)
|
||||
- **RJ45 10GBase-T** : Même prise pouvant dialoguer jusqu'à 10Gb/s (soit 1,25Go/s)
|
||||
- **SFP 1G** : Prise SFP, généralement utilisée pour la fibre optique, pouvant dialoguer jusqu'à 1Gpbs
|
||||
- **SFP+ 10G** : Prise SFP amélioriée, aussi utilisée pour la fibre optique, pouvant dialoguer jusqu'à 10Gb/s.
|
||||
- **SFP 1G** : Prise SFP, généralement utilisée pour la fibre optique, pouvant dialoguer jusqu'à 1Gbps
|
||||
- **SFP+ 10G** : Prise SFP améliorée, aussi utilisée pour la fibre optique, pouvant dialoguer jusqu'à 10Gb/s.
|
||||
|
||||
### Les cables Ethernet
|
||||
### Les câbles Ethernet
|
||||
|
||||
Ces cables en cuivre disposent généralement d'une prise dite `RJ45`. C'est la prise la plus standard du matériel réseau, que vous retrouvez sur vos routeurs et vos switch.
|
||||
Ces câbles en cuivre disposent généralement d'une prise dite `RJ45`. C'est la prise la plus standard du matériel réseau, que vous retrouvez sur vos routeurs et vos switch.
|
||||
|
||||
Ils sont définis en plusieurs catégorie, définissant le débit maximal selon la distance :
|
||||
|
||||
@@ -74,42 +74,42 @@ Ils sont définis en plusieurs catégorie, définissant le débit maximal selon
|
||||
| | CAT 5e | 30 m |
|
||||
| 2.5 Gb/s | CAT 5e | 100 m |
|
||||
| 1 Gb/s | CAT 5e | 100 m |
|
||||
| 100 Mbs | CAT 5 | 100 m |
|
||||
| 100 Mb/s | CAT 5 | 100 m |
|
||||
|
||||
Certains de ces cables sont plats, ronds, blindés (à relier à la terre), etc. Choisissez en fonction de votre installation. ce qu'il faut comprendre, c'est que pour relier un appareil qui dispose d'une prise RJ45 ethernet 2.5 Gb/s sur un routeur 2.5G b/s, il faut au moins un cable `CAT 5e`.
|
||||
Certains de ces câbles sont plats, ronds, blindés (à relier à la terre), etc. Choisissez en fonction de votre installation. ce qu'il faut comprendre, c'est que pour relier un appareil qui dispose d'une prise RJ45 ethernet 2.5 Gb/s sur un routeur 2.5G b/s, il faut au moins un câble `CAT 5e`.
|
||||
|
||||
En revanche, si votre appareil est limité à 100 Mb/s, vous n'avez besoin que d'un cable `CAT 5`.
|
||||
En revanche, si votre appareil est limité à 100 Mb/s, vous n'avez besoin que d'un câble `CAT 5`.
|
||||
|
||||
Aujourd'hui, dans les nouvelles construction, la norme est d'installer des cables `CAT 6A` dans les murs. Ainsi, les prises murales sont prêtes à accepter du 10 Gb/s sur 100 m
|
||||
Aujourd'hui, dans les nouvelles constructions, la norme est d'installer des câbles `CAT 6A` dans les murs. Ainsi, les prises murales sont prêtes à accepter du 10 Gb/s sur 100 m
|
||||
|
||||
|
||||
### Les cables optiques
|
||||
### Les câbles optiques
|
||||
|
||||
Très fins mais très fragile, on commence à les voir de plus en plus dans les installations chez soi. A commencer par le cable opérateur qui relie votre prise fibre à votre box/routeur. Ils ont plusieurs avantages :
|
||||
Très fins mais très fragiles, on commence à les voir de plus en plus dans les installations chez soi. À commencer par le câble opérateur qui relie votre prise fibre à votre box/routeur. Ils ont plusieurs avantages :
|
||||
|
||||
- Extrêmement compacts
|
||||
- Consommation électrique nulle (contrairement au cuivre, qui perd de l'énergie en chaleur)
|
||||
- Aucun rayonnement électromagnétique (pas besoin de blindage, pas de perturbation du signal)
|
||||
- Débits très élevés sur de longues distances
|
||||
|
||||
Pour du réseau local, il faut comprendre qu'il existe plusieurs types de cables fibres, conditionnant le débit selon la distance, et conditionnant le type de `transceiver` à utiliser. En effet, les cables fibres se branchent sur les ports SFP+ de vos appareils, via un petit objet qui traduit le signal lumineux en information électrique, et qui, dans le sens inverse, traduit les informations électrique en signal lumineux.
|
||||
Pour du réseau local, il faut comprendre qu'il existe plusieurs types de câbles fibres, conditionnant le débit selon la distance, et conditionnant le type de `transceiver` à utiliser. En effet, les câbles fibres se branchent sur les ports SFP+ de vos appareils, via un petit objet qui traduit le signal lumineux en information électrique, et qui, dans le sens inverse, traduit les informations électriques en signal lumineux.
|
||||
|
||||
Globalement, pour du réseau local, on évitera de choisir autre chose qu'un cable multimode OM3 avec prise LC, avec un transceiver LC SFP+ 10G. Cela permet de relier des appareils en 10 Gb/s et est compatible avec la plupart des appareils disposant d'un port SFP+.
|
||||
Globalement, pour du réseau local, on évitera de choisir autre chose qu'un câble multimode OM3 avec prise LC, avec un transceiver LC SFP+ 10G. Cela permet de relier des appareils en 10 Gb/s et est compatible avec la plupart des appareils disposant d'un port SFP+.
|
||||
|
||||
::warning
|
||||
|
||||
__Attention :__ Veillez à bien utiliser des `transceiver` compatibles avec vos materiels (routeur, switch ou appareil). Il n'existe pas encore de standard absolu, les constructeurs précisent généralement les marques compatibles.
|
||||
__Attention :__ Veillez à bien utiliser des `transceiver` compatibles avec vos matériels (routeur, switch ou appareil). Il n'existe pas encore de standard absolu, les constructeurs précisent généralement les marques compatibles.
|
||||
::
|
||||
|
||||
|
||||
### Les cables DAC
|
||||
### Les câbles DAC
|
||||
|
||||
Ce sont des cables en cuivre fichés dans des `transceiver`. Ils permettent à deux ports SFP/SFP+ de dialoguer, à courte distance, sans utiliser une fibre plus fragile ou d'adapteteur RJ45. Cependant, ils demandent plus d'énergie, la deperdition dans le cuivre etant non négligeable.
|
||||
Ce sont des câbles en cuivre fichés dans des `transceiver`. Ils permettent à deux ports SFP/SFP+ de dialoguer, à courte distance, sans utiliser une fibre plus fragile ou d'adaptateur RJ45. Cependant, ils demandent plus d'énergie, la déperdition dans le cuivre étant non négligeable.
|
||||
|
||||
|
||||
### Les transceiver SFP+
|
||||
|
||||
Ils permettent de connecter différents types de cables à vos ports SFP/SFP+. Il en existe pour :
|
||||
Ils permettent de connecter différents types de câbles à vos ports SFP/SFP+. Il en existe pour :
|
||||
|
||||
- la fibre optique
|
||||
- le DAC
|
||||
@@ -117,5 +117,5 @@ Ils permettent de connecter différents types de cables à vos ports SFP/SFP+. I
|
||||
|
||||
::warning
|
||||
|
||||
__Attention :__ Un transceiver RJ45 consommera beaucoup d'energie due à la deperdition naturelle dans le cuivre, et donc génerera beaucoup de chaleur. Il existe des transceiver basse consommation, consommant moins de 2W. De manière peu intuitive, ils sont généralement indiqués pour des cables plus long (80m au lieu de 30m). Ils sont conseillés plutot que ceux indiqués pour les cables plus court car ces derniers dégagent plus de chaleur et demandent plus d'energie, ce qui peut poser des problemes de compatibilité avec votre matériel, et dégrader votre réseau, voir le couper.
|
||||
__Attention :__ Un transceiver RJ45 consommera beaucoup d'énergie due à la déperdition naturelle dans le cuivre, et donc générera beaucoup de chaleur. Il existe des transceiver basse consommation, consommant moins de 2W. De manière peu intuitive, ils sont généralement indiqués pour des câbles plus longs (80m au lieu de 30m). Ils sont conseillés plutôt que ceux indiqués pour les câbles plus courts car ces derniers dégagent plus de chaleur et demandent plus d'énergie, ce qui peut poser des problèmes de compatibilité avec votre matériel, et dégrader votre réseau, voire le couper.
|
||||
::
|
||||
|
||||
@@ -12,7 +12,7 @@ Cet article a été écrit avant l'augmentation __massive__ des prix du matérie
|
||||
|
||||
Lorsque l'on se lance dans l'aventure de son serveur chez soi, on se pose souvent la question _« Avec quoi dois-je commencer ? »_, _« Cela coûte cher non ? »_, et on finit soit par ne pas le faire, soit par acheter un NAS propriétaire qu'on jettera à la poubelle au bout d'un an quand on aura compris que cela n'apporte rien à part des problèmes et de l'argent jeté par la fenêtre.
|
||||
|
||||
Un serveur, ce n'est pas une armoire. C'est n'importe quel ordinateur capable de faire tourner linux. C'est pour cela que les mini PC à base de processeurs N100 sont populaires. Pour 100-130€ sur des plateformes chinoises on a une machine sous linux capable de tourner H24 des années durant, et d'executer tout ce qu'on attend d'un serveur/cloud chez soi sans perdre en performances.
|
||||
Un serveur, ce n'est pas une armoire. C'est n'importe quel ordinateur capable de faire tourner Linux. C'est pour cela que les mini PC à base de processeurs N100 sont populaires. Pour 100-130€ sur des plateformes chinoises on a une machine sous linux capable de tourner H24 des années durant, et d'exécuter tout ce qu'on attend d'un serveur/cloud chez soi sans perdre en performances.
|
||||
|
||||
Ce n'est objectivement pas cher et n'importe qui s'intéressant au sujet peut se lancer dans l'aventure.
|
||||
|
||||
@@ -20,7 +20,7 @@ Un Mini PC à 100 balles + un dock USB à 50 balles accueillant des disques durs
|
||||
|
||||
C'est tout simplement ça le **ProloNAS, un NAS accessible pour les prolo**. Charge à vous ensuite de calibrer votre besoin en Disques Durs.
|
||||
|
||||

|
||||

|
||||
|
||||
## Exemple de matériel
|
||||
|
||||
@@ -32,11 +32,11 @@ C'est tout simplement ça le **ProloNAS, un NAS accessible pour les prolo**. Cha
|
||||
|
||||
## Pourquoi un NAS ?
|
||||
|
||||
Un NAS (Network Attached Storage), c'est une machine conçue autour d'un espace de stockage ayant vocation a être partagé sur un réseau. L'idée du NAS, c'est d'avoir un stockage fiable et sécurisé sur lequel s'appuie nos usages et nos applicatifs comme des données cloud par exemple (un drive comme [Nextcloud](/serveex/cloud/nextcloud), une synchro photo comme [Immich](/serveex/cloud/immich). Mais aussi vos media comme vos films (par exemple avec [Jellyfin](/serveex/media/jellyfin)) ou les videos de vos caméra de surveillance.
|
||||
Un NAS (Network Attached Storage), c'est une machine conçue autour d'un espace de stockage ayant vocation à être partagé sur un réseau. L'idée du NAS, c'est d'avoir un stockage fiable et sécurisé sur lequel s'appuie nos usages et nos applicatifs comme des données cloud par exemple (un drive comme [Nextcloud](/serveex/cloud/nextcloud), une synchro photo comme [Immich](/serveex/cloud/immich)). Mais aussi vos media comme vos films (par exemple avec [Jellyfin](/serveex/media/jellyfin)) ou les vidéos de vos caméras de surveillance.
|
||||
|
||||
### Mais pourquoi un Mini PC avec un disque dur externe ne suffirait-il pas ?
|
||||
|
||||
Bien sûr, un simple mini PC avec ses 1 à 2To de stockage devraient suffire pour la plupart des gens. Et les films pourraient tenir dans un disque dur externe de quelques TB supplémentaire. En revanche ce n'est pas une solution fiable ni extensible de faire tourner ses applications et usages sur du stockage qui au moindre choc, au moindre probleme, fait perdre vos données définitivement.
|
||||
Bien sûr, un simple mini PC avec ses 1 à 2To de stockage devrait suffire pour la plupart des gens. Et les films pourraient tenir dans un disque dur externe de quelques TB supplémentaires. En revanche ce n'est pas une solution fiable ni extensible de faire tourner ses applications et usages sur du stockage qui au moindre choc, au moindre problème, fait perdre vos données définitivement.
|
||||
|
||||
Le vrai NAS est construit autour de la fiabilité du support qui contient vos données. Il nécessite de mettre en place des stratégies de stockages type [RAID](/general/storage/raid) afin de préserver vos données en cas de panne et de la sauvegarde en cas de corruption (comme les snapshot [ZFS](/general/storage/zfs)).
|
||||
|
||||
@@ -50,25 +50,25 @@ De nombreuses marques proposent des plateformes prêtes à accueillir vos disque
|
||||
|
||||
350€, c'est le prix de départ d'un NAS 2 baies (sans les disques) chez Syno, avec un processeur qui date de 2019, pas de logement pour un SSD pour l'OS, et 2 pauvres giga-octets de RAM.
|
||||
|
||||
Rappelez vous le **ProloNAS** : un N100 4 coeurs, 16Go de RAM, un SSD de 512Go, pour 100-130€ et un DAS 4 baies à 55€. Soit deux fois moins que le Syno 2 baies, 4 fois moins que le Syno 4 baies.
|
||||
Rappelez vous le **ProloNAS** : un N100 4 cœurs, 16Go de RAM, un SSD de 512Go, pour 100-130€ et un DAS 4 baies à 55€. Soit deux fois moins que le Syno 2 baies, 4 fois moins que le Syno 4 baies.
|
||||
|
||||
### OS limités
|
||||
|
||||
« Oui mais ok l'argument du prix, mais au moins tu lances le truc et c'est bon, t'as de jolies applications qui tournent toute seule sans maintenance ».
|
||||
|
||||
Une année.
|
||||
Une année c'est le temps qu'il m'a fallu pour jeter à la poubelle mon Syno en me disant que j'aurais du dès le départ partir sur mon **ProloNAS** (devenu un vrai serveur, depuis).
|
||||
Une année c'est le temps qu'il m'a fallu pour jeter à la poubelle mon Syno en me disant que j'aurais dû dès le départ partir sur mon **ProloNAS** (devenu un vrai serveur, depuis).
|
||||
|
||||
Les constructeurs vous mettent à disposition des OS linux customisés à leur sauce, ne partageant pas les catalogues d'applications linux des distributions majeures, avec des noyaux linux datant souvent de l'antiquité, et surtout des OS tres fermés ne vous permettant pas de développer votre NAS exactement selon vos besoins. En gros, soit vous utilisez leurs applications, soit vous rentrer dans un monde de souffrance. Pour donner un exemple, de nombreux conteneurs docker ne fonctionnent pas sur ces NAS constructeurs car le kernel est tellement vieux qu'il ne peut supporter les versions pourtant pas toujours récentes de docker.
|
||||
Les constructeurs vous mettent à disposition des OS Linux customisés à leur sauce, ne partageant pas les catalogues d'applications Linux des distributions majeures, avec des noyaux linux datant souvent de l'antiquité, et surtout des OS très fermés ne vous permettant pas de développer votre NAS exactement selon vos besoins. En gros, soit vous utilisez leurs applications, soit vous rentrez dans un monde de souffrance. Pour donner un exemple, de nombreux conteneurs docker ne fonctionnent pas sur ces NAS constructeurs car le kernel est tellement vieux qu'il ne peut supporter les versions pourtant pas toujours récentes de docker.
|
||||
|
||||
### Dépendance des mises à jours propriétaires
|
||||
### Dépendance des mises à jour propriétaires
|
||||
|
||||
« Oui mais moi j'ai pas d'autre usages que ce que leurs applicatifs natifs proposent ».
|
||||
Oui oui, moi aussi j'ai cru ça. Mais 1 an après mon Syno, mes usages ont explosés. Media center, gestion de mot de passe, plateforme git, plateforme de développement, Authentification forte et SSO hébergement web... Pourquoi etre bloqués par les solutions constructeurs jamais excellentes, souvent baclées et compatibles avec rien ?
|
||||
Oui oui, moi aussi j'ai cru ça. Mais 1 an après mon Syno, mes usages ont explosé. Media center, gestion de mot de passe, plateforme git, plateforme de développement, Authentification forte et SSO hébergement web... Pourquoi être bloqués par les solutions constructeurs jamais excellentes, souvent bâclées et compatibles avec rien ?
|
||||
|
||||
D'autre part, ces applicatifs, vous devenez dépendant de la bonne volonté du constructeur, en terme de sécurité, de mises à jour, et de disponibilités. Je préfère confier cette dépendance à des projets open-source, mis à jour plus régulièrement et ne dépendant pas de la bonne volonté d'un board commercial.
|
||||
D'autre part, avec ces applicatifs propriétaires, vous devenez dépendant de la bonne volonté du constructeur, en terme de sécurité, de mises à jour, et de disponibilité. Je préfère confier cette dépendance à des projets open-source, mis à jour plus régulièrement et ne dépendant pas de la bonne volonté d'un board commercial.
|
||||
|
||||
Et cela ne s'arrête pas là, qui vous dit que les disques dur que vous avez inséré dans ces NAS proproietaires vont etre supportés ? Synology a rendu incompatible son matériel avec les marques n'ayant pas un partenariat avec eux, afin de booster la vente de leurs propres disques. Qui vous dit que votre media center pourra profiter des performances de l'iGPU de votre processeur pour streamer vos media vers vos appareils ? [Synology a désactivé le transcodage matériel de ses NAS](https://www.cachem.fr/synology-desactive-transcodage-materiel-nas/).
|
||||
Et cela ne s'arrête pas là, qui vous dit que les disques dur que vous avez inséré dans ces NAS propriétaires vont être supportés ? Synology a rendu incompatible son matériel avec les marques n'ayant pas un partenariat avec eux, afin de booster la vente de leurs propres disques. Qui vous dit que votre media center pourra profiter des performances de l'iGPU de votre processeur pour streamer vos media vers vos appareils ? [Synology a désactivé le transcodage matériel de ses NAS](https://www.cachem.fr/synology-desactive-transcodage-materiel-nas/).
|
||||
|
||||
Bref, vous n'avez aucun pouvoir sur un produit qui n'est pas réellement ni ouvert ni à vous.
|
||||
|
||||
|
||||
@@ -6,9 +6,9 @@ description: Comprendre comment une commande Linux est construite, apprendre les
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
|
||||
Un serveur n'a pas de bureau, pas d'icônes et pas de souris. Tout se passe dans un terminal, et cette fenêtre noire avec un curseur clignotant est principalement ce qui décourage les gens de se lancer de le self-hosting. À tort : le terminal n'est qu'un chat. Vous posez une question ou écrivez un ordre, la machine répond. Rien de plus complexe qu'une barre de recherche, sauf qu'il en fait bien plus et ne cache jamais une option derrière trois menus.
|
||||
Un serveur n'a pas de bureau, pas d'icônes et pas de souris. Tout se passe dans un terminal, et cette fenêtre noire avec un curseur clignotant est principalement ce qui décourage les gens de se lancer dans le self-hosting. À tort : le terminal n'est qu'un chat. Vous posez une question ou écrivez un ordre, la machine répond. Rien de plus complexe qu'une barre de recherche, sauf qu'il en fait bien plus et ne cache jamais une option derrière trois menus.
|
||||
|
||||
La bonne nouvelle, c'est que vous n'avez pas besoin de connaître des centaines de commandes. Une dizaine d'entre elles couvrent presque tout vos besoins sur un serveur maison, et elles suivent toutes le même schéma. Apprenez à lire ce schéma et chaque commande que vous croiserez par la suite deviendra lisible, même celles que vous n'avez jamais vues.
|
||||
La bonne nouvelle, c'est que vous n'avez pas besoin de connaître des centaines de commandes. Une dizaine d'entre elles couvrent presque tous vos besoins sur un serveur maison, et elles suivent toutes le même schéma. Apprenez à lire ce schéma et chaque commande que vous croiserez par la suite deviendra lisible, même celles que vous n'avez jamais vues.
|
||||
|
||||
## Comment une commande est construite
|
||||
|
||||
@@ -83,7 +83,7 @@ Vous dit où vous êtes. Elle ne change rien, elle répond juste à la question.
|
||||
pwd
|
||||
```
|
||||
|
||||
```console [Sortie]
|
||||
```console [Output]
|
||||
/home/utilisateur/docker
|
||||
```
|
||||
|
||||
@@ -95,7 +95,7 @@ Liste ce qu'il y a dans le dossier courant. Seule, elle n'affiche que les noms,
|
||||
ls -lah
|
||||
```
|
||||
|
||||
```console [Sortie]
|
||||
```console [Output]
|
||||
total 20K
|
||||
drwxr-xr-x 4 utilisateur utilisateur 4.0K Sep 5 10:12 .
|
||||
drwxr-xr-x 18 utilisateur utilisateur 4.0K Sep 4 21:03 ..
|
||||
@@ -108,7 +108,7 @@ La première colonne, ce sont les permissions, le `d` tout au début signifiant
|
||||
|
||||
### `cd`, change directory
|
||||
|
||||
Permet de changer de repertoire. Lorsque vous indiquez un chemin, elle vous y rend. Avec `..` elle remonte d'un niveau, et sans rien du tout elle vous ramène dans votre dossier utilisateur.
|
||||
Permet de changer de répertoire. Lorsque vous indiquez un chemin, elle vous y emmène. Avec `..` elle remonte d'un niveau, et sans rien du tout elle vous ramène dans votre dossier utilisateur.
|
||||
|
||||
```console [Terminal]
|
||||
utilisateur@serveex:~/docker$ cd /var/log
|
||||
@@ -128,7 +128,7 @@ mkdir sauvegardes
|
||||
mkdir -p docker/immich/config
|
||||
```
|
||||
|
||||
```console [Sortie]
|
||||
```console [Output]
|
||||
|
||||
```
|
||||
|
||||
@@ -145,11 +145,11 @@ mv ancien-nom.txt nouveau-nom.txt
|
||||
ls
|
||||
```
|
||||
|
||||
```console [Sortie]
|
||||
```console [Output]
|
||||
compose.yaml compose.yaml.bak config config-backup nouveau-nom.txt
|
||||
```
|
||||
|
||||
Trois commandes silencieuses, et `ls` qui montre le résultat : la copie est à côté de l'original, le dossier a été dupliqué, et `ancien-nom.txt` a disparu parce que le déplacer vers un autre nom équivaut à le renommer/
|
||||
Trois commandes silencieuses, et `ls` qui montre le résultat : la copie est à côté de l'original, le dossier a été dupliqué, et `ancien-nom.txt` a disparu parce que le déplacer vers un autre nom équivaut à le renommer.
|
||||
|
||||
### `rm`, remove
|
||||
|
||||
@@ -169,7 +169,7 @@ Pour éditer un fichier, `nano` ouvre un éditeur simple : les flèches pour se
|
||||
cat .env
|
||||
```
|
||||
|
||||
```properties [Sortie]
|
||||
```properties [Output]
|
||||
PUID=1000
|
||||
PGID=1000
|
||||
TZ=Europe/Paris
|
||||
@@ -183,14 +183,14 @@ TZ=Europe/Paris
|
||||
grep -rin "password" /home/utilisateur/docker
|
||||
```
|
||||
|
||||
```console [Sortie]
|
||||
```console [Output]
|
||||
/home/utilisateur/docker/immich/.env:6:DB_PASSWORD=changeme
|
||||
/home/utilisateur/docker/vaultwarden/compose.yaml:14: ADMIN_PASSWORD=hunter2
|
||||
```
|
||||
|
||||
Chaque ligne indique le fichier, puis le numéro de ligne à l'intérieur, puis la ligne correspondante elle-même. Très pratique le jour où vous ne vous souvenez plus dans quelle stack se trouve un réglage.
|
||||
|
||||
### `sudo`, lancer en privilèges administrateur
|
||||
### `sudo`, lancer en tant qu'administrateur
|
||||
|
||||
*Substitute user do*. Afin d'éviter de casser votre serveur par accident, un utilisateur normal ne peut pas toucher aux fichiers du système. Préfixer une commande par `sudo` lance cette seule commande avec les droits administrateur. Cette commande vous demandera votre mot de passe au moins une fois par session, et parfois plusieurs fois selon le temps qui se sera écoulé depuis sa dernière utilisation.
|
||||
|
||||
@@ -198,7 +198,7 @@ Chaque ligne indique le fichier, puis le numéro de ligne à l'intérieur, puis
|
||||
nano /etc/ssh/sshd_config
|
||||
```
|
||||
|
||||
```console [Sortie]
|
||||
```console [Output]
|
||||
Error writing /etc/ssh/sshd_config: Permission denied
|
||||
```
|
||||
|
||||
@@ -206,12 +206,12 @@ Error writing /etc/ssh/sshd_config: Permission denied
|
||||
sudo nano /etc/ssh/sshd_config
|
||||
```
|
||||
|
||||
```console [Sortie]
|
||||
```console [Output]
|
||||
[sudo] password for utilisateur:
|
||||
```
|
||||
|
||||
::note
|
||||
Lordsqu'une commande répond `Permission denied`, c'est quasiment certain que c'est parce qu'elle a besoin des privilèges administrateurs : il lui fallait `sudo`. Cependant, résistez tout de même au réflexe de mettre `sudo` partout, un fichier créé avec les privilèges root continuera de vous embêter par la suite parce que votre utilisateur normal n'en sera plus propriétaire.
|
||||
Lorsqu'une commande répond `Permission denied`, c'est quasiment certain que c'est parce qu'elle a besoin des privilèges administrateurs : il lui fallait `sudo`. Cependant, résistez tout de même au réflexe de mettre `sudo` partout, un fichier créé avec les privilèges root continuera de vous embêter par la suite parce que votre utilisateur normal n'en sera plus propriétaire.
|
||||
::
|
||||
|
||||
## Aide-mémoire
|
||||
@@ -243,7 +243,7 @@ Les commandes qui valent la peine d'être gardées sous la main, et d'où vienne
|
||||
| `chmod` | change mode | Change les permissions d'un fichier |
|
||||
| `chown` | change owner | Change le propriétaire d'un fichier |
|
||||
| `sudo` | substitute user do | Lance une commande en administrateur |
|
||||
| `apt` | advanced package tool | Installe, met à jour et supprime des paquets |
|
||||
| `apt` | Advanced Package Tool | Installe, met à jour et supprime des paquets |
|
||||
| `systemctl` | control systemd | Démarre, arrête et active des services |
|
||||
| `ssh` | secure shell | Ouvre une session sur une machine distante |
|
||||
| `scp` | secure copy | Copie des fichiers via SSH |
|
||||
|
||||
@@ -6,11 +6,11 @@ description: Comment le système de fichiers de Debian est organisé, ce que con
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
|
||||
Windows donne à chaque disque sa propre lettre. Linux non : il y a un arbre, il commence à `/`, la racine (root), et tout le reste s'y accroche, y compris vos autres disques. Un deuxième disque n'est pas `D:`, il est *monté* sur un dossier de l'arbre, `/mnt/data` par exemple, et à partir de là il ressemble à n'importe quel autre dossier. Cela peut paraître éroutant au début, mais très pratique ensuite, puisqu'un programme n'a jamais à savoir sur quel disque physique il écrit.
|
||||
Windows donne à chaque disque sa propre lettre. Linux non : il y a un arbre, il commence à `/`, la racine (root), et tout le reste s'y accroche, y compris vos autres disques. Un deuxième disque n'est pas `D:`, il est *monté* sur un dossier de l'arbre, `/mnt/data` par exemple, et à partir de là il ressemble à n'importe quel autre dossier. Cela peut paraître déroutant au début, mais très pratique ensuite, puisqu'un programme n'a jamais à savoir sur quel disque physique il écrit.
|
||||
|
||||
## L'arborescence
|
||||
|
||||
Cet arborescence n'a rien d'arbitraire. Toutes les installations de Debian sont organisées de la même manière, et c'est pour ça qu'un tutoriel écrit pour le serveur de quelqu'un d'autre s'applique également au vôtre.
|
||||
Cette arborescence n'a rien d'arbitraire. Toutes les installations de Debian sont organisées de la même manière, et c'est pour ça qu'un tutoriel écrit pour le serveur de quelqu'un d'autre s'applique également au vôtre.
|
||||
|
||||
| Dossier | Ce qu'il contient |
|
||||
| --- | --- |
|
||||
@@ -46,13 +46,13 @@ sdb 8:16 0 3.6T 0 disk
|
||||
|
||||
## Quelques habitudes à prendre
|
||||
|
||||
- **Ne travaillez que dans un seul dossier pour l'usage de votre serveur.** `/srv` est le dossier que la norme réserve aux données servies par la machine, ce qui en fait l'endroit le plus propre pour mettre les sous dossiers et fichiers dont vous avez besoin de stocker sur votre serveur. Par exemple pour Docker, [Serveex](/serveex/introduction) met tout dans `/srv/docker`, un dossier par stack. Ce qui compte, c'est de choisir un endroit et de s'y tenir, plutôt que d'en éparpiller la moitié dans votre dossier personnel ou pire, dans les dossiers de Debian et directement à la racine.
|
||||
- **Ne travaillez que dans un seul dossier pour l'usage de votre serveur.** `/srv` est le dossier que la norme réserve aux données servies par la machine, ce qui en fait l'endroit le plus propre pour mettre les sous dossiers et fichiers que vous avez besoin de stocker sur votre serveur. Par exemple pour Docker, [Serveex](/serveex/introduction) met tout dans `/srv/docker`, un dossier par stack. Ce qui compte, c'est de choisir un endroit et de s'y tenir, plutôt que d'en éparpiller la moitié dans votre dossier personnel ou pire, dans les dossiers de Debian et directement à la racine.
|
||||
- **Vos fichiers à vous, propre à un utilisateur, vont dans votre home.** Les scripts dans `~/bin`, les notes, les téléchargements, tout ce qui est personnel. `/root` est le dossier du compte root, pas un endroit commode où déposer des choses.
|
||||
- **Ne modifiez jamais quoi que ce soit sous `/usr` ou `/bin` à la main.** `apt` en est propriétaire, et vos changements disparaîtront à la prochaine mise à jour. Ce que vous avez le droit de configurer vit dans `/etc`.
|
||||
- **Dans `/etc`, préférez créer un fichier additionnel plutôt que de modifier le principal.** Beaucoup de services lisent tous les `.conf` d'un dossier `quelquechose.d/` posé à côté de leur config principale, `/etc/ssh/sshd_config.d/` par exemple. Votre fichier survit alors à une mise à jour de paquet qui réécrirait l'original.
|
||||
- **Montez les disques de données par UUID, pas par `/dev/sdb`.** Les lettres de périphérique sont attribuées dans l'ordre où le noyau trouve les disques, elles peuvent donc s'échanger après un redémarrage ou l'ajout d'un disque. `lsblk -f` vous donne l'UUID à mettre dans `/etc/fstab`.
|
||||
- **Gardez un œil sur `/var`.** Les images Docker, les logs des conteneurs et ceux du système s'y accumulent tous, sur la même partition que le reste. `du -sh /var/lib/docker` vous dit ce que pèsent les conteneurs, `df -h` s'il faut s'inquiéter.
|
||||
- **Ne créez pas vos fichiers avec `sudo` lorque ce n'est pas nécessaire.** Un fichier créé en root dans votre home reste la propriété de root, et vous vous battrez avec des erreurs de permissions dessus pendant des semaines.
|
||||
- **Ne créez pas vos fichiers avec `sudo` lorsque ce n'est pas nécessaire.** Un fichier créé en root dans votre home reste la propriété de root, et vous vous battrez avec des erreurs de permissions dessus pendant des semaines.
|
||||
|
||||
::note{to="/general/linux/cli-basics"}
|
||||
Tout ce qui précède suppose que vous savez déjà vous déplacer dans un terminal. Si `cd`, `ls` et `sudo` ne vous parlent pas encore, commencez par les **bases de la ligne de commande**.
|
||||
|
||||
@@ -37,7 +37,7 @@ sudo apt install btop duf ncdu tealdeer ufw
|
||||
|
||||
## `btop`, surveiller ce que fait la machine
|
||||
|
||||
Le remplaçant moderne de `top` et `htop` : CPU, RAM, disques, réseau et processus sur un seul écran, avec des graphiques, des couleurs et une souris qui marche. C'est ce que vous ouvrez quand quelque chose semble lent, l'équivalent du gestionnaire de tache sur Windows ou du moniteur d'activité sur Mac.
|
||||
Le remplaçant moderne de `top` et `htop` : CPU, RAM, disques, réseau et processus sur un seul écran, avec des graphiques, des couleurs et une souris qui marche. C'est ce que vous ouvrez quand quelque chose semble lent, l'équivalent du gestionnaire de tâches sur Windows ou du moniteur d'activité sur Mac.
|
||||
|
||||
::steps{level="4"}
|
||||
#### L'installer
|
||||
@@ -61,7 +61,7 @@ Cliquez sur un processus pour le sélectionner, :kbd{value="Esc"} ouvre le menu,
|
||||
|
||||
## `duf`, l'espace disque qui se lit comme un tableau
|
||||
|
||||
`df -h` affiche tous tous vos dossiers/fichiers et vous laisse vous exploser les yeux sur les colonnes, les chiffres, les tailles. `duf` montre les mêmes informations groupées, alignées et colorées, avec une barre d'utilisation par système de fichiers.
|
||||
`df -h` affiche jusqu'au moindre loop device créé par Docker et vous laisse vous exploser les yeux sur les colonnes, les chiffres, les tailles. `duf` montre les mêmes informations groupées, alignées et colorées, avec une barre d'utilisation par système de fichiers.
|
||||
|
||||
::steps{level="4"}
|
||||
#### L'installer
|
||||
@@ -179,8 +179,8 @@ Il a besoin d'accéder au socket Docker, d'où le `sudo` à moins que votre util
|
||||
| Touche | Ce qu'elle fait |
|
||||
| --- | --- |
|
||||
| `1` à `6` | Aller à un onglet : projets, services, conteneurs, images, volumes, réseaux |
|
||||
| Flèches | Se déplacer dans le onglet, la partie droite suit la sélection |
|
||||
| :kbd{value="Enter"} | Passer sur le onglet principal à droite, :kbd{value="Esc"} revient |
|
||||
| Flèches | Se déplacer dans l'onglet, la partie droite suit la sélection |
|
||||
| :kbd{value="Enter"} | Passer sur l'onglet principal à droite, :kbd{value="Esc"} revient |
|
||||
| `x` | Ouvrir le menu de tout ce que vous pouvez faire avec la sélection |
|
||||
| `m` | Suivre les logs |
|
||||
| `s` / `r` / `p` | Arrêter, redémarrer, mettre en pause le conteneur sélectionné |
|
||||
@@ -196,7 +196,7 @@ La casse compte : `E` ouvre un shell dans le conteneur, `e` masque ceux qui sont
|
||||
La [liste complète](https://github.com/jesseduffield/lazydocker/blob/master/docs/keybindings/Keybindings_en.md) se trouve dans la documentation du projet.
|
||||
|
||||
::note
|
||||
N'etant pas un package de Debian signifie qu'il ne sera pas mis à jour par `apt full-upgrade`. Ré-éxecutez ces étapes lorsque vous voudrez une version plus récente.
|
||||
Ne pas être un paquet Debian signifie qu'il ne sera pas mis à jour par `apt full-upgrade`. Réexécutez ces étapes lorsque vous voudrez une version plus récente.
|
||||
::
|
||||
|
||||
#### Terminé !
|
||||
@@ -247,7 +247,7 @@ sudo ufw enable
|
||||
sudo ufw status verbose
|
||||
```
|
||||
|
||||
```console [Sortie]
|
||||
```console [Output]
|
||||
Status: active
|
||||
Logging: on (low)
|
||||
Default: deny (incoming), allow (outgoing), disabled (routed)
|
||||
|
||||
@@ -9,7 +9,7 @@ navigation:
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
## Un homelab de débutant, pour les débutants
|
||||
|
||||

|
||||

|
||||
|
||||
**Serveex** est avant tout un projet personnel visant à héberger chez soi le plus de services du quotidien possible, sans dépendre de plateformes propriétaires (Google, Apple, Netflix, etc.). L'objectif était d'expérimenter, d'apprendre, et de documenter chaque étape du chemin. C'est un projet purement scientifique, pas destiné à un usage en production.
|
||||
|
||||
@@ -62,7 +62,7 @@ to: /serveex/core/wireguard
|
||||
ui:
|
||||
icon: text-[#88171A]
|
||||
---
|
||||
Installer et déployer Wireguard
|
||||
Installer et déployer WireGuard
|
||||
::
|
||||
|
||||
::card{icon="i-noto-globe-showing-americas" title="Reverse Proxy" to="/serveex/core/swag"}
|
||||
@@ -174,7 +174,7 @@ to: /serveex/media/qbittorrent
|
||||
ui:
|
||||
icon: text-[#2F67BA]
|
||||
---
|
||||
Installer et déployer Qbittorrent
|
||||
Installer et déployer qBittorrent
|
||||
::
|
||||
|
||||
::card
|
||||
@@ -189,7 +189,7 @@ Installer et déployer la stack Servarr
|
||||
::
|
||||
::
|
||||
|
||||
### Cloud & Photos
|
||||
### Cloud Drive & Photos
|
||||
|
||||
:::div{class="relative"}
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px}
|
||||
@@ -284,7 +284,7 @@ to: /serveex/apps/adguard
|
||||
ui:
|
||||
icon: text-[#68BC71]
|
||||
---
|
||||
Installer et déployer Adguard Home
|
||||
Installer et déployer AdGuard Home
|
||||
::
|
||||
|
||||
::card
|
||||
@@ -296,6 +296,8 @@ ui:
|
||||
icon: text-[#175DDC]
|
||||
---
|
||||
Installer et déployer Vaultwarden
|
||||
::
|
||||
|
||||
::
|
||||
::
|
||||
|
||||
@@ -313,6 +315,14 @@ Installer et déployer Authentik
|
||||
::card{icon="i-noto-crystal-ball" title="Gestionnaire Docker multi-hôtes" to="/serveex/advanced/arcane"}
|
||||
Installer et déployer Arcane
|
||||
::
|
||||
|
||||
::card{icon="i-lucide-database-backup" title="Sauvegardes en 3-2-1" to="/serveex/advanced/backrest"}
|
||||
Installer et déployer Backrest
|
||||
::
|
||||
|
||||
::card{icon="i-lucide-rotate-ccw" title="Retour en arrière instantané" to="/serveex/advanced/btrfs-snapshots"}
|
||||
Mettre en place les snapshots BTRFS
|
||||
::
|
||||
::
|
||||
|
||||
## Bientôt
|
||||
|
||||
@@ -10,7 +10,7 @@ description: Guide pas à pas pour installer Debian 13 sur un serveur maison et
|
||||
|
||||
L'autre raison, c'est qu'il ne vous donnera aucune limite, il ne vous enfermera jamais. Les systèmes clés en main comme Unraid, TrueNAS ou le DSM de Synology posent leur propre couche par-dessus, et le jour où vous avez besoin de quelque chose que leur interface n'expose pas, vous serez coincé ou devrez bricoler autour. Debian n'est qu'un serveur : vous installez ce que vous voulez, où vous voulez, et rien n'est caché derrière l'interface de quelqu'un d'autre. C'est exactement ce que la plupart des projets auto-hébergés visent en premier, leurs docs vous donnent donc des commandes `apt` qui fonctionnent telles quelles, et n'importe quel message d'erreur collé dans un moteur de recherche a déjà des années de réponses derrière lui. Une installation minimale est assez légère pour laisser la quasi intégralité de la RAM et du CPU à tous les délires que vous installerez dessus.
|
||||
|
||||

|
||||

|
||||
|
||||
## Installation
|
||||
|
||||
@@ -40,11 +40,11 @@ Si vous êtes en dual boot avec Windows, désactivez son *démarrage rapide* : i
|
||||
|
||||
Récupérez l'image **netinst** `amd64` sur [debian.org](https://www.debian.org/download.fr.html). Elle fait environ 700 Mo et récupère le reste des paquets sur le réseau pendant l'installation, ce qui est exactement ce qu'on veut sur un serveur branché en ethernet : vous obtenez des paquets à jour au lieu d'installer depuis un instantané vieux de plusieurs mois puis de tout mettre à jour derrière. Les images DVD complètes n'ont de sens que si la machine n'a pas de réseau pendant l'installation.
|
||||
|
||||
#### Créer une clée bootable avec Rufus
|
||||
#### Créer une clé bootable avec Rufus
|
||||
|
||||
Sous Windows, utilisez [Rufus](https://rufus.ie/) (portable, aucune installation nécessaire). Branchez une clé USB de 2 Go ou plus, en gardant en tête qu'**elle sera entièrement effacée**, puis :
|
||||
|
||||
- **Périphérique** : votre clé USB. Vérifiez la capacité deux fois, Sinon Rufus écrira sans rechigner sur le mauvais disque si vous le laissez faire.
|
||||
- **Périphérique** : votre clé USB. Vérifiez la capacité deux fois : sinon, Rufus écrira sans rechigner sur le mauvais disque si vous le laissez faire.
|
||||
- **Type de démarrage** : `SÉLECTION`, puis choisissez l'ISO Debian que vous venez de télécharger.
|
||||
- **Schéma de partition** : il doit correspondre au mode de démarrage réglé dans le BIOS plus haut. `GPT` pour l'UEFI, `MBR` uniquement si vous restez en legacy/CSM. Le champ système de destination suit automatiquement.
|
||||
- Laissez les options de formatage par défaut, puis cliquez sur `DÉMARRER`. Si Rufus demande comment écrire l'image, gardez le *mode image ISO* recommandé.
|
||||
@@ -89,6 +89,10 @@ Confirmez le fuseau horaire deviné à partir de votre pays.
|
||||
|
||||
*Assisté, utiliser un disque entier* sur le disque système, puis *Tout dans une seule partition*, ce qui vous donne un gros `/` plus une partition de swap. Des partitions `/home` ou `/var` séparées n'apportent pas grand-chose ici et garantissent surtout que l'une se remplit pendant que les autres restent à moitié vides. Ne prenez LVM que si vous savez déjà que vous voulez des snapshots ou agrandir des volumes plus tard. Vos disques de données ne sont pas touchés à ce stade, vous les monterez ensuite.
|
||||
|
||||
::warning{to="/serveex/advanced/btrfs-snapshots"}
|
||||
__Pour les utilisateurs avancés :__ c'est maintenant qu'il faut décider, pas plus tard. Choisir *Manuel* ici plutôt qu'*Assisté* permet de formater la partition racine en Btrfs plutôt qu'en ext4, ce qui débloque des snapshots instantanés et quasi gratuits vers lesquels revenir avant une mise à jour risquée ou un changement de config. Une fois cette étape passée et Debian installé en ext4, passer à Btrfs n'est plus possible sans effacer le disque et tout recommencer. Voir **Snapshots BTRFS** pour la mise en place, ça ne remplace pas non plus de vraies sauvegardes, un snapshot vit sur le même disque.
|
||||
::
|
||||
|
||||
Terminez avec *Terminer le partitionnement et appliquer les changements*, puis confirmez avec *Oui* : c'est le point de non-retour pour ce disque.
|
||||
|
||||

|
||||
@@ -160,7 +164,7 @@ Toujours sur l'autre machine, générez une clé.
|
||||
ssh-keygen -t ed25519
|
||||
```
|
||||
|
||||
Appuyez sur :kbd{value="Enter"} pour accepter le chemin par défaut, et mettez une passphrase (elle protège le fichier de clé lui-même, votre système la retiendra après le premier déverrouillage). Il s'agit ensuite de transmettre la clée publique à votre serveur. A noter que Windows n'a pas de `ssh-copy-id`, nous pousserons donc la clé manuellement dans ce cas :
|
||||
Appuyez sur :kbd{value="Enter"} pour accepter le chemin par défaut, et mettez une passphrase (elle protège le fichier de clé lui-même, votre système la retiendra après le premier déverrouillage). Il s'agit ensuite de transmettre la clé publique à votre serveur. À noter que Windows n'a pas de `ssh-copy-id`, nous pousserons donc la clé manuellement dans ce cas :
|
||||
|
||||
::code-group
|
||||
```bash [macOS]
|
||||
@@ -203,7 +207,7 @@ sudo systemctl restart ssh
|
||||
```
|
||||
|
||||
::warning
|
||||
Gardez votre session SSH actuelle ouverte pendant le test. Ouvrez un **second** terminal et reconnectez-vous : si la clé ne fonctionne plus, la session restée ouverte est votre porte de secours pour corriger la configuration. Si vous la fermez avant d'avoir vérifié et une faute de frappe vous enferme en dehors de votre propre serveur, avec l'écran et le clavier comme seul recours.
|
||||
Gardez votre session SSH actuelle ouverte pendant le test. Ouvrez un **second** terminal et reconnectez-vous : si la clé ne fonctionne plus, la session restée ouverte est votre porte de secours pour corriger la configuration. Si vous la fermez avant d'avoir vérifié et qu'une faute de frappe vous enferme en dehors de votre propre serveur, l'écran et le clavier deviennent votre seul recours.
|
||||
::
|
||||
|
||||
::note
|
||||
|
||||
@@ -12,7 +12,7 @@ Un **conteneur** contourne le problème : il empaquette une application avec tou
|
||||
|
||||
**Docker** est l'outil qui construit, démarre et gère ces conteneurs. Pointez-le sur une *image*, un instantané prêt à l'emploi d'une application maintenu par ses développeurs, et il la télécharge et la lance en une commande. Tout le reste de Serveex est bâti dessus : chaque application à partir d'ici est un conteneur Docker, ou une poignée de conteneurs qui travaillent ensemble.
|
||||
|
||||

|
||||

|
||||
|
||||
## Installer Docker
|
||||
::steps{level="3"}
|
||||
@@ -53,7 +53,7 @@ sudo mkdir /srv/docker
|
||||
## Installer [Dockge](https://github.com/louislam/dockge) pour gérer et déployer les conteneurs
|
||||
[Dockge](https://github.com/louislam/dockge) est un outil web permettant de créer, configurer, lancer et gérer des conteneurs pour Docker. C'est une interface simple, intuitive, qui est plus légère et plus facile pour les débutants que d'utiliser docker en CLI ou Portainer.
|
||||
|
||||

|
||||

|
||||
|
||||
### Configuration
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Wireguard
|
||||
title: WireGuard
|
||||
description: Installer et configurer WireGuard VPN pour accéder à votre homelab de n'importe où et connecter tous vos appareils à votre réseau privé.
|
||||
---
|
||||
|
||||
@@ -7,36 +7,36 @@ description: Installer et configurer WireGuard VPN pour accéder à votre homela
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
|
||||
## Introduction
|
||||
L'utilisation d'un VPN permet d'accéder à distance aux ressources locales du serveur sans les exposer sur internet. C'est notamment une manière propre de sécuriser l'accès à la console SSH, plutot que d'exposer le port sur internet. C'est pouvoir se connecter à son réseau où que l'on soit, de maniere sécurisée, et de faire dialoguer des machines qui sont sur des réseaux différents.
|
||||
L'utilisation d'un VPN permet d'accéder à distance aux ressources locales du serveur sans les exposer sur internet. C'est notamment une manière propre de sécuriser l'accès à la console SSH, plutôt que d'exposer le port sur internet. C'est pouvoir se connecter à son réseau où que l'on soit, de manière sécurisée, et de faire dialoguer des machines qui sont sur des réseaux différents.
|
||||
|
||||
Ici nous utiliserons [Wireguard](https://www.wireguard.com/), un serveur VPN sécurisé et très performant, à l'aide des conteneurs :
|
||||
Ici nous utiliserons [WireGuard](https://www.wireguard.com/), un serveur VPN sécurisé et très performant, à l'aide des conteneurs :
|
||||
|
||||
- [wg-easy](https://github.com/wg-easy/wg-easy) pour le serveur, qui propose une interface web très simple pour controler les connexions et télécharger les fichiers de conf (notamment par QR code pour les téléphones)
|
||||
- [Wireguard](https://docs.linuxserver.io/images/docker-wireguard/?h=wireguard) pour les clients linux
|
||||
- [wg-easy](https://github.com/wg-easy/wg-easy) pour le serveur, qui propose une interface web très simple pour contrôler les connexions et télécharger les fichiers de conf (notamment par QR code pour les téléphones)
|
||||
- [WireGuard](https://docs.linuxserver.io/images/docker-wireguard/?h=wireguard) pour les clients Linux
|
||||
|
||||
Il existe aussi des clients Windows, MacOS, iOS et Android.
|
||||
Il existe aussi des clients Windows, macOS, iOS et Android.
|
||||
|
||||
Le principe est le suivant :
|
||||
|
||||
- Sur internet, n'importe qui peut contacter n'importe quel box internet et donc essayer de contacter n'importe quel serveur exposé.
|
||||
- Votre serveur est sur votre réseau local. Il est accessible depuis le réseau local mais pas depuis internet, mis à part les services exposés (comme nous l'avons fait avec Dockge). Pour accéder aux ressources non exposées, vous devez être connecté sur le meme réseau que votre serveur et donc etre chez vous. De plus, vous devez laisser ouvert les ports utilisés par vos services à travers le pare feu de votre serveur.
|
||||
- Nous souhaitons ici au contraire, depuis n'importe où, pouvoir accéder de maniere securisée aux services non exposés sur internet du serveur, comme la console SSH qui permet de se connecter à la machine par exemple.
|
||||
- Nous souhaitons aussi accéder aux services d'autres serveurs, et par exemple relier de maniere sécurisée deux instances de Dockge pour tout controler depuis la meme interface.
|
||||
- Votre serveur est sur votre réseau local. Il est accessible depuis le réseau local mais pas depuis internet, mis à part les services exposés (comme nous l'avons fait avec Dockge). Pour accéder aux ressources non exposées, vous devez être connecté sur le même réseau que votre serveur et donc être chez vous. De plus, vous devez laisser ouverts les ports utilisés par vos services à travers le pare-feu de votre serveur.
|
||||
- Nous souhaitons ici au contraire, depuis n'importe où, pouvoir accéder de manière sécurisée aux services non exposés sur internet du serveur, comme la console SSH qui permet de se connecter à la machine par exemple.
|
||||
- Nous souhaitons aussi accéder aux services d'autres serveurs, et par exemple relier de manière sécurisée deux instances de Dockge pour tout contrôler depuis la même interface.
|
||||
|
||||
Pour cela nous allons créer un **réseau privé virtuel**, ou VPN, c'est à dire un tunnel sécurisé auquel personne n'a accès à part les machines que vous relierez entre elles. Elles feront partie d'un nouveau réseau et pourront dialoguer entre elle comme dans un réseau local.
|
||||
Pour cela nous allons créer un **réseau privé virtuel**, ou VPN, c'est-à-dire un tunnel sécurisé auquel personne n'a accès à part les machines que vous relierez entre elles. Elles feront partie d'un nouveau réseau et pourront dialoguer entre elles comme dans un réseau local.
|
||||
|
||||
D'autre part, vous pourrez ajouter votre téléphone, un ordinateur portable ou n'importe quel appareil au réseau pour pouvoir utiliser vos ressources depuis vos appareils quotidiens, où que vous soyiez.
|
||||
D'autre part, vous pourrez ajouter votre téléphone, un ordinateur portable ou n'importe quel appareil au réseau pour pouvoir utiliser vos ressources depuis vos appareils quotidiens, où que vous soyez.
|
||||
|
||||

|
||||

|
||||
|
||||
Dans cette illustration, la machine 1 est sur deux réseaux :
|
||||
|
||||
- son réseau local (tous les appareils liés à la box, avec une adresse IP du type `192.168.x.x ` donc ici la machine 1 et la machine 2)
|
||||
- le réseau du VPN (tous les appareils reliés au VPN, avec une seconde adresse IP du type `10.8.x.x` donc ici la machine 1 et 4)
|
||||
|
||||
On peut aussi faire en sorte que les machines reliées au réseau virtuel partagent les acces à leur réseau local. Ici nous ne le ferons pas, pour des raisons de sécurité, et de complexité en terme de sous-réseau (si les deux machines distantes ont des machines locales qui utilisent la meme adresse IP locale, par exemple `192.168.1.1`, cela posera des conflits).
|
||||
On peut aussi faire en sorte que les machines reliées au réseau virtuel partagent les accès à leur réseau local. Ici nous ne le ferons pas, pour des raisons de sécurité, et de complexité en termes de sous-réseau (si les deux machines distantes ont des machines locales qui utilisent la même adresse IP locale, par exemple `192.168.1.1`, cela posera des conflits).
|
||||
|
||||
Ainsi, sur le réseau virtuel, seules les machines directement reliées pourront dialoguer entre elle depuis ce réseau. Elles ne pourront pas dialoguer avec une machine situées sur un autre réseau local et non reliée au VPN.
|
||||
Ainsi, sur le réseau virtuel, seules les machines directement reliées pourront dialoguer entre elles depuis ce réseau. Elles ne pourront pas dialoguer avec une machine située sur un autre réseau local et non reliée au VPN.
|
||||
|
||||
## Côté serveur
|
||||
::note{icon=""}
|
||||
@@ -276,4 +276,4 @@ Répétez cette installation pour chaque client.
|
||||
|
||||
Et voici le schéma final de l'installation :
|
||||
|
||||

|
||||

|
||||
|
||||
@@ -6,18 +6,18 @@ description: Configurer SWAG comme reverse proxy avec SSL automatique, exposer v
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
|
||||
[Swag](https://docs.linuxserver.io/general/swag/) est le noyau de ce homelab. C'est un reverse proxy puissant qui permet d'exposer des services sur internet via des noms de domaine, en se chargeant de l'émission des certificats SSL (pour garder des connexions chiffrées), du routage des requêtes et de la sécurisation des accès (par authentification HTTP ou par SSO comme Authelia ou Authentik). Toute la documentation nécessaire est [disponible ici](https://docs.linuxserver.io/general/swag).
|
||||
[SWAG](https://docs.linuxserver.io/general/swag/) est le noyau de ce homelab. C'est un reverse proxy puissant qui permet d'exposer des services sur internet via des noms de domaine, en se chargeant de l'émission des certificats SSL (pour garder des connexions chiffrées), du routage des requêtes et de la sécurisation des accès (par authentification HTTP ou par SSO comme Authelia ou Authentik). Toute la documentation nécessaire est [disponible ici](https://docs.linuxserver.io/general/swag).
|
||||
|
||||
::warning{to="/serveex/core/wireguard"}
|
||||
|
||||
SWAG n'a d'utilité que pour exposer vos services sur internet, c'est-à-dire y accéder via une URL publique du type `https://service.mondomaine.fr`. Si vous ne souhaitez pas exposer vos services et préférez systématiquement passer par un VPN pour vous connecter à distance, allez plutôt **par ici**.
|
||||
::
|
||||
|
||||
Ci-dessous, un exemple exposant Dockge. Nous installerons SWAG ainsi que le mod dbip servant à bloquer les connexions selon la géolocalisation, et le mod dashboard qui permet de piloter swag, fail2ban et la géolocalisation.
|
||||
Ci-dessous, un exemple exposant Dockge. Nous installerons SWAG ainsi que le mod dbip servant à bloquer les connexions selon la géolocalisation, le mod dashboard qui permet de piloter swag, fail2ban et la géolocalisation, et le mod auto-reload qui recharge automatiquement nginx dès qu'un fichier de configuration change, sans avoir à redémarrer le conteneur.
|
||||
|
||||
**Principe d'un reverse proxy et application dans notre cas :**
|
||||
|
||||

|
||||

|
||||
|
||||
## Installation
|
||||
|
||||
@@ -155,13 +155,13 @@ Donnez-lui les permissions suivantes :
|
||||
* `POST /domain/zone/*`
|
||||
* `DELETE /domain/zone/*`
|
||||
|
||||
Notez temporairement les 3 clés et saisissez-les dans `ovh.ini`. (Dans nano, tapez directement, puis :kbd{value="Ctrl+O"}, :kbd{value="Enter"}, :kbd{value="Ctrl+X"} pour enregistrer et quitter)
|
||||
Notez temporairement les 3 clés et saisissez-les dans `ovh.ini`.
|
||||
|
||||
Enregistrez avec :kbd{value="Ctrl+O"}, puis :kbd{value="Enter"}, et quittez avec :kbd{value="Ctrl+X"}.
|
||||
|
||||
### Activer DBIP dans nginx.conf
|
||||
|
||||
Configurons maintenant swag pour accéder à DBIP, le module de contrôle d'accès par géolocalisation. Ouvrez le fichier `nginx.conf` :
|
||||
Configurons maintenant SWAG pour accéder à DBIP, le module de contrôle d'accès par géolocalisation. Ouvrez le fichier `nginx.conf` :
|
||||
|
||||
```bash [Terminal]
|
||||
sudo nano /srv/docker/swag/config/nginx/nginx.conf
|
||||
@@ -182,7 +182,7 @@ Redémarrez la stack dans Dockge. Cette fois, le certificat SSL devrait être g
|
||||
Accédez au tableau de bord en local sur `http://ipdevotreserveur:81`
|
||||
Sur la gauche, vous verrez la liste des services actuellement « proxifiés » (aucun pour l'instant). Sur la droite, la liste des IP bannies. En dessous, différents indicateurs. Pour plus de détails, [cliquez ici](https://www.linuxserver.io/blog/introducing-swag-dashboard).
|
||||
|
||||

|
||||

|
||||
|
||||
## DBIP
|
||||
DBIP permet de bloquer les connexions selon les pays. Il s'appuie sur le fichier de configuration nommé `dbip.conf` situé dans `/srv/docker/swag/config/nginx`. [Plus d'infos ici](https://virtualize.link/secure/).
|
||||
@@ -290,7 +290,7 @@ Il est temps d'exposer Dockge sur internet pour accéder à vos conteneurs et le
|
||||
|
||||
::warning
|
||||
|
||||
Dockge ne gère pas l'authentification multifacteur. L'exposer en ligne pourrait compromettre toutes les machines reliées. Ne le faites que si vous utilisez une solution MFA comme [TinyAuth](/serveex/security/tinyauth) ou [Authentik](/serveex/advanced/authentik/). Sinon, ne l'exposez pas avec SWAG. Utilisez plutôt un VPN comme [Wireguard](/serveex/core/wireguard).
|
||||
Dockge ne gère pas l'authentification multifacteur. L'exposer en ligne pourrait compromettre toutes les machines reliées. Ne le faites que si vous utilisez une solution MFA comme [TinyAuth](/serveex/security/tinyauth) ou [Authentik](/serveex/advanced/authentik/). Sinon, ne l'exposez pas avec SWAG. Utilisez plutôt un VPN comme [WireGuard](/serveex/core/wireguard).
|
||||
::
|
||||
|
||||
::steps{level="3"}
|
||||
|
||||
@@ -8,16 +8,16 @@ description: Utiliser les tunnels Cloudflare et Zero Trust pour exposer des serv
|
||||

|
||||
|
||||
## Introduction
|
||||
L'architecture _Zero Trust_ est la pratique consistant à concevoir des systèmes fondés sur le principe de __« ne jamais faire confiance__, __toujours vérifier »__, par opposition au principe traditionnel de __« confiance, mais vérifier »__. Ce concept est devenu très populaires récemment, à la suite des attaques toujours plus nombreuses concernant les données des utilisateurs. C'est un concept très large, nous nous concentrerons sur l’application du _Zero Trust_ aux services Web que nous hébergeons.
|
||||
L'architecture _Zero Trust_ est la pratique consistant à concevoir des systèmes fondés sur le principe de __« ne jamais faire confiance__, __toujours vérifier »__, par opposition au principe traditionnel de __« confiance, mais vérifier »__. Ce concept est devenu très populaire récemment, à la suite des attaques toujours plus nombreuses concernant les données des utilisateurs. C'est un concept très large, nous nous concentrerons sur l’application du _Zero Trust_ aux services Web que nous hébergeons.
|
||||
|
||||
Les _tunnels Cloudflare_ offrent un moyen simple d'arriver au _Zero Trust_, en s'appuyant sur [SWAG](/serveex/core/swag) et [Authentik](/serveex/advanced/authentik).
|
||||
|
||||
Pour le dire simplement, les Tunnels Cloudflare permettent notamment de :
|
||||
|
||||
- Masquer l'IP de votre serveur (et donc de votre box s'il est hébergé chez vous).
|
||||
- D'authentifier le traffic.
|
||||
- De bénéficier des protection de Cloudflare (attaques DDOS, etc, blacklist, requêtes malveillantes, etc...).
|
||||
- De bénéficier du CDN, c'est à dire du serveur de cache de Cloudlfare, qui permet d'augmenter les performances de vos sites web.
|
||||
- D'authentifier le trafic.
|
||||
- De bénéficier des protections de Cloudflare (attaques DDOS, etc, blacklist, requêtes malveillantes, etc.).
|
||||
- De bénéficier du CDN, c'est-à-dire du serveur de cache de Cloudflare, qui permet d'augmenter les performances de vos sites web.
|
||||
- De ne plus avoir besoin de l'ouverture de ports de votre routeur pour les services exposés par SWAG.
|
||||
|
||||
Ici, nous expliquerons comment associer SWAG aux tunnels Cloudflare.
|
||||
@@ -34,25 +34,25 @@ __Attention :__
|
||||
|
||||
Avant toute chose, vous devez définir Cloudflare comme gestionnaire de votre [zone DNS](/general/networking/dns). Si vous avez réservé votre nom de domaine chez Cloudflare, c'est déjà le cas. Sinon, renseignez vous auprès de votre registrar sur comment ajouter des DNS externes. Cloudflare dispose d'[une documentation expliquant pas à pas comment paramétrer une Zone DNS](https://developers.cloudflare.com/dns/zone-setups/full-setup/setup/), que vous ayez un domaine externe ou reservé chez Cloudflare.
|
||||
|
||||
Si vous avez qu'un seul serveur à protéger derrière Cloudflare, vous pouvez supprimer l'ensemble des enregistrement DNS existant, par défaut le domaine et tout ses sous-domaines seront directement redirigés vers le tunnel.
|
||||
Si vous n'avez qu'un seul serveur à protéger derrière Cloudflare, vous pouvez supprimer l'ensemble des enregistrements DNS existants, par défaut le domaine et tous ses sous-domaines seront directement redirigés vers le tunnel.
|
||||
|
||||
Si vous avez des sous-domaines à rediriger vers d'autres serveurs, vous pourrez toujours les déclarer dans la zone DNS à l'aide d'un enregistrement A.
|
||||
|
||||
Si vous avez plusieurs serveurs et donc plusieurs tunnels pour un meme domaine principal, [voyez ici](#gérer-plusieurs-tunnels-pour-plusieurs-serveurs).
|
||||
Si vous avez plusieurs serveurs et donc plusieurs tunnels pour un même domaine principal, [voyez ici](#gérer-plusieurs-tunnels-pour-plusieurs-serveurs).
|
||||
|
||||
### Clé API
|
||||
|
||||
Pour commencer, nous devons créer un nouveau jeton API pour Cloudflare et récupérer nos identifiants de zone et de compte.
|
||||
Pour commencer, vous devez créer un nouveau jeton API pour Cloudflare et récupérer vos identifiants de zone et de compte.
|
||||
|
||||
Sur le tableau de bord de Cloudflare, dans la page de présentation de votre domaine, vous pouvez voir les identifiants de `zone` et de `compte` en bas à droite de l'écran. Copiez précieusement ces deux identifiants.
|
||||
|
||||

|
||||
|
||||
Juste en dessous d'eux, il y a un lien intitulé _Obtenez votre jeton API_. Cliquez dessus. Le périmètre dont nous avons besoin pour le jeton doit inclure `Zone:DNS:Edit` et `Account:Cloudflare Tunnel:Edit`. Assurez-vous que votre page de création de token ressemble à celle illustrée dans la capture d'écran ci-dessous.
|
||||
Juste en dessous d'eux, il y a un lien intitulé _Obtenez votre jeton API_. Cliquez dessus. Le périmètre dont vous avez besoin pour le jeton doit inclure `Zone:DNS:Edit` et `Account:Cloudflare Tunnel:Edit`. Assurez-vous que votre page de création de token ressemble à celle illustrée dans la capture d'écran ci-dessous.
|
||||
|
||||

|
||||
|
||||
Une fois que nous aurons enregistré, notre jeton sera affiché une fois. copiez le précieusement, car vous ne pourrez plus le revoir après la fermeture.
|
||||
Une fois que vous aurez enregistré, votre jeton sera affiché une fois. Copiez-le précieusement, car vous ne pourrez plus le revoir après la fermeture.
|
||||
|
||||
### Cloudflare Zero Trust
|
||||
|
||||
@@ -60,7 +60,7 @@ Vous devez vous inscrire à _Cloudflare Teams_ pour pouvoir accéder au tableau
|
||||
|
||||
Inscrivez-vous [via ce lien](https://one.dash.cloudflare.com/).
|
||||
|
||||
## Configuration de Swag
|
||||
## Configuration de SWAG
|
||||
::note
|
||||
|
||||
Nous partons du principe que vous avez le domaine `mondomaine.fr` avec les DNS qui pointent bien vers ceux de Cloudflare, comme vu précédemment.
|
||||
@@ -69,7 +69,7 @@ Nous partons du principe que vous avez le domaine `mondomaine.fr` avec les DNS q
|
||||
SWAG dispose de deux `Docker Mods` permettant d'y intégrer :
|
||||
|
||||
- __Cloudflared__, le conteneur qui permet de créer et de gérer les tunnels
|
||||
- __Cloudflared Real IP__, un conteneur qui permet à SWAG d'obtenir la vraie source IP des requêtes depuis internet plutot que celle de Docker (ce qui pourrait entrer en conflit avec le mod de géolocalisatioN DBIP).
|
||||
- __Cloudflared Real IP__, un conteneur qui permet à SWAG d'obtenir la vraie source IP des requêtes depuis internet plutôt que celle de Docker (ce qui pourrait entrer en conflit avec le mod de géolocalisation DBIP).
|
||||
|
||||
Ces deux mods, fusionnés dans le conteneur de SWAG, nécessitent un peu de configuration.
|
||||
|
||||
@@ -211,9 +211,9 @@ TUNNEL_PW=
|
||||
| `TUNNEL_NAME`{lang=properties} | Le nom de votre tunnel | `mon_tunnel` |
|
||||
| `TUNNEL_PW`{lang=properties} | Un mot de passe fort généré aléatoirement | `iSzKRmP4VbnlsMvdSdgBEJiJi` |
|
||||
|
||||
Une fois fait, déployez la stack. Cela prendra un peu de temps, vérifiez les logs, vous devriez arriver à `serveur ready`
|
||||
Une fois fait, déployez la stack. Cela prendra un peu de temps, vérifiez les logs, vous devriez arriver à `server ready`.
|
||||
|
||||
Une fois le conteneur en ligne, vérifiez dans cloudflare que votre tunnel est bien présent dans la section _Networks > Tunnels_ de [Cloudflare Zero Trust](https://one.dash.cloudflare.com/). Par défaut, l'ensemble des sous domaine sont redirigés vers le tunnel, sans avoir besoin de les déclarer [dans votre zone DNS](/general/networking/dns).
|
||||
Une fois le conteneur en ligne, vérifiez dans cloudflare que votre tunnel est bien présent dans la section _Networks > Tunnels_ de [Cloudflare Zero Trust](https://one.dash.cloudflare.com/). Par défaut, l'ensemble des sous-domaines sont redirigés vers le tunnel, sans avoir besoin de les déclarer [dans votre zone DNS](/general/networking/dns).
|
||||
|
||||
::tip{icon="" to="/general/networking/dns"}
|
||||
✨ __Astuce :__ si vous voulez exposer un service sans tunnel, déclarez simplement un enregistrement A **dans votre zone DNS**. En cas de problème de résolution, désactivez la fonction _proxy_ pour cet enregistrement, par exemple pour `sous.mondomaine.fr`.
|
||||
@@ -249,7 +249,7 @@ Dans le [tableau de bord DNS de Cloudflare](https://dash.cloudflare.com/), cliqu
|
||||
### Terminé !
|
||||
::
|
||||
|
||||
Si vous avez de nombreux sous-domaines, vous pouvez déclarer un seul sous domaine par tunnel comme ci-dessus, puis déclarer vos autres sous domaine en les faisant pointer vers ces sous domaines de référence.
|
||||
Si vous avez de nombreux sous-domaines, vous pouvez déclarer un seul sous-domaine par tunnel comme ci-dessus, puis déclarer vos autres sous-domaines en les faisant pointer vers ces sous-domaines de référence.
|
||||
|
||||
Ainsi, en cas de changement d'ID de tunnel, vous n'aurez qu'un seul enregistrement DNS à modifier.
|
||||
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
---
|
||||
title: TinyAuth
|
||||
description: Installer TinyAuth, un proxy de forward-auth léger, et l'associer à Pocket ID pour ajouter une connexion SSO devant vos applications auto-hébergées. Protéger votre application derrière Swag avec le forward-auth.
|
||||
description: Installer TinyAuth, un proxy de forward-auth léger, et l'associer à Pocket ID pour ajouter une connexion SSO devant vos applications auto-hébergées. Protéger votre application derrière SWAG avec le forward-auth.
|
||||
---
|
||||
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
|
||||
[TinyAuth](https://tinyauth.app) est une application qui permet de forcer une authentification avant d'accéder à un service : une page de connexion que Swag peut insérer devant n'importe quelle application avant de laisser passer une requête, en vérifiant si le visiteur est authentifié avant de le rediriger.
|
||||
[TinyAuth](https://tinyauth.app) est une application qui permet de forcer une authentification avant d'accéder à un service : une page de connexion que SWAG peut insérer devant n'importe quelle application avant de laisser passer une requête, en vérifiant si le visiteur est authentifié avant de le rediriger.
|
||||
|
||||

|
||||
|
||||
@@ -15,6 +15,8 @@ Nativement il gère une simple connexion locale identifiant/mot de passe, c'est
|
||||
- [Documentation de TinyAuth](https://tinyauth.app/docs/getting-started)
|
||||
- [TinyAuth sur GitHub](https://github.com/tinyauthapp/tinyauth)
|
||||
|
||||

|
||||
|
||||
## Installation
|
||||
|
||||
::file-tree
|
||||
@@ -135,7 +137,7 @@ Elle redemande l'identifiant, le mot de passe et le code à 6 chiffres du moment
|
||||
|
||||
À partir de maintenant, cet utilisateur a besoin à la fois de son mot de passe et d'un code valide de son application d'authentification pour se connecter.
|
||||
|
||||
## Exposer TinyAuth avec Swag
|
||||
## Exposer TinyAuth avec SWAG
|
||||
TinyAuth a besoin de son propre sous-domaine : c'est la page sur laquelle les utilisateurs arrivent avant d'être redirigés vers l'application qu'ils veulent réellement.
|
||||
|
||||
::note
|
||||
@@ -174,7 +176,7 @@ Nous partons ici du principe que le nom du réseau de TinyAuth est `tinyauth_def
|
||||
|
||||
### Créer le fichier subdomain.conf
|
||||
|
||||
Dans les dossiers de Swag, créez le fichier `tinyauth.subdomain.conf` :
|
||||
Dans les dossiers de SWAG, créez le fichier `tinyauth.subdomain.conf` :
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
✨ __Astuce :__ utilisez **File Browser Quantum** pour naviguer et modifier les fichiers plutôt que des commandes dans le terminal.
|
||||
@@ -225,7 +227,7 @@ __Si ça ne marche pas :__ vérifiez les règles de votre pare-feu.
|
||||
::
|
||||
|
||||
## Protéger une application via le reverse proxy
|
||||
Swag ne fournit pas de fichier d'inclusion tout prêt pour TinyAuth, nous ajouterons donc la vérification forward-auth directement dans le `*.subdomain.conf` de l'application. Nous prendrons Dockge en exemple.
|
||||
SWAG ne fournit pas de fichier d'inclusion tout prêt pour TinyAuth, nous ajouterons donc la vérification forward-auth directement dans le `*.subdomain.conf` de l'application. Nous prendrons Dockge en exemple.
|
||||
|
||||
::steps{level="3"}
|
||||
### Ouvrir le fichier subdomain.conf de l'application
|
||||
|
||||
@@ -15,6 +15,8 @@ C'est donc un bon choix si vous voulez simplement un backend SSO simple et rapid
|
||||
- [Documentation de Pocket ID](https://pocket-id.org/docs)
|
||||
- [Pocket ID sur GitHub](https://github.com/pocket-id/pocket-id)
|
||||
|
||||

|
||||
|
||||
## Installation
|
||||
|
||||
::file-tree
|
||||
@@ -96,7 +98,7 @@ TRUST_PROXY=true
|
||||
|----------|-------|---------|
|
||||
| `APP_URL`{lang=properties} | L'URL publique par laquelle vous joindrez Pocket ID (voir l'exposition plus bas) | `https://id.mondomaine.fr` |
|
||||
| `ENCRYPTION_KEY`{lang=properties} | La clé générée ci-dessus | `Q2pVEqsTNRkJSO9SkJzU3KZ2...` |
|
||||
| `TRUST_PROXY`{lang=properties} | Nécessaire puisque Pocket ID se trouve derrière Swag | `true` |
|
||||
| `TRUST_PROXY`{lang=properties} | Nécessaire puisque Pocket ID se trouve derrière SWAG | `true` |
|
||||
|
||||
Déployez la stack. L'interface locale est disponible sur `http://ipdevotreserveur:1411`.
|
||||
|
||||
@@ -114,7 +116,7 @@ Pocket ID n'utilise pas de mots de passe : votre premier compte est créé avec
|
||||
Les passkeys exigent un contexte sécurisé : HTTPS, ou `localhost`. Enregistrer une passkey depuis `http://ipdevotreserveur:1411` sur une autre machine sera refusé par le navigateur, puisque c'est du HTTP simple vers une adresse qui n'est pas `localhost`. Si la configuration ne se termine pas en local, exposez d'abord Pocket ID (voir plus bas) et terminez la configuration en HTTPS.
|
||||
::
|
||||
|
||||
## Exposer Pocket ID avec Swag
|
||||
## Exposer Pocket ID avec SWAG
|
||||
Les autres applications doivent joindre Pocket ID en HTTPS pour finaliser le processus de connexion OIDC, il doit donc être exposé même si vous ne l'utilisez que depuis chez vous.
|
||||
|
||||
::note
|
||||
@@ -153,7 +155,7 @@ Nous partons ici du principe que le nom du réseau de Pocket ID est `pocket-id_d
|
||||
|
||||
### Créer le fichier subdomain.conf
|
||||
|
||||
Dans les dossiers de Swag, créez le fichier `id.subdomain.conf` :
|
||||
Dans les dossiers de SWAG, créez le fichier `id.subdomain.conf` :
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
✨ __Astuce :__ utilisez **File Browser Quantum** pour naviguer et modifier les fichiers plutôt que des commandes dans le terminal.
|
||||
@@ -230,6 +232,8 @@ Enregistrez, puis copiez le __Client ID__ et le __Client Secret__ générés. Vo
|
||||
## Connecter Pocket ID à TinyAuth
|
||||
[TinyAuth](/serveex/security/tinyauth) peut déléguer sa connexion à Pocket ID plutôt que (ou en plus de) son identifiant/mot de passe local, de sorte que quiconque visite une application protégée s'authentifie avec une passkey et se retrouve redirigé.
|
||||
|
||||

|
||||
|
||||
::steps{level="3"}
|
||||
### Enregistrer TinyAuth comme client OIDC
|
||||
|
||||
|
||||
@@ -6,7 +6,9 @@ description: Installer Uptime-Kuma pour surveiller la disponibilité de vos serv
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
|
||||

|
||||
[Uptime-Kuma](https://github.com/louislam/uptime-kuma) est un outil de surveillance auto-hébergé qui vérifie régulièrement si vos autres services et sites sont en ligne et joignables, et vous alerte dès que l'un d'eux tombe. Il permet aussi de construire une page de statut publique pour partager l'état de vos services avec d'autres personnes.
|
||||
|
||||

|
||||
|
||||
## Installation
|
||||
|
||||
@@ -65,7 +67,7 @@ __Si ça ne marche pas :__ vérifiez les règles de votre pare-feu.
|
||||
### Terminé !
|
||||
::
|
||||
|
||||
## Exposer avec Swag
|
||||
## Exposer avec SWAG
|
||||
::note{icon=""}
|
||||
📋 __Au préalable :__
|
||||
<br/><br/>
|
||||
@@ -74,13 +76,13 @@ Nous partons du principe que vous avez le sous-domaine `stats.mondomaine.fr` ave
|
||||
|
||||
::warning
|
||||
|
||||
Uptime-Kuma n'utilise pas d'authentification multifacteur. L'exposer sur internet pourrait compromettre les machines qu'il surveille. Ne le faites que si vous utilisez un système MFA comme [TinyAuth](/serveex/security/tinyauth) ou [Authentik](/serveex/advanced/authentik/). Sinon, ne l'exposez pas avec SWAG, utilisez plutôt un VPN comme [Wireguard](/serveex/core/wireguard).
|
||||
Uptime-Kuma n'utilise pas d'authentification multifacteur. L'exposer sur internet pourrait compromettre les machines qu'il surveille. Ne le faites que si vous utilisez un système MFA comme [TinyAuth](/serveex/security/tinyauth) ou [Authentik](/serveex/advanced/authentik/). Sinon, ne l'exposez pas avec SWAG, utilisez plutôt un VPN comme [WireGuard](/serveex/core/wireguard).
|
||||
::
|
||||
|
||||
::steps{level="3"}
|
||||
### Créer le fichier subdomain.conf
|
||||
|
||||
Dans les dossiers de Swag, créez le fichier `stats.subdomain.conf`.
|
||||
Dans les dossiers de SWAG, créez le fichier `stats.subdomain.conf`.
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
✨ __Astuce pour les allergiques au terminal :__
|
||||
@@ -179,7 +181,7 @@ Nous partons ici du principe que le nom du réseau d'Uptime-Kuma est `uptime-kum
|
||||
Et voilà ! Uptime-Kuma est maintenant exposé, et vous pouvez y accéder via `https://stats.mondomaine.fr`.
|
||||
|
||||
## Protéger Uptime-Kuma avec TinyAuth
|
||||
[TinyAuth](/serveex/security/tinyauth) peut se placer devant Uptime-Kuma comme devant n'importe quelle autre application, mais ici nous voulons aussi que la page de statut publique (et les ressources dont elle a besoin pour s'afficher) reste joignable sans se connecter. Cela utilise la même technique de `location` en expression régulière que [Laisser certains chemins publics](/serveex/security/tinyauth#leaving-specific-paths-public), appliquée directement à `stats.subdomain.conf`.
|
||||
[TinyAuth](/serveex/security/tinyauth) peut se placer devant Uptime-Kuma comme devant n'importe quelle autre application, mais ici nous voulons aussi que la page de statut publique (et les ressources dont elle a besoin pour s'afficher) reste joignable sans se connecter. Cela utilise la même technique de `location` en expression régulière que [Laisser certains chemins publics](/serveex/security/tinyauth#laisser-certains-chemins-publics), appliquée directement à `stats.subdomain.conf`.
|
||||
|
||||
::steps{level="3"}
|
||||
### Ouvrir le fichier subdomain.conf
|
||||
@@ -190,7 +192,7 @@ sudo nano /srv/docker/swag/config/nginx/proxy-confs/stats.subdomain.conf
|
||||
|
||||
### Ajouter la vérification forward-auth et les chemins publics
|
||||
|
||||
Remplacez le contenu du fichier par ce qui suit. Le bloc `location ~ ^/(...)` correspond à la page de statut publique d'Uptime-Kuma et à ses ressources, et est servi directement, sans jamais atteindre la vérification `auth_request` du `location /` :
|
||||
Remplacez le contenu du fichier par ce qui suit. Le bloc `location ~ ^/(...)` correspond à la page de statut publique d'Uptime-Kuma et à ses ressources, et est servi directement, sans jamais atteindre la vérification `auth_request` du `location /`. Seul `api/status-page` est laissé public, pas tout `/api`, car le reste de l'API d'Uptime-Kuma doit rester derrière l'authentification ; `/metrics` (l'endpoint Prometheus d'Uptime-Kuma) est volontairement absent de la regex pour la même raison :
|
||||
|
||||
```nginx [stats.subdomain.conf]{9-16,32-33}
|
||||
server {
|
||||
@@ -201,7 +203,7 @@ server {
|
||||
|
||||
include /config/nginx/ssl.conf;
|
||||
|
||||
location ~ ^/(status|assets|icon\.svg|api|upload|metrics) {
|
||||
location ~ ^/(status|assets|icon\.svg|api/status-page|upload) {
|
||||
include /config/nginx/proxy.conf;
|
||||
include /config/nginx/resolver.conf;
|
||||
set $upstream_app uptime-kuma;
|
||||
@@ -238,7 +240,7 @@ server {
|
||||
}
|
||||
```
|
||||
|
||||
::note{to="/serveex/security/tinyauth#exposing-tinyauth-with-swag"}
|
||||
::note{to="/serveex/security/tinyauth#exposer-tinyauth-avec-swag"}
|
||||
|
||||
Le bloc `location /tinyauth` s'exécute dans le conteneur de SWAG lui-même, SWAG doit donc être sur le réseau Docker de TinyAuth pour le joindre par son nom (`tinyauth` ici). Cela devrait déjà être en place depuis **l'exposition de TinyAuth**. Si vous rencontrez une erreur, revérifiez que le fichier compose de SWAG a toujours ce réseau rattaché.
|
||||
::
|
||||
@@ -251,7 +253,7 @@ Appuyez sur :kbd{value="Ctrl+O"}, puis :kbd{value="Enter"} pour enregistrer, et
|
||||
Redéployez la stack. Uptime-Kuma sera alors joignable publiquement via `https://stats.mondomaine.fr`, avec la page de statut ouverte et tout le reste derrière TinyAuth.
|
||||
|
||||
::tip{icon=""}
|
||||
✨ __Astuce :__ vous pouvez aussi protéger cette application avec [Authentik](/serveex/advanced/authentik) à la place : ouvrez `stats.subdomain.conf` et décommentez les lignes `include /config/nginx/authentik-server.conf;` et `include /config/nginx/authentik-location.conf;`. N'oubliez pas de [créer une application et un provider dans Authentik](/serveex/advanced/authentik#protecting-an-app-via-reverse-proxy). Modifiez ensuite le provider Uptime-Kuma, et dans *Advanced Protocol Settings > Authenticated Paths*, saisissez :
|
||||
✨ __Astuce :__ vous pouvez aussi protéger cette application avec [Authentik](/serveex/advanced/authentik) à la place : ouvrez `stats.subdomain.conf` et décommentez les lignes `include /config/nginx/authentik-server.conf;` et `include /config/nginx/authentik-location.conf;`. N'oubliez pas de [créer une application et un provider dans Authentik](/serveex/advanced/authentik#protéger-une-app-par-reverse-proxy). Modifiez ensuite le provider Uptime-Kuma, et dans *Advanced Protocol Settings > Authenticated Paths*, saisissez :
|
||||
|
||||
```properties
|
||||
^/$
|
||||
|
||||
@@ -39,6 +39,8 @@ services:
|
||||
image: amir20/dozzle:latest
|
||||
ports:
|
||||
- 9135:8080
|
||||
volumes:
|
||||
- /docker/dozzle/data:/data
|
||||
env_file:
|
||||
- .env
|
||||
environment:
|
||||
@@ -104,14 +106,14 @@ Déployez le conteneur. Allez sur `http://ipdevotreserveur:9135`. Et voilà, vot
|
||||
### Terminé !
|
||||
::
|
||||
|
||||
## Exposer Dozzle avec Swag
|
||||
## Exposer Dozzle avec SWAG
|
||||
|
||||
::warning
|
||||
|
||||
Dozzle n'utilise pas d'authentification multifacteur. L'exposer sur internet pourrait compromettre les machines auxquelles il est relié. Ne le faites que si vous utilisez un système d'authentification multifacteur comme [TinyAuth](/serveex/security/tinyauth) ou [Authentik](/serveex/advanced/authentik/). Sinon, ne l'exposez pas avec SWAG et utilisez plutôt un VPN comme [Wireguard](/serveex/core/wireguard).
|
||||
Dozzle n'utilise pas d'authentification multifacteur. L'exposer sur internet pourrait compromettre les machines auxquelles il est relié. Ne le faites que si vous utilisez un système d'authentification multifacteur comme [TinyAuth](/serveex/security/tinyauth) ou [Authentik](/serveex/advanced/authentik/). Sinon, ne l'exposez pas avec SWAG et utilisez plutôt un VPN comme [WireGuard](/serveex/core/wireguard).
|
||||
::
|
||||
|
||||
Vous voudrez peut-être accéder à Dozzle à distance et sur tous vos appareils. Pour cela, nous allons exposer Dozzle via Swag.
|
||||
Vous voudrez peut-être accéder à Dozzle à distance et sur tous vos appareils. Pour cela, nous allons exposer Dozzle via SWAG.
|
||||
|
||||
::note{icon=""}
|
||||
📋 __Au préalable :__
|
||||
@@ -150,7 +152,7 @@ Nous partons du principe que le nom du réseau de Dozzle est `dozzle_default`. V
|
||||
|
||||
### Créer le fichier subdomain.conf
|
||||
|
||||
Dans le dossier de Swag, créez le fichier `dozzle.subdomain.conf`.
|
||||
Dans le dossier de SWAG, créez le fichier `dozzle.subdomain.conf`.
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
✨ __Astuce :__ vous pouvez utiliser **File Browser Quantum** pour naviguer et modifier vos fichiers plutôt que des commandes dans le terminal.
|
||||
|
||||
@@ -56,7 +56,7 @@ services:
|
||||
- ${PORT}:80
|
||||
environment:
|
||||
- PUID=${PUID}
|
||||
- PGID=${GUID}
|
||||
- PGID=${PGID}
|
||||
- TZ=Europe/Paris
|
||||
- APP_KEY=${API_KEY}
|
||||
- DB_CONNECTION=sqlite
|
||||
@@ -67,19 +67,19 @@ services:
|
||||
|
||||
### Renseigner vos variables d'environnement
|
||||
|
||||
Trouvez vos `PUID` et `GUID` avec la commande suivante :
|
||||
Trouvez vos `PUID` et `PGID` avec la commande suivante :
|
||||
|
||||
```bash [Terminal]
|
||||
id votreutilisateur
|
||||
```
|
||||
|
||||
Dans le fichier `.env`, renseignez la variable `API_KEY` avec la clé générée et ajoutez une planification des tests au format cron, ainsi que vos `PUID` et `GUID`, par exemple :
|
||||
Dans le fichier `.env`, renseignez la variable `API_KEY` avec la clé générée et ajoutez une planification des tests au format cron, ainsi que vos `PUID` et `PGID`, par exemple :
|
||||
|
||||
```properties [.env]
|
||||
SCHEDULE=15 */6 * * * # toutes les 6 heures
|
||||
API_KEY=base64:zihejehkj8_nzhY/OjeieR= # votre clé
|
||||
PUID=1000
|
||||
GUID=1000
|
||||
PGID=1000
|
||||
PORT=3225 # port d'accès à l'interface web
|
||||
```
|
||||
|
||||
@@ -102,7 +102,7 @@ Nous voulons maintenant exposer Speedtest Tracker sur internet pour y accéder
|
||||
|
||||
::warning
|
||||
|
||||
Speedtest Tracker n'utilise pas d'authentification multifacteur. L'exposer sur internet pourrait compromettre les appareils connectés. Ne le faites que si vous utilisez un système multifacteur comme [TinyAuth](/serveex/security/tinyauth) ou [Authentik](/serveex/advanced/authentik/). Sinon, évitez SWAG et préférez un VPN comme [Wireguard](/serveex/core/wireguard).
|
||||
Speedtest Tracker n'utilise pas d'authentification multifacteur. L'exposer sur internet pourrait compromettre les appareils connectés. Ne le faites que si vous utilisez un système multifacteur comme [TinyAuth](/serveex/security/tinyauth) ou [Authentik](/serveex/advanced/authentik/). Sinon, évitez SWAG et préférez un VPN comme [WireGuard](/serveex/core/wireguard).
|
||||
::
|
||||
|
||||
::steps{level="3"}
|
||||
@@ -200,7 +200,7 @@ Ceci suppose que le réseau de Speedtest Tracker s'appelle `speedtest-tracker_de
|
||||
Patientez un instant, puis visitez `https://speedtest.mondomaine.fr` dans votre navigateur. Vous devriez être redirigé vers Speedtest Tracker. Vous pouvez vérifier l'état du service via le tableau de bord (`http://ipdevotreserveur:81` depuis le réseau local).
|
||||
|
||||
## Protéger Speedtest Tracker avec TinyAuth
|
||||
Ajoutez la vérification forward-auth de [TinyAuth](/serveex/security/tinyauth) directement dans `speedtest.subdomain.conf`, de la même façon que dans [le tutoriel TinyAuth](/serveex/security/tinyauth#protecting-an-app-via-reverse-proxy) :
|
||||
Ajoutez la vérification forward-auth de [TinyAuth](/serveex/security/tinyauth) directement dans `speedtest.subdomain.conf`, de la même façon que dans [le tutoriel TinyAuth](/serveex/security/tinyauth#protéger-une-application-via-le-reverse-proxy) :
|
||||
|
||||
```nginx [speedtest.subdomain.conf]{22-34,37-38}
|
||||
## Version 2023/12/19
|
||||
@@ -262,7 +262,7 @@ server {
|
||||
}
|
||||
```
|
||||
|
||||
::note{to="/serveex/security/tinyauth#exposing-tinyauth-with-swag"}
|
||||
::note{to="/serveex/security/tinyauth#exposer-tinyauth-avec-swag"}
|
||||
|
||||
Le bloc `location /tinyauth` s'exécute dans le conteneur de SWAG lui-même, SWAG doit donc être sur le réseau Docker de TinyAuth pour le joindre par son nom (`tinyauth` ici). Cela devrait déjà être en place depuis **l'exposition de TinyAuth**. Si vous rencontrez une erreur, revérifiez que le fichier compose de SWAG a toujours ce réseau rattaché.
|
||||
::
|
||||
@@ -270,5 +270,5 @@ Le bloc `location /tinyauth` s'exécute dans le conteneur de SWAG lui-même, SWA
|
||||
::tip{icon=""}
|
||||
✨ Vous pouvez protéger cette application avec [Authentik](/serveex/advanced/authentik) plutôt que TinyAuth, en ouvrant `speedtest.subdomain.conf` et en décommentant
|
||||
`include /config/nginx/authentik-server.conf;` et `include /config/nginx/authentik-location.conf;`.
|
||||
N'oubliez pas de [créer une application et un provider dans Authentik](/serveex/advanced/authentik#protecting-an-app-via-reverse-proxy).
|
||||
N'oubliez pas de [créer une application et un provider dans Authentik](/serveex/advanced/authentik#protéger-une-app-par-reverse-proxy).
|
||||
::
|
||||
|
||||
@@ -182,14 +182,14 @@ Déployez la stack sur le serveur distant. Les données commenceront à remonter
|
||||
__Si ça ne marche pas :__ vérifiez les règles de votre pare-feu.
|
||||
::
|
||||
|
||||
## Exposer Beszel avec Swag
|
||||
## Exposer Beszel avec SWAG
|
||||
|
||||
::warning
|
||||
|
||||
Beszel ne gère pas l'authentification multifacteur. L'exposer sur internet pourrait compromettre les machines connectées. Ne le faites que si vous utilisez un système comme [TinyAuth](/serveex/security/tinyauth) ou [Authentik](/serveex/advanced/authentik/). Sinon, ne l'exposez pas avec SWAG. Utilisez plutôt un VPN comme [Wireguard](/serveex/core/wireguard).
|
||||
Beszel ne gère pas l'authentification multifacteur. L'exposer sur internet pourrait compromettre les machines connectées. Ne le faites que si vous utilisez un système comme [TinyAuth](/serveex/security/tinyauth) ou [Authentik](/serveex/advanced/authentik/). Sinon, ne l'exposez pas avec SWAG. Utilisez plutôt un VPN comme [WireGuard](/serveex/core/wireguard).
|
||||
::
|
||||
|
||||
Si vous voulez accéder à Beszel à distance depuis tous vos appareils, exposez-le avec Swag.
|
||||
Si vous voulez accéder à Beszel à distance depuis tous vos appareils, exposez-le avec SWAG.
|
||||
|
||||
::note{icon="" to="/general/networking/nat"}
|
||||
📋 __Au préalable :__
|
||||
@@ -200,7 +200,7 @@ Vous devez avoir créé un sous-domaine DNS du type `beszel.mondomaine.fr` avec
|
||||
::steps{level="3"}
|
||||
### Ajouter le réseau de Beszel à SWAG
|
||||
|
||||
Dans Dockge, modifiez le fichier compose de Swag et ajoutez le réseau de Beszel :
|
||||
Dans Dockge, modifiez le fichier compose de SWAG et ajoutez le réseau de Beszel :
|
||||
|
||||
```yaml [compose.yaml]
|
||||
---
|
||||
@@ -219,16 +219,16 @@ networks:
|
||||
external: true
|
||||
```
|
||||
|
||||
Redéployez la stack et attendez que Swag soit pleinement opérationnel.
|
||||
Redéployez la stack et attendez que SWAG soit pleinement opérationnel.
|
||||
|
||||
::note
|
||||
|
||||
Nous partons du principe que le nom du réseau est `beszel_default`. Vous pouvez vérifier la connectivité en visitant le tableau de bord de Swag sur `http://ipdevotreserveur:81`.
|
||||
Nous partons du principe que le nom du réseau est `beszel_default`. Vous pouvez vérifier la connectivité en visitant le tableau de bord de SWAG sur `http://ipdevotreserveur:81`.
|
||||
::
|
||||
|
||||
### Créer le fichier subdomain.conf
|
||||
|
||||
Dans les dossiers de configuration de Swag, créez `beszel.subdomain.conf`.
|
||||
Dans les dossiers de configuration de SWAG, créez `beszel.subdomain.conf`.
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
✨ __Astuce :__ utilisez **File Browser Quantum** pour naviguer et modifier vos fichiers plutôt que des commandes dans le terminal.
|
||||
|
||||
@@ -8,7 +8,7 @@ description: Installer UpSnap pour réveiller à distance les machines de votre
|
||||
|
||||
[UpSnap](https://github.com/seriousm4x/UpSnap) est un conteneur qui permet d'allumer, d'éteindre ou de mettre en veille vos machines à distance. Il utilise principalement le Wake-On-Lan (WoL) sur le réseau et propose des fonctions avancées.
|
||||
|
||||

|
||||

|
||||
|
||||
## Installation
|
||||
|
||||
@@ -85,14 +85,14 @@ Déployez le conteneur et allez sur `http://ipdevotreserveur:8095`. Suivez simpl
|
||||
__Si ça ne marche pas :__ vérifiez les règles de votre pare-feu.
|
||||
::
|
||||
|
||||
## Exposer UpSnap avec Swag
|
||||
## Exposer UpSnap avec SWAG
|
||||
|
||||
::warning
|
||||
|
||||
UpSnap ne gère pas l'authentification multifacteur. L'exposer sur internet pourrait compromettre les machines connectées. Ne le faites que si vous utilisez un système d'authentification multifacteur comme [TinyAuth](/serveex/security/tinyauth) ou [Authentik](/serveex/advanced/authentik/). Sinon, évitez de l'exposer avec SWAG et utilisez plutôt un VPN comme [Wireguard](/serveex/core/wireguard).
|
||||
UpSnap ne gère pas l'authentification multifacteur. L'exposer sur internet pourrait compromettre les machines connectées. Ne le faites que si vous utilisez un système d'authentification multifacteur comme [TinyAuth](/serveex/security/tinyauth) ou [Authentik](/serveex/advanced/authentik/). Sinon, évitez de l'exposer avec SWAG et utilisez plutôt un VPN comme [WireGuard](/serveex/core/wireguard).
|
||||
::
|
||||
|
||||
Vous voudrez peut-être y accéder à distance depuis tous vos appareils. Pour cela, nous allons exposer UpSnap via Swag.
|
||||
Vous voudrez peut-être y accéder à distance depuis tous vos appareils. Pour cela, nous allons exposer UpSnap via SWAG.
|
||||
|
||||
::note{icon=""}
|
||||
📋 __Au préalable :__
|
||||
@@ -101,9 +101,9 @@ Nous partons du principe que vous avez créé un sous-domaine dans votre [zone D
|
||||
::
|
||||
|
||||
::steps{level="3"}
|
||||
### Ajouter le réseau d'UpSnap à SWAG
|
||||
### Rendre l'hôte accessible depuis SWAG
|
||||
|
||||
Allez dans Dockge et modifiez le compose de SWAG en y ajoutant le réseau d'UpSnap :
|
||||
UpSnap tourne en `network_mode: host` (nécessaire pour que la diffusion Wake-on-LAN et le scan réseau fonctionnent de manière fiable), il ne rejoint donc jamais de réseau Docker auquel SWAG pourrait se rattacher comme pour les autres stacks. Il faut à la place donner à SWAG un moyen d'atteindre l'hôte lui-même :
|
||||
|
||||
```yaml [compose.yaml]
|
||||
---
|
||||
@@ -111,27 +111,20 @@ services:
|
||||
swag:
|
||||
container_name: # ...
|
||||
# ...
|
||||
networks: # Rattache le conteneur au réseau personnalisé
|
||||
# ...
|
||||
- upsnap # Nom du réseau déclaré dans la stack
|
||||
|
||||
networks: # Définit le réseau personnalisé
|
||||
# ...
|
||||
upsnap: # Nom du réseau déclaré dans la stack
|
||||
name: upsnap_default # Nom réel du réseau externe
|
||||
external: true # Indique qu'il s'agit d'un réseau externe
|
||||
extra_hosts:
|
||||
- "host.docker.internal:host-gateway" # se résout vers l'IP de l'hôte Docker lui-même
|
||||
```
|
||||
|
||||
Redémarrez la stack en cliquant sur « deploy » et attendez que SWAG soit pleinement opérationnel.
|
||||
|
||||
::note
|
||||
|
||||
Nous partons ici du principe que le nom du réseau d'upsnap est `upsnap_default`. Vous pouvez vérifier la connexion dans le tableau de bord de SWAG sur `http://ipdevotreserveur:81`.
|
||||
`host-gateway` est une valeur spéciale que Docker résout automatiquement vers l'IP de la machine hôte, donc cela fonctionne quelle que soit l'adresse réelle de votre serveur.
|
||||
::
|
||||
|
||||
### Créer le fichier subdomain.conf
|
||||
|
||||
Dans les dossiers de Swag, créez le fichier `upsnap.subdomain.conf`.
|
||||
Dans les dossiers de SWAG, créez le fichier `upsnap.subdomain.conf`.
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
✨ __Astuce :__ vous pouvez utiliser **File Browser Quantum** pour naviguer dans vos fichiers et éditer vos documents plutôt que des commandes dans le terminal.
|
||||
@@ -184,7 +177,7 @@ server {
|
||||
|
||||
include /config/nginx/proxy.conf;
|
||||
include /config/nginx/resolver.conf;
|
||||
set $upstream_app upsnap;
|
||||
set $upstream_app host.docker.internal;
|
||||
set $upstream_port 8095;
|
||||
set $upstream_proto http;
|
||||
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
|
||||
@@ -201,7 +194,7 @@ Appuyez sur :kbd{value="Ctrl+O"}, puis :kbd{value="Enter"} pour enregistrer, et
|
||||
Et voilà ! Vous avez exposé UpSnap !
|
||||
|
||||
## Protéger UpSnap avec TinyAuth
|
||||
Ajoutez la vérification forward-auth de [TinyAuth](/serveex/security/tinyauth) directement dans `upsnap.subdomain.conf`, de la même façon que dans [le tutoriel TinyAuth](/serveex/security/tinyauth#protecting-an-app-via-reverse-proxy) :
|
||||
Ajoutez la vérification forward-auth de [TinyAuth](/serveex/security/tinyauth) directement dans `upsnap.subdomain.conf`, de la même façon que dans [le tutoriel TinyAuth](/serveex/security/tinyauth#protéger-une-application-via-le-reverse-proxy) :
|
||||
|
||||
```nginx [upsnap.subdomain.conf]{26-38,41-42}
|
||||
## Version 2023/12/19
|
||||
@@ -262,7 +255,7 @@ server {
|
||||
|
||||
include /config/nginx/proxy.conf;
|
||||
include /config/nginx/resolver.conf;
|
||||
set $upstream_app upsnap;
|
||||
set $upstream_app host.docker.internal;
|
||||
set $upstream_port 8095;
|
||||
set $upstream_proto http;
|
||||
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
|
||||
@@ -271,11 +264,11 @@ server {
|
||||
}
|
||||
```
|
||||
|
||||
::note{to="/serveex/security/tinyauth#exposing-tinyauth-with-swag"}
|
||||
::note{to="/serveex/security/tinyauth#exposer-tinyauth-avec-swag"}
|
||||
|
||||
Le bloc `location /tinyauth` s'exécute dans le conteneur de SWAG lui-même, SWAG doit donc être sur le réseau Docker de TinyAuth pour le joindre par son nom (`tinyauth` ici). Cela devrait déjà être en place depuis **l'exposition de TinyAuth**. Si vous rencontrez une erreur, revérifiez que le fichier compose de SWAG a toujours ce réseau rattaché.
|
||||
::
|
||||
|
||||
::tip{icon=""}
|
||||
✨ Vous pouvez protéger cette application avec [Authentik](/serveex/advanced/authentik) plutôt que TinyAuth, en ouvrant `upsnap.subdomain.conf` et en retirant le `#` devant `include /config/nginx/authentik-server.conf;`{lang=nginx} et `include /config/nginx/authentik-location.conf;`{lang=nginx}. N'oubliez pas de [créer une application et un provider dans Authentik](/serveex/advanced/authentik#protecting-an-app-via-reverse-proxy).
|
||||
✨ Vous pouvez protéger cette application avec [Authentik](/serveex/advanced/authentik) plutôt que TinyAuth, en ouvrant `upsnap.subdomain.conf` et en retirant le `#` devant `include /config/nginx/authentik-server.conf;`{lang=nginx} et `include /config/nginx/authentik-location.conf;`{lang=nginx}. N'oubliez pas de [créer une application et un provider dans Authentik](/serveex/advanced/authentik#protéger-une-app-par-reverse-proxy).
|
||||
::
|
||||
|
||||
@@ -16,7 +16,7 @@ Comme toujours, nous utiliserons l'[image linuxserver.io](https://docs.linuxserv
|
||||
|
||||
::note{to="/serveex/core/wireguard"}
|
||||
|
||||
Contrairement à Plex, Jellyfin n'a pas de relais cloud : pour accéder à votre serveur en dehors de votre réseau local, vous devez l'exposer vous-même (voir plus bas), ou utiliser un VPN comme **Wireguard**.
|
||||
Contrairement à Plex, Jellyfin n'a pas de relais cloud : pour accéder à votre serveur en dehors de votre réseau local, vous devez l'exposer vous-même (voir plus bas), ou utiliser un VPN comme **WireGuard**.
|
||||
::
|
||||
|
||||
## Installer Jellyfin
|
||||
@@ -44,7 +44,7 @@ tree:
|
||||
Créez les dossiers `movies`, `tvseries` et `library` dans `/media` :
|
||||
|
||||
```bash [Terminal]
|
||||
mkdir -p /media/movies /media/library /media/tvseries
|
||||
mkdir -p /media/movies /media/tvseries /media/library
|
||||
```
|
||||
|
||||
### Déployer la stack
|
||||
@@ -59,7 +59,7 @@ services:
|
||||
container_name: jellyfin
|
||||
environment:
|
||||
- PUID=${PUID}
|
||||
- PGID=${GUID}
|
||||
- PGID=${PGID}
|
||||
- TZ=Europe/Paris
|
||||
volumes:
|
||||
- /srv/docker/jellyfin/config:/config
|
||||
@@ -86,7 +86,7 @@ services:
|
||||
|
||||
### Renseigner vos variables d'environnement
|
||||
|
||||
Trouvez vos PUID et GUID en lançant :
|
||||
Trouvez vos PUID et PGID en lançant :
|
||||
|
||||
```bash [Terminal]
|
||||
id utilisateur
|
||||
@@ -96,7 +96,7 @@ Remplissez votre fichier `.env` avec les valeurs récupérées, par exemple :
|
||||
|
||||
```properties [.env]
|
||||
PUID=1000
|
||||
GUID=1000
|
||||
PGID=1000
|
||||
```
|
||||
|
||||
Déployez la stack. L'interface locale est disponible sur `http://ipdevotreserveur:8096`.
|
||||
@@ -124,7 +124,7 @@ Si vos médias sont stockés sur un disque réseau (un NAS ou un disque dur exte
|
||||
|
||||
## Transcodage matériel
|
||||
|
||||
Jellyfin réencode la vidéo à la volée dès qu'un client ne peut pas lire un fichier tel quel : la résolution de l'écran de l'appareil est inférieure à celle de la source, sa connexion réseau est trop lente pour le débit du fichier, ou il ne prend pas en charge le codec, le format HDR ou le type de sous-titres du fichier. C'est ce qu'on appelle le **transcodage**. Lorsque le transcodage est logiciel et éxecuté par le CPU, cela prend énormément de ressources et cela peut saturer un serveur modeste avec seulement un ou deux flux simultanés. Le **transcodage matériel** délègue ce travail au GPU intégré à votre processeur (Intel QuickSync, sur la plupart du matériel de homelab), qui s'en occupe bien plus vite et laisse le CPU libre pour tout le reste.
|
||||
Jellyfin réencode la vidéo à la volée dès qu'un client ne peut pas lire un fichier tel quel : la résolution de l'écran de l'appareil est inférieure à celle de la source, sa connexion réseau est trop lente pour le débit du fichier, ou il ne prend pas en charge le codec, le format HDR ou le type de sous-titres du fichier. C'est ce qu'on appelle le **transcodage**. Lorsque le transcodage est logiciel et exécuté par le CPU, cela prend énormément de ressources et cela peut saturer un serveur modeste avec seulement un ou deux flux simultanés. Le **transcodage matériel** délègue ce travail au GPU intégré à votre processeur (Intel QuickSync, sur la plupart du matériel de homelab), qui s'en occupe bien plus vite et laisse le CPU libre pour tout le reste.
|
||||
|
||||
Le **tone mapping** est une fonction liée mais distincte : convertir une vidéo HDR (qui a besoin d'un écran HDR compatible pour rendre correctement) en SDR pour qu'elle s'affiche correctement sur un écran, une TV ou un client qui ne gère pas le HDR, au lieu de paraître délavée ou trop sombre.
|
||||
|
||||
@@ -192,7 +192,7 @@ Jellyfin ne sera pas exposé sur internet dans ce site, contrairement à la plup
|
||||
|
||||
Plutôt que de faire passer tout le trafic d'un appareil par le VPN, ou même tout le sous-réseau VPN `10.8.0.0/24`, nous utiliserons un **split tunnel** plus serré : chaque appareil distant ne route par le tunnel que le trafic destiné à l'adresse VPN de votre serveur. Tout le reste (navigation, autres applications) reste sur la connexion normale de l'appareil, et le VPN ne sert jamais qu'à joindre cette seule machine.
|
||||
|
||||
::note{to="/serveex/core/wireguard#client-server-setup"}
|
||||
::note{to="/serveex/core/wireguard#sur-le-serveur-client"}
|
||||
|
||||
Ceci suppose que votre serveur Jellyfin fait déjà tourner son propre client WireGuard, le reliant à votre VPN comme décrit dans **Client Server Setup**. Notez l'adresse VPN que wg-easy lui a attribuée (par exemple `10.8.0.2`) ; c'est l'adresse que viseront tous les appareils ci-dessous.
|
||||
::
|
||||
@@ -204,7 +204,7 @@ Ce split tunnel est une convention côté client, pas une frontière de sécurit
|
||||
::steps{level="3"}
|
||||
### Créer un client dans wg-easy pour chaque appareil
|
||||
|
||||
En suivant [Récupérer les fichiers de configuration](/serveex/core/wireguard#retrieve-configuration-files), créez un client par appareil (téléphone, ordinateur, TV/boîtier multimédia) et téléchargez son fichier de configuration.
|
||||
En suivant [Récupérer les fichiers de configuration](/serveex/core/wireguard#récupérer-les-fichiers-de-configuration), créez un client par appareil (téléphone, ordinateur, TV/boîtier multimédia) et téléchargez son fichier de configuration.
|
||||
|
||||
### Restreindre le tunnel au seul serveur
|
||||
|
||||
|
||||
@@ -1,24 +1,24 @@
|
||||
---
|
||||
title: Qbittorrent
|
||||
title: qBittorrent
|
||||
description: Installer qBittorrent avec Gluetun et ProtonVPN pour télécharger des torrents de manière sécurisée derrière un VPN sur votre serveur auto-hébergé.
|
||||
---
|
||||
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
|
||||

|
||||

|
||||
|
||||
Afin de télécharger vos media favoris en toute sécurité, nous allons monter un système à base de :
|
||||
|
||||
- [Qbittorent](https://github.com/linuxserver/docker-qbittorrent) comme logiciel de téléchargement bittorent
|
||||
- [Proton VPN Plus](https://protonvpn.com/torrenting), VPN pour sécuriser vos échanges, auquel vous devez souscrire (il y a de nombreux codes promo) pour accéder au protocole Bittorent, mais vous pouvez également en choisir un autre, à condition qu'il propose le protocole bittorent.
|
||||
- [qBittorrent](https://github.com/linuxserver/docker-qbittorrent) comme logiciel de téléchargement BitTorrent
|
||||
- [Proton VPN Plus](https://protonvpn.com/torrenting), VPN pour sécuriser vos échanges, auquel vous devez souscrire (il y a de nombreux codes promo) pour accéder au protocole BitTorrent, mais vous pouvez également en choisir un autre, à condition qu'il propose le protocole BitTorrent.
|
||||
- [Gluetun](https://github.com/qdm12/gluetun)
|
||||
- [Qbittorrent port update](https://codeberg.org/TechnoSam/qbittorrent-gluetun-port-update) pour mettre automatiquement à jour le port de votre VPN (qui change régulièrement).
|
||||
- [qBittorrent port update](https://codeberg.org/TechnoSam/qbittorrent-gluetun-port-update) pour mettre automatiquement à jour le port de votre VPN (qui change régulièrement).
|
||||
- Et le mode [vuetorrent](https://github.com/gabe565/linuxserver-mod-vuetorrent) pour une interface moderne et intuitive.
|
||||
|
||||
Nous monterons ici le système ci-dessous :
|
||||
|
||||

|
||||

|
||||
|
||||
## Configuration
|
||||
|
||||
@@ -34,7 +34,7 @@ tree:
|
||||
- gluetun/
|
||||
- compose.yaml
|
||||
- .env
|
||||
- "media # relié à Jellyfin et Qbittorrent":
|
||||
- "media # relié à Jellyfin et qBittorrent":
|
||||
- "downloads/ # téléchargements génériques, choisis dans les réglages"
|
||||
- "movies/ # utilisé pour télécharger les films"
|
||||
- "tvseries/ # utilisé pour télécharger les séries"
|
||||
@@ -47,7 +47,7 @@ tree:
|
||||
Si ce n'est pas déjà fait, créez le dossier `downloads` dans `/media` :
|
||||
|
||||
```bash [Terminal]
|
||||
mkdir -P /media/downloads
|
||||
mkdir -p /media/downloads
|
||||
```
|
||||
|
||||
### Déployer la stack
|
||||
@@ -67,7 +67,7 @@ services:
|
||||
- DOCKER_MODS=ghcr.io/gabe565/linuxserver-mod-vuetorrent|ghcr.io/t-anc/gsp-qbittorent-gluetun-sync-port-mod:main
|
||||
- TZ=Europe/Paris
|
||||
- PUID=${PUID}
|
||||
- PGID=${GUID}
|
||||
- PGID=${PGID}
|
||||
- WEBUI_PORT=${UI_PORT}
|
||||
- GSP_GTN_API_KEY=${GSP_KEY}
|
||||
- GSP_QBT_USERNAME=${ID}
|
||||
@@ -88,7 +88,7 @@ services:
|
||||
devices:
|
||||
- /dev/net/tun:/dev/net/tun
|
||||
ports:
|
||||
- ${UI_PORT}:5695 # Port de la web-ui
|
||||
- ${UI_PORT}:${UI_PORT} # Port de la web-ui
|
||||
- 8000:8000 # Port de controle de Gluetun
|
||||
cap_add:
|
||||
- NET_ADMIN
|
||||
@@ -122,7 +122,7 @@ services:
|
||||
|
||||
### Configurer la mise à jour du port de téléchargement
|
||||
|
||||
Avant de renseigner le `.env` dans Dockge, configurons la mise à jour du port de téléchargement. Proton et la plupart des VPN font tourner le port de redirection, qui doit être communiqué à Qbittorrent.
|
||||
Avant de renseigner le `.env` dans Dockge, configurons la mise à jour du port de téléchargement. Proton et la plupart des VPN font tourner le port de redirection, qui doit être communiqué à qBittorrent.
|
||||
|
||||
Nous avons ajouté le mod `ghcr.io/t-anc/gsp-qbittorent-gluetun-sync-port-mod` au conteneur.
|
||||
|
||||
@@ -164,7 +164,7 @@ Dans Dockge, renseignez les variables du `.env` :
|
||||
|
||||
```properties [.env]
|
||||
PUID=
|
||||
GUID=
|
||||
PGID=
|
||||
UI_PORT=
|
||||
PR_KEY=
|
||||
GSP_KEY= # la clé générée et saisie dans config.toml
|
||||
@@ -177,12 +177,12 @@ Détail :
|
||||
| Variable | Description | Exemple |
|
||||
|------------|-------------|---------|
|
||||
| `PUID` | ID utilisateur (`id votreutilisateur`) | `1000` |
|
||||
| `GUID` | ID de groupe (`id votreutilisateur`) | `1000` |
|
||||
| `PGID` | ID de groupe (`id votreutilisateur`) | `1000` |
|
||||
| `UI_PORT` | Port d'accès à l'interface web | `5695` |
|
||||
| `PR_KEY` | Clé privée fournie par Proton | `buKsjNHLyzKMM1qYnzOy4s7SHfly` |
|
||||
| `GSP_KEY` | Clé générée pour la mise à jour du port | `MnBa47MeVmk7xiv` |
|
||||
| `ID` | Identifiant de connexion à l'interface Qbittorrent | `user` |
|
||||
| `PW` | Mot de passe de l'interface Qbittorrent | `password` |
|
||||
| `ID` | Identifiant de connexion à l'interface qBittorrent | `user` |
|
||||
| `PW` | Mot de passe de l'interface qBittorrent | `password` |
|
||||
|
||||
### Terminé !
|
||||
::
|
||||
@@ -194,7 +194,7 @@ Détail :
|
||||
|
||||
Une fois fait, déployez le conteneur.
|
||||
|
||||
::note{to="/serveex/core/docker/#dockge"}
|
||||
::note{to="/serveex/core/docker#installer-dockge-pour-gérer-et-déployer-les-conteneurs"}
|
||||
|
||||
**Les logs de démarrage affichent un mot de passe temporaire pour l'utilisateur `admin`.**
|
||||
Consultez les logs dans **Dockge** pour le récupérer, ou tapez cette commande dans un terminal :
|
||||
@@ -217,7 +217,7 @@ Changez votre identifiant et votre mot de passe dans les réglages « webui ».
|
||||
### Terminé !
|
||||
::
|
||||
|
||||
C'est terminé ! Dans les réglages de Qbittorrent, section « Téléchargements », définissez `/media/downloads` comme dossier par défaut.
|
||||
C'est terminé ! Dans les réglages de qBittorrent, section « Téléchargements », définissez `/media/downloads` comme dossier par défaut.
|
||||
|
||||
Lors de l'ajout d'un téléchargement, pensez à choisir le bon dossier pour que Jellyfin se synchronise correctement (`/media/movies` ou `/media/tvseries`). Vous pouvez aussi automatiser cela avec des catégories et des dossiers.
|
||||
|
||||
@@ -225,10 +225,10 @@ Lors de l'ajout d'un téléchargement, pensez à choisir le bon dossier pour que
|
||||
|
||||
::warning
|
||||
|
||||
Qbittorrent ne gère pas l'authentification multifacteur. L'exposer sur internet peut mettre votre système en danger. Ne le faites que si vous utilisez du MFA via [TinyAuth](/serveex/security/tinyauth) ou [Authentik](/serveex/advanced/authentik/). Sinon, ne l'exposez pas avec SWAG. Utilisez plutôt un VPN comme [Wireguard](/serveex/core/wireguard).
|
||||
qBittorrent ne gère pas l'authentification multifacteur. L'exposer sur internet peut mettre votre système en danger. Ne le faites que si vous utilisez du MFA via [TinyAuth](/serveex/security/tinyauth) ou [Authentik](/serveex/advanced/authentik/). Sinon, ne l'exposez pas avec SWAG. Utilisez plutôt un VPN comme [WireGuard](/serveex/core/wireguard).
|
||||
::
|
||||
|
||||
Pour lancer des téléchargements depuis l'extérieur, sans VPN, vous pouvez exposer l'interface web de Qbittorrent.
|
||||
Pour lancer des téléchargements depuis l'extérieur, sans VPN, vous pouvez exposer l'interface web de qBittorrent.
|
||||
|
||||
::note
|
||||
|
||||
@@ -321,7 +321,7 @@ server {
|
||||
include /config/nginx/proxy.conf;
|
||||
include /config/nginx/resolver.conf;
|
||||
set $upstream_app gluetun;
|
||||
set $upstream_port 5555;
|
||||
set $upstream_port 5695;
|
||||
set $upstream_proto http;
|
||||
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
|
||||
|
||||
@@ -334,10 +334,10 @@ Appuyez sur :kbd{value="Ctrl+O"}, puis :kbd{value="Enter"} pour enregistrer, et
|
||||
### Terminé !
|
||||
::
|
||||
|
||||
Attendez quelques minutes, puis allez sur `https://seedbox.mondomaine.fr`. Vous devriez arriver sur l'interface de Qbittorrent.
|
||||
Attendez quelques minutes, puis allez sur `https://seedbox.mondomaine.fr`. Vous devriez arriver sur l'interface de qBittorrent.
|
||||
|
||||
## Protéger Qbittorrent avec TinyAuth
|
||||
Ajoutez la vérification forward-auth de [TinyAuth](/serveex/security/tinyauth) directement dans `seedbox.subdomain.conf`, de la même façon que dans [le tutoriel TinyAuth](/serveex/security/tinyauth#protecting-an-app-via-reverse-proxy) :
|
||||
## Protéger qBittorrent avec TinyAuth
|
||||
Ajoutez la vérification forward-auth de [TinyAuth](/serveex/security/tinyauth) directement dans `seedbox.subdomain.conf`, de la même façon que dans [le tutoriel TinyAuth](/serveex/security/tinyauth#protéger-une-application-via-le-reverse-proxy) :
|
||||
|
||||
```nginx [seedbox.subdomain.conf]{26-38,41-42}
|
||||
## Version 2023/12/19
|
||||
@@ -399,7 +399,7 @@ server {
|
||||
include /config/nginx/proxy.conf;
|
||||
include /config/nginx/resolver.conf;
|
||||
set $upstream_app gluetun;
|
||||
set $upstream_port 5555;
|
||||
set $upstream_port 5695;
|
||||
set $upstream_proto http;
|
||||
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
|
||||
|
||||
@@ -407,15 +407,15 @@ server {
|
||||
}
|
||||
```
|
||||
|
||||
::note{to="/serveex/security/tinyauth#exposing-tinyauth-with-swag"}
|
||||
::note{to="/serveex/security/tinyauth#exposer-tinyauth-avec-swag"}
|
||||
|
||||
Le bloc `location /tinyauth` s'exécute dans le conteneur de SWAG lui-même, SWAG doit donc être sur le réseau Docker de TinyAuth pour le joindre par son nom (`tinyauth` ici). Cela devrait déjà être en place depuis **l'exposition de TinyAuth**. Si vous rencontrez une erreur, revérifiez que le fichier compose de SWAG a toujours ce réseau rattaché.
|
||||
::
|
||||
|
||||
::tip{icon=""}
|
||||
✨ Vous pouvez sécuriser cette application avec [Authentik](/serveex/advanced/authentik) plutôt que TinyAuth, en décommentant les lignes `authentik-server.conf` et `authentik-location.conf`. N'oubliez pas de [créer une application et un provider dans Authentik](/serveex/advanced/authentik#protecting-an-app-via-reverse-proxy).
|
||||
✨ Vous pouvez sécuriser cette application avec [Authentik](/serveex/advanced/authentik) plutôt que TinyAuth, en décommentant les lignes `authentik-server.conf` et `authentik-location.conf`. N'oubliez pas de [créer une application et un provider dans Authentik](/serveex/advanced/authentik#protéger-une-app-par-reverse-proxy).
|
||||
::
|
||||
|
||||
Et voilà ! Vous avez maintenant un media center prêt à l'emploi.
|
||||
|
||||

|
||||

|
||||
|
||||
@@ -49,7 +49,7 @@ tree:
|
||||
|
||||
::warning
|
||||
|
||||
__Attention :__ respectez bien cette structure de fichiers, en particulier le dossier `media`. Ce dossier doit être monté **exactement de la même façon** dans le fichier compose de _Qbittorrent_ (`/votre/chemin/media:/media`) et dans les applications _arr_. Sinon, les applications _arr_ risquent de ne pas reconnaître le chemin fourni par Qbittorrent et ne créeront pas de _hardlinks_. Sans hardlinks, les applications _arr_ copieront les fichiers, ce qui **doublera l'espace utilisé** sur votre stockage.
|
||||
__Attention :__ respectez bien cette structure de fichiers, en particulier le dossier `media`. Ce dossier doit être monté **exactement de la même façon** dans le fichier compose de _Qbittorrent_ (`/votre/chemin/media:/media`) et dans les applications _arr_. Sinon, les applications _arr_ risquent de ne pas reconnaître le chemin fourni par qBittorrent et ne créeront pas de _hardlinks_. Sans hardlinks, les applications _arr_ copieront les fichiers, ce qui **doublera l'espace utilisé** sur votre stockage.
|
||||
::
|
||||
|
||||
::steps{level="3"}
|
||||
@@ -133,8 +133,8 @@ services:
|
||||
container_name: bazarr
|
||||
restart: unless-stopped
|
||||
environment:
|
||||
- PUID=1000
|
||||
- PGID=1000
|
||||
- PUID=${PUID}
|
||||
- PGID=${PGID}
|
||||
- TZ=Europe/Paris
|
||||
volumes:
|
||||
- /srv/docker/bazarr/config:/config
|
||||
@@ -170,7 +170,7 @@ MEDIA_PATH=
|
||||
|----------------|-------------------------------------------------------------------------------------------------|-------------|
|
||||
| `PUID` | À renseigner avec vos informations utilisateur (à vérifier avec `id votreutilisateur`) | `1000` |
|
||||
| `PGID` | Idem | `1000` |
|
||||
| `MEDIA_PATH` | Chemin de votre dossier média, ici `/media`. Il doit correspondre à celui utilisé par Qbittorrent. | `/media` |
|
||||
| `MEDIA_PATH` | Chemin de votre dossier média, ici `/media`. Il doit correspondre à celui utilisé par qBittorrent. | `/media` |
|
||||
|
||||
::note
|
||||
|
||||
@@ -207,7 +207,7 @@ Créez un compte et choisissez *forms login*.
|
||||
|
||||
::warning
|
||||
|
||||
__Attention :__ si vous avez déjà des films dans `movies` provenant de Qbittorrent, ne laissez pas Radarr les ajouter. Radarr pourrait les modifier, ce qui interromprait le seed dans Qbittorrent.
|
||||
__Attention :__ si vous avez déjà des films dans `movies` provenant de qBittorrent, ne laissez pas Radarr les ajouter. Radarr pourrait les modifier, ce qui interromprait le seed dans qBittorrent.
|
||||
::
|
||||
|
||||
#### Configurer les profils
|
||||
@@ -216,12 +216,12 @@ Allez dans *Settings > Profiles*. Ce sont vos profils de qualité par défaut. Q
|
||||
|
||||

|
||||
|
||||
#### Ajouter Qbittorrent
|
||||
#### Ajouter qBittorrent
|
||||
|
||||
Dans *Settings > Download Clients*, ajoutez Qbittorrent.
|
||||
Dans *Settings > Download Clients*, ajoutez qBittorrent.
|
||||
|
||||
- Utilisez l'IP de votre serveur comme *Host* et le port `5695` si vous suivez ce guide.
|
||||
- Renseignez vos *Username* et *Password* Qbittorrent.
|
||||
- Renseignez vos *Username* et *Password* qBittorrent.
|
||||
- Cliquez sur *Test*.
|
||||
- Si le test réussit, cliquez sur *Save*.
|
||||
|
||||
@@ -389,12 +389,12 @@ Il peut être utile d'exposer Seerr si vous voulez envoyer des demandes depuis l
|
||||
|
||||
::warning
|
||||
|
||||
Seerr n'a pas d'authentification à deux facteurs intégrée. Ne l'exposez que si vous utilisez une solution d'authentification robuste comme [TinyAuth](/serveex/security/tinyauth) ou [Authentik](/serveex/advanced/authentik). Sinon, ne l'exposez pas avec SWAG, utilisez plutôt un VPN comme [Wireguard](/serveex/core/wireguard).
|
||||
Seerr n'a pas d'authentification à deux facteurs intégrée. Ne l'exposez que si vous utilisez une solution d'authentification robuste comme [TinyAuth](/serveex/security/tinyauth) ou [Authentik](/serveex/advanced/authentik). Sinon, ne l'exposez pas avec SWAG, utilisez plutôt un VPN comme [WireGuard](/serveex/core/wireguard).
|
||||
::
|
||||
|
||||
::note
|
||||
|
||||
Nous partons du principe que vous avez le sous-domaine `films.mondomaine.fr` avec un `CNAME` pointant vers `films.fr` dans votre [zone DNS](/general/networking/dns). Et que, [à moins d'utiliser Cloudflare Zero Trust](/serveex/security/cloudflare), le port `443` de votre box est redirigé vers le port `443` de votre serveur via les [règles NAT](/general/networking/nat).
|
||||
Nous partons du principe que vous avez le sous-domaine `films.mondomaine.fr` avec un `CNAME` pointant vers `mondomaine.fr` dans votre [zone DNS](/general/networking/dns). Et que, [à moins d'utiliser Cloudflare Zero Trust](/serveex/security/cloudflare), le port `443` de votre box est redirigé vers le port `443` de votre serveur via les [règles NAT](/general/networking/nat).
|
||||
::
|
||||
|
||||
::steps{level="3"}
|
||||
@@ -514,7 +514,7 @@ __Si ça ne marche pas :__ vérifiez les règles de votre pare-feu.
|
||||
Et voilà, Seerr est maintenant accessible publiquement !
|
||||
|
||||
## Protéger Seerr avec TinyAuth
|
||||
Ajoutez la vérification forward-auth de [TinyAuth](/serveex/security/tinyauth) directement dans `films.subdomain.conf`, de la même façon que dans [le tutoriel TinyAuth](/serveex/security/tinyauth#protecting-an-app-via-reverse-proxy). L'interface web (`/`) reçoit la vérification, `/api` en est exclu, puisque les appels d'API de Seerr (et tout ce qui s'y intègre) ne peuvent pas faire de connexion interactive dans un navigateur :
|
||||
Ajoutez la vérification forward-auth de [TinyAuth](/serveex/security/tinyauth) directement dans `films.subdomain.conf`, de la même façon que dans [le tutoriel TinyAuth](/serveex/security/tinyauth#protéger-une-application-via-le-reverse-proxy). L'interface web (`/`) reçoit la vérification, `/api` en est exclu, puisque les appels d'API de Seerr (et tout ce qui s'y intègre) ne peuvent pas faire de connexion interactive dans un navigateur :
|
||||
|
||||
```nginx [films.subdomain.conf]{24-36,39-40}
|
||||
## Version 2024/07/16
|
||||
@@ -592,11 +592,11 @@ server {
|
||||
}
|
||||
```
|
||||
|
||||
::note{to="/serveex/security/tinyauth#exposing-tinyauth-with-swag"}
|
||||
::note{to="/serveex/security/tinyauth#exposer-tinyauth-avec-swag"}
|
||||
|
||||
Le bloc `location /tinyauth` s'exécute dans le conteneur de SWAG lui-même, SWAG doit donc être sur le réseau Docker de TinyAuth pour le joindre par son nom (`tinyauth` ici). Cela devrait déjà être en place depuis **l'exposition de TinyAuth**. Si vous rencontrez une erreur, revérifiez que le fichier compose de SWAG a toujours ce réseau rattaché.
|
||||
::
|
||||
|
||||
::tip{icon=""}
|
||||
✨ Vous pouvez protéger cette application avec [Authentik](/serveex/advanced/authentik) plutôt que TinyAuth, en ouvrant `films.subdomain.conf` et en retirant le `#` devant `include /config/nginx/authentik-server.conf;`{lang=nginx} et `include /config/nginx/authentik-location.conf;`{lang=nginx}. N'oubliez pas de [créer une application et un provider dans Authentik](/serveex/advanced/authentik#protecting-an-app-via-reverse-proxy).
|
||||
✨ Vous pouvez protéger cette application avec [Authentik](/serveex/advanced/authentik) plutôt que TinyAuth, en ouvrant `films.subdomain.conf` et en retirant le `#` devant `include /config/nginx/authentik-server.conf;`{lang=nginx} et `include /config/nginx/authentik-location.conf;`{lang=nginx}. N'oubliez pas de [créer une application et un provider dans Authentik](/serveex/advanced/authentik#protéger-une-app-par-reverse-proxy).
|
||||
::
|
||||
|
||||
@@ -8,7 +8,7 @@ description: Installer Immich, une alternative auto-hébergée à Google Photos
|
||||
|
||||
[Immich](https://immich.app/docs/overview/introduction) est une solution auto-hébergée de gestion de photos et de vidéos qui remplace les services cloud comme Google Photos ou iCloud. Elle propose des fonctions puissantes comme la reconnaissance faciale et la géolocalisation.
|
||||
|
||||

|
||||

|
||||
|
||||
## Installation
|
||||
|
||||
@@ -177,7 +177,7 @@ Immich gère OIDC nativement, vous pouvez donc exiger une connexion Pocket ID av
|
||||
::steps{level="3"}
|
||||
### Enregistrer Immich comme client OIDC
|
||||
|
||||
[Enregistrez un client OIDC dans Pocket ID](/serveex/security/pocket-id#registering-an-oidc-client) nommé `immich`, avec ces trois URL de callback :
|
||||
[Enregistrez un client OIDC dans Pocket ID](/serveex/security/pocket-id#enregistrer-un-client-oidc) nommé `immich`, avec ces trois URL de callback :
|
||||
|
||||
```text
|
||||
https://immich.mondomaine.fr/auth/login
|
||||
|
||||
@@ -8,7 +8,7 @@ description: Installer Nextcloud pour auto-héberger vos fichiers, photos et age
|
||||
|
||||
[Nextcloud](https://nextcloud.com/) est une solution auto-hébergée qui permet d'accéder à vos données et de les synchroniser sur tous vos appareils. Elle inclut aussi des fonctions de collaboration, un agenda, et bien plus. C'est une excellente alternative à des services comme Google Drive, iCloud ou OneDrive.
|
||||
|
||||

|
||||

|
||||
|
||||
## Installation
|
||||
::note{to="https://docs.linuxserver.io/images/docker-nextcloud/"}
|
||||
@@ -43,7 +43,7 @@ services:
|
||||
container_name: nextcloud
|
||||
environment:
|
||||
- PUID=${PUID}
|
||||
- PGID=${GUID}
|
||||
- PGID=${PGID}
|
||||
- TZ=Etc/UTC
|
||||
volumes:
|
||||
- /srv/docker/nextcloud/config:/config
|
||||
@@ -60,7 +60,7 @@ Si vous utilisez un NAS ou un disque partagé sur le réseau via **Samba**, remp
|
||||
|
||||
### Renseigner vos variables d'environnement
|
||||
|
||||
Trouvez vos `PUID` et `GUID` avec la commande suivante :
|
||||
Trouvez vos `PUID` et `PGID` avec la commande suivante :
|
||||
|
||||
```bash [Terminal]
|
||||
id utilisateur
|
||||
@@ -70,7 +70,7 @@ Remplissez ensuite le fichier `.env` avec le port de votre choix et les valeurs
|
||||
|
||||
```properties [.env]
|
||||
PUID=1000
|
||||
GUID=1000
|
||||
PGID=1000
|
||||
PORT=4545
|
||||
```
|
||||
|
||||
@@ -84,8 +84,8 @@ Déployez la stack et visitez `http://ipdevotreserveur:4545` pour terminer la co
|
||||
__Si ça ne marche pas :__ vérifiez les règles de votre pare-feu.
|
||||
::
|
||||
|
||||
## Exposer Nextcloud avec Swag
|
||||
L'objectif de cette installation est d'accéder à Nextcloud à distance depuis tous vos appareils. Nous allons utiliser Swag pour exposer l'application.
|
||||
## Exposer Nextcloud avec SWAG
|
||||
L'objectif de cette installation est d'accéder à Nextcloud à distance depuis tous vos appareils. Nous allons utiliser SWAG pour exposer l'application.
|
||||
|
||||
::note
|
||||
|
||||
@@ -155,7 +155,7 @@ Appuyez sur :kbd{value="Ctrl+O"}, puis :kbd{value="Enter"} pour enregistrer, et
|
||||
|
||||
### Créer le fichier subdomain.conf
|
||||
|
||||
Dans les dossiers de Swag, créez le fichier `nextcloud.subdomain.conf` :
|
||||
Dans les dossiers de SWAG, créez le fichier `nextcloud.subdomain.conf` :
|
||||
|
||||
```bash [Terminal]
|
||||
sudo nano /srv/docker/swag/config/nginx/proxy-confs/nextcloud.subdomain.conf
|
||||
@@ -212,7 +212,7 @@ Dans Nextcloud, allez dans _Apps > Integration_ et installez __OpenID Connect us
|
||||
|
||||
### Enregistrer Nextcloud comme client OIDC
|
||||
|
||||
[Enregistrez un client OIDC dans Pocket ID](/serveex/security/pocket-id#registering-an-oidc-client) nommé `Nextcloud`, avec cette URL de callback :
|
||||
[Enregistrez un client OIDC dans Pocket ID](/serveex/security/pocket-id#enregistrer-un-client-oidc) nommé `Nextcloud`, avec cette URL de callback :
|
||||
|
||||
```text
|
||||
https://nextcloud.mondomaine.fr/apps/user_oidc/code
|
||||
|
||||
@@ -89,7 +89,6 @@ Montez chaque dossier listé sous `sources` dans `config.yaml` au même chemin
|
||||
filebrowser-quantum:
|
||||
#...
|
||||
labels:
|
||||
|
||||
- com.centurylinklabs.watchtower.enable=true
|
||||
```
|
||||
::
|
||||
@@ -104,14 +103,14 @@ Déployez le conteneur et allez sur `http://ipdevotreserveur:8020`. Connectez-vo
|
||||
__Si ça ne marche pas :__ vérifiez les règles de votre pare-feu.
|
||||
::
|
||||
|
||||
## Exposer File Browser Quantum avec Swag
|
||||
## Exposer File Browser Quantum avec SWAG
|
||||
|
||||
::warning
|
||||
|
||||
File Browser Quantum ne gère pas l'authentification multifacteur. L'exposer publiquement pourrait mettre vos systèmes en danger. Ne le faites que si vous utilisez une solution d'authentification robuste comme [TinyAuth](/serveex/security/tinyauth) ou [Authentik](/serveex/advanced/authentik/). Sinon, ne l'exposez pas avec SWAG. Utilisez plutôt un VPN comme [Wireguard](/serveex/core/wireguard).
|
||||
File Browser Quantum ne gère pas l'authentification multifacteur. L'exposer publiquement pourrait mettre vos systèmes en danger. Ne le faites que si vous utilisez une solution d'authentification robuste comme [TinyAuth](/serveex/security/tinyauth) ou [Authentik](/serveex/advanced/authentik/). Sinon, ne l'exposez pas avec SWAG. Utilisez plutôt un VPN comme [WireGuard](/serveex/core/wireguard).
|
||||
::
|
||||
|
||||
Vous voudrez peut-être accéder à File Browser Quantum à distance depuis tous vos appareils. Pour cela, nous allons l'exposer à travers Swag.
|
||||
Vous voudrez peut-être accéder à File Browser Quantum à distance depuis tous vos appareils. Pour cela, nous allons l'exposer à travers SWAG.
|
||||
|
||||
::note{icon=""}
|
||||
|
||||
@@ -149,7 +148,7 @@ Redémarrez la stack en cliquant sur « deploy » et attendez que SWAG soit comp
|
||||
|
||||
### Créer le fichier subdomain.conf
|
||||
|
||||
Dans les dossiers de Swag, créez le fichier `fbq.subdomain.conf`.
|
||||
Dans les dossiers de SWAG, créez le fichier `fbq.subdomain.conf`.
|
||||
|
||||
```bash [Terminal]
|
||||
sudo nano /srv/docker/swag/config/nginx/proxy-confs/fbq.subdomain.conf
|
||||
@@ -211,7 +210,7 @@ Appuyez sur :kbd{value="Ctrl+O"}, puis :kbd{value="Enter"} pour enregistrer, et
|
||||
Et voilà ! File Browser Quantum est maintenant exposé.
|
||||
|
||||
## Protéger File Browser Quantum avec TinyAuth
|
||||
Ajoutez la vérification forward-auth de [TinyAuth](/serveex/security/tinyauth) directement dans `fbq.subdomain.conf`, de la même façon que dans [le tutoriel TinyAuth](/serveex/security/tinyauth#protecting-an-app-via-reverse-proxy) :
|
||||
Ajoutez la vérification forward-auth de [TinyAuth](/serveex/security/tinyauth) directement dans `fbq.subdomain.conf`, de la même façon que dans [le tutoriel TinyAuth](/serveex/security/tinyauth#protéger-une-application-via-le-reverse-proxy) :
|
||||
|
||||
```nginx [fbq.subdomain.conf]{22-34,37-38}
|
||||
## Version 2023/12/19
|
||||
@@ -276,11 +275,11 @@ server {
|
||||
}
|
||||
```
|
||||
|
||||
::note{to="/serveex/security/tinyauth#exposing-tinyauth-with-swag"}
|
||||
::note{to="/serveex/security/tinyauth#exposer-tinyauth-avec-swag"}
|
||||
|
||||
Le bloc `location /tinyauth` s'exécute dans le conteneur de SWAG lui-même, SWAG doit donc être sur le réseau Docker de TinyAuth pour le joindre par son nom (`tinyauth` ici). Cela devrait déjà être en place depuis **l'exposition de TinyAuth**. Si vous rencontrez une erreur, revérifiez que le fichier compose de SWAG a toujours ce réseau rattaché.
|
||||
::
|
||||
|
||||
::tip{icon=""}
|
||||
✨ __Astuce :__ vous pouvez protéger cette application avec [Authentik](/serveex/advanced/authentik) plutôt que TinyAuth, en ouvrant `fbq.subdomain.conf` et en décommentant `include /config/nginx/authentik-server.conf;`{lang=nginx} et `include /config/nginx/authentik-location.conf;`{lang=nginx}. N'oubliez pas de [créer une application et un provider dans Authentik](/serveex/advanced/authentik#protecting-an-app-via-reverse-proxy).
|
||||
✨ __Astuce :__ vous pouvez protéger cette application avec [Authentik](/serveex/advanced/authentik) plutôt que TinyAuth, en ouvrant `fbq.subdomain.conf` et en décommentant `include /config/nginx/authentik-server.conf;`{lang=nginx} et `include /config/nginx/authentik-location.conf;`{lang=nginx}. N'oubliez pas de [créer une application et un provider dans Authentik](/serveex/advanced/authentik#protéger-une-app-par-reverse-proxy).
|
||||
::
|
||||
|
||||
@@ -8,7 +8,7 @@ description: Installer Pingvin Share, une plateforme de partage de fichiers auto
|
||||
|
||||
[Pingvin](https://github.com/stonith404/pingvin-share) est un outil pour partager rapidement des fichiers, à la manière de WeTransfer. Ses nombreuses options de partage (mot de passe, durée d'expiration, lien personnalisé, etc.) en font l'outil idéal pour partager des fichiers rapidement. Pingvin peut aussi créer des _demandes d'envoi_, c'est-à-dire un lien partageable à envoyer à quelqu'un pour qu'il dépose ses fichiers et que vous les récupériez.
|
||||
|
||||

|
||||

|
||||
|
||||
## Installation
|
||||
|
||||
@@ -42,7 +42,7 @@ services:
|
||||
```
|
||||
::note
|
||||
|
||||
À partir d'ici, nous partons du principe que le nom du réseau de Swag est `swag_default`.
|
||||
À partir d'ici, nous partons du principe que le nom du réseau de SWAG est `swag_default`.
|
||||
::
|
||||
|
||||
::tip{icon=""}
|
||||
@@ -53,13 +53,11 @@ services:
|
||||
pingvin-share:
|
||||
#...
|
||||
labels:
|
||||
|
||||
- com.centurylinklabs.watchtower.enable=true
|
||||
|
||||
clamav:
|
||||
#...
|
||||
labels:
|
||||
|
||||
- com.centurylinklabs.watchtower.enable=true
|
||||
```
|
||||
::
|
||||
@@ -74,8 +72,8 @@ Déployez le conteneur et allez sur `http://ipdevotreserveur:3600`. Et voilà !
|
||||
__Si ça ne marche pas :__ vérifiez les règles de votre pare-feu.
|
||||
::
|
||||
|
||||
## Exposer Pingvin avec Swag
|
||||
Tout l'intérêt d'une solution comme celle-ci est de pouvoir y accéder à distance, depuis tous vos appareils. Pour cela, nous allons exposer Pingvin à travers Swag.
|
||||
## Exposer Pingvin avec SWAG
|
||||
Tout l'intérêt d'une solution comme celle-ci est de pouvoir y accéder à distance, depuis tous vos appareils. Pour cela, nous allons exposer Pingvin à travers SWAG.
|
||||
|
||||
::note{icon=""}
|
||||
📋 __Au préalable :__ <br/><br/>
|
||||
@@ -113,7 +111,7 @@ Redéployez la stack en cliquant sur « deploy » et attendez que SWAG soit comp
|
||||
|
||||
### Créer le fichier subdomain.conf
|
||||
|
||||
Dans les dossiers de Swag, créez le fichier `pingvin.subdomain.conf`.
|
||||
Dans les dossiers de SWAG, créez le fichier `pingvin.subdomain.conf`.
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
|
||||
@@ -190,7 +188,7 @@ Pingvin gère OIDC nativement, vous pouvez donc exiger une connexion Pocket ID a
|
||||
::steps{level="3"}
|
||||
### Enregistrer Pingvin comme client OIDC
|
||||
|
||||
[Enregistrez un client OIDC dans Pocket ID](/serveex/security/pocket-id#registering-an-oidc-client) nommé `pingvin`, avec cette URL de callback :
|
||||
[Enregistrez un client OIDC dans Pocket ID](/serveex/security/pocket-id#enregistrer-un-client-oidc) nommé `pingvin`, avec cette URL de callback :
|
||||
|
||||
```text
|
||||
https://pingvin.mondomaine.fr/api/oauth/callback/oidc
|
||||
@@ -224,15 +222,15 @@ Dans l'espace d'administration d'Authentik, créez un provider OAuth2/OpenID.
|
||||
|
||||
Remplissez chaque section comme suit, en remplaçant `mondomaine.fr` par votre propre domaine. Copiez les champs `Client ID` et `Client Secret` en lieu sûr.
|
||||
|
||||

|
||||

|
||||

|
||||

|
||||

|
||||

|
||||
|
||||
#### Créer l'application
|
||||
|
||||
Enregistrez et créez une application `pingvin` comme suit.
|
||||
|
||||

|
||||

|
||||
|
||||
#### Ajouter le provider à votre outpost
|
||||
|
||||
|
||||
@@ -43,7 +43,7 @@ services:
|
||||
container_name: code-server
|
||||
environment:
|
||||
- PUID=${PUID}
|
||||
- PGID=${GUID}
|
||||
- PGID=${PGID}
|
||||
- TZ=Etc/UTC
|
||||
- HASHED_PASSWORD=${PW}
|
||||
volumes:
|
||||
@@ -63,7 +63,6 @@ services:
|
||||
code-server:
|
||||
#...
|
||||
labels:
|
||||
|
||||
- com.centurylinklabs.watchtower.enable=true
|
||||
```
|
||||
::
|
||||
@@ -76,7 +75,7 @@ Choisissez un mot de passe et générez son hash :
|
||||
echo -n "votremotdepasse" | npx argon2-cli -e
|
||||
```
|
||||
|
||||
Conservez précieusement le résultat. Trouvez vos PUID et GUID avec :
|
||||
Conservez précieusement le résultat. Trouvez vos PUID et PGID avec :
|
||||
|
||||
```bash [Terminal]
|
||||
id votreutilisateur
|
||||
@@ -87,7 +86,7 @@ Remplissez le fichier `.env` avec les valeurs trouvées, par exemple :
|
||||
```properties [.env]
|
||||
PW='$argon2i$v=19$m=4096,t=3,p=1$wST5QhBgk2lu1ih4DMuxvg$LS1alrVdIWtvZHwnzCM1DUGg+5DTO3Dt1d5v9XtLws4'
|
||||
PUID=1000
|
||||
GUID=1000
|
||||
PGID=1000
|
||||
```
|
||||
|
||||
::warning
|
||||
@@ -118,8 +117,8 @@ services:
|
||||
```
|
||||
Une fois dans VS Code, vous aurez accès au dossier monté.
|
||||
|
||||
## Exposer code-server avec Swag
|
||||
Tout l'intérêt d'une telle solution est d'y accéder à distance depuis n'importe quel appareil. Pour cela, nous allons exposer code-server via Swag.
|
||||
## Exposer code-server avec SWAG
|
||||
Tout l'intérêt d'une telle solution est d'y accéder à distance depuis n'importe quel appareil. Pour cela, nous allons exposer code-server via SWAG.
|
||||
|
||||
::note
|
||||
|
||||
@@ -144,7 +143,7 @@ services:
|
||||
networks: # Définit le réseau personnalisé
|
||||
# ...
|
||||
code-server: # Nom du réseau défini dans la stack
|
||||
name: code-serveur # Nom réel du réseau externe
|
||||
name: code-server_default # Nom réel du réseau externe
|
||||
external: true # Indique qu'il s'agit d'un réseau externe
|
||||
```
|
||||
|
||||
@@ -157,7 +156,7 @@ Redéployez la stack en cliquant sur « deploy » et attendez que SWAG soit plei
|
||||
|
||||
### Créer le fichier subdomain.conf
|
||||
|
||||
Dans les dossiers de configuration de Swag, créez le fichier `code.subdomain.conf`.
|
||||
Dans les dossiers de configuration de SWAG, créez le fichier `code.subdomain.conf`.
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
✨ __Astuce :__ vous pouvez utiliser **File Browser Quantum** pour naviguer et modifier vos fichiers plutôt que des commandes dans le terminal.
|
||||
@@ -227,7 +226,7 @@ Appuyez sur :kbd{value="Ctrl+O"}, puis :kbd{value="Enter"} pour enregistrer, et
|
||||
Et voilà ! code-server est maintenant exposé !
|
||||
|
||||
## Protéger code-server avec TinyAuth
|
||||
Ajoutez la vérification forward-auth de [TinyAuth](/serveex/security/tinyauth) directement dans `code.subdomain.conf`, de la même façon que dans [le tutoriel TinyAuth](/serveex/security/tinyauth#protecting-an-app-via-reverse-proxy) :
|
||||
Ajoutez la vérification forward-auth de [TinyAuth](/serveex/security/tinyauth) directement dans `code.subdomain.conf`, de la même façon que dans [le tutoriel TinyAuth](/serveex/security/tinyauth#protéger-une-application-via-le-reverse-proxy) :
|
||||
|
||||
```nginx [code.subdomain.conf]{26-38,41-42}
|
||||
## Version 2023/12/19
|
||||
@@ -296,11 +295,11 @@ server {
|
||||
}
|
||||
```
|
||||
|
||||
::note{to="/serveex/security/tinyauth#exposing-tinyauth-with-swag"}
|
||||
::note{to="/serveex/security/tinyauth#exposer-tinyauth-avec-swag"}
|
||||
|
||||
Le bloc `location /tinyauth` s'exécute dans le conteneur de SWAG lui-même, SWAG doit donc être sur le réseau Docker de TinyAuth pour le joindre par son nom (`tinyauth` ici). Cela devrait déjà être en place depuis **l'exposition de TinyAuth**. Si vous rencontrez une erreur, revérifiez que le fichier compose de SWAG a toujours ce réseau rattaché.
|
||||
::
|
||||
|
||||
::tip{icon=""}
|
||||
✨ __Astuce :__ vous pouvez protéger cette application avec [Authentik](/serveex/advanced/authentik) plutôt que TinyAuth, en ouvrant `code.subdomain.conf` et en décommentant `include /config/nginx/authentik-server.conf;`{lang=nginx} et `include /config/nginx/authentik-location.conf;`{lang=nginx}. N'oubliez pas de [créer une application et un provider dans Authentik](/serveex/advanced/authentik#protecting-an-app-via-reverse-proxy).
|
||||
✨ __Astuce :__ vous pouvez protéger cette application avec [Authentik](/serveex/advanced/authentik) plutôt que TinyAuth, en ouvrant `code.subdomain.conf` et en décommentant `include /config/nginx/authentik-server.conf;`{lang=nginx} et `include /config/nginx/authentik-location.conf;`{lang=nginx}. N'oubliez pas de [créer une application et un provider dans Authentik](/serveex/advanced/authentik#protéger-une-app-par-reverse-proxy).
|
||||
::
|
||||
|
||||
@@ -73,8 +73,8 @@ Déployez le conteneur et allez sur `http://ipdevotreserveur:3333`. Votre instan
|
||||
__Si ça ne marche pas :__ vérifiez les règles de votre pare-feu.
|
||||
::
|
||||
|
||||
## Exposer Forgejo avec Swag
|
||||
L'intérêt de cette installation est de pouvoir y accéder à distance depuis n'importe lequel de vos appareils. Pour cela, nous allons exposer Forgejo à travers Swag.
|
||||
## Exposer Forgejo avec SWAG
|
||||
L'intérêt de cette installation est de pouvoir y accéder à distance depuis n'importe lequel de vos appareils. Pour cela, nous allons exposer Forgejo à travers SWAG.
|
||||
|
||||
::note
|
||||
|
||||
@@ -112,7 +112,7 @@ Redéployez la stack en cliquant sur « Deploy » et attendez que SWAG soit plei
|
||||
|
||||
### Créer le fichier subdomain.conf
|
||||
|
||||
Dans les dossiers de Swag, créez le fichier `forgejo.subdomain.conf`.
|
||||
Dans les dossiers de SWAG, créez le fichier `forgejo.subdomain.conf`.
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
✨ __Astuce :__ vous pouvez utiliser **File Browser Quantum** pour naviguer et modifier vos fichiers plutôt que des commandes dans le terminal.
|
||||
@@ -212,7 +212,7 @@ Forgejo peut aussi déléguer la connexion à un fournisseur OIDC plutôt qu'à
|
||||
::steps{level="3"}
|
||||
### Enregistrer Forgejo comme client OIDC
|
||||
|
||||
[Enregistrez un client OIDC dans Pocket ID](/serveex/security/pocket-id#registering-an-oidc-client) nommé `Forgejo`, avec cette URL de callback :
|
||||
[Enregistrez un client OIDC dans Pocket ID](/serveex/security/pocket-id#enregistrer-un-client-oidc) nommé `Forgejo`, avec cette URL de callback :
|
||||
|
||||
```text
|
||||
https://forgejo.mondomaine.fr/user/oauth2/PocketID/callback
|
||||
|
||||
@@ -36,7 +36,6 @@ services:
|
||||
it-tools:
|
||||
#...
|
||||
labels:
|
||||
|
||||
- com.centurylinklabs.watchtower.enable=true
|
||||
```
|
||||
::
|
||||
@@ -51,8 +50,8 @@ Déployez le conteneur et visitez `http://ipdevotreserveur:3222`. Voilà, votre
|
||||
__Si ça ne marche pas :__ vérifiez les règles de votre pare-feu.
|
||||
::
|
||||
|
||||
## Exposer IT Tools avec Swag
|
||||
Vous voudrez peut-être y accéder à distance sur tous vos appareils. Pour cela, nous allons exposer IT Tools avec Swag.
|
||||
## Exposer IT Tools avec SWAG
|
||||
Vous voudrez peut-être y accéder à distance sur tous vos appareils. Pour cela, nous allons exposer IT Tools avec SWAG.
|
||||
|
||||
::note
|
||||
|
||||
@@ -95,7 +94,7 @@ Redémarrez la stack en cliquant sur « deploy » et attendez que SWAG soit plei
|
||||
|
||||
### Créer le fichier subdomain.conf
|
||||
|
||||
Dans les dossiers de Swag, créez le fichier `tools.subdomain.conf`.
|
||||
Dans les dossiers de SWAG, créez le fichier `tools.subdomain.conf`.
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
✨ __Astuce :__ vous pouvez utiliser **File Browser Quantum** pour naviguer et modifier vos fichiers plutôt que des commandes dans le terminal.
|
||||
@@ -166,7 +165,7 @@ Appuyez sur :kbd{value="Ctrl+O"}, puis :kbd{value="Enter"} pour enregistrer, et
|
||||
Et voilà ! IT Tools est maintenant exposé !
|
||||
|
||||
## Protéger IT Tools avec TinyAuth
|
||||
Ajoutez la vérification forward-auth de [TinyAuth](/serveex/security/tinyauth) directement dans `tools.subdomain.conf`, de la même façon que dans [le tutoriel TinyAuth](/serveex/security/tinyauth#protecting-an-app-via-reverse-proxy) :
|
||||
Ajoutez la vérification forward-auth de [TinyAuth](/serveex/security/tinyauth) directement dans `tools.subdomain.conf`, de la même façon que dans [le tutoriel TinyAuth](/serveex/security/tinyauth#protéger-une-application-via-le-reverse-proxy) :
|
||||
|
||||
```nginx [tools.subdomain.conf]{26-38,41-42}
|
||||
## Version 2023/12/19
|
||||
@@ -236,11 +235,11 @@ server {
|
||||
}
|
||||
```
|
||||
|
||||
::note{to="/serveex/security/tinyauth#exposing-tinyauth-with-swag"}
|
||||
::note{to="/serveex/security/tinyauth#exposer-tinyauth-avec-swag"}
|
||||
|
||||
Le bloc `location /tinyauth` s'exécute dans le conteneur de SWAG lui-même, SWAG doit donc être sur le réseau Docker de TinyAuth pour le joindre par son nom (`tinyauth` ici). Cela devrait déjà être en place depuis **l'exposition de TinyAuth**. Si vous rencontrez une erreur, revérifiez que le fichier compose de SWAG a toujours ce réseau rattaché.
|
||||
::
|
||||
|
||||
::tip{icon=""}
|
||||
✨ __Astuce :__ vous pouvez sécuriser cette application avec [Authentik](/serveex/advanced/authentik) plutôt que TinyAuth, en ouvrant `tools.subdomain.conf` et en décommentant les lignes `include /config/nginx/authentik-server.conf;` et `include /config/nginx/authentik-location.conf;`. N'oubliez pas de [créer une application et un provider dans Authentik](/serveex/advanced/authentik#protecting-an-app-via-reverse-proxy).
|
||||
✨ __Astuce :__ vous pouvez sécuriser cette application avec [Authentik](/serveex/advanced/authentik) plutôt que TinyAuth, en ouvrant `tools.subdomain.conf` et en décommentant les lignes `include /config/nginx/authentik-server.conf;` et `include /config/nginx/authentik-location.conf;`. N'oubliez pas de [créer une application et un provider dans Authentik](/serveex/advanced/authentik#protéger-une-app-par-reverse-proxy).
|
||||
::
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Adguard Home
|
||||
title: AdGuard Home
|
||||
description: Installer AdGuard Home pour bloquer publicités et trackers à l'échelle du réseau avec DNS-over-HTTPS, gestion des clients et règles de filtrage personnalisées.
|
||||
---
|
||||
|
||||
@@ -12,22 +12,22 @@ Il fonctionne comme un serveur DNS qui redirige les domaines de suivi vers un «
|
||||
|
||||
En pratique, une fois en place, il vous faudra juste configurer les serveurs DNS de vos appareils, pour que ces derniers l'utilisent.
|
||||
|
||||

|
||||

|
||||
|
||||
**Rappel sur le fonctionnement d'un DNS :**
|
||||
|
||||
Lorsque vous naviguez sur un site, ou une application, des requêtes sont émises vers un ou des domaines afin d'afficher le contenu de votre page. Les publicités notamment. Votre appareil ne connait pas les adresses IP de ces serveurs à joindre. Pour les connaitre, il va contacter un _serveur de nom_ (Domain Name Server) qui lui va lui répondre avec l'adresse IP la plus à jour pour le domaine de la requête.
|
||||
|
||||
Par défaut, votre appareil utilise le serveur votre fournisseur d'accès, paramétré dans votre box ou directement sur le CGNAT de votre opérateur si appareil mobile. Cela peut etre changé directement dans les réglages de votre navigateur, mais aussi dans le système de votre appareil, et parfois directement dans votre box si votre FAI le permet.
|
||||
Par défaut, votre appareil utilise le serveur de votre fournisseur d'accès, paramétré dans votre box ou directement sur le CGNAT de votre opérateur si appareil mobile. Cela peut être changé directement dans les réglages de votre navigateur, mais aussi dans le système de votre appareil, et parfois directement dans votre box si votre FAI le permet.
|
||||
|
||||
Adguard lui, va s'intercaler entre le serveur de nom et votre appareil. Si vous paramétrez vos appareil, ils contacteront d'abord adguard qui filtrera les requetes, via des listes régulièrement mises à jour :
|
||||
AdGuard lui, va s'intercaler entre le serveur de nom et votre appareil. Si vous paramétrez vos appareil, ils contacteront d'abord AdGuard qui filtrera les requêtes, via des listes régulièrement mises à jour :
|
||||
|
||||
- Si le domaine n'est pas dans une blocklist, il contactera des serveurs de noms génériques (dit upstreams) et répondra vers vos appareils avec l'adresse IP recherchée.
|
||||
- Si le domaine est dans une blocklist, il ne contactera pas les DNS upstream et ne répondre pas à vos appareils. Le contenu affilié à cette requete ne s'affichera pas.
|
||||
- Si le domaine est dans une blocklist, il ne contactera pas les DNS upstream et ne répondra pas à vos appareils. Le contenu affilié à cette requête ne s'affichera pas.
|
||||
|
||||
C'est ainsi que les pubs et domaines malveillants sont bloqués : leurs domaines sont présents dans la blocklist, le reste de la page lui charge correctement.
|
||||
C'est ainsi que les pubs et domaines malveillants sont bloqués : leurs domaines sont présents dans la blocklist, le reste de la page se charge correctement.
|
||||
|
||||

|
||||

|
||||
|
||||
## Installation
|
||||
|
||||
@@ -47,7 +47,7 @@ tree:
|
||||
|
||||
::note
|
||||
|
||||
Nous monterons également le dossier `/srv/docker/swag/config/etc/letsencrypt` pour accéder au certificat SSL de Swag.
|
||||
Nous monterons également le dossier `/srv/docker/swag/config/etc/letsencrypt` pour accéder au certificat SSL de SWAG.
|
||||
::
|
||||
|
||||
::steps{level="3"}
|
||||
@@ -102,7 +102,7 @@ L'assistant de configuration vous demande de choisir un port pour l'interface d'
|
||||
### Terminé !
|
||||
::
|
||||
|
||||
C'est tout ! Adguard est déployé.
|
||||
C'est tout ! AdGuard est déployé.
|
||||
|
||||
## Exposer AdGuard avec SWAG
|
||||
Pour rendre AdGuard utilisable en dehors de votre réseau domestique, vous devez l'exposer.
|
||||
@@ -240,7 +240,7 @@ server {
|
||||
::
|
||||
|
||||
## Protéger AdGuard avec TinyAuth
|
||||
Ajoutez la vérification forward-auth de [TinyAuth](/serveex/security/tinyauth) directement dans `adguard.subdomain.conf`, de la même façon que dans [le tutoriel TinyAuth](/serveex/security/tinyauth#protecting-an-app-via-reverse-proxy). Le `location /dns-query` est laissé en dehors de la vérification `auth_request`, puisque les clients DNS-over-HTTPS ne peuvent pas faire de connexion interactive :
|
||||
Ajoutez la vérification forward-auth de [TinyAuth](/serveex/security/tinyauth) directement dans `adguard.subdomain.conf`, de la même façon que dans [le tutoriel TinyAuth](/serveex/security/tinyauth#protéger-une-application-via-le-reverse-proxy). Le `location /dns-query` est laissé en dehors de la vérification `auth_request`, puisque les clients DNS-over-HTTPS ne peuvent pas faire de connexion interactive :
|
||||
|
||||
```nginx [adguard.subdomain.conf]{28-40,43-44,69-70}
|
||||
## Version 2023/05/31
|
||||
@@ -337,7 +337,7 @@ server {
|
||||
}
|
||||
```
|
||||
|
||||
::note{to="/serveex/security/tinyauth#exposing-tinyauth-with-swag"}
|
||||
::note{to="/serveex/security/tinyauth#exposer-tinyauth-avec-swag"}
|
||||
|
||||
Le bloc `location /tinyauth` s'exécute dans le conteneur de SWAG lui-même, SWAG doit donc être sur le réseau Docker de TinyAuth pour le joindre par son nom (`tinyauth` ici). Cela devrait déjà être en place depuis **l'exposition de TinyAuth**. Si vous rencontrez une erreur, revérifiez que le fichier compose de SWAG a toujours ce réseau rattaché.
|
||||
::
|
||||
@@ -347,28 +347,28 @@ Le bloc `location /tinyauth` s'exécute dans le conteneur de SWAG lui-même, SWA
|
||||
<br/><br/>
|
||||
Vous pouvez protéger cette app avec Authentik en ouvrant `adguard.subdomain.conf` et en retirant les `#` devant `include /config/nginx/authentik-server.conf;`{lang=nginx} et `include /config/nginx/authentik-location.conf;`{lang=nginx}. n'oubliez pas de [créer une application et un fournisseur dans Authentik](/serveex/advanced/authentik#protéger-une-app-par-reverse-proxy). Il vous faudra exclure l'url `https://adguard.mondomaine.fr/dns-query` de l'authentification :
|
||||
|
||||
- Editez le fournisseur d'Adguard
|
||||
- Éditez le fournisseur d'AdGuard
|
||||
- Dans *paramètres avancés du protocole > chemins authentifiés*, saisissez `^/dns-query`
|
||||
::
|
||||
|
||||
Enregistrez avec :kbd{value="Ctrl+O"} puis :kbd{value="Entrée"}, puis quittez avec :kbd{value="Ctrl+X"}.
|
||||
|
||||
Et voilà, vous exposez Adguard à présent !
|
||||
Et voilà, vous exposez AdGuard à présent !
|
||||
|
||||
## Configurer le chiffrement SSL/TLS
|
||||
Le chiffrement est essentiel si vous souhaitez garder privées les requêtes que vous faites vers adguard. Chiffrer ces requêtes c'est vous assurez que personne, meme votre FAI ne connaissent votre historique. C'est aussi vous assurer que personne d'autre que votre serveur vous répond.
|
||||
Le chiffrement est essentiel si vous souhaitez garder privées les requêtes que vous faites vers AdGuard. Chiffrer ces requêtes c'est vous assurer que personne, même votre FAI, ne connaisse votre historique. C'est aussi vous assurer que personne d'autre que votre serveur vous répond.
|
||||
|
||||
Afin de configurer le chiffrement :
|
||||
|
||||
- Allez dans _paramètre_ puis dans _chiffrement_.
|
||||
- Parametrez comme suit
|
||||
- Allez dans _paramètres_ puis dans _chiffrement_.
|
||||
- Paramétrez comme suit
|
||||
|
||||

|
||||

|
||||
|
||||
- Puis en dessous, dans la section _certificats_ cochez _Définir un emplacement de fichier du certificat_
|
||||
- Dans le champs de saisie, mettez `/swag-ssl/live/mondomaine.fr/fullchain.pem` en remplaçant `mondomaine.fr` par votre domaine principal.
|
||||
- Dans le champ de saisie, mettez `/swag-ssl/live/mondomaine.fr/fullchain.pem` en remplaçant `mondomaine.fr` par votre domaine principal.
|
||||
- Dans _clé privée_ cochez _Définir un fichier pour la clef privée_
|
||||
- Dans le champs de saisie, mettez `/swag-ssl/live/mondomaine.fr/privkey.pem` en remplaçant `mondomaine.fr` par votre domaine principal.
|
||||
- Dans le champ de saisie, mettez `/swag-ssl/live/mondomaine.fr/privkey.pem` en remplaçant `mondomaine.fr` par votre domaine principal.
|
||||
- Validez
|
||||
|
||||
Et voilà ! Vous avez protégé vos futures requêtes DNS !
|
||||
@@ -376,11 +376,11 @@ Et voilà ! Vous avez protégé vos futures requêtes DNS !
|
||||
## Configurer les appareils
|
||||
Pour configurer vos appareils, vous avez plusieurs choix (que vous pouvez cumuler).
|
||||
### Sécuriser le réseau local
|
||||
Vous pouvez sécuriser votre réseau local avec adguard en configurant votre box pour que chaque requête DNS soit dirigée par défaut vers adguard plutot que les services de votre FAI. Attention, votre box doit pouvoir permettre le changement de DNS (Orange ne le permet pas).
|
||||
Vous pouvez sécuriser votre réseau local avec AdGuard en configurant votre box pour que chaque requête DNS soit dirigée par défaut vers AdGuard plutôt que les services de votre FAI. Attention, votre box doit pouvoir permettre le changement de DNS (Orange ne le permet pas).
|
||||
|
||||
Généralement cette option est dans les paramètres _DHCP_ de votre box. Pensez bien à ajouter un serveur secondaire tel que :
|
||||
|
||||
- Cloudlare : `1.1.1.1`
|
||||
- Cloudflare : `1.1.1.1`
|
||||
- Google : `8.8.8.8`
|
||||
|
||||
En effet, sans cela, si votre serveur tombe, vos appareils n'arriveraient plus à se connecter à internet.
|
||||
@@ -390,14 +390,14 @@ En effet, sans cela, si votre serveur tombe, vos appareils n'arriveraient plus
|
||||
Des appareils peuvent avoir un autre DNS paramétré et ne pas utiliser ceux de la box.
|
||||
::
|
||||
|
||||
### Forcer un navigateur à utiliser Adguard
|
||||
### Forcer un navigateur à utiliser AdGuard
|
||||
|
||||
Dans votre navigateur, vous pouvez configurer un DNS pour le forcer à utiliser adguard home.
|
||||
Dans votre navigateur, vous pouvez configurer un DNS pour le forcer à utiliser AdGuard home.
|
||||
Dans les paramètres, il vous faudra renseigner l'adresse `https://adguard.mondomaine.fr/dns-query`
|
||||
|
||||
### Windows, paramétrer Adguard au niveau système
|
||||
### Windows, paramétrer AdGuard au niveau système
|
||||
|
||||
Dans windows, vous devez paramétrer Adguard pour chaque carte réseau que vous souhaitez utiliser.
|
||||
Dans Windows, vous devez paramétrer AdGuard pour chaque carte réseau que vous souhaitez utiliser.
|
||||
|
||||
- Rendez vous dans _accueil > Réseau et internet >_ et choisissez votre carte réseau à modifier
|
||||
- Cliquez sur _modifier les DNS_ (parfois dans _propriété du matériel_)
|
||||
@@ -408,7 +408,7 @@ Dans windows, vous devez paramétrer Adguard pour chaque carte réseau que vous
|
||||
- Désactivez _retour au texte en clair_
|
||||
- Enregistrez
|
||||
|
||||
Tous les programmes de votre machine utilisant cette carte réseau seront filtrés par Adguard.
|
||||
Tous les programmes de votre machine utilisant cette carte réseau seront filtrés par AdGuard.
|
||||
|
||||
## Ajouter des filtres
|
||||
|
||||
|
||||
@@ -257,7 +257,7 @@ Contrairement à la plupart des applications de ce site, Vaultwarden gère OIDC
|
||||
::steps{level="3"}
|
||||
### Enregistrer Vaultwarden comme client OIDC
|
||||
|
||||
[Enregistrez un client OIDC dans Pocket ID](/serveex/security/pocket-id#registering-an-oidc-client) (ou dans Authentik, ou tout autre fournisseur OIDC) avec cette URL de callback :
|
||||
[Enregistrez un client OIDC dans Pocket ID](/serveex/security/pocket-id#enregistrer-un-client-oidc) (ou dans Authentik, ou tout autre fournisseur OIDC) avec cette URL de callback :
|
||||
|
||||
```text
|
||||
https://vault.mondomaine.fr/identity/connect/oidc-signin
|
||||
|
||||
@@ -25,11 +25,11 @@ Il y a deux modes principaux à connaître :
|
||||
|
||||
- Le premier permet aux applications gérant nativement le SSO compatible OpenID de se connecter directement à Authentik. C'est la méthode à privilégier, puisque l'application décide elle-même de ce qui est public et de ce qui est protégé.
|
||||
|
||||

|
||||

|
||||
|
||||
- La seconde méthode injecte l'authentification Authentik via SWAG avant d'atteindre le service cible.
|
||||
|
||||

|
||||

|
||||
|
||||
Les deux modes se configurent application par application.
|
||||
|
||||
@@ -375,15 +375,15 @@ Pourquoi faire cela alors que Dockge a déjà une authentification ? Parce que D
|
||||
- Choisissez _Applications_ puis _Create with wizard_
|
||||
- Remplissez les champs comme suit :
|
||||
|
||||

|
||||

|
||||
|
||||
- À l'étape suivante, choisissez « Forward authentication (single application) » et configurez comme suit (les flows sont importants) :
|
||||
|
||||

|
||||

|
||||
|
||||
- Ensuite, allez dans le menu _Outposts_ à gauche et modifiez _authentik Embedded Outpost_ :
|
||||
|
||||

|
||||

|
||||
|
||||
- Ajoutez l'application `dockge` en la déplaçant dans la colonne de droite et enregistrez.
|
||||
|
||||
@@ -415,10 +415,10 @@ Répétez cette procédure pour chaque application que vous voulez protéger (sa
|
||||
|
||||
Votre nouvelle architecture ressemble à ceci :
|
||||
|
||||

|
||||

|
||||
|
||||
## Protéger un service sur un serveur distant
|
||||
Pour une [application native](/serveex/advanced/authentik/#protecting-a-native-app) (via OAuth 2.0 ou autre), rien ne change.
|
||||
Pour une [application native](/serveex/advanced/authentik/#protéger-une-app-native) (via OAuth 2.0 ou autre), rien ne change.
|
||||
|
||||
Pour une application non native derrière un reverse proxy, vous devez déployer un __Outpost__. Un Outpost est un conteneur qui fait office de proxy local. C'est la cible des requêtes d'authentification de votre application, et le seul autorisé à communiquer avec votre API Authentik.
|
||||
|
||||
@@ -429,14 +429,14 @@ Prérequis :
|
||||
- Si l'application n'a pas d'intégration native, utiliser un reverse proxy compatible. Nous utiliserons [SWAG](/serveex/core/swag) ici.
|
||||
::
|
||||
|
||||
Ce conteneur transmettra les requêtes à votre instance [Authentik](/serveex/advanced/authentik#authentik) principale via internet (ou votre réseau local). Le serveur effectuera les vérifications et répondra à l'Outpost, qui autorisera ou bloquera l'accès en conséquence.
|
||||
Ce conteneur transmettra les requêtes à votre instance [Authentik](/serveex/advanced/authentik) principale via internet (ou votre réseau local). Le serveur effectuera les vérifications et répondra à l'Outpost, qui autorisera ou bloquera l'accès en conséquence.
|
||||
|
||||

|
||||
|
||||
::steps{level="3"}
|
||||
### Configuration d'Authentik
|
||||
|
||||
Créez vos [providers et applications](/serveex/advanced/authentik/#protecting-a-native-app) comme montré plus haut.
|
||||
Créez vos [providers et applications](/serveex/advanced/authentik/#protéger-une-app-native) comme montré plus haut.
|
||||
|
||||
Puis, dans le panneau d'administration, allez dans _Applications > Outposts_, et créez un nouvel outpost.
|
||||
|
||||
@@ -460,7 +460,6 @@ authentik_host_insecure: false
|
||||
container_image:
|
||||
docker_network: null
|
||||
docker_map_ports: true
|
||||
docker_labels: null
|
||||
```
|
||||
|
||||
Enregistrez avec :kbd{value="Ctrl+O"}, puis :kbd{value="Enter"}, et quittez avec :kbd{value="Ctrl+X"}.
|
||||
@@ -476,7 +475,7 @@ Sur votre machine distante, utilisez [Dockge](/serveex/core/docker/#installer-do
|
||||
Si vous n'avez pas installé [Dockge](/serveex/core/docker/#installer-dockge-pour-gérer-et-déployer-les-conteneurs), créez un dossier `/srv/docker/authentik-outpost`, ou directement en ligne de commande :
|
||||
|
||||
```bash [Terminal]
|
||||
sudo mkdir -P /srv/docker/authentik-outpost
|
||||
sudo mkdir -p /srv/docker/authentik-outpost
|
||||
```
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
@@ -620,7 +619,7 @@ Enregistrez avec :kbd{value="Ctrl+O"}, puis :kbd{value="Enter"}, et quittez avec
|
||||
### Terminé !
|
||||
::
|
||||
|
||||
Configurez ensuite les applications à protéger comme vous l'avez fait sur votre serveur principal, qu'elles soient [natives](/serveex/advanced/authentik/#protecting-a-native-app) ou protégées via [reverse proxy](/serveex/advanced/authentik#protéger-une-app-par-reverse-proxy).
|
||||
Configurez ensuite les applications à protéger comme vous l'avez fait sur votre serveur principal, qu'elles soient [natives](/serveex/advanced/authentik/#protéger-une-app-native) ou protégées via [reverse proxy](/serveex/advanced/authentik#protéger-une-app-par-reverse-proxy).
|
||||
|
||||
## Migrer une base de données Authentik
|
||||
|
||||
|
||||
@@ -155,7 +155,7 @@ Le principal intérêt de cette installation est de pouvoir accéder à Arcane
|
||||
|
||||
::warning
|
||||
|
||||
La connexion locale d'Arcane n'a pas d'authentification multifacteur. Ne l'exposez que si vous utilisez [Pocket ID](/serveex/security/pocket-id) (voir plus bas) ou [Authentik](/serveex/advanced/authentik) pour la connexion. Sinon, ne l'exposez pas avec SWAG. Utilisez plutôt un VPN comme [Wireguard](/serveex/core/wireguard), surtout vu le niveau d'accès qu'Arcane a sur votre hôte.
|
||||
La connexion locale d'Arcane n'a pas d'authentification multifacteur. Ne l'exposez que si vous utilisez [Pocket ID](/serveex/security/pocket-id) (voir plus bas) ou [Authentik](/serveex/advanced/authentik) pour la connexion. Sinon, ne l'exposez pas avec SWAG. Utilisez plutôt un VPN comme [WireGuard](/serveex/core/wireguard), surtout vu le niveau d'accès qu'Arcane a sur votre hôte.
|
||||
::
|
||||
|
||||
::note
|
||||
@@ -194,7 +194,7 @@ Nous partons ici du principe que le nom du réseau d'Arcane est `arcane_default`
|
||||
|
||||
### Créer le fichier subdomain.conf
|
||||
|
||||
Dans les dossiers de Swag, créez le fichier `arcane.subdomain.conf` :
|
||||
Dans les dossiers de SWAG, créez le fichier `arcane.subdomain.conf` :
|
||||
|
||||
::tip{icon="" to="/serveex/files/file-browser-quantum"}
|
||||
✨ __Astuce :__ utilisez **File Browser Quantum** pour naviguer et modifier les fichiers plutôt que des commandes dans le terminal.
|
||||
|
||||
@@ -0,0 +1,253 @@
|
||||
---
|
||||
title: Backrest
|
||||
description: Installer Backrest, une interface web conviviale pour restic, et sauvegarder son serveur comme il faut avec la règle 3-2-1, vers un disque local, un autre serveur, S3 ou Backblaze B2.
|
||||
---
|
||||
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
|
||||
Soyons honnêtes deux secondes : la "stratégie de sauvegarde" de la plupart des homelabbers, c'est avoir copié quelques dossiers sur une clé USB une fois en 2019, et espérer que tout ira bien. [Backrest](https://github.com/garethgeorge/backrest) est là pour arranger ça, sans vous forcer à apprendre un outil en ligne de commande qui fait peur.
|
||||
|
||||
Sous le capot, Backrest est une interface web propre posée sur [restic](https://restic.net/), un moteur de sauvegarde open-source qui a fait ses preuves. Restic fait le vrai travail (chiffrer, dédupliquer, et envoyer vos données là où vous le lui dites) ; Backrest vous donne des boutons et des formulaires plutôt qu'un mur d'options à retenir.
|
||||
|
||||

|
||||
|
||||
## La règle du 3-2-1, ou pourquoi une seule sauvegarde n'en est pas une
|
||||
|
||||
Avant d'installer quoi que ce soit, parlons de la règle qui compte vraiment ici, parce qu'une sauvegarde mal pensée vous donne une fausse confiance, ce qui est pire que pas de sauvegarde du tout.
|
||||
|
||||
La **règle du 3-2-1** dit :
|
||||
|
||||
- **3** copies de vos données : l'originale, plus au moins deux sauvegardes.
|
||||
- **2** types de stockage différents : pas deux copies sur le même disque, ni sur deux disques dans la même machine.
|
||||
- **1** copie hors site : physiquement ailleurs, pas dans la même pièce, la même maison ou le même bâtiment que l'original.
|
||||
|
||||
Chaque chiffre ferme un scénario de panne précis :
|
||||
|
||||
- Une seule **(1)** sauvegarde ? Une seule erreur (un `rm -rf` malheureux, une restauration ratée, un fichier corrompu copié par-dessus le bon sans que vous le voyiez) peut emporter votre seul filet de sécurité en même temps que l'original.
|
||||
- Des sauvegardes sur le **même type de stockage** (disons, un second disque interne dans le même serveur) ? Une surtension, un bug de firmware, ou une alimentation bas de gamme qui lâche peuvent très bien emporter tous les disques du boîtier d'un coup.
|
||||
- Pas de copie **hors site** ? Un incendie, une inondation, un vol, ou "j'ai débranché la mauvaise multiprise" se moquent du nombre de disques que vous avez, s'ils sont tous dans la même pièce.
|
||||
|
||||
C'est aussi exactement pour ça que [le RAID n'est pas une sauvegarde](/general/storage/raid) : le RAID garde un service en marche quand un disque meurt, il ne fait rien contre un ransomware qui chiffre tous les fichiers qu'il peut atteindre, une suppression malheureuse, ou votre maison qui prend feu. Backrest, pointé vers une destination en dehors de votre serveur, est ce qui couvre réellement ces cas-là.
|
||||
|
||||
## Ce que Backrest sauvegarde, et où
|
||||
|
||||
Deux concepts à connaître avant de cliquer partout :
|
||||
|
||||
- Un **dépôt** (repository) est la destination : un espace de stockage chiffré et dédupliqué. C'est votre "2" et votre "1" de la règle ci-dessus, un disque externe, un autre serveur, ou du stockage cloud.
|
||||
- Un **plan** est la règle que vous définissez : quels dossiers sauvegarder, vers quel dépôt, selon quel planning, et combien d'anciens instantanés (snapshots) conserver.
|
||||
|
||||
Vous pouvez avoir plusieurs plans sauvegardant vers plusieurs dépôts en même temps, ce qui est exactement comment on construit un vrai 3-2-1 : un plan vers un dépôt local pour des restaurations rapides, un autre plan vers un dépôt hors site pour le scénario "ma maison brûle".
|
||||
|
||||
## Installation
|
||||
|
||||
::file-tree
|
||||
---
|
||||
tree:
|
||||
/:
|
||||
- srv:
|
||||
- docker:
|
||||
- backrest:
|
||||
- data/
|
||||
- config/
|
||||
- cache/
|
||||
- compose.yaml
|
||||
---
|
||||
::
|
||||
|
||||
::steps{level="3"}
|
||||
### Déployer la stack
|
||||
|
||||
Ouvrez Dockge, cliquez sur `compose`, nommez la stack `backrest`, et collez ce qui suit :
|
||||
|
||||
```yaml [compose.yaml]
|
||||
---
|
||||
services:
|
||||
backrest:
|
||||
image: garethgeorge/backrest:latest
|
||||
container_name: backrest
|
||||
restart: unless-stopped
|
||||
ports:
|
||||
- 9898:9898
|
||||
volumes:
|
||||
- ./data:/data
|
||||
- ./config:/config
|
||||
- ./cache:/cache
|
||||
# Tout ce que vous voulez que Backrest puisse sauvegarder doit
|
||||
# aussi être monté ici : la stack ne voit que ce qu'on lui donne.
|
||||
- /srv/docker:/userdata/docker:ro
|
||||
- /etc:/userdata/etc:ro
|
||||
- /home:/userdata/home:ro
|
||||
environment:
|
||||
- BACKREST_DATA=/data
|
||||
- BACKREST_CONFIG=/config/config.json
|
||||
- XDG_CACHE_HOME=/cache
|
||||
- TZ=Europe/Paris
|
||||
```
|
||||
|
||||
Les lignes `/srv/docker`, `/etc` et `/home` ci-dessus couvrent ce qui vaut réellement la peine d'être sauvegardé hors site sur un serveur homelab, selon [dossiers et partitions](/general/linux/filesystem) : `/srv/docker` contient la config et les données de chaque stack (bases de données, fichiers uploadés, le coffre de Vaultwarden, les utilisateurs de Pocket ID, etc.), `/etc` contient votre configuration système (le durcissement SSH du [guide d'installation](/serveex/core/installation#refermer-la-porte-derrière-vous), vos fichiers `.subdomain.conf` de SWAG, les unités systemd), et `/home` contient vos propres scripts et notes. Les trois sont montées en lecture seule, un outil de sauvegarde n'a aucune raison d'écrire dans ce qu'il sauvegarde.
|
||||
|
||||
Ce qui ne vaut généralement **pas** le coup : une grosse bibliothèque média ou un dossier de téléchargement torrent sur un disque de données séparé. C'est souvent énorme, remplaçable, et rarement justifié de payer du stockage cloud ou de la bande passante SSH pour le protéger.
|
||||
|
||||
::tip{icon=""}
|
||||
✨ __Astuce :__ ajoutez le label Watchtower pour automatiser les mises à jour
|
||||
```yaml [compose.yaml]
|
||||
services:
|
||||
backrest:
|
||||
#...
|
||||
labels:
|
||||
- com.centurylinklabs.watchtower.enable=true
|
||||
```
|
||||
::
|
||||
|
||||
Déployez le conteneur, puis ouvrez `http://ipdevotreserveur:9898`. La première visite vous demande de définir un identifiant et un mot de passe administrateur : faites-le immédiatement, Backrest n'a pas de compte par défaut et l'écran de configuration est grand ouvert tant que vous ne l'avez pas fait.
|
||||
|
||||
### Terminé !
|
||||
::
|
||||
|
||||
## Créer votre premier dépôt
|
||||
|
||||

|
||||
|
||||
Dans Backrest, allez dans **Add Repo**. Le formulaire est découpé en plusieurs sections, voici ce que fait chaque champ :
|
||||
|
||||
- **Repo Name** : ce qui vous aidera à le reconnaître plus tard, `cle-usb` ou `vps-hors-site` par exemple. Impossible de le renommer ensuite, choisissez quelque chose que vous ne regretterez pas.
|
||||
- **Auto Unlock** : laissez désactivé sauf si vous comprenez bien ce que ça fait. Restic verrouille un dépôt pendant qu'il y travaille, pour qu'un second processus ne corrompe pas tout en écrivant en même temps. Auto Unlock retire ce verrou automatiquement au démarrage, pratique si Backrest a planté en pleine sauvegarde et laissé un verrou fantôme, mais réellement dangereux si deux machines écrivent un jour dans le même dépôt en même temps. Pour la configuration mono-serveur de cet article, c'est un confort mineur ; laissez désactivé en cas de doute.
|
||||
- **Shared** : ne concerne que la fonctionnalité multihost de Backrest (plusieurs de vos machines gérant la même configuration de dépôt). Ignorez-le pour un serveur unique.
|
||||
- **Repository URI** : là où les données vivent réellement. C'est ce champ qui change pour chaque destination ci-dessous.
|
||||
- **Password** : le mot de passe de chiffrement de ce dépôt, cliquez sur **Generate** pour en générer un solide aléatoirement. **Conservez-le quelque part en dehors de ce serveur**, un gestionnaire de mots de passe, une note sur votre téléphone, n'importe où sauf un fichier texte posé à côté des sauvegardes qu'il protège. Perdez-le, et chaque sauvegarde devient un tas de bruit illisible et coûteux, sans exception, même pour les développeurs de restic.
|
||||
- **Env Vars** : là où vous collerez les identifiants pour les destinations qui en ont besoin (S3 et B2 plus bas). Un disque local et le SFTP n'en ont besoin d'aucun.
|
||||
|
||||
::note
|
||||
Les onglets **Scheduling**, **Hooks** et **Advanced** de ce formulaire configurent la maintenance du dépôt dans son ensemble (purge des anciennes données, vérification d'intégrité, notifications) plutôt que quoi que ce soit de spécifique à une destination. Ils sont couverts à la fin de cet article, une fois que vous avez un dépôt qui fonctionne réellement.
|
||||
::
|
||||
|
||||
### Sauvegarder vers un disque local ou une clé USB
|
||||
|
||||
La copie hors site la plus simple qui soit est un disque que vous déplacez physiquement ailleurs après chaque sauvegarde, ou le disque d'une seconde machine joint par le réseau. Dans les deux cas, du point de vue de Backrest c'est juste un dossier, donc la configuration est identique : branchez le disque (ou montez le partage réseau) sur l'hôte, ajoutez-le aux volumes du fichier compose comme vous l'avez fait pour `/srv/docker` plus haut, puis dans le champ Repository URI, utilisez le chemin tel qu'il apparaît **à l'intérieur du conteneur** :
|
||||
|
||||
```text
|
||||
/userdata/disque-sauvegarde
|
||||
```
|
||||
|
||||
Voilà, aucun identifiant, aucune variable d'environnement. C'est aussi le dépôt le plus rapide pour restaurer, puisqu'il n'y a aucun aller-retour réseau, ce qui en fait un excellent choix pour votre copie de "récupération rapide", accompagnée d'une vraie copie hors site ci-dessous pour le scénario "ma maison brûle".
|
||||
|
||||
::caution
|
||||
__Si ça ne marche pas :__ le chemin doit exister et être accessible en écriture par le conteneur avant de valider le formulaire. Un dossier vide convient très bien, restic initialise lui-même la structure du dépôt à la première utilisation.
|
||||
::
|
||||
|
||||
### Sauvegarder vers un autre serveur
|
||||
|
||||
Pas de compte cloud, pas de problème : si vous avez un accès SSH à une autre machine, le serveur d'un ami, un petit VPS pas cher, un Raspberry Pi chez de la famille, c'est un dépôt hors site parfaitement valable, et ça ne coûte que ce que cette machine vous coûte déjà.
|
||||
|
||||
D'abord, assurez-vous que ce serveur peut se connecter en SSH à l'autre sans taper de mot de passe à chaque fois :
|
||||
|
||||
```bash [Terminal]
|
||||
ssh-keygen -t ed25519 -f /srv/docker/backrest/config/id_ed25519 -N ""
|
||||
ssh-copy-id -i /srv/docker/backrest/config/id_ed25519.pub votreutilisateur@lautreserveur
|
||||
```
|
||||
|
||||
Montez cette clé dans le conteneur en l'ajoutant aux volumes du fichier compose :
|
||||
|
||||
```yaml [compose.yaml]
|
||||
volumes:
|
||||
# ...
|
||||
- ./config/id_ed25519:/root/.ssh/id_ed25519:ro
|
||||
```
|
||||
|
||||
Redéployez la stack, puis dans Backrest utilisez :
|
||||
|
||||
```text
|
||||
sftp:votreutilisateur@lautreserveur:/chemin/vers/les/sauvegardes
|
||||
```
|
||||
|
||||
::caution
|
||||
__Si ça ne marche pas :__ le dossier cible (`/chemin/vers/les/sauvegardes` ci-dessus) doit déjà exister sur l'autre serveur, et cet utilisateur doit avoir le droit d'y écrire. Connectez-vous une fois à la main (`ssh votreutilisateur@lautreserveur`) pour confirmer que la connexion fonctionne et accepter la clé de l'hôte, Backrest tournant dans un conteneur n'aura pas l'invite interactive pour ça.
|
||||
::
|
||||
|
||||
## Avancé : stockage objet dans le cloud
|
||||
|
||||
Un disque local ou le serveur de secours d'un ami couvre très bien la règle du 3-2-1, et ne coûte rien de plus que ce que vous possédez déjà. Le stockage objet dans le cloud est l'autre option classique, intéressante quand vous voulez une copie hors site qui ne dépend pas du matériel de quelqu'un d'autre restant allumé, pour un coût de quelques centimes à quelques euros par mois selon ce que vous sauvegardez.
|
||||
|
||||
### Backblaze B2
|
||||
|
||||
[Backblaze B2](https://www.backblaze.com/cloud-storage) est du stockage objet pensé exactement pour cet usage, et c'est généralement l'option la moins chère pour le schéma "on écrit souvent, on lit rarement" d'une sauvegarde.
|
||||
|
||||
Créez un bucket dans votre compte Backblaze, puis générez une **clé d'application** limitée à celui-ci. Dans Backrest, utilisez :
|
||||
|
||||
```text
|
||||
b2:nom-de-votre-bucket:backrest
|
||||
```
|
||||
|
||||
Avec les variables d'environnement suivantes :
|
||||
|
||||
| Variable | Valeur |
|
||||
|----------|-------|
|
||||
| `B2_ACCOUNT_ID` | L'identifiant de la clé d'application |
|
||||
| `B2_ACCOUNT_KEY` | La clé d'application elle-même |
|
||||
|
||||
### Stockage compatible S3
|
||||
|
||||
S3 n'est pas juste un truc Amazon, c'est un protocole de stockage que la plupart des fournisseurs cloud parlent (OVH, Scaleway, MinIO si vous auto-hébergez le vôtre, et bien d'autres), ce qui en fait un choix solide et portable si vous préférez ne pas dépendre d'un fournisseur en particulier.
|
||||
|
||||
Créez un bucket chez le fournisseur de votre choix, puis dans le champ Repository URI de Backrest, utilisez :
|
||||
|
||||
```text
|
||||
s3:https://s3.votre-fournisseur.com/nom-de-votre-bucket/backrest
|
||||
```
|
||||
|
||||
Pour du vrai AWS S3, retirez le endpoint personnalisé :
|
||||
|
||||
```text
|
||||
s3:s3.amazonaws.com/nom-de-votre-bucket/backrest
|
||||
```
|
||||
|
||||
Avec les variables d'environnement suivantes :
|
||||
|
||||
| Variable | Valeur |
|
||||
|----------|-------|
|
||||
| `AWS_ACCESS_KEY_ID` | La clé d'accès de votre fournisseur |
|
||||
| `AWS_SECRET_ACCESS_KEY` | La clé secrète de votre fournisseur |
|
||||
|
||||
::note
|
||||
Générez ces clés depuis le tableau de bord de votre fournisseur, généralement sous un intitulé du genre "Clés API" ou "Identifiants S3", limitées à ce seul bucket si le fournisseur le permet. Il n'y a aucune raison que la clé d'un job de sauvegarde puisse toucher à autre chose sur votre compte.
|
||||
::
|
||||
|
||||
### Maintenance du dépôt (optionnel, mais à mettre en place une fois pour toutes)
|
||||
|
||||
Retour dans l'onglet **Scheduling**, trois politiques gardent un dépôt en bonne santé dans le temps. Aucune n'est nécessaire pour commencer à sauvegarder, restic fonctionne très bien sans jamais y toucher, mais elles valent la peine d'être comprises une fois que votre dépôt tourne depuis un moment :
|
||||
|
||||
:::collapsible{name="les trois politiques de maintenance"}
|
||||
- **Prune Policy** : supprime les données qui ne sont plus référencées par aucun instantané (parce que les anciens instantanés qui les contenaient ont été oubliés, voir la politique de rétention plus bas). C'est la seule opération qui libère réellement de l'espace sur votre stockage. C'est lent et ça lit beaucoup de données, donc planifiez-la rarement, une fois par mois est la suggestion de Backrest lui-même. **Max Unused After Prune** contrôle à quel point c'est minutieux : un pourcentage plus élevé laisse plus de données inutilisées derrière mais termine plus vite et copie moins.
|
||||
- **Check Policy** : vérifie que votre dépôt n'est pas silencieusement corrompu. **Read Data %** contrôle quelle proportion des données réellement sauvegardées est relue et vérifiée par somme de contrôle, pas juste la structure interne du dépôt. 100% signifie relire l'intégralité du dépôt, ce qui consomme de la bande passante et du temps réels ; un pourcentage plus faible vérifie un échantillon aléatoire à la place. Une fois par mois est, encore une fois, un défaut raisonnable.
|
||||
- **Forget Policy** : une règle de rétention optionnelle pour tout le dépôt, appliquée à travers tous les plans qui y écrivent au lieu d'être par plan. Laissez-la désactivée sauf si vous voulez spécifiquement une seule politique de rétention partagée par plusieurs plans, elle désactive la politique de rétention propre à chaque plan dès que vous l'activez.
|
||||
|
||||
Chacune de ces politiques a un **Schedule Type** : `Disabled`, un simple `Interval` en heures ou en jours, ou une `Cron Expression` pour quelque chose de plus précis, plus une **Reference Clock** (l'heure locale de votre serveur, UTC, ou relative à la dernière exécution) pour ancrer ce planning.
|
||||
:::
|
||||
|
||||
## Créer un plan de sauvegarde
|
||||
|
||||
Retour dans Backrest, allez dans **Add Plan**. Ce formulaire couvre quoi sauvegarder et quand, contrairement au formulaire de dépôt ci-dessus, qui ne couvre que où :
|
||||
|
||||
- **Plan Name** : même règle que le nom du dépôt, choisissez quelque chose de clair, impossible à changer ensuite.
|
||||
- **Repository** : celui que vous venez de créer plus haut.
|
||||
- **Paths** : cliquez sur **Add** pour ajouter une ligne, puis tapez le chemin côté conteneur de ce que vous avez monté plus haut, c'est un champ texte, mais il autocomplète les vrais chemins du système de fichiers du conteneur au fur et à mesure, pratique pour confirmer qu'un montage a bien atterri là où vous pensez. `/userdata/docker` pour vos stacks, `/userdata/etc` pour votre config système, `/userdata/home` pour vos propres fichiers. Cliquez à nouveau sur **Add** pour chaque dossier supplémentaire, le petit bouton `-` retire une ligne dont vous n'avez plus besoin.
|
||||
- **Excludes** et **Excludes (Case Insensitive)** : des motifs à ignorer au sein de ces chemins, pratique pour les dossiers de cache ou tout ce qui est vraiment jetable et qui gonflerait chaque instantané pour rien.
|
||||
- **Schedule Type** : les trois mêmes choix que les plannings du dépôt ci-dessus, `Disabled`, un `Interval`, ou une `Cron Expression`. Un cron nocturne du type `0 3 * * *` (tous les jours à 3h du matin) est un défaut raisonnable pour un homelab.
|
||||
- **Retention Policy** : combien d'instantanés conserver, et pendant combien de temps. **By Time Period** vous permet de dire "garder 7 quotidiens, 4 hebdomadaires, 6 mensuels" indépendamment, ce qui vous donne largement assez de points de restauration étalés dans le temps sans que le dépôt grossisse indéfiniment, puisque restic déduplique de toute façon les données inchangées entre les instantanés. **By Count** conserve à la place simplement les N derniers instantanés, quel que soit leur âge. **Latest (Count)** en plus de l'un ou l'autre mode garantit qu'un nombre minimum d'instantanés récents survit toujours, quoi que dise le reste de la politique.
|
||||
- **Advanced** : **Backup Flags** vous permet de passer des options supplémentaires directement à la commande `restic backup` sous-jacente pour tout ce que ce formulaire n'expose pas ; **Hooks** exécute des scripts ou envoie des notifications sur les événements de sauvegarde, le même mécanisme que l'onglet Hooks du dépôt, mais limité à ce seul plan au lieu de tous les plans utilisant le dépôt.
|
||||
|
||||
Cette politique de rétention est d'ailleurs votre vraie défense contre les ransomwares : si quelque chose commence à chiffrer vos fichiers à 2h du matin, la sauvegarde de ce soir est compromise, mais celle de la semaine dernière ne l'est pas, et restic vous permet de restaurer depuis n'importe laquelle d'entre elles.
|
||||
|
||||
::tip{icon="" to="/nonsense/bash/backrest-docker-stop"}
|
||||
✨ __Pour aller plus loin :__ si ce que vous sauvegardez inclut une base de données en cours d'exécution, arrêter son conteneur le temps des quelques secondes que prend la sauvegarde est plus sûr que de la sauvegarder pendant qu'elle écrit. Voir **Backrest Docker Stop** pour un script qui fait exactement ça, déclenché automatiquement par Backrest lui-même.
|
||||
::
|
||||
|
||||
## Restaurer une sauvegarde
|
||||
Une sauvegarde qu'on n'a jamais essayé de restaurer est un pari, pas un plan, ça vaut le coup de le faire une fois avant d'en avoir vraiment besoin. Ouvrez le plan, cliquez sur un instantané, dépliez **Snapshot Browser** jusqu'à ce dont vous avez besoin, puis cliquez sur le menu **...** à côté et choisissez **Restore to path**.
|
||||
|
||||
Laissez le champ de chemin vide et Backrest l'envoie directement vers les téléchargements de votre navigateur, l'option la plus simple pour récupérer un seul fichier. Tapez un chemin et Backrest écrit plutôt les données restaurées dans le conteneur à cet endroit, et il pré-remplit un dossier temporaire du type `/userdata-backrest-restore-<id du snapshot>`, volontairement pas votre montage d'origine.
|
||||
|
||||
Ce choix par défaut n'est pas un hasard : `/srv/docker`, `/etc` et `/home` sont montés en `:ro`, donc restic ne peut pas y réécrire, restaurer directement dans `/userdata/docker` échoue avec une erreur de système de fichiers en lecture seule. Restaurez vers ce dossier temporaire suggéré (ou téléchargez à la place), vérifiez ce que vous avez récupéré, puis recopiez les fichiers à leur vraie place vous-même avec `sudo cp -a`, depuis l'hôte, en dehors de Backrest. Une étape de plus, mais ça garantit aussi qu'une restauration ne peut jamais écraser silencieusement des données en cours d'utilisation, exactement la prudence qu'on veut en plein incident.
|
||||
|
||||
Et voilà, vous avez maintenant une vraie stratégie de sauvegarde plutôt qu'un dossier appelé `sauvegarde_finale_v2_LAVRAIE`.
|
||||
@@ -0,0 +1,169 @@
|
||||
---
|
||||
title: Snapshots BTRFS
|
||||
description: Formater la partition racine de Debian en BTRFS et utiliser Snapper pour annuler instantanément une mise à jour ratée ou un mauvais changement de config, en complément local des sauvegardes 3-2-1 hors site de Backrest.
|
||||
---
|
||||
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
|
||||
[BTRFS](https://btrfs.readthedocs.io/) est un système de fichiers Linux avec une fonctionnalité redoutable pour un homelab : les **snapshots**. Un snapshot fige l'état exact d'un système de fichiers en un instant, à coût quasi nul, sans copier le moindre octet de données au départ. Cassez quelque chose dix minutes après un `apt full-upgrade`, ou écrasez le mauvais fichier `.env`, et vous pouvez revenir exactement à l'état d'avant, sans toucher à une sauvegarde.
|
||||
|
||||
Ce n'est pas le rôle de [Backrest et de la règle 3-2-1](/serveex/advanced/backrest), donc autant être précis sur la différence avant de mettre quoi que ce soit en place.
|
||||
|
||||
## Un snapshot n'est pas une sauvegarde
|
||||
Un snapshot vit sur le même disque que les données qu'il protège. Il est instantané, ne demande aucun réseau, et il est parfait pour annuler une bêtise que vous venez de faire, mais il ne sert strictement à rien le jour où ce disque lâche, se fait voler, ou où votre serveur part en fumée. C'est le rôle d'une vraie [sauvegarde 3-2-1](/serveex/advanced/backrest) : une copie sur un support différent, idéalement hors site.
|
||||
|
||||
Voyez ça comme ça :
|
||||
|
||||
- **Snapshot** = un bouton annuler. Instantané, local, gratuit, utile seulement tant que le disque est vivant.
|
||||
- **Sauvegarde** = une assurance. Plus lente, hors site, la seule chose qui survit à la mort du disque lui-même.
|
||||
|
||||
Gardez les deux. Les snapshots vous rendent serein face aux mises à jour et aux expérimentations, les sauvegardes garantissent qu'un disque mort reste un désagrément plutôt qu'une catastrophe.
|
||||
|
||||
::note{to="/serveex/core/installation#partitionnement"}
|
||||
|
||||
Ce guide suppose que la partition racine a été formatée en Btrfs pendant [l'installation de Debian](/serveex/core/installation#partitionnement). Btrfs ne peut pas être ajouté proprement à un `/` déjà en ext4 après coup, c'est donc un choix à faire une seule fois, à l'installation.
|
||||
::
|
||||
|
||||
## Formater la partition racine en BTRFS
|
||||
Le partitionnement *Assisté* de Debian ne propose que de l'ext4. Pour obtenir du Btrfs, choisissez plutôt le partitionnement *Manuel*, à la même étape que décrit [le guide d'installation principal](/serveex/core/installation#partitionnement) :
|
||||
|
||||
::steps{level="3"}
|
||||
### Sélectionner le partitionnement manuel
|
||||
|
||||
Sur l'écran de méthode de partitionnement, choisissez *Manuel* plutôt que *Assisté, utiliser un disque entier*.
|
||||
|
||||
### Créer une table de partitions
|
||||
|
||||
Sélectionnez le disque, confirmez la création d'une nouvelle table de partitions vide, puis sélectionnez l'*ESPACE LIBRE* obtenu et choisissez *Créer une nouvelle partition*.
|
||||
|
||||
### Définir la taille et le type de la partition
|
||||
|
||||
Donnez à la partition le reste du disque (moins une petite partition EFI si vous êtes en UEFI, gérée comme dans une installation Assistée), et réglez *Utiliser comme* sur __Système de fichiers journalisé Btrfs__, avec comme point de montage `/`.
|
||||
|
||||
### Terminer le partitionnement
|
||||
|
||||
*Terminer le partitionnement et appliquer les changements*, puis confirmez avec *Oui*.
|
||||
|
||||
### Terminé !
|
||||
::
|
||||
|
||||
Tout le reste de [l'installeur](/serveex/core/installation#installer-debian) reste identique.
|
||||
|
||||
## Installer Snapper
|
||||
Plutôt que de jongler à la main avec des commandes `btrfs subvolume` brutes, [Snapper](https://github.com/openSUSE/snapper) est un petit outil qui gère tout le cycle de vie des snapshots : les créer, les ranger proprement, supprimer les anciens, et encadrer automatiquement chaque opération `apt` d'une paire de snapshots.
|
||||
|
||||
```bash [Terminal]
|
||||
sudo apt install snapper
|
||||
sudo snapper -c root create-config /
|
||||
```
|
||||
|
||||
`create-config` enregistre une configuration nommée `root` pour le système de fichiers `/`, et crée un sous-volume `.snapshots` dédié en dessous pour y stocker chaque snapshot, verrouillé pour root uniquement. Pas besoin de découpage `@`/`@home`, ça fonctionne très bien sur le layout à sous-volume unique que le partitionnement manuel vient de créer.
|
||||
|
||||
Activez la configuration en éditant `/etc/default/snapper` :
|
||||
|
||||
```properties [/etc/default/snapper]
|
||||
SNAPPER_CONFIGS="root"
|
||||
```
|
||||
|
||||
Puis activez les timers qui exécutent les snapshots périodiques et le nettoyage de Snapper :
|
||||
|
||||
```bash [Terminal]
|
||||
sudo systemctl enable --now snapper-timeline.timer snapper-cleanup.timer
|
||||
```
|
||||
|
||||
`snapper-timeline.timer` se déclenche **toutes les heures** par défaut, c'est fixé par l'unité elle-même, pas par une option de configuration. Chaque exécution prend un snapshot et le range dans la bonne catégorie (horaire, quotidien, mensuel, annuel) ; les réglages `TIMELINE_LIMIT_*` vus plus bas ne contrôlent que combien de snapshots de chaque catégorie survivent, pas la fréquence à laquelle ils sont pris. `snapper-cleanup.timer` tourne une fois par jour (plus une fois 10 minutes après le démarrage) pour appliquer ces limites.
|
||||
|
||||
::tip
|
||||
✨ Pour prendre des snapshots de chronologie à une fréquence différente, par exemple toutes les 6 heures plutôt que toutes les heures, surchargez le timer plutôt que de modifier directement le fichier d'unité du paquet :
|
||||
|
||||
```bash [Terminal]
|
||||
sudo systemctl edit snapper-timeline.timer
|
||||
```
|
||||
|
||||
```ini [override.conf]
|
||||
[Timer]
|
||||
OnCalendar=
|
||||
OnCalendar=*-*-* 0/6:00:00
|
||||
```
|
||||
|
||||
La ligne `OnCalendar=` vide efface d'abord la valeur `hourly` du paquet, puisque systemd ajoute sinon les nouvelles lignes `OnCalendar` à celles déjà présentes au lieu de les remplacer. Appliquez avec `sudo systemctl daemon-reload && sudo systemctl restart snapper-timeline.timer`.
|
||||
::
|
||||
|
||||
::note
|
||||
|
||||
Le paquet Debian embarque aussi un hook APT (`/etc/apt/apt.conf.d/80snapper`) qui s'active dès qu'une configuration figure dans `SNAPPER_CONFIGS` : à partir de maintenant, chaque `apt install`, `apt upgrade` ou `apt full-upgrade` obtient automatiquement un snapshot juste avant et juste après son exécution, sans aucun effort de votre part.
|
||||
::
|
||||
|
||||
## Prendre un snapshot
|
||||
Pour tout ce qui sort du cadre d'apt, comme modifier une unité systemd ou un fichier Docker Compose, prenez-en un vous-même avec une description qui voudra vraiment dire quelque chose plus tard :
|
||||
|
||||
```bash [Terminal]
|
||||
sudo snapper create --description "avant changement compose sur swag"
|
||||
```
|
||||
|
||||
Listez-les tous avec :
|
||||
|
||||
```bash [Terminal]
|
||||
sudo snapper list
|
||||
```
|
||||
|
||||
```console [Output]
|
||||
# | Type | Pre # | Date | Description
|
||||
---+--------+-------+--------------------------+---------------------------------
|
||||
0 | single | | | current
|
||||
1 | single | | Tue 09 Sep 2026 18:30:00 | avant changement compose sur swag
|
||||
2 | pre | | Tue 09 Sep 2026 19:00:01 | apt install unattended-upgrades
|
||||
3 | post | 2 | Tue 09 Sep 2026 19:00:14 | apt install unattended-upgrades
|
||||
```
|
||||
|
||||
## Restaurer des fichiers depuis un snapshot
|
||||
Snapper conserve l'état complet du système de fichiers au moment du snapshot sous `/.snapshots/<numéro>/snapshot`, consultable comme n'importe quel autre dossier :
|
||||
|
||||
```bash [Terminal]
|
||||
ls /.snapshots/1/snapshot/etc/ssh/
|
||||
```
|
||||
|
||||
Pour voir exactement ce qui a changé entre un snapshot et le système actuel (`0` désigne toujours "l'état actuel") avant de toucher à quoi que ce soit :
|
||||
|
||||
```bash [Terminal]
|
||||
sudo snapper status 1..0
|
||||
```
|
||||
|
||||
Ça affiche chaque fichier créé, modifié ou supprimé depuis. Pour annuler ces changements automatiquement :
|
||||
|
||||
```bash [Terminal]
|
||||
sudo snapper undochange 1..0
|
||||
```
|
||||
|
||||
Ou restaurez un seul fichier à la main, souvent le choix le plus sûr et le plus chirurgical :
|
||||
|
||||
```bash [Terminal]
|
||||
sudo cp -a /.snapshots/1/snapshot/etc/ssh/sshd_config /etc/ssh/sshd_config
|
||||
```
|
||||
|
||||
::note
|
||||
|
||||
Ça couvre l'immense majorité des vrais accidents de homelab : une mauvaise config, un fichier supprimé, une mise à jour de paquet qui a cassé un truc. Snapper peut aussi faire un `rollback` de toute la partition racine vers un snapshot antérieur (il crée un nouveau sous-volume par défaut et démarre dessus au prochain redémarrage), pour un système dans un état vraiment cassé plutôt qu'un simple fichier manquant. C'est une opération plus délicate et bien plus rare, à tester une fois sur une machine où redémarrer ne vous dérange pas, avant d'en avoir vraiment besoin. Et si le disque lui-même est le problème, c'est exactement le scénario pour lequel votre sauvegarde [Backrest](/serveex/advanced/backrest) hors site existe.
|
||||
::
|
||||
|
||||
## Gérer et nettoyer les snapshots
|
||||
Les snapshots sont bon marché, pas gratuits : dès que le système de fichiers actif diverge d'un snapshot, les anciens blocs qu'il référence toujours restent occupés. Sans surveillance, des mois de snapshots sur un serveur qui change beaucoup (images de conteneurs, logs) peuvent discrètement grignoter de l'espace disque réel.
|
||||
|
||||
Le `snapper-cleanup.timer` activé plus haut nettoie déjà automatiquement, selon la configuration de `/etc/snapper/configs/root` :
|
||||
|
||||
| Réglage | Défaut | Ce que ça fait |
|
||||
|---------|---------|---------------|
|
||||
| `TIMELINE_LIMIT_HOURLY` / `_DAILY` / `_MONTHLY` / `_YEARLY` | `10` | Combien de snapshots de chronologie garder pour chaque granularité |
|
||||
| `TIMELINE_LIMIT_WEEKLY` | `0` | Désactivé par défaut |
|
||||
| `NUMBER_LIMIT` | `50` | Combien de snapshots manuels (`single`) garder |
|
||||
|
||||
Ajustez ça à votre goût, puis supprimez-en un immédiatement à la main si vous avez besoin de la place tout de suite :
|
||||
|
||||
```bash [Terminal]
|
||||
sudo snapper delete 1
|
||||
```
|
||||
|
||||
Vérifiez l'usage disque réel avec `df -h /` : les chiffres ci-dessus ne plafonnent que le nombre de snapshots, pas l'espace qu'un serveur très actif peut encore consommer entre deux nettoyages.
|
||||
|
||||
Et voilà : un bouton annuler automatique et permanent pour votre serveur, qui encadre discrètement chaque mise à jour et se nettoie tout seul, en tournant à côté des vraies sauvegardes que Backrest prend déjà hors site.
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Introduction
|
||||
title: Stockeex
|
||||
description: Introduction à Stockeex, un projet personnel de gestion de stock et d'inventaire. Documentation en cours de rédaction.
|
||||
navigation:
|
||||
icon: i-lucide-bookmark
|
||||
@@ -15,5 +15,5 @@ currently writing, come back later...
|
||||
--
|
||||
```
|
||||
<div align="center">
|
||||
<img src="/img/stockeex/stockeex-raid.svg" alt="Image" style="max-width: 60%;">
|
||||
<img src="/img/stockeex/stockeex-raid.svg" alt="Schéma d'une grappe RAID" style="max-width: 60%;">
|
||||
</div>
|
||||
|
||||
@@ -9,7 +9,7 @@ navigation:
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
## Scripts et projets annexes
|
||||
|
||||
Cette section rassemble mes projets Python et Bash écrits en chemin : des scripts qui automatisent une des usages précis, répond à des besoins particuliers, créés au fil du temps. Vous les trouverez peut-être utiles, les voici en vrac.
|
||||
Cette section rassemble mes projets Python et Bash écrits en chemin : des scripts qui automatisent un des usages précis, répondent à des besoins particuliers, créés au fil du temps. Vous les trouverez peut-être utiles, les voici en vrac.
|
||||
|
||||
### Python
|
||||
|
||||
@@ -32,7 +32,7 @@ Des alertes Discord sur la disponibilité des GPU
|
||||
::card
|
||||
---
|
||||
icon: i-cbi-adguard
|
||||
title: Adguard CIDRE
|
||||
title: AdGuard CIDRE
|
||||
to: /nonsense/python/adguard-cidre
|
||||
ui:
|
||||
icon: text-[#68BC71]
|
||||
|
||||
@@ -6,11 +6,11 @@ description: Un bot Python qui surveille la disponibilité des GPU en temps rée
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
|
||||
Depuis déjà 4 ans, la pénurie de materiel electronique fait rage. Et les cartes graphiques ne sont pas épargnées. En 2020, j'ai du attendre 2 mois pour obtenir mon exemplaire de RTX 3080, et pour cela j'ai du m'inscrire sur [JV Hardware](https://discord.gg/gxffg3GA96) où une poignée de geek avait mis en place un bot qui envoyait un ping lorsqu'elles étaient disponibles.
|
||||
Depuis déjà 4 ans, la pénurie de materiel electronique fait rage. Et les cartes graphiques ne sont pas épargnées. En 2020, j'ai dû attendre 2 mois pour obtenir mon exemplaire de RTX 3080, et pour cela j'ai dû m'inscrire sur [JV Hardware](https://discord.gg/gxffg3GA96) où une poignée de geek avait mis en place un bot qui envoyait un ping lorsqu'elles étaient disponibles.
|
||||
|
||||
4 ans après et 5000 abonnés plus tard, vient la sortie des RTX 5000. Et là aucun bot dispo sur le marché ne semble fonctionner correctement. Je ne parle même pas d'un certain "influenceur" qui se permet de faire payer l'accès à son bot qui ne fonctionne meme pas. Il copie à la main les alertes provenant d'autres serveurs, comme le notre qui ont résolu le problème.
|
||||
4 ans après et 5000 abonnés plus tard, vient la sortie des RTX 5000. Et là aucun bot dispo sur le marché ne semble fonctionner correctement. Je ne parle même pas d'un certain "influenceur" qui se permet de faire payer l'accès à son bot qui ne fonctionne même pas. Il copie à la main les alertes provenant d'autres serveurs, comme le nôtre qui ont résolu le problème.
|
||||
|
||||
Quoiqu'il en soit, désireux d'obtenir une RTX 5090 pour ma machine dédiée à l'IA, je me suis dit qu'il était peut etre le temps de plonger dans le monde de python et de ChatGPT pour m'épauler. A l'aide d'un autre membre du serveur, KevOut, qui a principalement guidé sur le principe de départ et les sources des différentes API, j'ai réussi à obtenir un bot propre, fonctionnel, qui envoie différents types d'alertes via Discord. Avec un simple conteneur docker à déployer.
|
||||
Quoiqu'il en soit, désireux d'obtenir une RTX 5090 pour ma machine dédiée à l'IA, je me suis dit qu'il était peut-être le temps de plonger dans le monde de python et de ChatGPT pour m'épauler. A l'aide d'un autre membre du serveur, KevOut, qui a principalement guidé sur le principe de départ et les sources des différentes API, j'ai réussi à obtenir un bot propre, fonctionnel, qui envoie différents types d'alertes via Discord. Avec un simple conteneur docker à déployer.
|
||||
|
||||
Après moult déconvenues, je suis passé de ceci :
|
||||
|
||||
|
||||
@@ -1,33 +1,33 @@
|
||||
---
|
||||
title: Adguard CIDRE
|
||||
title: AdGuard CIDRE
|
||||
description: Un script Python pour synchroniser automatiquement les listes CIDR d'AdGuard Home et sécuriser votre serveur DNS auto-hébergé exposé sur internet.
|
||||
---
|
||||
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
|
||||
Adguard Home est une solution merveilleuse pour filter ses requêtes DNS et ainsi se débarasser de la publicité ou des DNS des fournisseurs d'accès, ou encore réécrire des requetes.
|
||||
AdGuard Home est une solution merveilleuse pour filtrer ses requêtes DNS et ainsi se débarrasser de la publicité ou des DNS des fournisseurs d'accès, ou encore réécrire des requêtes.
|
||||
|
||||
Quand c'est en local, c'est très chouette. Mais quand on veut que tout ses appareils en profitent même à l'exterieur, on est obligé de l'exposer sur le net. Et n'importe qui peut s'en servir et saturer le petit remote à 1€ qu'on a pris pour l'heberger.
|
||||
Quand c'est en local, c'est très chouette. Mais quand on veut que tous ses appareils en profitent même à l'extérieur, on est obligé de l'exposer sur le net. Et n'importe qui peut s'en servir et saturer le petit remote à 1€ qu'on a pris pour l'héberger.
|
||||
|
||||
Adguard permet d'avoir des listes de clients autorisés ou bloqués. Problème, pour autoriser un client il faut son IP, et dans le cas d'un téléphone sur le réseau mobile, beh elle change régulièrement. L'idée est donc plutot de bloquer des listes générales plutot que d'autoriser des IP qui de toute façon changent régulièrement.
|
||||
AdGuard permet d'avoir des listes de clients autorisés ou bloqués. Problème, pour autoriser un client il faut son IP, et dans le cas d'un téléphone sur le réseau mobile, beh elle change régulièrement. L'idée est donc plutôt de bloquer des listes générales plutôt que d'autoriser des IP qui de toute façon changent régulièrement.
|
||||
|
||||
CIDRE est un outil qui permet de synchroniser des listes de plages IP géolocalisées mises à jour régulièrement avec un pare feu. Plutot que de faire tourner CIDRE sur le remote complet avec des règles de pare feu complexes, je me suis dit qu'il fallait simplement s'arranger pour ajouter les plages IP à jour que CIDRE propose au systeme de block list d'adguard, selon les pays que l'on souhaite bloquer.
|
||||
CIDRE est un outil qui permet de synchroniser des listes de plages IP géolocalisées mises à jour régulièrement avec un pare feu. Plutôt que de faire tourner CIDRE sur le remote complet avec des règles de pare-feu complexes, je me suis dit qu'il fallait simplement s'arranger pour ajouter les plages IP à jour que CIDRE propose au système de block list d'AdGuard, selon les pays que l'on souhaite bloquer.
|
||||
|
||||
C'est ainsi qu'est né Adguard CIDRE Sync, un conteneur qui synchronise régulièrement la block list d'Adguard avec les plages IP recensées par CIDRE à la fréquence que vous voulez.
|
||||
C'est ainsi qu'est né AdGuard CIDRE Sync, un conteneur qui synchronise régulièrement la block list d'AdGuard avec les plages IP recensées par CIDRE à la fréquence que vous voulez.
|
||||
|
||||
L'idée etant de :
|
||||
L'idée étant de :
|
||||
|
||||
- Backup le fichier de conf d'Adguard au premier lancement (le fichier jamais touché par le robot est ainsi conservé au cas où)
|
||||
- Télécharger la liste des pays selectionnés via une variable d'environnement
|
||||
- Permettre d'ajouter soi-meme des IP "à la main" dans un fichier
|
||||
- Concaténer le tout, backup le fichier de conf (dernière update), et injecter la liste dans la bonne section du fichier de conf d'Adguard
|
||||
- Recharger Adguard en relançant le container (accès au socket via docker socket proxy pour limiter les permissions)
|
||||
- Backup le fichier de conf d'AdGuard au premier lancement (le fichier jamais touché par le robot est ainsi conservé au cas où)
|
||||
- Télécharger la liste des pays sélectionnés via une variable d'environnement
|
||||
- Permettre d'ajouter soi-même des IP "à la main" dans un fichier
|
||||
- Concaténer le tout, backup le fichier de conf (dernière update), et injecter la liste dans la bonne section du fichier de conf d'AdGuard
|
||||
- Recharger AdGuard en relançant le container (accès au socket via docker socket proxy pour limiter les permissions)
|
||||
|
||||
Tout ceci de manière complètement autonome, avec une fréquence choisie en variable d'environnement dans la conf du compose.
|
||||
|
||||
Plus d'infos directement sur le repo :
|
||||
|
||||
::card{title="🐋 __Adguard CIDRE Sync__"}
|
||||
[Robot de synchronisation de la blocklist d'Adguard](https://git.djeex.fr/Djeex/adguard-cidre)
|
||||
::card{title="🐋 __AdGuard CIDRE Sync__" to="https://git.djeex.fr/Djeex/adguard-cidre" target="_blank"}
|
||||
Robot de synchronisation de la blocklist d'AdGuard
|
||||
::
|
||||
|
||||
@@ -6,13 +6,13 @@ description: Lumeex est un générateur de galerie photo statique en Python, min
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
<div align="center">
|
||||
<img src="https://git.djeex.fr/Djeex/lumeex/raw/branch/main/illustration/logo.svg" alt="Lumeex Screenshot" width="300"/>
|
||||
<img src="/img/nonsense/lumeex-logo.svg" alt="Logo Lumeex" width="300"/>
|
||||
</div>
|
||||
<div align="center">
|
||||
<p>Yet another minimalist, lightweight photo gallery static site generator.</p>
|
||||
</div>
|
||||
<div align="center">
|
||||
<img src="https://git.djeex.fr/Djeex/lumeex/raw/branch/main/illustration/lumeex.png" alt="Lumeex Screenshot" />
|
||||
<img src="/img/nonsense/lumeex.png" alt="Page d'accueil de la galerie Lumeex" />
|
||||
</div>
|
||||
|
||||
---
|
||||
@@ -28,7 +28,7 @@ Finalement, après avoir obtenu de bons résultats, je me suis dit autant aller
|
||||
C'est ainsi qu'est né **Lum[eex]{style="color: #1ad6ff"}**.
|
||||
|
||||
<div align="center">
|
||||
<img src="https://git.djeex.fr/Djeex/lumeex/raw/branch/main/illustration/lumeex-webui.png" alt="Lumeex Screenshot" />
|
||||
<img src="/img/nonsense/lumeex-webui.png" alt="Interface web de configuration de Lumeex" />
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
@@ -6,13 +6,13 @@ description: Instameex est un outil Docker pour fusionner des exports SDR et HDR
|
||||
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px zIndex=60}
|
||||
<div align="center">
|
||||
<img src="https://git.djeex.fr/Djeex/instameex/raw/branch/main/src/assets/img/logo-long.svg" alt="Instameex Screenshot" width="300"/>
|
||||
<img src="/img/nonsense/instameex-logo-long.svg" alt="Logo Instameex" width="300"/>
|
||||
</div>
|
||||
<div align="center">
|
||||
<p>Mixez vos photos SDR et HDR pour obtenir un fichier parfait pour Instagram</p>
|
||||
</div>
|
||||
<div align="center">
|
||||
<img src="https://git.djeex.fr/Djeex/instameex/raw/branch/main/illustration/instameex-illustration.png" width="640" alt="Instameex Screenshot" />
|
||||
<img src="/img/nonsense/instameex-illustration.png" width="640" alt="Illustration Instameex" />
|
||||
</div>
|
||||
---
|
||||
|
||||
@@ -25,7 +25,7 @@ Je me suis alors inspiré d'un [fork du premier projet](https://github.com/kosti
|
||||
|
||||
En gros, voilà ce que donne mon workflow à présent pour poster sur Insta :
|
||||
|
||||

|
||||

|
||||
|
||||
Je vous présente donc **Instam[eex]{style="color: #1ad6ff"}**
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user