Part 7 · Platform, hosting and artificial intelligence

Blue Fox OS workstations

Describe your Blue Fox OS fleet on one record, set exceptions, share machines, track and revoke machines, and hold disk passphrases in escrow.

Symbifox 18.0 (September 2026 catalogue) · Modules: Blue Fox OS Policy, Blue Fox OS Zero-Touch Install · Revised 2026-10-06

Watch it

Blue Fox OS is the workstation system that Symbifox installs and configures remotely. This chapter covers the Policy application, where a single record describes an organization's whole fleet: what gets installed, how the session is protected, what the desktop looks like, and who is allowed to set up a machine. It is written for the person who runs the fleet, and for the separate person who holds the disk passphrases. The goal: a new machine installs without anyone touching a setting, whether it serves one person or several. A change made in Symbifox then reaches the machines already in use.

Overview#

The Policy application has six menus. Five ideas are enough to read them.

• Organization record: the shared rules, one record per company. It holds installation, sign-in, security, the look of the session, applications and browser extensions.
• Per-person exception: an optional record that changes only what you fill in. Any field left blank falls back to the organization's rule.
• Machine: an installed workstation. It enrols itself during installation, in the name of whoever authorized the install or of a shared seat profile, then re-reads its policy every day.
• Shared seat: a machine that belongs to a profile rather than to a person. The profile describes a lab, where many people log in, or a pool of machines lent to one borrower at a time.
• Escrow: the disk passphrase, generated by the installer and stored encrypted in Symbifox. Only someone with the Custodian role can read it, and every read is written on the machine's record.

A personal machine always receives the merge of both levels: the organization record, with the person's exception on top. For lists (mounted folders, web apps, applications, extensions), the exception adds or removes items; it never replaces the whole list. A shared seat receives the organization record and its profile's settings, with nobody's exception, photo or time zone.

What sets this approach apart: a workstation is no longer something you configure, it is the reflection of a record. The automatic install file is served by Symbifox from that same record, and a change reaches machines in use at their next sync. A few settings stay as they were set at installation: the machine name, its language, its keyboard and the directory connection (see Understanding).

Configuration#

Access and rights#

Two roles, kept apart on purpose.

The Custodian right does not come with administration. Once the module is installed, nobody holds it, not even the administrator who installed it: it has to be granted explicitly, and that step shows up in Symbifox's log. This is deliberate, so that "who can administer Symbifox" never quietly becomes "who can open every disk in the fleet".

Settings#

There is nothing to set under Settings. Everything lives on the organization record, under Policy › Org Defaults.

Passphrase escrow needs one step on the server: an encryption key stored outside the database, set by whoever administers the server. The help text under the Escrow disk passphrase checkbox says where it goes. Without that key, the installer does not attempt escrow and asks for a typed passphrase, as before.

Base data#

Three things must exist before the first installation.

1. The organization record, with at least the domain and the system image (Zero-Touch tab). With no image, automatic installation is turned off for that organization.
2. The organization's identity provider, whose addresses and the installer's OIDC Client ID go in the Authorization and Zero-Touch tabs. It is what asks the installing person for two-factor sign-in.
3. Symbifox users for the people who will receive a workstation: internal, active users attached to the record's company. A personal machine always enrols in the name of an existing user. A portal account, an archived account or an account from another company can never set up a workstation, whatever the setting.

The application and extension catalogues are optional: without them, a machine gets the base already built into the system image. Shared seat profiles are optional too. They require the organization to sign people in through the directory: directory accounts, not Symbifox users, log in on them.

Getting started#

This walk-through creates an organization record and takes you to a first enrolled machine.

1. Go to Policy › Org Defaults, then select New.
2. Pick the Company and enter the Domain: the address the installing person will type when the machine starts, without "https://" or "www".
3. On the Install tab, check the Locale, Timezone and keyboard; on the Zero-Touch tab, fill in the OCI Image, the identity provider's addresses and the OIDC Client ID.
4. On the Authorization tab, choose who may set up a workstation, then save. A new record starts on Members of selected groups with no group: nobody can set up a machine until you choose the Authorized groups.
5. Start the new machine from the Blue Fox OS USB key, pick automatic installation in the boot menu and type the domain.
6. On the installing person's phone, scan the code shown on the machine's screen and sign in. The installation carries on by itself.
7. Come back to Policy › Machines: the machine is listed, with its name, its user and its first sync.

