macOS (edge, dev seulement)

Le binaire ongrid-edge cross-compile vers darwin/amd64 et darwin/arm64. Le Makefile build les deux dans le cadre de make build-edge-all :

build-edge-darwin-amd64   → bin/darwin-amd64/ongrid-edge
build-edge-darwin-arm64   → bin/darwin-arm64/ongrid-edge

Les binaires existent pour que les ingénieurs travaillant sur l'agent puissent itérer sur un Mac sans monter une VM Linux. Ils ne sont pas une cible de production supportée.

Ce qui marche sur macOS

• Le processus agent démarre, lit les variables d'env ONGRID_EDGE_* depuis votre shell, et ouvre le tunnel geminio vers le manager.
• Les RPCs de cycle de vie marchent : l'agent s'enregistre, envoie des heartbeats, accepte les appels d'outils initiés par le manager.
• Le skill bash (gaté par cmdpolicy) tourne contre l'host : ls, ps, df, uname et un ensemble curé en lecture seule marchent comme annoncé.
• Le collecteur gopsutil embarqué adosse host_info, get_host_load, get_host_processes. Ils renvoient de vrais chiffres.
• WebSSH contre 127.0.0.1:22 marche (en supposant que vous avez activé Remote Login dans System Settings).

Ce qui NE marche PAS sur macOS

Capacité	Pourquoi
Plugin promtail logs	Grafana ne publie pas de binaire promtail darwin dans leurs tarballs de release. L'étape make fetch-promtail ne fetch que Linux.
Plugin node_exporter host-metrics	Même trou upstream — node_exporter livre des releases Linux-only.
Plugin process-exporter proc-metrics	Même trou upstream.
Plugin otelcol-contrib traces	Embarqué seulement pour Linux — garde le tarball de release sous contrôle.
L'installer curl-pipe	deploy/install/edge/install.sh erre explicitement avec only linux is supported by this installer; got: darwin.
Supervision style systemd	macOS utilise launchd. Pas de plist launchd livrée dans la release.
Source de logs journald	macOS utilise l'unified log (os_log) ; le plugin logs aurait besoin d'un reader différent même si promtail avait un binaire.
Le hook d'upgrade staged-bundle ADR-024	Le hook est un script shell Linux câblé dans ExecStartPre=. Il n'y a pas de chemin équivalent.

Ce que ça veut dire en pratique : si vous make build-edge-darwin-arm64 et exécutez ./bin/darwin-arm64/ongrid-edge sur votre Mac, vous verrez votre laptop apparaître dans la page Edges de l'UI du manager, vous pouvez chatter avec l'agent et lui faire exécuter ls, ps, df, mais la page Logs, les panels host de la page Monitor et la page Traces resteront tous vides pour cet edge.

Exécuter l'agent sur un Mac

# 1. cross-compile (or just `go build`, since you're already on darwin)
make build-edge-darwin-arm64

# 2. point at your manager
export ONGRID_EDGE_CLOUD_ADDR=ongrid.example.com:40012
export ONGRID_EDGE_ACCESS_KEY=<from manager UI: Edges → New>
export ONGRID_EDGE_SECRET_KEY=<from manager UI; shown once>

# 3. run it in the foreground
./bin/darwin-arm64/ongrid-edge

L'agent logge vers stderr. Il n'y a pas de /var/log/ongrid-edge/ parce que rien ne le crée ; si vous voulez un fichier de log, redirigez : ./ongrid-edge 2>&1 | tee ~/ongrid-edge.log.

launchd ? Pas encore

Une plist launchd vous donnerait start-on-login plus restart automatique. Nous n'en avons pas livrée parce que :

• Les quatre plugins ne tournent de toute façon pas sur macOS, donc un agent supervisé là vous donne un sous-ensemble de features qui est dur à raisonner.
• Les hosts macOS en production sont extrêmement rares. Nous préférons ne pas nous engager à une plateforme à moitié supportée.

Si vous en voulez une pour votre propre développement, voici un exemple minimal. Sauvez comme ~/Library/LaunchAgents/io.ongrid.edge.plist :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key><string>io.ongrid.edge</string>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/local/bin/ongrid-edge</string>
  </array>
  <key>EnvironmentVariables</key>
  <dict>
    <key>ONGRID_EDGE_CLOUD_ADDR</key><string>ongrid.example.com:40012</string>
    <key>ONGRID_EDGE_ACCESS_KEY</key><string>...</string>
    <key>ONGRID_EDGE_SECRET_KEY</key><string>...</string>
  </dict>
  <key>RunAtLoad</key><true/>
  <key>KeepAlive</key><true/>
  <key>StandardOutPath</key><string>/tmp/ongrid-edge.out.log</string>
  <key>StandardErrorPath</key><string>/tmp/ongrid-edge.err.log</string>
</dict>
</plist>

Puis launchctl load ~/Library/LaunchAgents/io.ongrid.edge.plist.

Codesigning / Gatekeeper

L'agent n'est pas codesigné. La première fois que vous l'exécutez, macOS refusera avec « cannot be opened because the developer cannot be verified ». Soit :

• xattr -d com.apple.quarantine ./ongrid-edge pour retirer le flag de quarantaine, soit
• Clic droit → Open dans Finder une fois, puis il se souvient de votre choix.

Construire depuis les sources (go build ./cmd/ongrid-edge) sur votre propre Mac évite entièrement le flag de quarantaine.

Devriez-vous utiliser macOS en production ?

Non. Utilisez une box Linux. L'agent tourne parfaitement sur une VM Linux à 5$/mois ; l'exécuter sur un Mac mini marche pour un homelab mais vous perdez les quatre plugins qui fournissent 80% de la valeur qu'Ongrid livre (métriques host, logs, traces).

Le chemin dev-only existe pour qu'on puisse dogfood l'agent pendant le développement. Ce n'est pas une cible de déploiement.