[
https://issues.apache.org/jira/browse/KUDU-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16859818#comment-16859818
]
Yingchun Lai commented on KUDU-1948:
------------------------------------
Now we have added a config file for Kudu CLI tools, we can use CLI tool like
"kudu tserver list @cluster_name" to access a Kudu cluster alternatively.
The 'cluster_name' is configured in a YAML format config file
${KUDU_CONFIG}/kudurc, its content is like:
{code:java}
clusters_info:
cluster_name1:
master_addresses: ip1:port1,ip2:port2,ip3:port3
cluster_name2:
master_addresses: ip4:port4{code}
When we use CLI tools, if the master_addresses section is start with a
character '@', this tool will treat the following string as a cluster name, and
then try to parse the config file mentioned above, use the master_addresses
value of this cluster to access. On the other hand, if the master_addresses
section is NOT start with a character '@', this tool will treat it as master
addresses directly as before.
> Client-side configuration of cluster details
> --------------------------------------------
>
> Key: KUDU-1948
> URL: https://issues.apache.org/jira/browse/KUDU-1948
> Project: Kudu
> Issue Type: New Feature
> Components: client, security
> Affects Versions: 1.3.0
> Reporter: Todd Lipcon
> Assignee: Yingchun Lai
> Priority: Major
>
> In the beginning, Kudu clients were configured with only the address of the
> single Kudu master. This was nice and simple, and there was no need for a
> client "configuration file".
> Then, we added multi-masters, and the client API had to take a list of master
> addresses. This wasn't awful, but started to be a bit aggravating when trying
> to use tools on a multi-master cluster (who wants to type out three long
> hostnames in a 'ksck' command line every time?).
> Now with security, we have a couple more bits of configuration for the
> client. Namely:
> - "require SSL" and "require authentication" booleans -- necessary to prevent
> MITM downgrade attacks
> - custom Kerberos principal -- if the server wants to use a principal other
> than 'kudu/<HOST>@REALM' then the client needs to know to expect it and fetch
> the appropriate service ticket. (Note this isn't yet supported but would like
> to be!)
> In the future, there are other items that might be best specified as part of
> a client configuration as well (e.g. CA cert for BYO PKI, wire compression
> options, etc).
> For the above use cases it would be nicer to allow the various options to be
> specified in a configuration file rather than adding specific APIs for all
> options.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