Common tasks#

Create an organization record#

An organization has exactly one record. Symbifox refuses a second one for the same company.

1. Go to Policy › Org Defaults, then select New.
2. Pick the Company.
3. Enter the Domain. Left blank, it is taken from the company's website.
4. Work through the tabs in order: Authorization, Install, Zero-Touch, Login, Policies, Session, Apps, Browser.
5. Save.

The record is served to machines straight away. When the instance holds several companies, each record needs its own domain: an address that matches no record gets a refusal, never another organization's policy.

Choose who may set up a workstation#

1. Open the organization record, Authorization tab.
2. Under Who can provision, choose Members of selected groups, Explicit users or Any internal user of the company.
3. Depending on the choice, fill in Authorized groups or Authorized users.
4. If needed, set Identity claim: the piece of information from the identity provider (email, username or identifier) compared with the login of Symbifox users.
5. Save.

A new record starts on Members of selected groups, with no group: it authorizes nobody until you choose one. Existing records keep their choice. Whatever the mode, portal accounts, archived accounts and accounts from another company are refused.

The person who signs in is matched to a user through the Identity claim alone, which must match their login exactly (ignoring case). No matching user, or more than one, and setup is refused.

The Require install client in token box adds a check: the sign-in must have been made for the workstation installer, not for another application of the same identity provider. It is checked by default on a new record; existing records keep their value. It needs a provider that issues JWT tokens, and the OIDC Client ID on the Zero-Touch tab: without it, every setup is refused. Checked or not, the directory Bind password only goes to a sign-in made for the installer. With directory sign-in, a provider without JWT tokens will therefore not do: the machine would not receive that password.

This rule is checked again at every sync. Removing someone from the authorized group is enough to cut off their machines: they keep the last policy they received, but get no new one. A shared seat depends on no person: it is its profile that has to stay active.

Set installation, language and keyboard#

1. Open the Install tab.
2. In the Regional block, check the Locale, Timezone and Hostname Pattern. "{username}" in the pattern is replaced with the person's username.
3. Leave Root Mode on Locked.
4. In the Keyboard block, set both the Keymap and the XKB layout, then the XKB variant if needed.
5. Save.

Set sign-in and security#

1. Open the Login tab and choose the Login Mode: Local accounts, or the organization's directory accounts.
2. For the directory, fill in its address, its base and the service account that queries it. The Bind password is never displayed: type it only to replace it.
3. Leave Local recovery account checked unless your organization has decided otherwise.
4. Open the Policies tab. Set Allow offline login and its length in days, MFA required and Auto-lock (minutes).
5. Check TPM2 auto-unlock if the disk should unlock by itself at start-up, with no passphrase to type. Leave TPM2 PCRs at its default.
6. Check Escrow disk passphrase to put the passphrases of future machines in escrow.
7. Save.

An offline limit of zero never expires, and an auto-lock of zero is off. Escrow only applies to machines installed after it is turned on.

The Bind password reaches a machine only at installation: the sync never sends it. Changing it here therefore does not reach machines already installed, which keep the one they received until they are reinstalled. Bear this in mind before changing the service account's password in the directory.

Set the look of the session#

1. Open the Session tab.
2. Enter the Accent Color and the wallpaper address in Wallpaper Url.
3. Choose the Clock format: 24 h or 12 h (AM/PM).
4. Under Default mounts, add one line per Nextcloud folder to mount: a name, the remote path, the location on the machine.
5. Under Default PWAs, add the web apps to install, and check Pinned to pin them.
6. Save.

The clock adapts to the person on its own: when their time zone differs from the organization's, a second clock appears showing the organization's time. There is no setting for it.

Choose the installed applications#

The system image already includes Brave, Thunderbird, Nextcloud and Bitwarden. The record adds and removes on top of that base.

1. Open the Apps tab.
2. Under Default apps, add the extra applications to install.
3. Under Apps to remove, add the base applications to take out.
4. Save.

The picker first offers only the BF recommended applications. Remove that filter to choose from the whole catalogue. An application in both lists is removed: removal wins.

Maintain the application catalogue#

