Deployment guide

GLPI

Videos

Overview: GLPI on Azure: overview (watch on YouTube)

Launch and log in: GLPI on Azure: launch and log in (watch on YouTube)

Deep Dive: GLPI on Azure: deep dive (watch on YouTube)

Overview

GLPI is a leading open source IT Service Management (ITSM) and IT Asset Management (ITAM) platform. From an ordinary browser, your team can run a helpdesk, log and track tickets, build a CMDB and asset inventory, manage software licences and contracts, and report on it all.

This SecureAnyCloud image ships GLPI 11.0.8 served by nginx and PHP 8.3 FPM on a hardened Ubuntu 24.04 LTS base, patched at build time. It includes a bundled local MariaDB server, so the appliance is complete and useful on its own. GLPI runs behind an nginx reverse proxy on port 80. The bundled MariaDB listens only on the loopback interface (127.0.0.1:3306) and keeps its data on a dedicated Azure data disk. A unique Super-Admin password is generated on the first boot of every VM, and all four of the well-known GLPI default accounts are secured.

What you get:

GLPI 11.0.8 served by nginx and PHP 8.3 FPM, managed by systemd
A bundled MariaDB 10.11 server that holds the GLPI database, already installed and ready
The GLPI web console on :80 served from the hardened public/ web root
A per-VM Super-Admin password generated on first boot and recorded in a root-only file
All four GLPI default accounts secured: the glpi Super-Admin password is rotated per VM, and tech, normal and post-only are disabled
MariaDB bound to 127.0.0.1 only, never exposed to the network
Two dedicated Azure data disks: the MariaDB database at /var/lib/mysql and the GLPI files, dumps and sessions at /var/lib/glpi
nginx.service, php8.3-fpm.service and mariadb.service as enabled systemd units
An unauthenticated /healthz endpoint for Azure Load Balancer health probes
24/7 SecureAnyCloud support

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B2s (2 vCPU / 4 GiB RAM) is a sensible starting size. Choose a larger size for bigger inventories, more agents or heavier ticket volumes.

Configure the network security group (NSG) to allow inbound 22/tcp from your management network and 80/tcp for the web console. GLPI serves plain HTTP on port 80, so for production terminate TLS in front of it with your own domain. The bundled MariaDB is never exposed. It listens on 127.0.0.1 only, so port 3306 stays off the network.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for GLPI by SecureAnyCloud, and select Create.

On the Basics tab, pick your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) and HTTP (80).

Review the dedicated data disks on the Disks tab, then select Review + create and Create.

Step 2 - Deploy from the Azure CLI

Create the VM with the Azure CLI:

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:glpi-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name glpi \
  --image sac1647283583153:glpi-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Then open port 80 for the web console:

az vm open-port --resource-group <your-rg> --name glpi --port 80

Step 3 - Confirm the services are running

SSH in as azureuser and confirm that nginx, PHP FPM and MariaDB are all active. MariaDB listens only on 127.0.0.1:3306, while nginx serves the web console on port 80.

systemctl is-active nginx php8.3-fpm mariadb glpi-firstboot

ss -tlnp | grep -E ':80 |:3306 ' | sed 's/ */ /g'

Step 4 - Retrieve the per-VM administrator password

Every VM generates its own GLPI Super-Admin password on first boot. It writes the password, along with the login user and URL, to a root-only credentials file. Read the file with sudo:

sudo cat /root/glpi-credentials.txt

Sign in to the GLPI web console as user glpi with the GLPI_ADMIN_PASSWORD from this file. On the VM itself, you can also run sudo mariadb to reach the database directly over the local socket without a password.

Step 5 - Sign in to the GLPI web console

Browse to http://<vm-public-ip>/. Sign in with username glpi and the password from Step 4. Leave the login source on GLPI internal database.

After you sign in, GLPI opens the Central dashboard, its home page. The left menu gives you Assets, Assistance (the helpdesk), Management, Tools, Administration and Setup. The dashboard tiles summarise your tickets, assets, software and more.

Step 6 - Log a helpdesk ticket

Open Assistance, select Tickets, and use the + button to raise a new ticket. Give the ticket a title and description, set the type, category, urgency and requester, and attach any files. Then select Add.

Technicians can then assign, track and resolve the ticket through its lifecycle.

Step 7 - Manage assets and inventory

Open the Assets menu to manage your IT estate: computers, monitors, software, network devices, peripherals, printers, racks and more. Each asset type has its own inventory list with search, filtering and bulk actions. Each list also links to the tickets, contracts and licences associated with the asset.

Step 8 - The secured default accounts

A stock GLPI install ships four well-known default accounts: glpi, tech, normal and post-only. The SecureAnyCloud image secures all four before capture. The glpi Super-Admin password is rotated to a unique per-VM secret, and tech, normal and post-only are disabled.

You can confirm the state directly. You can also run the built-in round-trip check, which shows that the per-VM administrator signs in while every default login is rejected:

sudo mariadb --protocol=socket -uroot -N -e "SELECT CONCAT(name,' is_active=',is_active) FROM glpi.glpi_users WHERE name IN ('glpi','tech','normal','post-only') ORDER BY FIELD(name,'glpi','tech','normal','post-only')"

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

Step 9 - Verify the stack and where your data lives

The MariaDB database lives on the data disk mounted at /var/lib/mysql. GLPI's variable data (uploaded documents, dumps, sessions and cache) lives on the data disk mounted at /var/lib/glpi. All of your state is therefore kept separate from the operating system disk and rides with the VM.

Confirm the GLPI version, the health endpoint, the two dedicated data disks and the installed GLPI schema:

sudo -u www-data php /var/www/glpi/bin/console --version

