GLPI maintenance mode and console administration

How GLPI maintenance mode and console administration fit day-to-day operations

When your team runs GLPI in its own infrastructure, the moment you need to block user access during a database change, a file replacement or a plugin update is the moment day-to-day administration matters most. Maintenance mode and the `bin/console` command line are the two controls that let you close the door on users and run routine checks without improvising. Use them as a standard part of change work, not as an emergency tool. The console is GLPI's administrative entry point, and it is the same tool the upgrade procedure relies on when it runs php bin/console db:update, so a team that already knows it for upgrades will recognize most of the pattern.

Maintenance mode is appropriate when a change touches data or code that users would otherwise read or write mid-task: a schema update, a restore from backup, a plugin change, or a web server reconfiguration. Decide in advance who announces the window, how long sessions are allowed to finish, and who is authorized to switch the mode back off. Before any change, confirm the exact subcommands and options on your installed version by running the console's help output, since command names and options can differ between GLPI 10, 11 and 12. Also check that the account running the console has the same file ownership as the web server user, otherwise cache and configuration files can end up with the wrong permissions after a run.

Routine checks such as system status and schema integrity should be run on a schedule, recorded and compared over time, not only when something breaks. Treat each console command as a change with its own record: note the version, the time, the output and any follow-up. Ask your platform team to confirm whether the check is read-only on your version before running it in production, and to test it first on a restored copy of the database. Keep a short runbook that lists which commands are safe during business hours, which require maintenance mode, and who approves each one. The GLPI installation docs describe the update sequence that these checks should fit into.

Which console task fits which change

This table compares the bin/console command families for maintenance mode, system status, schema integrity, database updates and user management. Read each row as a question: what are you about to change, and which task matches it. The main takeaway is that only some of these tasks alter data or application state, so confirm the backup and the window before running any of them.

Task	Purpose	Risk to live users	Confirm before running
Maintenance mode on or off	Blocks regular user access while files, plugins or the database are changed	Low to moderate: users are locked out, and a forgotten switch-off leaves the service down	Change window is announced, the team knows who switches it back on, and the exact command name for your installed version
System status check	Reports the GLPI version, environment, database connection and whether maintenance mode is active	None: read-only	Run it before and after each change so you have a baseline to compare against
Schema integrity check	Compares the database schema with what the installed version expects and reports differences	None to low: reports drift, but fixing it is a separate step	A current database backup exists and you have recorded the output for your change record
Database update	Applies pending schema and data changes after application files are replaced, as the update procedure describes	High: changes the production database and is hard to reverse without a restore	Files, database and config keys including glpi.key and glpicrypt.key are backed up, and a test restore has succeeded
User management commands	Lists, creates, modifies or deactivates accounts and sessions from the command line	Moderate: an error can lock administrators out or grant unintended access	The target account, the change request that authorizes it, and a second administrator who can reverse it
Plugin state after update	Plugins are suspended after a new version is detected and must be reactivated after major updates	Moderate: features stop working until plugins are checked and reactivated	Plugin compatibility with the target version is confirmed with each plugin's maintainer before reactivation
Command names and options	The exact syntax of each console task differs between releases	Moderate: a misremembered command can run a different task than intended	Check the command list with the help option on the installed version, and use the official installation docs as the reference

How to run a maintenance window safely

This sequence protects the database and configuration before anything changes, keeps regular users out while the instance is in flux, and closes only after logins and background work have been checked. Each step ends with a check, so the window leaves a record that the change completed cleanly.

