TL;DR: I spent a weekend setting up GLPI for a fictional company called FakeCorp, ran into every possible configuration nightmare, and somehow emerged with a fully functional helpdesk system. Here's what I learned about ITSM, patience, and why you should never trust default Nginx configurations.
The final GLPI dashboard - worth every hour of troubleshooting
The "Simple" Weekend Project That Wasn't
It started innocently enough. I was browsing through IT job descriptions when I noticed how often ITSM (IT Service Management) tools appeared in requirements. Names like ServiceNow, Jira Service Management, and GLPI kept popping up. As someone building practical IT skills through hands-on projects, I figured: "How hard could it be to set up a helpdesk system?"
Famous last words.
What I thought would be a 2-hour setup turned into a weekend-long deep dive into web server configurations, PHP socket connections, and the surprisingly complex world of enterprise helpdesk systems. But by the end, I had something pretty amazing running on my local Ubuntu machine.
💡 Pro Tip: I wish I'd documented every error message and configuration attempt. If you're following along, take screenshots of everything - your future self will thank you when writing about the experience!
Why GLPI? (And What Even Is It?)
GLPI stands for "Gestionnaire Libre de Parc Informatique" – fancy French for "Free IT Equipment Manager." Think of it as the Swiss Army knife of IT support tools. It handles:
- Ticket management (the core helpdesk functionality)
- Asset tracking (computers, phones, software licenses)
- User management (employees, departments, locations)
- Reporting and analytics (because managers love charts)
- ITIL compliance (important for enterprise environments)
The best part? It's completely free and open-source. Perfect for learning, and surprisingly robust enough for real production use.
Setting Up My Fictional Empire: Meet FakeCorp
Before diving into the technical setup, I needed a story. Enter FakeCorp – a mid-sized company I invented with:
- Three departments: IT (that's me), HR, and Customer Support
- Multiple locations: Headquarters, Lagos Branch, and Remote Offices
- Real problems: Like every company, they had printers that mysteriously stopped working on Mondays and Wi-Fi that decided to take coffee breaks
FakeCorp's organizational structure in GLPI - departments, locations, and user hierarchies
This context was crucial because GLPI isn't just about installing software – it's about modeling real organizational structures and workflows.
The Technical Journey (AKA: How Many Ways Can Nginx Break?)
Phase 1: The "Easy" Installation
I started with what seemed like a straightforward LAMP stack setup on Ubuntu. Downloaded GLPI, extracted it to /var/www/glpi
, configured Nginx to serve from the public
directory (because security matters), and... got a 404.
💥 The Plot Twist: Nothing says "welcome to web server administration" like confidently hitting refresh and seeing that familiar Nginx 404 page. At 2 AM, that error page becomes your nemesis.
# The commands that should have worked (but didn't)
sudo wget https://github.com/glpi-project/glpi/releases/latest
sudo tar -xzf glpi-*.tgz -C /var/www/
sudo chown -R www-data:www-data /var/www/glpi
# Navigate to http://127.0.0.1 expecting success...
# Get 404 instead 🤦♂️
Then I spent the next three hours learning that GLPI's directory structure is more nuanced than I expected. The modern versions separate public files from sensitive backend code, but my specific version had everything in the root directory. This led to an enlightening deep dive into proper web server security practices.
Lesson learned: Always check the actual file structure instead of assuming documentation matches your version.
Phase 2: The PHP Socket Saga
After fixing the directory issues, I encountered this delightful error:
connect() to unix:/run/php/php8.1-fpm.sock failed (2: No such file or directory)
🔍 Detective Mode Activated: This error message became my unwelcome companion for the next hour. The solution? My system had PHP 8.3, but Nginx was still looking for PHP 8.1 sockets. Classic case of conflicting configurations!
Plot twist: I had PHP 8.3 installed, but my default Nginx site was still configured for PHP 8.1. This taught me about the importance of:
- Cleaning up conflicting configurations
- Understanding how PHP-FPM sockets work
- Reading error logs thoroughly (they usually tell you exactly what's wrong)
The Nginx configuration that finally made everything work
Phase 3: The Security Awakening
Once GLPI finally loaded, it immediately hit me with security warnings:
- "Change default passwords for glpi, tech, normal, post-only users"
- "Web server root directory is not safe"
- "Move data directories outside web root"
GLPI's security check results - educational even when intimidating
This wasn't just nagging – these warnings introduced me to real-world security practices for production systems. Even though this was a local test environment, understanding why these practices matter was invaluable.
Building FakeCorp's Helpdesk Reality
With the technical foundation solid, the fun part began. I created user accounts for different roles and started submitting tickets as if I was actually working at FakeCorp:
A realistic mix of IT support requests that any company would recognize
Ticket #001: "Printer in Lagos office won't print color documents"
Assigned to: IT Technician
Priority: Medium
Status: Investigating
Ticket #002: "Need new software license for design team"
Assigned to: IT Manager
Priority: Low
Status: Pending Approval
Ticket #003: "VPN keeps disconnecting for remote workers"
Assigned to: Network Specialist
Priority: High
Status: In Progress
What struck me was how naturally GLPI handles the complexity of real IT environments. Each ticket could be categorized, prioritized, assigned, tracked, and reported on. The system enforced accountability while providing visibility into team workload.
Individual ticket view showing the full lifecycle and collaboration features
The "Aha!" Moments
Understanding ITIL in Practice
Before this project, ITIL was just acronym soup to me. But working with GLPI's workflow made concepts like Incident Management, Request Fulfillment, and Change Management tangible. I could see how these frameworks actually help organizations deliver consistent IT service.
Realizing the Consultant Opportunity
As I configured business rules for automatic ticket routing and set up SLA tracking, it dawned on me: small companies desperately need these systems but often lack the expertise to implement them. This represents a genuine consulting opportunity for someone with these skills.
Appreciating Good UX Design
GLPI's interface isn't the prettiest, but it's incredibly functional. Every click serves a purpose. Every form field maps to a real business need. This taught me to appreciate software designed for productivity over aesthetics.
The reporting interface - not flashy, but incredibly practical for managers
What I Built (The Satisfying Part)
After two days of configuration, I had:
- A fully functional helpdesk with 10 sample tickets across different categories
- User management with proper role-based access control
- Asset tracking for FakeCorp's fictional computer inventory
- Location-based routing so Lagos office issues go to the right team
- Basic reporting showing ticket resolution times and technician workload
- Custom branding (because even fictional companies deserve good design)
The complete FakeCorp helpdesk system - from chaos to organized IT support
The Real-World Value
This wasn't just an academic exercise. The skills I developed translate directly to:
- Consulting opportunities: Small businesses need ITSM implementations
- System administration roles: Understanding helpdesk workflows is crucial
- Process improvement: Many organizations have terrible IT support processes
- Vendor management: Knowing what good ITSM looks like helps evaluate commercial solutions
What's Next?
This project opened my eyes to the broader world of IT service management. I'm planning to explore:
- ServiceNow (the enterprise standard)
- Integration patterns (connecting helpdesk to monitoring systems)
- Advanced automation (AI-powered ticket routing and resolution)
- Mobile responsiveness (because users expect mobile-first experiences)
For Fellow Learners
If you're thinking about diving into ITSM tools:
Start simple: Set up GLPI in a VM or container first. Don't try to solve every configuration issue on day one.
Think organizationally: The technical setup is just the foundation. The real learning happens when you model actual business processes.
Document everything: I wish I'd kept better notes about what broke and why. These systems have lots of moving parts.
Embrace the complexity: Modern IT environments are genuinely complex. Tools like GLPI exist because managing IT at scale is hard work.
The winding path from "this looks easy" to "I actually understand ITSM now"
The Bottom Line
What started as a "simple weekend project" became a masterclass in web server configuration, IT service management, and the importance of reading error logs carefully. More importantly, it gave me hands-on experience with tools that power IT operations at companies worldwide.
GLPI might not be the flashiest technology, but it represents something important: the infrastructure that keeps businesses running smoothly. Understanding these systems – both technically and organizationally – is valuable whether you're aiming for a sysadmin role, considering IT consulting, or just want to understand how professional IT departments actually work.
Plus, I can now confidently add "ITSM" to my resume without feeling like a fraud. That's worth a weekend of troubleshooting PHP sockets any day.
Have you worked with helpdesk systems before? What tools have you found most effective for IT service management? Share your experiences in the comments – I'd love to hear about other platforms worth exploring!
What's your next IT learning project? Let me know in the comments below! 👇