EventStoreDB 6.0.0 Preview 3

We are pleased to announce the third preview release of EventStoreDB 6.0.0, which continues to move towards gRPC client access and .NET Core server support in EventStoreDB.

If you encounter any issues, please don’t hesitate to open an issue on GitHub if there isn’t one already.

You can download the packages from the downloads page under the Pre-Release section.

Cluster role name change

The terminology used for the cluster node roles has been changed from Master and Slave to Leader and Follower.

Following this change, there are a few things to take into consideration:

The ES-RequireMaster header for HTTP is being deprecated and ES-RequireLeader should be used going forwards
Monitoring scripts that monitor the number of masters and slaves in gossip will need to be updated to the new terminology

EventStoreDB gRPC client cluster connectivity

The EventStoreDB gRPC Client now has the ability to connect to a cluster. All the connectivity settings are located in the ClusterConnectivitySettings object which lives in the EventStoreClientSettings.

In order to connect to a 3 node cluster, you need to set the GossipSeeds for each of the nodes:

var client = new EventStoreClient(new EventStoreClientSettings
{
    ConnectivitySettings =
    {
        GossipSeeds = new[]
        {
            new DnsEndpoint("localhost", 1114),
            new DnsEndpoint("localhost", 2114),
            new DnsEndpoint("localhost", 3114),
        },
        NodePreference = NodePreference.Leader,
        MaxDiscoverAttempts = 5,
        DiscoveryInterval = TimeSpan.FromMilliseconds(100)
    }
};

The list of available node preferences is:

Leader
Follower
Random
ReadOnlyReplica

To connect to a single node you can set the address property as follows:

var client = new EventStoreClient(new EventStoreClientSettings
{
    ConnectivitySettings =
    {
         Address = new Uri(“https://localhost:2113”)
    }
};

Deprecation of macOS support for EventStoreDB server

Although macOS was never a supported server platform for EventStoreDB, we have historically shipped binaries for those developing on that platform. In this preview release we have completed the move to gRPC for both client access and gossip which enables TLS by default.

The gRPC implementation for .NET Core uses the system-native TLS library for the platform on which it is running. In the case of macOS server-side ALPN is not supported by Security.Framework and consequently the Core CLR.

As a result of this, we are no longer shipping binaries for macOS server until such time as this is rectified. We recommend that users on macOS use the Docker container build of the server instead.

The gRPC client will still be supported on Linux, Windows and macOS.

Deprecation of Atom and TCP

As we move over to gRPC we are deprecating AtomPub and TCP. Command line options have been added to the server to enable both TCP and AtomPub.

AtomPub over HTTP is enabled by default in this version and can be enabled or disabled with --enable-atom-pub-over-http. Note that disabling AtomPub over HTTP will affect the web user interface.

The external TCP interface is now disabled by default and can be enabled with option --enable-external-tcp.

In preparation for this, any new development should make use of the gRPC clients.

Internal security in a cluster

The internal interfaces in a cluster are now secured by default and will no longer be externally accessible.

Internal TCP connections are mutually authenticated, and both follower and leader nodes will verify the certificates of the other nodes when a connection is made. This behaviour can be disabled using the --disable-internal-tls option, and is disabled by default in development mode (--dev).

The external gossip over HTTP is still available, but is read-only.

For now, the certificates used to secure your nodes need to include the internal and external IP addresses of the nodes in the certificate’s SAN for them to work correctly. An example on how to do this is included in the form of terraform scripts in the EventStoreDB repository.

New options for configuring certificates

To make configuration easier, EventStoreDB now supports multiple options for configuring certificates to allow you to choose what best suits your setup. The options provided have also been updated to have more detailed descriptions and errors to help guide developers during setup.

A certificate can be provided from :

A PKCS #12 (.p12/.pfx) certificate file, by providing it to the --certificate-file option
A public and private key pair, by setting --certificate-file to point to an X.509 (.pem, .crt, .cer, .der) certificate file, and pointing --certificate-private-key-file to a private key (.key)
The windows store, using the --certificate-store-location, --certificate-store-name, --certificate-thumbprint and --certificate-subject-name options

Development mode still runs with a default development certificate, and we have included the scripts we use to generate our development certificate in the repository.

Mutually exclusive security on TCP

Each TCP interface can be started as either secure or non secured, but not both at the same time. This can be controlled with the --disable-internal-tls and --disable-external-tls options. Internal TLS is enabled by default.

Clarification of existing security options

We have updated and clarified the existing security options to improve the usability of TLS with EventStoreDB.

--disable-internal-tls and --disable-external-tls options have been added to allow disabling TLS on either interface
--ssl-validate-master-node and --ssl-validate-slave-node have been removed. Mutual authentication is always used if internal communication is secured
--use-internal-ssl was renamed to --disable-internal-tls. Internal TLS is enabled by default
--disable-insecure-tcp was removed. If the TCP interface is secured, it does not start the non-secure TCP server
The following options have been removed:
- --int-secure-tcp-port
- --ext-secure-tcp-port
- --int-secure-tcp-port-advertise-as
- --ext-secure-tcp-port-advertise-as
The --ssl-target-host option has been removed for internal connection, and the IP address of the node to connect to is used as the target host. Please see the cluster security section for more details about the required certificates

We have had great response from the community and continue to welcome your feedback.