Skip to content

Releases: openziti/ziti

v1.4.2

28 Feb 18:42
v1.4.2
37cedec
Compare
Choose a tag to compare
v1.4.2 Pre-release
Pre-release

Release 1.4.2

  • Bug fixes

Component Updates and Bug Fixes

v1.4.1

26 Feb 21:20
v1.4.1
b97f267
Compare
Choose a tag to compare
v1.4.1 Pre-release
Pre-release

Release 1.4.1

What's New

  • Bug fixes

Component Updates and Bug Fixes

v1.4.0

26 Feb 15:43
v1.4.0
dfec22e
Compare
Choose a tag to compare
v1.4.0 Pre-release
Pre-release

Release 1.4.0

What's New

  • Changes to backup/restore and standalone to HA migrations
  • Use cluster consistently for cluster operations
  • Event Doc and Consistency
  • ziti ops verify changes
    • Moved ziti ops verify-network to ziti ops verify network
    • Moved ziti ops verify traffic to ziti ops verify traffic
    • Added ziti ops verify ext-jwt-signer oidc to help users with configuring OIDC external auth
    • Added ziti ops verify ext-jwt-signer oidc to help users with configuring OIDC external auth
  • Router Controller Endpoint Changes
  • Bug fixes

Config Changes

NOTE: For HA configuration, the raft: config stanza is now named cluster:.

Example:

cluster:
  dataDir: ./data

Event Doc and Consistency

The event types are now exhaustively documented as part of the OpenZiti Reference Documentation.

During documentation, some inconsistencies were found the following changes were made.

Namespace Cleanup

Namespaces have been cleaned up, with the following changes:

  • edge.apiSessions -> apiSession
  • fabric.circuits -> circuit
  • edge.entityCount -> entityCount
  • fabric.links -> link
  • fabric.routers -> router
  • services -> service
  • edge.sessions -> session
  • fabric.terminators -> terminator
  • fabric.usage -> usage

Note that service events used services in the config file, but service.events in the event itself.
The old namespaces still work. If the old event type is used in the config file, the old namespace will be in the events as well

Timestamp field

The following event types now have a timestamp field:

  • service
  • usage

This timestamp is the time the event was generated.

Event Source ID

All event types now have a new field: event_src_id. This field is the id of the controller
which emitted the event. This may be useful in HA environments, during event processing.

Cluster Operations Naming

The CLI tools under ziti fabric raft are now found at ziti ops cluster.

The Raft APIs available in the fabric management API are now namespaced under Cluster instead.

Backup/Restore/HA Migrations

What restoring from a DB snapshot has in common with migrating from a standalone setup to
a RAFT enabled one, is that the controller is changing in a way that the router might not
notice.

Now that routers have a simplified data model, they need know if the controller database
has gone backwards. In the case of a migration to an HA setup, they need to know that
the data model index has changed, likely resetting back to close to zero.

To facilitate this, the database now has a timeline identifier. This is shared among
controllers and is sent to routers along with the data state. When the controller
restores to a snapshot of previous state, or when the the controller moves to a
raft/HA setup, the timeline identifier will change.

When the router requests data model changes, it will send along the current timeline
identifier. If the controller sees that the timeline identifier is different, it knows
to send down the full data state.

Implementation Notes

In general this is all handled behind the scenes. The current data model index and
timeline identifier can be inspected on controllers and routers using:

ziti fabric inspect router-data-model-index

Example

$ ziti fabric inspect router-data-model-index
Results: (3)
ctrl1.router-data-model-index
index: 25
timeline: MMt19ldHR

vEcsw2kJ7Q.router-data-model-index
index: 25
timeline: MMt19ldHR

ctrl2.router-data-model-index
index: 25
timeline: MMt19ldHR

Whenever we create a database snapshot now, the snapshot will contain a flag indicating
that the timeline identifier needs to be changed. When a standalone controller starts
up, if that flag is set, the controller changes the timeline identifier and resets the flag.

When an HA cluster is initialized using an existing controller database it also changes the
timeline id.

HA DB Restore

There's a new command to restore an HA cluster to an older DB snapshot.

ziti agent controller restore-from-db </path/to/database.file>

Note that when a controller is already up and running and receives a snapshot to apply, it
will move the database into place and then shutdown, expecting to be restarted. This is
because there is caching in various places and restartingi makes sure that everything is
coherent with the changes database.

Router Controller Endpoint Updates

Endpoints File Config

The config setting for controller the endpoints file location has changed.

It was:

ctrl:
  dataDir: /path/to/dir

The endpoints file would live in that directory but always be called endpoints.

This is replaced by a more flexible endpointsFile.

ctrl:
  endpointsFile: /path/to/endpoints.file

The default location is unchanged, which is a file named endpoints in the same
directory as the router config file.

