GLPI on AWS User Guide

Overview

GLPI is an open source IT service management suite. It combines a service desk (tickets, problems, changes, SLAs and business rules) with a CMDB and asset inventory covering computers, monitors, software, network devices, printers, phones, racks and virtual machines, plus software licence and contract management, a supplier and budget register, reservations, a knowledge base, a self service portal and a REST API.

This image runs GLPI 11.0.8 behind nginx with PHP FPM 8.3 and OPcache, with the mysqli, mbstring, curl, gd, intl, bcmath, xml, zip, bz2 and ldap extensions that GLPI needs. MariaDB provides the database, on the same instance and bound to the loopback interface only. The GLPI database schema is already installed and the web installer directory has been deleted, so the first request lands on the sign in page with no setup wizard to work through.

GLPI ships four well known default accounts — glpi, tech, normal and post-only. None of them is usable in this image. The three secondary accounts are disabled, and the glpi Super-Admin password is replaced on the first boot of every deployed instance with a random per instance secret written to /root/glpi-credentials.txt with mode 0600. GLPI's encryption key and the MariaDB maintenance credential are regenerated per instance at the same time. Two instances launched from the same Amazon Machine Image never share secrets.

Storage is split across two dedicated EBS volumes separate from the operating system disk. The MariaDB data directory sits at /var/lib/mysql, and GLPI's variable data — uploaded documents, plugins, dumps, sessions, cache and logs — sits at /var/lib/glpi. Each tier can be resized independently of the others. Both are recorded in /etc/fstab by filesystem UUID, so the layout reproduces on every instance you launch.

Prerequisites

Before you deploy this image you need:

• An Amazon Web Services account where you can launch EC2 instances
• IAM permissions to launch instances, create security groups, and subscribe to AWS Marketplace products
• An EC2 key pair in the target Region for SSH access to the instance
• A VPC and subnet in the target Region, with a security group allowing inbound port 22 from your management network and inbound ports 80 and 443 from the networks your agents and requesters will reach GLPI on
• The AWS CLI (version 2) installed locally if you plan to deploy from the command line

Step 1: Launch the Instance from the AWS Marketplace

Sign in to the AWS Management Console, open the EC2 service, and select Launch instance. Under Application and OS Images choose AWS Marketplace AMIs and search for GLPI. Select the cloudimg listing and choose Select, then Continue on the subscription summary.

Pick an instance type of m5.large or larger — GLPI is a PHP and MariaDB workload, and inventory imports, report generation and the dashboards benefit from memory. Choose your EC2 key pair under Key pair (login). Under Network settings select your VPC and subnet, and either create or select a security group that allows inbound port 22 from your management network and inbound ports 80 and 443 from the networks your users come from. Leave the root volume at the default size or larger; the two data volumes are attached automatically from the image.

Select Launch instance. First boot initialisation takes a few seconds after the instance state becomes Running and the status checks pass.

Step 2: Launch the Instance from the AWS CLI

The following block launches an instance from the cloudimg GLPI Marketplace AMI into an existing subnet and security group. Replace <ami-id> with the AMI ID shown on the Marketplace listing, <key-name> with your EC2 key pair name, <subnet-id> with your subnet ID, and <security-group-id> with a security group that opens ports 22, 80, and 443 as described above.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --block-device-mappings '[{"DeviceName":"/dev/sda1","Ebs":{"VolumeSize":30,"VolumeType":"gp3"}}]' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=glpi-01}]'

The command prints a JSON document on success. Note the instance ID, then retrieve its public address once it is running with aws ec2 describe-instances --instance-ids <instance-id> --query "Reservations[].Instances[].PublicIpAddress" --output text.

Connecting to your instance

Connect over SSH with the key pair you selected and the public IP address of the instance. The SSH login user depends on the operating system of the AMI variant you launched:

Step 3: Retrieve the Per Instance Administrator Password

The glpi Super-Admin password is generated on the first boot of the instance and written to /root/glpi-credentials.txt, readable only by root. Read the whole file on the instance with sudo cat /root/glpi-credentials.txt. The block below prints only the non secret keys, so it is safe to run in a shared terminal or paste into a ticket:

