It seems like your browser didn't download the required fonts. Please revise your security settings and try again.
Barracuda CloudGen Access

How to Set the CloudGen Access Console Endpoint

  • Last updated on

By default, access-cli communicates with the Enterprise Console (EC) endpoint enterprise.fyde.com. You can obtain the current endpoint using endpoint:

$ access-cli endpoint
Currently configured endpoint:
enterprise.fyde.com

You can change the configured endpoint using   endpoint set. The endpoint cluster can be selected using the shortcuts  us  for the US cluster and  eu  for the EU cluster. The Management Console endpoint should be specified as the IP address or FQDN, optionally including a port number and without the schema or any slashes. Valid examples include accessconsole.example.com, 10.123.20.2:3000 and example. local:9000. Regardless of the endpoint address/port, HTTPS is always used as the transport, unless an option is specified, as detailed further below.

$ access-cli endpoint set accessconsole.example.com
Endpoint changed to accessconsole.example.com.
Credentials cleared, please login again using `access-cli login`

The endpoint is saved in the authentication settings file. Therefore, when you switch between credentials files, the correct endpoint for the credentials is used automatically.

As indicated by the message shown, when the endpoint is set, credentials are cleared from the current credentials file.

Official Cluster Endpoints

ClusterEndpoint URLShortcut
US Clusterapi.us.access.barracuda.comUS
EU Clusterapi.eu.access.barracuda.comEU

Experimental Endpoint Settings

Use HTTP Cache

Experimental support for RFC 7234-compliant HTTP caching can be enabled by including the --experimental-use-cache option when setting the endpoint.

The location of the cache can be adjusted using the configuration file. The cache is cleared when the endpoint is set.

Advanced Endpoint Settings

Disabling TLS Certificate Validation

Under very specific circumstances, such as debugging certificate issues, it is possible to disable the validation of the EC TLS certificate.

This should only be used for development and testing.

Access-cli will still use HTTPS, but it will accept any certificate presented by the server and any host name in that certificate. This behavior can be enabled by including the --insecure-skip-verify option when setting the endpoint.

$ access-cli endpoint set --insecure-skip-verify example.org
Endpoint changed to example.org.
Credentials cleared, please login again using `access-cli login`
WARNING: TLS certificate verification is being skipped for the endpoint. THIS IS INSECURE.

Access-cli will show the above warning on every run, until the endpoint is set again, without using this option.

Using HTTP Instead of HTTPS

Under very specific circumstances, it is possible to have access-cli communicate with the EC over HTTP instead of HTTPS.

This should only be used for development and testing.

Access-cli will still follow any redirects to HTTPS that the server might present. This behavior can be enabled by including the --insecure-skip-verify option when setting the endpoint.

$ access-cli endpoint set --insecure-use-http example.org
Endpoint changed to example.org.
Credentials cleared, please login again using `access-cli login`
WARNING: HTTP, instead of HTTPS, is being used for API communication. THIS IS INSECURE.

Access-cli will show the above warning on every run, until the endpoint is set again, without using this option.