Confirm backups and config keys
Before touching the instance, confirm that a current database dump, a copy of the files directory and a copy of the config directory exist and can be read. The config directory holds glpi.key and glpicrypt.key, and the update procedure in the GLPI installation docs names them explicitly, so check that both files are present in the copy. Done when you have restored the database dump to a separate host or confirmed that a restore has been rehearsed, and the change does not begin until all three artifacts are confirmed.
Record the starting state
Capture the current GLPI version, the list of active plugins, the output of the status check and the automatic actions that are scheduled. Run php bin/console list to confirm which console commands your installed version offers, because command names can differ between releases, and write the names you will use into the change record. Done when the record exists and a second person can read it and compare it with the state after the change.
Enable maintenance mode
Turn on maintenance mode from bin/console, then open GLPI in a private browser session as a non-administrator user. Confirm that the session is turned away and sees the maintenance notice rather than the working interface. Ask the service desk to pause new ticket work and tell users when the window opens. Before continuing, confirm that no automatic action is in the middle of a run. If you cannot find the maintenance option in your version, check the command list again before proceeding.
Run status and schema integrity checks
While maintenance mode is on, run the system status command and the database schema integrity check available in bin/console. The status output reports the environment and configuration checks that GLPI performs, and the integrity check compares the live schema with the one the installed version expects. Treat any reported mismatch as a stop condition and resolve it first, since a schema problem found after an update is harder to separate from the change itself. Done when both checks return clean output and the results are saved to the change record.
Perform the update or change
Apply the change itself. For a version update, follow the update procedure in the GLPI installation docs: replace the application files while keeping the config directory and its keys in place, then run php bin/console db:update to migrate the database. For GLPI 11 and later, plugins are suspended when a new version is detected, so expect them to show as inactive afterwards. Reactivate each plugin only after confirming that it supports the new release, and treat major updates as the point where reactivation needs the closest review. Done when db:update completes without errors and the reported version matches the target.
Disable maintenance mode and test logins
Turn maintenance mode off from bin/console once the change is complete and the status check passes again. Sign in with a standard user account and an administrator account from separate browsers, open a test ticket and confirm that authentication goes through the method you expect, such as the internal database or LDAP. Done when both test accounts reach their profiles and the test ticket saves. If either login fails, return the instance to maintenance mode and investigate before opening it to users.
Verify scheduled actions and notifications
Confirm that automatic actions run after the window, starting with the notification queue and mail collection if your instance uses them. Check the automatic actions list for entries that failed or stopped, then send one test notification to confirm that outbound mail leaves the queue. Done when the queue drains as expected, no action shows an error from the change, and the change record is closed with the result of each check.

Security risks of console and maintenance access

The bin/console tool and maintenance mode give whoever uses them broad control over a GLPI instance, its data and its encryption. The cards below cover the access decisions, the output that can leak configuration, the keys that must survive any recovery, and the audit trail that shows what changed and when.

Limit shell access to bin/console

Anyone who can run php bin/console as the web server user or as root can read configuration, change users and alter the database schema. Restrict shell accounts to a small named group of platform administrators, and remove access for people who only need the web interface. Confirm which OS account runs the console on your install and that it matches the account that owns the GLPI files.

Watch command output and logs

Console output, shell history and log files can reveal database hostnames, paths, plugin names and error details that help an attacker plan a further step. Treat them as sensitive. Avoid pasting full command output into tickets or chat, and set log access to the same group that holds console access.

Protect glpi.key and glpicrypt.key

The glpi.key and glpicrypt.key files encrypt stored secrets, and losing them makes encrypted data in the database unreadable after a restore. Anyone who copies them along with a database dump can recover those secrets. Store the keys with restricted file permissions, keep an offline copy under separate control, and never leave them in a public or world-readable directory.

Keep maintenance mode narrow

Maintenance mode blocks regular users while administrators work, but it does not replace access control. Confirm who may enable and disable it, and make sure the window is short and documented. A forgotten maintenance flag can leave an instance blocked, and a flag changed by an unknown person can signal an intrusion.

Record every maintenance action

A short log of who ran which command, when, and why gives you a basis to investigate unexpected changes to users, profiles or schema. Record the console command, the operator, the change ticket and the result. Keep these records outside the GLPI database where a bad command cannot erase them.

Confirm session and re-authentication features

The GLPI 12.0.0 release notes describe a view of active user sessions with revocation and step-up authentication for certain administrative actions. Whether these controls apply to console tasks and how they behave on your version is something to confirm in your own test instance before you rely on them for control.