sudo grep -E '^GLPI_(URL|ADMIN_USER)=' /root/glpi-credentials.txt

Expected output, with the address of your own instance:

GLPI_URL=http://203.0.113.10/
GLPI_ADMIN_USER=glpi

The password itself sits on the GLPI_ADMIN_PASSWORD= line of the same file. Never paste that value into a shared channel, and change it from My settings in the GLPI interface once you have signed in.

Step 4: Confirm the Stack Is Healthy

Three services make up the running appliance: nginx on port 80, PHP FPM behind it over a unix socket, and MariaDB on the loopback interface. Check all three:

systemctl is-active nginx php8.3-fpm mariadb

active
active
active

nginx serves an unauthenticated static health endpoint at /healthz for load balancer and target group probes, and the GLPI front controller answers on /:

curl -s -o /dev/null -w 'healthz: HTTP %{http_code}\n' http://127.0.0.1/healthz
curl -s -o /dev/null -w 'login page: HTTP %{http_code}\n' http://127.0.0.1/index.php

healthz: HTTP 200
login page: HTTP 200

Confirm the shipped versions:

sudo -u www-data php /var/www/glpi/bin/console --version
php -r 'echo "PHP " . PHP_VERSION . "\n";'
nginx -v
mariadb --version

GLPI CLI 11.0.8
PHP 8.3.6
nginx version: nginx/1.24.0 (Ubuntu)
mariadb  Ver 15.1 Distrib 10.11.14-MariaDB, for debian-linux-gnu (x86_64) using  EditLine wrapper

Step 5: Sign In to the Service Desk

Browse to http://<public-ip>/ and sign in as glpi with the password from step 3. GLPI opens on the standard interface with the ticket dashboard.

To raise a ticket, choose Assistance then Create ticket. The form carries the type, category, status, request source, urgency, impact and priority fields, the requester and observer actors, and file attachments up to 64 MB:

The Assets menu is the CMDB side of GLPI. Every asset type is available out of the box — computers, monitors, software, network devices, peripherals, printers, cartridges, consumables, phones, racks, enclosures, PDUs, passive devices, cables and SIM cards — plus an unmanaged assets bucket for anything discovered but not yet classified:

Step 6: Verify the Default Account Hardening

This is the single most important check on a GLPI deployment. A stock GLPI installation seeds four accounts with published passwords: glpi/glpi (Super-Admin), tech/tech, normal/normal and post-only/postonly. Anyone who can reach the sign in page of an unhardened GLPI can log in as an administrator.

In this image the glpi account's password is replaced on every first boot with a random per instance value, and the other three accounts are set inactive. Confirm it from the database:

sudo mariadb -N -B -e "SELECT CONCAT(name,' active=',is_active) FROM glpi.glpi_users ORDER BY name;"

glpi active=1
glpi-system active=1
normal active=0
post-only active=0
tech active=0

The image also ships a proof script that exercises the real browser sign in path through nginx. It signs in with the per instance administrator password and confirms it is accepted, then attempts all four published default credentials and confirms each one is rejected. Every attempt is cross checked against GLPI's own login audit log, so a probe that never reached the credential check cannot be mistaken for a rejection:

sudo /usr/local/sbin/glpi-cred-roundtrip.sh

OK per-instance GLPI admin accepted; 4/4 shipped default credentials rejected at the auth path (login audit 13 -> 18)

You can see the same state in the interface under Administration then Users — glpi is active and the three secondary accounts are not:

Step 7: Verify the Web Installer Is Gone

GLPI's setup wizard lives in an install/ directory. Left in place on a reachable instance it lets anyone re-run setup and take over the deployment. This image deletes the directory at build time and nginx denies the path outright, so the installer returns 404 rather than a setup page:

curl -s -o /dev/null -w 'install/install.php: HTTP %{http_code}\n' http://127.0.0.1/install/install.php
sudo find /var/www/glpi -name 'install.php' -type f

install/install.php: HTTP 404

The find prints nothing, because no installer file remains on disk.

Step 8: Storage Layout

The database and GLPI's variable data are on their own EBS volumes:

df -h --output=source,size,used,avail,target /var/lib/mysql /var/lib/glpi

