Skip to content

AcuGIS sync CLI mapping

The sibling AcuGIS CLI implements acugis sync by reusing the authenticated session created by acugis login <url>. It expects GeoSync under /geosync-service and uses HTML admin pages plus form actions; there is no dedicated CLI JSON API.

Implemented commands

acugis sync list [--json]

GET /geosync-service/admin/projects.php.

The client parses <tr data-id=...> rows and the visible Active column. It extracts ID, name/title, status, provider/server ID, upstream project ID, GeoPackage, schema, database, pglink, and rsync attributes. Human output always has ID/name/status; optional provider/owner/last-sync/schedule columns appear only if values exist. --json emits the parsed list, not raw HTML.

acugis sync info PROJECT [--json]

PROJECT resolves by exact case-insensitive ID, then name, then title. Ambiguous names require a unique ID. Enrichment performs:

  1. GET /admin/projects.php;
  2. GET /admin/project_settings.php?id=ID&tab=synchronize;
  3. GET ...&tab=frequency;
  4. POST /admin/action/server.php with project_info=1&id=SERVER_ID&project_id=UPSTREAM_ID;
  5. GET ...&tab=files.

Human output omits empty values and may include provider metadata, schedule, version count, GeoPackage, schema, database, and rsync. --json is a CLI-assembled object containing parsed project/settings/status/versions and open provider information; it is not a raw single API payload despite the option help text.

acugis sync status PROJECT [--json]

Uses the same enriched context as info. Status comes primarily from the Synchronize settings page and is normalized from systemd/UI text to labels such as Running, Idle, Failed, Queued, or Completed. It may include enabled, PID, CPU, and raw detail. GeoSync does not expose progress, so progress is omitted.

acugis sync run PROJECT [--wait]

After resolving/enriching the project, posts:

POST /geosync-service/admin/action/backend.php
Content-Type: application/x-www-form-urlencoded

op=start&id=ID

It rejects an already Running/Active state, checks JSON success, and best-effort refreshes the displayed status. --wait is accepted but explicitly ignored because GeoSync exposes no completion-polling contract.

acugis sync stop PROJECT

Posts the same endpoint with op=stop. It rejects a known Idle/Inactive state, checks JSON success, and best-effort refreshes status.

acugis sync versions PROJECT [--json]

Resolves the project through /admin/projects.php, then gets /admin/project_settings.php?id=ID&tab=files. The parser extracts links to files.php?...&gpkg=..., decodes the filename, recognizes archive date/time labels and .N.gpkg retention indexes, and prints VERSION/CREATED. --json returns {"project_id":"...","versions":[...]}.

Stubs

  • acugis sync create
  • acugis sync delete

Both invoke the CLI's not_implemented() helper. Although GeoSync has action/project.php save/delete operations, the CLI intentionally has no mapping for them.

Authentication and errors

The CLI's configured requests.Session supplies its session cookie. A 401, 403, or redirect/login HTML is reported as an expired/missing session and suggests acugis login <url>. Connection errors/502/503 become “GeoSync unavailable.” Non-2xx is checked at the HTTP layer.

For form actions, the client additionally requires a JSON object and checks success. This is essential because GeoSync commonly returns HTTP 200 for success:false. Empty action bodies become {}; non-object or malformed JSON is an error.

GeoSync endpoints with no acugis sync mapping

The command group does not map:

  • backend enable, disable, or restart;
  • project create/update/delete, password display, publish-to-web, or direct file download;
  • provider CRUD/listing beyond project_info;
  • PostgreSQL link, rsync, user, legacy group, GeoNode, GeoServer store/layer, daemon-setting, service-log, and DataTables actions;
  • express provisioning/list operations;
  • /api/proxy.php Analysis/Form Builder/GeoSync allowlist;
  • Analysis and Form Builder catch-all UI proxies;
  • local login, OIDC, OAuth, signup, or verification flows.

The CLI constants define PROJECT_ACTION and a helper for project conn_info, but current public command implementations do not call that helper.

HTML contract limitations

CLI list/status/version behavior depends on the current HTML structure, data-* attributes, headings, input names, and file links. These are more fragile than a JSON contract. Parser behavior is intentionally tolerant: provider enrichment and versions can be absent, while authentication, not-found, and settings ownership errors are surfaced. Consumers needing a stable machine API should not assume the CLI's parsed output is a server-side schema.