senofy/autofirmer-expanded
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Linux needs no enrolment - it never did

Browse Source 
The managed-device requirement is documented for Windows and macOS only, and a
Pi proved it: aarch64 Chromium fetched updates.xml with installedby=policy and
installed the CRX from a plain /etc policy file, with no enrolment, no Google
account and no Chrome. So setup-linux.sh writes the policy directly for
whichever browsers are present, and enrolment is a Windows concern again.

That also retires the ARM special case. Chromium could not be enrolled, which I
read as Chromium not being able to install this at all; the two are unrelated.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Brandon Li
2026-08-31 17:31:18 -05:00
co-authored by Claude Opus 5
parent d14bcdeed3
commit 458d667ca6
2 changed files with 33 additions and 47 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+15 -15
View File
@@ -139,7 +139,7 @@ powershell -NoProfile -ExecutionPolicy Bypass -File scripts\enroll-chrome-manage
```
```bash
sudo scripts/enroll-chrome-management.sh
sudo scripts/install-extension-policy.sh
```
The enrolment token is built into both scripts — a token is reusable across any
@@ -149,21 +149,21 @@ from Google's own enterprise MSI on Windows and the official .deb on Linux;
Chromium is not accepted as a substitute, because it has no cloud-management
support and can never be enrolled.
**On a Raspberry Pi, none of that applies.** Google publishes Chrome for x86_64
only, so an ARM box has Chromium and nothing else, and Chromium cannot be
enrolled. There the extension is loaded unpacked — `chrome://extensions` →
Developer mode → Load unpacked → `extension/` — and updates still arrive,
because an unpacked copy reloads itself from disk when the dashboard reports a
newer version. `setup-linux.sh` detects the architecture and says so rather than
offering an enrolment that cannot work.
**A Raspberry Pi needs none of it.** Chrome is not published for ARM, but
Chromium is, and on Linux Chromium honours the same forcelist policy — the CRX
is pure JavaScript, so the architecture is irrelevant. `setup-linux.sh` writes
the policy and Chromium installs the extension from the update server on its
next start. Loading `extension/` unpacked still works and still self-reloads,
but it is no longer the only option there.
**Enrolment is not optional.** No Chromium browser will force-install an
off-store extension on an unmanaged machine, whatever the registry says — it
reads the policy and blanks it. Enrolling is what makes Chrome managed without
joining a domain; Edge cannot be used this way at all. `install-extension-policy`
is still there for a genuinely domain-joined machine, where local policy is
honoured. See [deploy/README.md](deploy/README.md). Either way the extension
notices when
**Enrolment is a Windows problem only.** Windows refuses to force-install an
off-store extension unless the machine is domain-joined, Entra-joined or
enrolled in Chrome Enterprise Core — it reads the policy and blanks it — and
macOS wants MDM. Linux has no such requirement: a policy file under `/etc` is
enough, which is why a Raspberry Pi running Chromium installs this with no
Google account involved at all. On Linux, run `install-extension-policy.sh` and
skip enrolment entirely. See [deploy/README.md](deploy/README.md). Either way the
extension notices when
the dashboard is running newer code than it is: a policy install asks Chrome to
fetch the new CRX, an unpacked one reloads itself from disk. Clicking the reload
icon on its card still works and is the thing to try when something looks