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, Hébergement: Mises à jour système : section du digest · Revised 2026-10-18

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. The screens call it an update job.

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 Updates tab.
3. Select Generate an enrollment 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 Updates tab shows the state, the date of the last report and the number of systems.
7. Go to Hébergement › Infrastructure › Parc client › Tracked systems to see the system that just appeared.

Here is the Updates 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 › Update status.
2. Leave the grouping by state in place.
3. Open the Security updates pending, Silent and 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.

Watch the fleet from the dashboard#

The IT fleet card sums up the fleet in four numbers, without opening the hosting application.

1. Open Tableau de bord (dashboard) in the main bar.
2. Find the IT fleet card, right after the hosting card. Its title carries the number of tracked systems.
3. Read the four lines in order: Silent (48 h), Unknown count, Security updates pending, Reboot required.
4. Select a line to open the systems in that state, or the card's title to open the systems that need a look.

Each number counts exactly the list its click opens. The first two lines come first because they are the ones saying that nobody is measuring any more. The card's footer gives the time of the latest report, in your time zone; when there is no report yet, it says so in red, because a zero without a date reads like a zero from today.

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 › Tracked systems.
2. Keep the grouping by machine, so both sides of a dual boot read together.
3. Add the Change since 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, Not tracked, for want of an agent.

Spot what needs a decision#

1. Go to Hébergement › Infrastructure › Parc client › Systems to check.
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 › Update reports.
2. Open the report you want, or go through a system's Reports tab.
3. Read the Updates block for the count, the Reboot block for the kernel, the Disk block for the room left.
4. Open the 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 Remote apply 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 › Update jobs, then select New.
2. Choose the System to target.
3. Choose the Scope: Security only, All updates, Named packages or Reboot only.
4. For Named packages, enter the names separated by spaces or commas.
5. Choose Reboot afterwards: Never, If the machine requires it or Always.
6. Fill in 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 Queued or Claimed.
2. Select Remove from queue.
3. Check that the order moves to 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 Outcome block.

1. Open the order in state Failed.
2. Read the Exit code and the 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 Tracked systems.
2. Select Revoke 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 › Tous les horaires (all schedules), then select New.
2. Choose the Correctifs de sécurité (security patches) type.
3. Fill in the Fleet endpoint, and the Target system 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 list's Target column names the machine. The work joins the other deadlines in the hosting application: the dashboard's maintenance counters, the En retard (overdue) and Cette semaine (this week) lists, and the summary email, which names the machine. It drops out once the machine is archived or retired from the fleet.

The menus, one by one#

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

• Hébergement › Infrastructure › Parc client › Update status: the list of tracked machines, grouped by state. Useful columns: the reference, the client, the number of Systems, the Update status as a pill and the Last report. This is the chapter's entry screen.
• Hébergement › Infrastructure › Parc client › Tracked systems: 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 › Systems to check: 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 › Update reports: 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 › Update jobs: 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 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#

The section stays quiet when all is well: a paragraph that repeats every morning that all is well stops being read. But a silent system always brings it out, with an opening sentence recalling that a missing report is not good news. It is read as each recipient: someone without access to hosting gets no section, and someone limited to some clients only sees those clients' systems.

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 Unknown count. 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 Not tracked: 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
• My desk, Dashboard and Progress
• Settings and brand identity
• To-do, Notepad and Timer
• Seats