The catalogue is empty once the module is installed. It fills in one pass from Flathub, the application library Blue Fox OS uses.

1. Go to Policy › Flatpak Catalogue.
2. If the list is empty, add a first line by hand with an application's ID, for example "com.brave.Browser".
3. Tick a line, open the Action menu and select Sync Flathub.
4. Wait for the notification, which gives the number of applications added and updated.
5. Turn on the BF recommended toggle for the applications to offer by default.

The Action menu only appears once a line is ticked. The sync never touches your recommendation choices. It does not run on its own: run it again whenever you want a fresh catalogue.

Enforce browser extensions#

Enforced extensions are installed in Brave automatically, and the person cannot remove them.

1. Go to Policy › Browser Extensions to see the catalogue. It ships with Symbifox Signets, Symbifox Tokens and Bitwarden.
2. To add a Chrome Web Store extension, add a line with its name and its Extension ID: the 32 letters at the end of its store page address. Keep Source on Chrome Web Store.
3. Open the organization record, Browser tab.
4. Add the extensions to enforce, then save.

No extension is enforced out of the box. Symbifox extensions are served by your own instance. The Pass the instance address checkbox pre-fills your Symbifox address in the extension; access is still granted by the person.

Make an exception for one person#

1. Go to Policy › User Overrides, then select New.
2. Pick the User and the Company.
3. Fill in only what changes: colour, wallpaper, clock format, automatic disk unlock, language, time zone or keyboard.
4. Add extra folders, web apps, applications or extensions if needed.
5. Use Apps to remove and Browser extensions to skip to take away what the organization record enforces.
6. Save.

The time zone follows a three-step rule: the exception first, then the user's own time zone preference in Symbifox, then the organization record. Only fill it in here to pin a machine to a time zone that is not its user's. An exception never applies to a shared seat, even when the person logs in on it.

Show the person's photo at sign-in#

The workstation's sign-in screen shows the person's face. There is nothing to turn on.

1. Open the person's employee record in the Employees application.
2. Add a photo in PNG or JPEG format.
3. Wait for the machine's next sync.

Without an employee record, the user's photo is used. The initials avatar Symbifox generates by default is not sent, because the workstation cannot display it. A shared seat receives nobody's photo.

Get the automatic install file#

The install file is served by your Symbifox, from the organization record. Nobody needs to download it: the machine requests it when the domain is typed at start-up.

1. Open the organization record, Zero-Touch tab.
2. Check the OCI Image, the Tenant Display Name and the addresses in the OIDC device-flow bootstrap block.
3. To check it, open https://your-domain/blue-fox-install.ks in a browser, using the record's domain.
4. A plain text file appears: automatic installation is ready for that domain.

The file's language, keyboard and time zone come from the Install tab. A blank OCI Image turns automatic installation off: the address then answers that nothing is configured for that domain. The file holds no secrets.

Create a shared seat profile#

A profile describes a family of shared seats: a lab, or a pool of machines to lend. Before you start: the organization's Login Mode is the directory, and the groups that will log in exist in the directory.

1. Go to Policy › Shared Seats, then select New.
2. Enter the profile's name as its title, for example "Library lab".
3. Enter the Code: 2 to 32 lowercase letters, digits or dashes, for example "lab-library".
4. Choose the Kind, Lab (many people) or Loan (one borrower), then the Org.
5. Under Who logs in, enter the Groups allowed to log in: directory group names, separated by commas or spaces.
6. Under Session and Applications, set what differs from the organization: auto-lock, offline login, applications and extensions.
7. Save.

The profile's machines take their name from the Hostname Pattern. "{code}" becomes the profile code, and "{n}" a three-digit number that grows with each machine. Next Number shows which one comes next. A code is used only once per organization. For a loan profile, keep the groups to the IT staff: the borrower is added machine by machine. Check Allow offline login for a machine that goes home; leave it unchecked for a lab, always on the network.

To retire a profile, archive it (Action menu > Archive): its machines stop receiving their policy at their next sync, and no new machine can enrol under it. An archived profile stays in the list, with the Archived ribbon. A profile that has machines, even revoked ones, cannot be deleted.

Install a shared seat#

A shared seat installs like a personal machine, with its profile's code added. The installing person signs in as usual, but the machine does not become theirs.