Filesystem      Size  Used Avail Mounted on
/dev/nvme1n1     20G  320M   19G /var/lib/mysql
/dev/nvme2n1     20G  5.4M   19G /var/lib/glpi

Both are mounted from /etc/fstab by filesystem UUID with the nofail option, so the instance still boots if a volume is ever detached. To grow a tier, modify the EBS volume in the console or with aws ec2 modify-volume, then run sudo resize2fs <device> on the instance — no GLPI configuration changes are needed.

Step 9: Database Access and Schema

MariaDB listens on the loopback interface only. Port 3306 is never opened to the network by this image, and you should not open it in your security group:

ss -tln | grep 3306

LISTEN 0      80         127.0.0.1:3306      0.0.0.0:*

On the instance, the root database account authenticates through the unix socket, so sudo mariadb needs no password:

sudo mariadb -N -B -e "SELECT CONCAT(COUNT(*),' tables in the glpi schema') FROM information_schema.tables WHERE table_schema='glpi';"

442 tables in the glpi schema

GLPI itself connects over loopback TCP as the glpi database user, whose password is generated at build time and stored in /var/www/glpi/config/config_db.php. That file is outside the web root — the nginx document root is /var/www/glpi/public — so it is never served.

Step 10: Inventory, Email and LDAP

GLPI's native inventory accepts inventory data from GLPI Agent installations on your estate. Enable it under Administration then Inventory, and point your agents at http://<public-ip>/front/inventory.php.

Inbound email collectors, which turn replies and new mail into tickets, are configured under Setup then Collectors. Outbound notification mail is configured under Setup then Notifications. The php8.3-imap extension is not installed by default; if your collectors need IMAP rather than the built in socket transport, install it and restart PHP FPM.

LDAP and Active Directory authentication is configured under Setup then Authentication. The php8.3-ldap extension is already installed, so no package work is needed.

GLPI needs its scheduled tasks to run for notifications, escalations and inventory maintenance. The simplest reliable setup is a system cron entry that calls the console every minute. Add it with sudo crontab -u www-data -e and the line * * * * * /usr/bin/php /var/www/glpi/bin/console cron:run --no-interaction.

Step 11: Enable HTTPS

For anything beyond a trial, put GLPI behind TLS. The image ships nginx with a single HTTP server block on port 80. With a DNS name pointing at the instance and port 443 open in the security group, certbot will obtain a certificate and rewrite the nginx configuration for you:

sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d <your-domain>

After TLS is in place, update GLPI's own base URL so generated links and notification emails use the HTTPS address. Set it under Setup then General then Base URL of the application.

An AWS Application Load Balancer with an ACM certificate in front of the instance is the other common pattern. Point the target group health check at /healthz, which nginx answers unauthenticated with HTTP 200.

Step 12: Backup and Maintenance

Back up two things: the glpi MariaDB database, and GLPI's variable directory /var/lib/glpi/files, which holds ticket and asset documents, plugins and dumps.

sudo mariadb-dump --single-transaction --routines --events glpi > /var/backups/glpi-$(date +%F).sql
sudo tar -czf /var/backups/glpi-files-$(date +%F).tar.gz -C /var/lib/glpi files

Because both data tiers sit on their own EBS volumes, an EBS snapshot of the two data volumes is an equally valid backup and is the simpler option for scheduled protection through AWS Backup or Data Lifecycle Manager.

Keep the operating system patched with the distribution's own tooling, and read GLPI's release notes before upgrading the application. A GLPI upgrade replaces the code tree under /var/www/glpi and then runs php bin/console database:update; take a database backup and an EBS snapshot first.

Troubleshooting

Support

This image is supported by cloudimg. Support covers GLPI deployment and upgrades, nginx, PHP FPM and MariaDB configuration, LDAP and Active Directory authentication, email collectors and ticket routing, native inventory and inventory agents, plugins, and backup and restore of the GLPI database. Contact us by email or chat, 24/7; we aim to respond within one business day.

GLPI is published under the GNU General Public License version 3. cloudimg is not affiliated with the GLPI project or Teclib'. All product and company names are trademarks or registered trademarks of their respective holders.