Software Management & Lifecycle
OmniWeb provides a single place to see and manage the software running across the fleet — package versions, available updates, and licensing — so the lifecycle of the network's software is visible from the same portal used to operate it.
Software Page (APT Repository)
The Software page is an APT repository browser for Omnitouch packages. It connects to the configured APT repository server and shows, for the packages it manages:
- Available packages in the repository.
- Versions offered, including the latest available.
- Update status — whether a newer version exists than what is deployed.
This lets operators see at a glance which Omnitouch components have updates pending and which versions are current, providing the inventory side of the software lifecycle. Package installation/upgrade on hosts is performed through the standard APT/dpkg tooling (and is typically automated via Ansible); OmniWeb gives the visibility layer over what is published and current.
The Software page — each Omnitouch package with its latest repository and cache versions and an in-sync indicator that flags where a newer version is published than is cached/deployed (here omni-upf and omni-msc are out of sync).
Syncing Packages to the Cache
Deployments that run an on-site APT cache mirror (for airgapped or bandwidth-limited sites) keep a local copy of the packages published on the build repository. Over time the cache falls behind — the Software page flags each package that is out of sync (a newer version is published than is cached). From the same page you can pull those updates into the cache without leaving OmniWeb:
- Sync all — pull every updated package from the repo into the cache.
- Sync (per row) — pull just one package. Click several and they queue: they download one after another, and the package index is regenerated once at the end (not per package), so the cache is never left half-updated.
While a sync runs, the page shows live progress — which package is downloading, how many are queued, and a streaming log — and refreshes the version comparison when it finishes.
A sync in progress — omni-msc downloading with omni-upf queued, the phase banner, and the live log. When the queue drains, the cache index is regenerated once and the in-sync status updates.
The sync runs on the cache mirror itself (OmniWeb triggers it and streams the progress); the mirror pulls the updated .debs from the build repo and regenerates its index. Hosts at the site then install the updated packages from the cache as usual.
Versioning
OmniWeb reports its own build version (version, commit, and build date) so operators can confirm exactly which build of the portal they are running. This is the reference point when reporting issues or coordinating an upgrade of the portal itself.
License Management
The License Server is administered through OmniWeb like any other element, using the same generic patterns (see Common Operations). It surfaces:
License Server overview — current license status and validity, including trusted-time state.
| View | Description |
|---|---|
| Overview | Current license status, validity dates, and feature entitlements. |
| Request Logs | Historical license requests, with filtering — useful for auditing what was checked and when. |
| Query | Look up the license status for a specific licensee/product on demand. |
Licensing ties into the software lifecycle: entitlements determine which products and features a deployment is authorised to run, and the request logs give an audit trail of license activity over time.
Lifecycle at a Glance
- See what's available — the Software page shows pending updates.
- Confirm entitlements — the License Server shows what the deployment is licensed for.
- Apply — upgrades run via APT/Ansible on the hosts.
- Verify — confirm versions, then watch element Logs and Dashboards to confirm a healthy result.