Before you start: an active shared seat profile, and the right to set up a workstation for the person installing.

1. Start the new machine from the Blue Fox OS USB key.
2. In the boot menu, move to the automatic installation entry and press E to edit its boot line.
3. At the end of the line that starts the kernel, add "bfos.poste=" followed by the profile code, for example "bfos.poste=lab-library", then boot (Ctrl+X).
4. Type the domain, then have the install authorized on the phone, as for a personal machine.
5. Come back to Policy › Machines: the machine is listed under the name drawn from the profile.

On the machine record, Shared seat profile takes the place of User, and whoever installed it appears in Enrolled by. The machine receives its profile's policy, with nobody's personal settings. A malformed code is ignored: the machine then installs as a personal one, in the name of whoever authorizes. An unknown or archived code gets the policy refused: the machine installs on default settings, without enrolling.

For a loan machine, enter the borrower's directory username in Borrowers allowed to log in, on the machine record. The machine opens to that person at its next sync; clear the field when it comes back. With the School application, lending a machine fills and clears this field for you. A shared seat with no group and no borrower opens to nobody from the directory: only the Local recovery account, if kept, can still log in.

View enrolled machines#

1. Go to Policy › Machines.
2. Read Last seen: the date of the last successful sync.
3. Use the Never synced filter to find enrolled machines that have never re-read their policy.
4. Group by User to see all of one person's machines, or by Shared seat profile for those of a lab or a loan pool.
5. Use the Shared seats filter to keep only shared seats.

A reinstall creates a new record: the old one stays, and Last seen tells you which one is still alive. Revoke the old one.

A machine belongs either to a person or to a shared seat profile, never both. Enrolled by keeps whoever authorized the install: for a personal machine, the same person; for a shared seat, the installer, who does not become its owner. A machine record stays attached to its owner and organization: nobody else can take it over in their own name. To hand a personal machine to someone else, reinstall it and have that person authorize the setup: the machine gets a new record in their name. Then revoke the old record.

Revoke a machine#

Revoke a workstation that is lost, stolen, replaced or leaving the organization.

1. Open the machine under Policy › Machines.
2. Select Revoke and confirm.
3. Check for the Revoked ribbon on the record.

The machine is cut off at its next sync and can no longer re-enrol. Revoking erases nothing on the machine: it keeps its last known policy. Revoked machines are listed under the Revoked filter.

Read a passphrase held in escrow#

Before you start: you need the Custodian right. The passphrase is for when the disk no longer unlocks by itself, for example after a motherboard replacement.

1. Open the machine under Policy › Machines. The Escrowed passphrase box must be checked.
2. Select Reveal passphrase.
3. Read the warning and confirm.
4. Select the passphrase in the window to copy it, or read it out.
5. Select Close as soon as you have what you need.

The read is recorded before the passphrase is even shown: Reveals goes up by one, and Last reveal and Revealed by record the time and your name. The window has no copy button, by design.

The Disk passphrase window only opens through that button, and only the person who opened it can see it. After five minutes it no longer shows the passphrase: select Reveal passphrase again, which counts as a new read.

Remove a passphrase from escrow#

Remove it once the disk has been destroyed or wiped: keeping the key to a disk that no longer exists has nothing but downsides.

1. Open the machine, as a Custodian.
2. Select Remove escrow and confirm.

Removal is permanent. The passphrase cannot be recovered afterwards. This is the only way to erase an escrowed passphrase: an existing deposit is never replaced, not even by the person the workstation belongs to.

Give someone the Custodian role#

1. Turn on developer mode.
2. Go to Settings › Users & Companies › Groups.
3. Open the Blue Fox OS: Can Reveal Disk Passphrases group.
4. On the Users tab, add the person, then save.

Give this role to few people, and not necessarily to the ones who manage the fleet.

The menus, one by one#

All menus sit under the Policy application, visible to fleet managers only.