Enrollment

The router enrollment will now contain the set of known controllers at the time
the router as enrollled. This also works for standalone controllers, as long as
the advertiseAddress settings is set.

Example

ctrl:
  listener: tls:0.0.0.0:6262
  options:
    advertiseAddress: tls:ctrl1.ziti.example.com

This means that the controller no longer needs to be set manually in the config
file, enrollment should handle initializing the value appropriately.

Component Updates and Bug Fixes

Read more

v1.3.3

27 Jan 19:37
v1.3.3
2a62cc5
Compare
Choose a tag to compare

Release 1.3.3

What's New

  • Bug Fixes

Component Updates and Bug Fixes

  • github.com/openziti/ziti: v1.3.2 -> v1.3.3
    • Issue #2694 - Router should use router data model if it has more than one controller configured, regardless of controller configuration

v1.3.2

25 Jan 15:23
v1.3.2
94922ed
Compare
Choose a tag to compare
v1.3.2 Pre-release
Pre-release

Release 1.3.2

What's New

  • Bug Fixes

Component Updates and Bug Fixes

  • github.com/openziti/ziti: v1.3.1 -> v1.3.2
    • Issue #2692 - Routers get empty ctrl list on upgrade
    • Issue #2689 - OIDC authentication with form data requires "id" in form data, authReqeustID in query string is ignored

v1.3.1

24 Jan 15:45
v1.3.1
e80a109
Compare
Choose a tag to compare
v1.3.1 Pre-release
Pre-release

Release 1.3.1

What's New

  • Bug Fixes

Component Updates and Bug Fixes

  • github.com/openziti/ziti: v1.3.0 -> v1.3.1
    • Issue #2682 - HA Controller panics when bootstrapping by setting the db variable in the configuration
    • Issue #2683 - Controller fails to save peer configuration on a fresh install
    • Issue #2684 - Controller emits duplicate cluster events on startup

v1.3.0

23 Jan 18:10
v1.3.0
8b410b9
Compare
Choose a tag to compare
v1.3.0 Pre-release
Pre-release

Release 1.3.0

What's New

  • Router Data Model enabled by default
  • Bug fixes
  • Controller Health Check HA Update (from @nenkoru)

Router Data Model

As part of the controller HA work, a stripped down version of the data model can now be distributed to the routers,
allowing routers to make some authorization/authentication decisions. This code has existed for some time, but
after testing and validation, is now enabled by default.

It can still be disabled at the controller level using new configuration. Note that the router data model is required
for HA functionality, so if the controller is running in HA mode, it cannot be disabled.

routerDataModel:
  # Controls whether routers are told to enable functionality dependent on the router data model
  # Defaults to true
  enabled: true 

  # How many model changes to buffer so that routers can be updated iteratively. If a router requests
  # data that's no longer available, it will receive the full data model
  logSize: 10000

HA Changes

Routers no longer require the ha: enabled flag be set in the configuration. Routers should work correctly
whether connecting to HA or non-HA controllers.

NOTE: If the controller a router is connected changes modes, specifically if the controller goes from
supporting the router data model to not, or vice-versa, the router will shutdown so that it can
restart with the correct mode.

Controller Health Check HA Update

This feature was contributed by @nenkoru.

The controller health check can now optionally return information about raft and leadership when the /controller/raft path is provided.

$ curl -k https://localhost:1280/health-checks/controller/raft
{
    "data": {
        "checks": [
            {
                "healthy": true,
                "id": "bolt.read",
                "lastCheckDuration": "0s",
                "lastCheckTime": "2025-01-14T19:42:13Z"
            }
        ],
        "healthy": true
    },
    "meta": {},
    "raft": {
        "isLeader": true,
        "isRaftEnabled": true
    }
}

Note the raft section, which indicates if raft is enabled and if the queried controller is currently the leader. If the
controller/raft path isn't present in the request, the result should be unchanged from previous releases.

When querying the controller/raft health, if raft is enabled but the controller is not the leader, the check will
return an HTTP status of 429.

Component Updates and Bug Fixes

v1.1.16

14 Jan 19:10
v1.1.16
0b290a2
Compare
Choose a tag to compare

Release 1.1.16

What's New

Update golang.org/x dependencies, specifically golang.org/x/crypto, for latest security fixes

v1.2.2

23 Nov 00:18
v1.2.2
9a83ca8
Compare
Choose a tag to compare

Release 1.2.2

What's New

  • Bug fixes and continuing progress on controller HA

Component Updates and Bug Fixes

v1.2.1

18 Nov 21:18
v1.2.1
01d8122
Compare
Choose a tag to compare
v1.2.1 Pre-release
Pre-release

Release 1.2.1

What's New

  • Bug fixes and continuing progress on controller HA

Component Updates and Bug Fixes