82 Releases 305 Tags

RSS Feed

• v32.5.5 f2c8dea447

  Compare

  Onebox v32.5.5 Stable

  jkunz released this 2026-09-24 07:54:18 +00:00 | 154 commits to main since this release

  2026-09-24 - 32.5.5

  Fixes

  • Let an in-place backup restore keep the WorkloadInit approval its owner holds. The restore wrote the backup's encrypted environment back through the ordinary service update, and the service-secret writer refused that write whenever the stored approval differed from the backup's, so once an approval had been staged after a backup was taken the backup could no longer be restored in place: on central, Cloudly's approval moved to generation 4 after backup 4 was taken at generation 3, which left the documented rollback of the Cloudly App Store upgrade without a supported path. The approval owner now answers a replacement of a service's whole encrypted environment: WorkloadInitApprovalsStore.retainCustody returns the caller's secrets with the approval the service holds now in place of whatever approval they carry, proves that approval against the owner's current decision when the owner holds one, and refuses while an approval operation is pending. The in-place restore and its rollback ask it under the service mutation lock every approval operation takes, so a restore keeps the current generation, never writes an older one and restores everything else. The owner admits a first approval only through its verified stage, so a backup whose environment carries an approval is refused for an import or clone before a service is created, where it previously failed midway through deploying the new service, and an in-place restore of such a backup into a service without an approval is refused the same way.
  • Put back the App Store template when a restore puts back the image and configuration. Neither the restore nor the ops API updateService reset appTemplateVersion, so after rolling back an App Store upgrade the service still reported the newer template version and Onebox refused to repeat the upgrade. A backup now records the service's appTemplateId and appTemplateVersion, as null when the service has none, an in-place restore sets both back together with the image, and an import or clone creates its service with them. A failed in-place restore puts the previous template back with the rest of the configuration, as the entries below describe. A backup taken before this release lacks both keys: restoring it in place leaves the service's template as it stands and names that in the restore's warnings. A backup that records only one of the two is refused before the service changes.
  • Return a service to exactly its previous configuration when an in-place restore fails after it replaced the service. The rollback of an image-inclusive restore passed the previous values through the ordinary service update, which keeps a field it is not given, so every field the restore had set and the service had not recorded kept the backup's value: the primary domain and with it a route to the backup's domain, the Onebox registry settings (useOneboxRegistry, registryRepository, registryImageTag, autoUpdateOnPush), the platform requirements, the App Store template, and the port and volume lists of a record that predates them. An App Store service, whose image is a tag with its digest recorded beside it, also lost that digest and came back on the bare tag, and a service with a storage spec kept the volumes a backup without one had written. The rollback now puts the runtime and its routes back through the service manager and then writes every field the restore wrote back to its previous stored value, removing a field the service did not record, through OneboxDatabase.restoreServiceFields, all under the service mutation lock.
  • Configure a service exactly as its backup records it when an in-place restore succeeds. The restore passed the backup's values through the same ordinary service and record updates, so a field the backup recorded as absent kept the service's current value: restoring a manual service's backup over a service that had since gained a primary domain, a registry, Onebox registry settings, platform requirements or an App Store template left all of them in place, together with the domain's route. The restore now writes the fields the backup holds and removes every field it records as absent through OneboxDatabase.clearServiceFields. It tells a field the backup records as absent from one the backup's format predates: every field except the image digest and the template has been written by every export since Onebox 32.0.0, the oldest format this release restores, so a missing key there means the service had none; the export now also writes imageDigest, appTemplateId and appTemplateVersion, as null when the service has none, so their missing key marks a backup written before this release, whose restore keeps the service's template and, for an image restored by its tag, keeps the service's digest only while its image and registry are unchanged, and names both in the warnings, reading the pin the restore actually applied. A restore by image reference now pins the tag to the recorded digest, or drops a pin the service holds when the backup records none. A restore from an archived image still runs that verified image by its identity. A backup that records neither managed storage nor volumes is now refused before the service changes when the service has since gained managed storage, as a backup that records volumes already was; the restore used to leave the managed volumes in place. The backup format and its logical-items tag are unchanged: no 32.x release reads the added keys, so an earlier 32.x release restores a new backup as it restores its own.

  Downloads

  • onebox-linux-arm64
    1.0 GiB

    2026-09-24 08:03:40 +00:00
  • onebox-linux-x64
    1.0 GiB

    2026-09-24 07:59:05 +00:00
  • serve.zone-onebox-32.5.5.tgz
    12 MiB

    2026-09-24 07:54:21 +00:00
  • SHA256SUMS.txt
    257 B

    2026-09-24 08:03:41 +00:00
  • THIRD_PARTY_NOTICES.md
    43 KiB

    2026-09-24 08:03:41 +00:00
  • Source Code (ZIP)
  • Source Code (TAR.GZ)