Part 7 · Platform, hosting and artificial intelligence

Fleet updates

Track the update state of every machine in the fleet, read its agent's reports, and order updates applied remotely.

Symbifox 18.0 (September 2026 catalogue) · Modules: Hébergement: Mises à jour du système · Revised 2026-09-12

A fleet machine accumulates pending packages, an installed kernel it has not booted yet, an end of support that is approaching and a disk that fills up. This chapter covers the five screens that make all of it visible, machine by machine, and the order that applies updates without opening a session on the machine. It is for the person who runs the fleet, for their own organization or for clients. The goal: no machine ever goes quiet without someone knowing.

Overview#

These screens live inside the Hosting management application, under Hébergement › Infrastructure › Parc client (hosting, infrastructure, client fleet). They add to the fleet inventory rather than replace it: a machine remains a fleet record, with its warranty, serial number and assigned user.

Five notions are enough to read every screen.

• Machine: the physical object, the one with a serial number and a warranty. That is the fleet record.
• System: one installation on that machine. A dual-boot laptop carries two systems, and each has its own kernel, its own package manager and its own backlog.
• Agent: the small program installed on the machine. It measures the state and files it in Symbifox, then asks whether an order is waiting for it.
• Report: one timestamped measurement, with the detail of the packages pending at that moment.
• Order: a request to apply updates on one system, dropped into a queue that the agent comes to empty.

A machine's state is the worst of its systems. A laptop whose Linux side is up to date and whose other side has not spoken for six days is not up to date: it is silent.

Here is the overview screen on the Boréal demo, grouped by state.

What sets the approach apart: a missing report is an alert, never a silence. A machine that stops talking flips after forty-eight hours into a state that shows up in red, exactly like a machine two hundred packages behind. And a package count is never displayed without the date of the report that produced it, because a zero from three weeks ago does not mean what a zero from today means.

Configuration#

Access and rights#

The two groups of the hosting application also govern these screens.

The enrolment code is readable only at the second level. That is deliberate: it is valid for one machine, and for thirty minutes it grants the right to file reports.

Settings#

There is nothing to set in Symbifox. The cadences are fixed, and the only decision that matters is taken on the machine itself, not here: remote application stays closed until a consent file has been placed by hand on the machine.

Base data#

Only one thing has to exist first: the machine's record. The agent never creates a fleet record, it only fills in one that a person created. If the machine is not in the fleet yet, create it under Hébergement › Infrastructure › Parc client › Tous les postes (all devices).

Getting started#

This walkthrough installs the agent on a machine and takes you to its first report.

1. Go to Hébergement › Infrastructure › Parc client › Tous les postes and open the machine to track.
2. Open the Mises à jour (updates) tab.
3. Select Générer un code d'enrôlement (generate an enrolment code). A notification shows the code. It lasts thirty minutes, and covers one system.
4. On the machine, as an administrator, run the installer shipped with the module, passing it your Symbifox address and that code.
5. The installation drops the agent, exchanges the code for a token specific to that machine, then takes a first report.
6. Come back to the record. The Mises à jour tab shows the state, the date of the last report and the number of systems.
7. Go to Hébergement › Infrastructure › Parc client › Systèmes suivis (tracked systems) to see the system that just appeared.

Here is the Mises à jour tab of one of Boréal's servers, once the agent is in place.

Common tasks#

Read the fleet state on one screen#

This screen answers one question: where to look first.

1. Go to Hébergement › Infrastructure › Parc client › État des mises à jour (update state).
2. Leave the grouping by state in place.
3. Open the Sécurité en attente (security pending), Muet (silent) and Compte inconnu (unknown count) groups before the others.
4. Open a machine to see its systems.

Machines without an agent do not appear here: this screen shows only what is tracked.

Follow systems rather than machines#

A machine aggregates, a system measures. When you are after the cause rather than the alert, switch to systems.

1. Go to Hébergement › Infrastructure › Parc client › Systèmes suivis.
2. Keep the grouping by machine, so both sides of a dual boot read together.
3. Add the Écart au relevé précédent (change since the previous report) column if you are following how a backlog grows.

On the demo, machine BOR-PC-014 carries two systems: the Linux side, up to date, and the Windows side, Non suivi (not tracked), for want of an agent.

Spot what needs a decision#

1. Go to Hébergement › Infrastructure › Parc client › Systèmes à regarder (systems to watch).
2. Work the list from the top. It keeps only the systems that are silent, whose count is unknown, that await a security fix or that await a reboot.

This list is empty when all is well. It is the only screen in this chapter whose emptiness is good news.

Read a report and its packages#

A report says what the machine measured, to the second, and what was still pending at that moment.

1. Go to Hébergement › Infrastructure › Parc client › Relevés de mise à jour (update reports).
2. Open the report you want, or go through a system's Relevés (reports) tab.
3. Read the Mises à jour block for the count, the Redémarrage (reboot) block for the kernel, the Disque (disk) block for the room left.
4. Open the Paquets en attente (pending packages) tab for the detail, name by name.

Allow remote application on a machine#

Three consents are needed, and all three are required: a person creates the order, the server checks that the machine has declared its agreement, and the machine checks its own consent file at the moment of acting.

1. On the machine, as an administrator, create the consent file.
2. Enable the regular poll, so the agent comes and asks whether it has an order.
3. Wait for the next report.
4. On the system's record, check that Application autorisée (remote application allowed) is ticked and that a blue banner says so.

To close it again, delete the file on the machine. The effect is immediate: the agent turns the next order down, and Symbifox withdraws the authorization from the record as soon as it hears about that refusal.

Order updates applied#

