AP2 — PARCUS project

Project at a glance

The need

A small organisation needed a full in-house IT service: knowing what hardware it owns, receiving and handling requests from its staff, and being able to fix workstations remotely — all self-hosted, without relying on an online service.

The project was therefore split into three complementary lots, each led by one team member. Beyond my own lot, I took part in setting up the other two. Everything runs on virtual machines connected to the internal 192.168.137.0/24 network: no service is exposed to the internet.

Split of the lots

• LOT 1 — RustDesk (Maxence Rodriguez): self-hosted remote-control server, BitLocker encryption.
• LOT 2 — GLPI (Aksel Karacelik): asset management, automated inventory and helpdesk tickets.
• LOT 3 — Windows Server 2025 (Alexis Jeanney): Active Directory, DHCP, WDS and software deployment through GPO.

Architecture

My work: the GLPI lot

GLPI is an open source IT asset management and service desk (ITSM) solution. I installed and commissioned it end to end, then documented it for three different audiences: whoever installs it, whoever uses it, whoever operates it.

Stack

What I set up

• GLPI server on a LAMP stack — installing Apache, PHP and its extensions, then MariaDB; securing the database and importing the time zones.
• Post-installation hardening — removing the install directory, changing every default account password and disabling unused accounts.
• Automated inventory — deploying the GLPI Agent on Windows workstations, both through the GUI and silently (msiexec /quiet) for mass deployment. Machines report themselves into Assets > Computers with their CPU, RAM, disks and software.
• Mail collector — an email sent to the support address automatically becomes a ticket (subject = title, body = description), polled every 10 minutes by the mailgate automatic action.
• Centralised authentication — connecting GLPI to the LOT 3 Active Directory over LDAPS (port 636), so staff sign in with their domain account.
• Ticket lifecycle — from the Self-Service portal on the user side through to assignment, handling and closure on the technician side.

Problems I ran into

The most instructive part of the project. Every blocker is documented in the deliverable with its symptom, its cause and how it was fixed.

• The Debian VM could not reach the network — no DNS resolution, no ping. The network adapter added to the VM was not up. Fixed by bringing the interface up and requesting an address (ip link set ens33 up, dhclient), then making it permanent in /etc/network/interfaces.
• The php-imap extension missing from the Debian 13 repositories — yet it is required by the mail collector. It had to be added another way, then verified with php -m | grep imap.
• The inventory agent created a folder instead of sending the inventory — the server URL had been typed into the install folder field (Local Target) instead of Remote Targets. An interface trap that costs you a full reinstall of the agent.
• LDAPS unreachable — “No route to host” on port 636 — GLPI was stuck at the TCP flow step towards the domain controller. Methodical diagnosis from the Debian box: ping first to check the two VMs can see each other, then nc -zv to check the port is actually open.

Acceptance testing

Each lot was validated by a test plan, replayed after every significant change to the infrastructure. For the GLPI lot, eight tests cover the whole chain — all passed.

What I took away from it

This project had me doing real Linux administration — setting up a LAMP stack, network troubleshooting, hardening a service — but also something I did not expect: writing for someone else. Producing three sets of documentation for three different audiences forces you to actually understand what you built.

Interconnecting the three lots was also a good teamwork exercise: my GLPI server had to authenticate against a teammate's Active Directory, which meant agreeing on addressing, ports and certificates.

Curriculum skills involved