Release 0.19.7

What's New

Update to Golang 1.16
Idle route garbage collection: orphaned routing table entries will be garbage collected. New
infrastructure for session confirmation facilitating additional types of garbage collection
Configurable Xgress dial "dwell time"
Database tracing support
Immediately close router ctrl channel connection if fingerprint validation fails
Immediately close router ctrl channel if no version info is provided
Ziti Controller Remove All Ziti Controller Remove API Sessions and Edge Sessions API Sessions and
Edge Sessions
Fixed posture check error responses to include only failed checks
Heartbeat Collection And Batching
Add Service Request Failures for Posture Checks
Remove database migration code for versions older than 0.17.1

Idle Route Garbage Collection

The following router configuration stanza controls idle route garbage collection:

forwarder:
  #
  # After how many milliseconds of inactivity is a forwarding table entry considered idle?
  #
  idleSessionTimeout: 60000
  #
  # How frequently will we confirm idle sessions with the controller?
  #
  idleTxInterval: 60000

Xgress Dial Dwell Time

The following router configuration stanza controls Xgress dial "dwell time". You probably don't want
to use this unless you're debugging a timing-related issue in the overlay:

forwarder:
  #
  # (Debugging) Xgress dial "dwell time". When dialing, the Xgress framework will wait this number of milliseconds
  # before responding in the affirmative to the controller.
  #
  xgressDialDwellTime: 0

Database Tracing

Enable database tracing using the dbTrace controller configuration directive:

dbTrace: true

This will result in log output that describes the entrance into and exit from transactional
functions operating against the underlying database:

[   0.003]    INFO fabric/controller/db.traceUpdateEnter: Enter Update (tx:18) [github.com/openziti/fabric/controller/db.createRoots]
[   0.003]    INFO fabric/controller/db.traceUpdateExit: Exit Update (tx:18) [github.com/openziti/fabric/controller/db.createRoots]
[   0.006]    INFO fabric/controller/db.traceUpdateEnter: Enter Update (tx:19) [github.com/openziti/foundation/storage/boltz.(*migrationManager).Migrate.func1]
[   0.006]    INFO foundation/storage/boltz.(*migrationManager).Migrate.func1: fabric datastore is up to date at version 4
[   0.006]    INFO fabric/controller/db.traceUpdateExit: Exit Update (tx:19) [github.com/openziti/foundation/storage/boltz.(*migrationManager).Migrate.func1]

Ziti Controller Remove All Ziti Controller Remove API Sessions and Edge Sessions API Sessions and Edge Sessions

With the Ziti Controller shutdown, it is now possible to clear out all API Sessions and Edge
Sessions that were persisted prior to the controller being stopped. All connecting identities will
need to re-authenticate when the controller is restarted.

This command is useful in situations where the number of sessions is large and the database is being
copied and/or used for debugging.

Example Command:
ziti-controller delete-sessions

Example Output:

[   0.017]    INFO ziti/ziti-controller/subcmd.deleteSessions: {go-version=[go1.16] revision=[local] build-date=[2020-01-01 01:01:01] os=[windows] arch=[amd64] version=[v0.0.0]} removing API Sessions and Edge Sessions from ziti-controller
[   9.469]    INFO ziti/ziti-controller/subcmd.deleteSessions.func2: existing api Sessions: 2785
[  18.274]    INFO ziti/ziti-controller/subcmd.deleteSessions.func2: edge sessions bucket does not exist, skipping, count is: 4035
[  47.104]    INFO ziti/ziti-controller/subcmd.deleteSessions.func3: done removing api Sessions
[  55.866]    INFO ziti/ziti-controller/subcmd.deleteSessions.func3: done removing api session indexes
[  58.325]    INFO ziti/ziti-controller/subcmd.deleteSessions.func3: done removing edge session indexes

Heartbeat Collection And Batching

In previous versions heartbeats from REST API usage and discrete Edge Router connection would all cause writes
for the same API Session as they were encountered. In situations where one or more REST API requests were issues and/or one or more
Edge Router connections were held by a ZitI Application, multiple simultaneous heartbeats could occur for no apparent benefit
and consume disk write I/O.

Heartbeats are now aggregated over a window of time in a cache and written to disk on an interval. The write interval defaults to 90s
and the batch size (for write transactions) to 250. Additionally, all heartbeats are flush to disk when the controller is properly shut down.

These settings can be defined in the edge.api section for the Ziti Controller configuration.

Example:

edge:
  api:
    ...
    #(optional, default 90s) Alters how frequently heartbeat and last activity values are persisted
    activityUpdateInterval: 90s
    #(optional, default 250) The number of API Sessions updated for last activity per transaction
    activityUpdateBatchSize: 250
    ...

Add Service Request Failures for Posture Checks

When a Ziti Identity (endpoint) requests a service that is provided via a Service Policy with
Posture Checks associated with it, failure to meet the Posture Check requirements results in an
error message with a code of INVALID_POSTURE and data elaborating on what Service Policies ids and
Posture Check ids failed. Additionally, now the controller will log the most recent requests and
provide detailed error output for administrators.

The output will show every Service Policy that was checked for access and every Posture Check that
failed. The failed Posture Checks include the Posture Data that was available for the identity and
the requirements defined in the Posture Check at the time of the Edge Session request.

New Endpoint: GET /identities/{id}/failed-service-requests