When user management from the console beats the web interface

The console is the better tool when the web interface is no longer reachable for the people who need it, or when the same change must be applied to many accounts the same way. The most common case is a locked-out administrator: if the only super-administrator account is locked, its password is lost, or an authentication change has broken web login, bin/console run on the server is the path back in. The same applies to scripted changes, such as disabling accounts for leavers from an approved list or correcting a profile assignment across a batch of users. Before you use it, confirm the exact user management commands and their options for your GLPI version with the GLPI documentation for that release, because the command set is not something to assume from memory or from an older guide.

The trade-off is auditability and error risk. A web change is recorded in the GLPI history with the acting user, while a console change run under a shell account may leave no GLPI-side record unless you capture the command, the operator and the time in your own change log. A console command also acts directly on whatever matches its selection, so a wrong filter can touch more accounts than intended. Agree in advance who may run these commands, require a ticket or change reference for each run, and test the filter in a restored copy of the database before you run it against production.

Authentication order changes which accounts a console change reaches. GLPI tries the internal database first, then LDAP directories, then IMAP mail servers, then other external methods such as REMOTE_USER. A user who exists in both the database and a directory may be authenticated by the database entry, so changing the password or status of the database record does not necessarily change how that person signs in. Check, for each account in scope, which source authenticates it, and record that in the change ticket so a successful console change does not leave the user able to sign in through another path.

Limits to confirm in your environment

The maintenance and console commands behave differently across GLPI releases, database engines and plugin sets. The cards below list what to check against the documentation for your exact version before a change window, not after.

Supported PHP and database versions

The README on the main branch lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later, while the installation docs for GLPI 11.0 list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6. Only MySQL and MariaDB are supported. Confirm the minimums for the exact release you run, because a maintenance window can fail on a version mismatch before any console command executes.

Command names across releases

Console commands such as php bin/console db:update are documented for specific releases, and option names can change between major versions. Run php bin/console list on your own installation and compare the output with the documentation for that version. Treat any command copied from a blog or older guide as unverified until it matches your list output.

Maintenance mode and cron actions

Confirm how your environment behaves when maintenance mode is on and automatic actions run from a system cron job. Check whether scheduled actions such as mail collection and notifications pause, queue or continue, and whether users see a maintenance page while those jobs run. Test this on a staging copy because the answer determines whether notifications are delayed or lost during the change.

Plugin suspension after version changes

Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates. Before the change, list active plugins and their versions, and confirm that each has a release compatible with the target GLPI version. Plan who reactivates them and in what order, since a suspended plugin can hide forms or features users rely on.

Console user management scope

Confirm which user management tasks your release supports from bin/console and which still require the web interface. Verify how password resets, account activation and profile changes are logged, and whether a console change is subject to the same authorization rules as a web change. Record the result so auditors can trace who changed an account and through which path.

Schema check output and backups

Schema integrity checks and database updates can alter tables, so confirm what the check reports, what it repairs automatically and what it only lists. Confirm that you hold a verified database backup and the glpi.key and glpicrypt.key files before running any write operation. Keep the check output with the change record for later review.

Questions teams ask before running GLPI console maintenance

How much effort does a GLPI maintenance window need?

Effort depends on what the window touches, not on the console commands themselves. A window that only enables maintenance mode, checks system status and runs an integrity check is short. A window that also updates the application files, runs php bin/console db:update and reactivates plugins needs a rollback plan, a verified backup and someone available to test the results. The main drivers are the size of the database, how many plugins are installed, how many users depend on the instance during business hours and whether the change crosses a major version. Ask your team to list each step and its owner before agreeing on a window.

Can an internal admin run GLPI console maintenance alone?

Often yes, for routine tasks such as checking status, toggling maintenance mode and running integrity checks, provided the admin has shell access to the server and knows the GLPI document layout. Tasks that change the schema, replace application files or touch plugins carry more risk and benefit from a second person who can review the steps and verify the result. Confirm internally who holds root or web server user access, who can approve a production change and who will test logins and ticket creation afterwards. A partner is useful when the team lacks time or experience with PHP applications, not because the commands are out of reach.