Prerequisite: the system must be tracked and must have declared its consent.

1. Go to Hébergement › Infrastructure › Parc client › Ordres de mise à jour (update orders), then select Nouveau (new).
2. Choose the Système (system) to target.
3. Choose the Portée (scope): Sécurité seulement (security only), Toutes les mises à jour (all updates), Paquets nommés (named packages) or Redémarrer seulement (reboot only).
4. For Paquets nommés, enter the names separated by spaces or commas.
5. Choose Redémarrer ensuite (reboot afterwards): Jamais (never), Si la machine le demande (if the machine asks for it) or Toujours (always).
6. Fill in Pas avant (not before) to hold the order until a quiet hour, or leave it empty for straight away.
7. Save. The order joins the queue and the machine will take it at its next poll.

Pull an order from the queue#

1. Open the order while it is still En file (queued) or Pris en charge (claimed).
2. Select Retirer de la file (pull from the queue).
3. Check that the order moves to Périmé (expired) and that the reason is recorded.

An order that has already been applied cannot be pulled: it happened.

Make sense of a refused order#

An order that fails always carries the machine's own words, in the Issue (outcome) block.

1. Open the order in state Échoué (failed).
2. Read the Code de sortie (exit code) and the Sortie de la machine (machine output).
3. Act on the machine, then create a new order if needed.

On the demo, the Clinique dentaire Rosemont workstation refused because its consent file does not exist. The order went out, the machine said no, and the refusal is written down.

Revoke a system's agent#

1. Open the system under Systèmes suivis.
2. Select Révoquer l'agent (revoke the agent) and confirm.
3. That agent's next report will be refused, and the system stops being tracked.

Use this when a machine leaves the fleet or changes hands. Putting it back in service takes a new enrolment code.

Schedule maintenance on a machine#

A scheduled maintenance could target a hosted service, never a machine. It can now target a machine, and even one side of a dual boot.

1. Go to Hébergement › Maintenance › Maintenances planifiées (scheduled maintenance), then select Nouveau.
2. Choose the Correctif de sécurité (security patch) type.
3. Fill in the Machine, and the Système if the work concerns one side only.
4. Choose the frequency and the first due date, then save.

The client on the record follows from the machine, and the work joins the other deadlines in the hosting application.

The menus, one by one#

The five entries live under Hébergement › Infrastructure › Parc client, after the inventory screens.

• Hébergement › Infrastructure › Parc client › État des mises à jour: the list of tracked machines, grouped by state. Useful columns: the reference, the client, the number of Systèmes, the État des mises à jour as a pill and the Dernier relevé (last report). This is the chapter's entry screen.
• Hébergement › Infrastructure › Parc client › Systèmes suivis: one system per row, grouped by machine, with the package count, the security share, the reboot flag and the date of the last report. Red rows need a decision, amber rows need attention.
• Hébergement › Infrastructure › Parc client › Systèmes à regarder: the same list, reduced to systems that are silent, whose count is unknown, or that await security fixes or a reboot.

• Hébergement › Infrastructure › Parc client › Relevés de mise à jour: the full history, newest first, across every system. The filters by system and by date serve to follow how a backlog grows.
• Hébergement › Infrastructure › Parc client › Ordres de mise à jour: the queue and its history, with each order's state, what it targeted and what it changed.

Reference#

Fields on the System form#

Fields on the Update order form#

Reports and exports#

No printed report. The five screens export like every Symbifox list, and a report's Charge utile (payload) tab keeps the raw measurement exactly as the machine sent it.

Automations#

Three mechanisms run on their own, and a fourth comes from a satellite module.

On the machine side, the agent reports once a day and on waking, and polls the queue every minute wherever consent exists.

Public pages and portal#

No portal page. The module exposes token-protected filing addresses that only the agent uses: the token authenticates a machine, never a person, and it can do nothing but file a report on the record it names.

Modules that extend this application#

Understanding#

Why the machine talks and the centre listens. Symbifox has no route into the fleet machines, and wants none. The agent files its reports and asks whether it has an order. That settles three things at once: machines you cannot reach from outside, the laptop that is only on part of the time, and the attack surface, since a compromised instance holds no key into the fleet.

Why three consents. The first is the person who creates the order. The second is the server, which refuses to hand an order to a machine that has not declared its agreement. The third is the machine itself, and it is the only one that truly counts: it is local, placed by hand, and withdrawn without going through Symbifox. The first two catch an operating mistake, the third protects the machine even if Symbifox falls into the wrong hands.

Why a count is never guessed. After a successful application, the counters on display are still the ones from before: the agent reports the outcome of the order, not a fresh measurement. Rather than subtract an estimate, the record shows a warning saying its figures predate the order. A recent agent files a report right after and the warning clears within seconds; an older agent leaves the gap open until the next daily run.

Why a count can read as unknown. When the package manager does not answer, the machine does not return zero: it says it could not count, and the state becomes Compte inconnu. That is the difference between a healthy machine and a machine whose tooling is broken, and it is exactly the kind of failure an all-green board usually hides.

What a report does not do. It does not refresh the machine's package index: it reads what the machine already knows. On a machine whose index has not been refreshed for weeks, the count is that many weeks old, and keeping it current is the job of the local auto-updater, whose mode is reported for that very reason.

Which systems are covered. The agent covers the package managers of the common Linux distributions. A Windows side can exist as a system record, and it then reads Non suivi: it counts in the inventory, not in the monitoring. Saying so is better than implying a coverage that does not exist.

Troubleshooting#

See also#

• Hosting management
• Settings and brand identity
• To-do, Notepad and Timer
• Seats