curl -sI http://127.0.0.1/healthz | head -1

findmnt -no SOURCE,TARGET,FSTYPE,SIZE /var/lib/mysql;
findmnt -no SOURCE,TARGET,FSTYPE,SIZE /var/lib/glpi

Adding your own domain and TLS

The appliance serves plain HTTP on port 80. For production, front GLPI with your own domain and a TLS certificate. Then update the GLPI base URL under Setup > General, so that notification links and the API use the public address.

You can terminate TLS with Azure Application Gateway, an nginx or Caddy reverse proxy, or a managed load balancer with a certificate for your domain.

Security notes

Encrypt web traffic. GLPI serves plain HTTP on port 80. For anything beyond a trusted network, put it behind your own TLS-terminating reverse proxy or Azure Application Gateway with a certificate for your domain.
Keep MariaDB private. The bundled MariaDB listens on 127.0.0.1 only and is never reachable from the network. Administer it through GLPI or over SSH.
Protect the default accounts. All four GLPI default accounts are secured on every VM. The glpi Super-Admin password is unique per VM, and tech, normal and post-only are disabled. Keep /root/glpi-credentials.txt protected, and change the password from within GLPI if you share access.
Restrict network access. Limit inbound 80/tcp in your NSG to the networks that need the web console.

Support

SecureAnyCloud maintains this image and provides 24/7 support. For help deploying or operating GLPI on Azure, contact us at secureanycloud.com.

Deploy on Azure

Launch GLPI on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on Azure

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. The inventory covers computers, monitors, software, network devices, printers, phones, racks and virtual machines. GLPI also provides 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, 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. On the first boot of every deployed instance, the glpi Super-Admin password is replaced with a random per-instance secret, which is 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 that are separate from the operating system disk. The MariaDB data directory is at /var/lib/mysql. GLPI's variable data (uploaded documents, plugins, dumps, sessions, cache and logs) is at /var/lib/glpi. You can resize each tier 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 that allows inbound port 22 from your management network and inbound ports 80 and 443 from the networks that your agents and requesters use to reach GLPI
The AWS CLI (version 2) installed locally if you plan to deploy from the command line

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 SecureAnyCloud listing, choose Select, and then choose 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 create or select a security group. The security group must allow 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.

Launch the instance from the AWS CLI

The following command launches an instance from the SecureAnyCloud 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}]'

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

Connecting to your instance

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

AMI variant SSH login user SSH command

GLPI on Ubuntu 24.04 ubuntu ssh -i /path/to/key.pem ubuntu@<public-ip>

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, which only root can read. To read the whole file on the instance, run sudo cat /root/glpi-credentials.txt.

The following command 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 is on the GLPI_ADMIN_PASSWORD= line of the same file. Never paste that value into a shared channel. After you sign in, change the password from My settings in the GLPI interface.

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

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 and 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. An unmanaged assets bucket holds anything that was discovered but not yet classified.

Verify the default account hardening

This is the 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 this 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. The script signs in with the per-instance administrator password and confirms that it is accepted. It then attempts all four published default credentials and confirms that each one is rejected. Every attempt is cross-checked against the GLPI 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 > Users. The glpi account is active and the three secondary accounts are not.

Verify the web installer is gone

The GLPI setup wizard lives in an install/ directory. If 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 command prints nothing, because no installer file remains on disk.

Storage layout

The database and the GLPI 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.

Database access and schema

MariaDB listens on the loopback interface only. This image never opens port 3306 to the network, 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. The password for this user is generated at build time and stored in /var/www/glpi/config/config_db.php. That file is outside the web root, because the nginx document root is /var/www/glpi/public, so it is never served.

Inventory, email and LDAP

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

Inbound email collectors turn replies and new mail into tickets. Configure them under Setup > Collectors. Configure outbound notification mail under Setup > Notifications.

The php8.3-imap extension is not installed by default. If your collectors need IMAP rather than the built-in socket transport, install the extension and restart PHP FPM.

Configure LDAP and Active Directory authentication under Setup > 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.

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 that points at the instance and port 443 open in the security group, certbot obtains a certificate and rewrites 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 the GLPI base URL so that generated links and notification emails use the HTTPS address. Set it under Setup > General > Base URL of the application.

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

Backup and maintenance

Back up two things: the glpi MariaDB database, and the GLPI 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

Both data tiers sit on their own EBS volumes, so an EBS snapshot of the two data volumes is an equally valid backup. It 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. Read the GLPI release notes before you upgrade the application. A GLPI upgrade replaces the code tree under /var/www/glpi and then runs php bin/console database:update, so take a database backup and an EBS snapshot first.

Troubleshooting

Symptom Check

Sign-in page does not load Run systemctl status nginx php8.3-fpm, then sudo tail /var/log/nginx/error.log

Sign-in is rejected for glpi Confirm that you are using the value from GLPI_ADMIN_PASSWORD in /root/glpi-credentials.txt on this instance. Every instance has its own

Credentials file shows only the unset marker text instead of a password First boot has not finished. Check systemctl status glpi-firstboot and sudo journalctl -u glpi-firstboot

Links or notification emails point at the wrong address Set Setup > General > Base URL of the application to the address your users use

Database errors after an upgrade Run sudo -u www-data php /var/www/glpi/bin/console database:update

Slow dashboards on a large estate Increase the instance size, and confirm that the cron entry from step 10 is running so that GLPI scheduled maintenance completes

Support

SecureAnyCloud supports this image. 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. SecureAnyCloud is not affiliated with the GLPI project or Teclib'. All product and company names are trademarks or registered trademarks of their respective holders.

Deploy on AWS

Launch GLPI on AWS with 24/7 support from SecureAnyCloud.

View on Marketplace

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on AWS