• Policy › Org Defaults: the list of organization records, one per company. Columns: Company, Domain, Who can provision, Login Mode, MFA required and Allow offline login. This is the chapter's starting screen.
• Policy › User Overrides: per-person exceptions, with the user, the company and the accent colour. A person has at most one exception per company.
• Policy › Flatpak Catalogue: the application catalogue, recommended ones first. The list is edited in place. The BF recommended filter and the Recommended grouping help you maintain the short list.
• Policy › Browser Extensions: the extension catalogue, edited in place, with the BF recommended toggle, the ID, the source, the instance address option and a note.
• Policy › Machines: enrolled workstations, most recently seen first. Columns: Hostname, User, Shared seat profile, Org, Last seen, Synchronizations and Escrowed passphrase. The Borrowers allowed to log in, Image version, Last IP, Enrolled on and Escrowed on columns can be added as needed.
• Policy › Shared Seats: the shared seat profiles, archived ones included. Columns: Name, Code, Kind, Org, Groups allowed to log in and Machine Count. A profile's form lists its machines at the bottom, with their borrowers and their last sync.

Reference#

Fields on the organization record#

Fields on the Machine record#

Fields on the shared seat profile#

Reports and exports#

No printed report. Lists export like every list in Symbifox. No passphrase ever leaves through an export: only the reveal button displays it.

Automations#

The application catalogue never refreshes on its own: the Flathub sync is run by hand.

Public pages and portal#

No portal page. The module serves a few technical addresses that only workstations use. The install file, /blue-fox-install.ks, is public and holds no secrets; the policy itself is only handed to a person signed in with the identity provider and authorized, or to an enrolled machine. The Bind password is included only for a sign-in made for the installer, even with Require install client in token unchecked; a sync never receives it. A Symbifox session open in the browser does not give access to the policy.

Modules that extend this application#

Understanding#

Why the machine re-reads its policy on its own. At installation, the machine receives an identity of its own, separate from the person who installed it. Every day, it re-reads its policy with that identity. Symbifox keeps only a fingerprint of it: even a full copy of the database is not enough to impersonate the machine.

Why revoking does not lock the machine. Revocation cuts the link; it erases nothing. A revoked machine keeps its last known policy, so it is never left without a configuration. To take a machine back in hand, reinstall it.

Why the Custodian is a separate role. Running a fleet's policy is an administration task; holding a disk passphrase is not. The module keeps the two apart, and makes every read a counted, dated and signed act.

Why escrow cannot be added later. The passphrase is generated by the installer and deposited during installation, the only moment an authorized person is demonstrably present. A machine installed before escrow was turned on, or whose deposit failed, keeps a passphrase typed by hand that only that person knows. To cover it, reinstall it.

Why an escrowed passphrase is never replaced. A deposit is not replaced by a new one, even one coming from the workstation itself. A normal reinstall creates a new record and is not affected. To deposit another passphrase on the same record, the Custodian first removes the old one, a restricted and traced action.

Why escrow fails safe. If the server lacks the encryption key, the installer does not use the passphrase it generated: it asks for a typed one, as before. A disk locked by a passphrase nobody holds would be worse than either alternative.

Why a shared seat belongs to nobody. A lab machine serves a whole class, and a lent machine changes borrower without being reinstalled. Tying it to the person who installs it would give it that person's policy, photo and time zone. The machine therefore belongs to its profile, and its name comes from the profile's counter. The installing person stays visible in Enrolled by; only they, or an administrator, can replay the machine's enrolment.

Why a shared seat needs the directory. With local accounts, the installer creates a single account, the installing person's. A shared seat must instead open to directory groups. Symbifox therefore refuses an active profile for an organization on local accounts, and stops serving a shared seat whose organization switches back to them.

Why an empty shared seat opens to nobody. An empty access list would let the whole directory in. A loan machine back on the shelf, with no group and no borrower, therefore closes to the whole directory. Only the local recovery account can still log in on it.

What installation does if the network drops. It does not stop: it falls back to default settings. A machine installed that way may not be enrolled; it then does not appear under Machines and will not follow policy changes.

What no longer changes after installation. The machine name, language and keyboard stay as they were set at installation. So does the directory connection. The Bind password is handed over only at installation, never by the sync. On a personal machine, the sync does not rewrite that connection, nor therefore the offline login it carries. A shared seat, for its part, receives at every sync the list of who may log in on it. The other settings follow the record.

Troubleshooting#

See also#

• Fleet updates
• Hosting management
• Settings and brand identity
• Employees
• School
• Nextcloud and Collabora
• Mobile applications and extension