Fraîche Flow
MILOUD NECILI
IT SYSTEMS INTEGRATION
Starting point
Fraîche Flow is a project scenario for the town of Carhaix-Plouguer. Together with Klemmbausteine GmbH and the Université de Bretagne Occidentale, it involves networking systems for water distribution, sensors and mist-spraying actuators.
Problem
The systems were decentralised. Operational and personal data were intended to remain within the municipal environment. At the same time, selected services had to be accessible to the participating partners.
Assignment
My task was to build the required server environment in the lab. This included setting up systems, configuring services, functional testing, troubleshooting and documentation.
Project profile
As part of my vocational retraining, I built and documented a virtual lab environment covering Linux, core services, storage, web applications, containers, backup and monitoring.
| Project context | Training and educational lab; no claim of production operation |
|---|---|
| My role | Practical setup, configuration, testing, troubleshooting and documentation |
| Completion | All documented tasks addressed within the lab exercise |
| Evidence | Terminal output, configuration checks and technical screenshots |
| Documentation | 20 individual technical reports plus this project overview |
Technical focus
- Linux and virtualisation: Debian, Hyper-V, Proxmox, management client and the LXC context.
- Core services and storage: BIND9, Kea, SSH, TrueNAS, Windows Storage Spaces and iSCSI.
- Applications: Apache, PHP, MariaDB, native and containerised Nextcloud, Redis, Portainer and a mail server.
- Operations: rsync, Cron, restore testing, Chrony, Uptime Kuma and AutoKuma.
Results at a glance
The final Uptime Kuma dashboard shows 15 monitored endpoints online and none offline. Some historical availability figures are below 100%. The documentation distinguishes current reachability, historical availability and functional testing.
Architecture and service roles
| System | Service role |
|---|---|
| ff-edge-01 · .1 | Gateway and SSH entry point into the lab |
| ff-pve-01 · .10 | Proxmox hypervisor |
| ff-core-01 · .11 | DNS and core services |
| ff-store-01 · .12 | TrueNAS and iSCSI backup target |
| ff-app-01 · .13 | Apache, native services and Docker workloads |
| ff-mail-01 | Separate mail server in the Proxmox/LXC context |
| ff-mgmt-01 | Administration client; its address changed during the project |
Address prefix: 192.168.10.0/24. Internal DNS zone: fraicheflow.test. The table describes the lab, not public infrastructure.
Selected technical evidence
- DNS: zone syntax OK; ff-app-01, portal and nextcloud resolved to 192.168.10.13.
- Web: Apache syntax OK; HTTP 200 and an HTTPS redirect to the Nextcloud login.
- Backup: rsync backup, Cron configuration, logging and a file-based restore test addressed during the project.
- Containers: Nextcloud, Redis, MariaDB, Portainer, Chrony and the web server shown as running in
docker ps. - Monitoring: AutoKuma created monitors; Socket.IO responded; system MariaDB heartbeats showed
status=1.
Scope and transparency
The project lead has confirmed that all tasks were addressed. Where original output is unavailable, no individual test value is invented. The reports distinguish this confirmation from directly visible results. The grouping is thematic; it does not constitute an official task acceptance or one certified by the training provider.
Not presented as verified implementations: a publicly trusted DuckDNS/Let’s Encrypt certificate, Nginx Proxy Manager, a full disaster recovery test, a production SLA or end-to-end external alert delivery.
Documentation overview
- 01 Linux administration and the shell
- 02 Git and version-controlled documentation
- 03 Linux management client and local IAM
- 04 Architecture and virtualisation
- 05 Edge access and SSH port forwarding
- 06 DNS with BIND9
- 07 DHCP with Kea
- 08 SSH administration and access security
- 09 TrueNAS and Windows Storage Spaces
- 10 iSCSI and block storage
- 11 Automated backup and restore
- 12 Nextcloud on Apache, PHP and MariaDB
- 13 TLS certificates and HTTPS
- 14 Docker Engine and a custom web server image
- 15 Nextcloud stack with MariaDB and Redis
- 16 Portainer for container management
- 17 Containerised time service with Chrony
- 18 Mail server, DNS and client connectivity
- 19 Central monitoring with Uptime Kuma
- 20 Acceptance, recovery and operational handover
For a technical discussion
I can explain service dependencies, trace the access path from client to container and narrow down faults using DNS, ports, logs and heartbeats. Particularly useful examples include an incorrect DNS server address, Apache host-header selection and the distinction between a red historical record and a current online status.