What does the team need before starting a GLPI maintenance task?

Before any console change, the team should have:

A recent, tested backup of the database, the files directory and the config directory, including glpi.key and glpicrypt.key
A test environment running the same GLPI version, PHP version and plugin set as production
Shell access with a named account and a record of who ran each command
A written rollback path, including how to restore files and the database
A communication plan that tells users when the instance will be unavailable

The update procedure in the installation documentation starts with backups for this reason. Confirm each item against your own environment rather than assuming the backup job is complete.

How long does a GLPI maintenance window typically run?

No duration can be stated here without knowing your environment. The length of a window grows with database size, the number of plugins that must be reactivated after a major update and the time needed to validate integrations such as LDAP, mail and inventory. Large databases take longer to dump and restore, so backup time often sets the minimum window. Test the same steps in a staging copy, record the elapsed time for each step and use that record to set the production window. Ask any partner to base its schedule on your measured numbers, not on generic estimates.

Which GLPI console tasks need a change window and which can run live?

Read-only checks such as system status and schema integrity checks can usually run on a live instance during quiet hours, since they do not change data. Enabling maintenance mode, updating application files and running database updates should be planned, because users cannot safely work during those steps. Running a forced automatic action may affect notifications and queued mail, so check the queue before running it. Document which commands your team treats as safe to run live and which require approval.

When should a team bring in outside help for GLPI maintenance?

Bring in outside help when a change involves a major version move, plugins that have no clear upgrade path, a large or heavily customized database, or integrations with identity and mail systems that your team has not tested before. Help is also useful when a maintenance window failed and the team needs a structured recovery. DeployOpen plans, implements, upgrades, documents and supports self-hosted open-source platforms, including GLPI, inside your own infrastructure. Work is usually fixed-scope and agreed in writing, and ongoing support is available as a retainer. Ask for a written scope that names the commands, environments and acceptance checks included.

Who pays for GLPI console maintenance, and what recurs?

Your organization pays for its own staff time, test infrastructure, backup storage and any change approval process, whether work is done in-house or by a partner. Fees for an outside partner depend on the written scope, so ask for line items for planning, execution, testing and post-change support. Most console tasks are recurring because GLPI releases new versions and databases keep growing, so budget for routine checks as an ongoing activity rather than a one-time project. The GLPI project publishes its own release history on GitHub, which helps you plan the cadence.

How DeployOpen approaches GLPI console administration in your environment

DeployOpen writes the console runbook for your GLPI instance before anyone runs a command on production. The runbook names each bin/console task your team will use, the maintenance window in which it runs, who may enable maintenance mode, the check that confirms the instance is healthy afterward, and the rollback step if it is not. We agree the runbook in writing as part of the fixed scope, so your operators know which steps are theirs and which belong to the engagement. Commands are documented against the GLPI version you actually run, because the console surface changes between the 10, 11 and 12 lines and the update procedure in the installation docs is version specific.

The commands themselves depend on your installed release, your database engine and how your web server and PHP are set up, so DeployOpen confirms each one on a staging copy that mirrors production before it appears in the runbook. We check the console help output for the version in your environment, record the exact options, and note any task that must be preceded by a backup of the database, the files directory and the config directory with its keys. Ask us to show you the runbook template and the verification steps it contains, and ask who signs off changes to it. Those answers matter more to your audit trail than the length of the document.

Ongoing work follows the same pattern. Many organizations engage DeployOpen for a single fixed-scope piece, such as writing the runbooks and training your operators on them. Others place the instance under a retainer that covers version reviews, console task checks after each GLPI release, and support when a maintenance window runs long. Ask for the scope, deliverables, timelines and any recurring terms in writing before work starts, and confirm which items recur and which are one-time. Your own team remains responsible for approving changes in your environment and for the platform owner role. Confirm these responsibilities during scoping so the runbook and the support terms describe the same division of work.