How get controllers.yaml from existing controller


#1

I have a controller running at some IP.

The controller is connected to candid (multiuser setup with Active Directory integration).

I want to let users connect to this controller - pretty much as the “juju register” command would allow me to do.

But, since the controller is setup for multi-user, the juju register command is to no avail.

My questions is how to a let end users find, login and get a client-side “controllers.yaml” properly setup without having to download and edit the controllers.yaml and clouds.yaml manually?

This is also very needed when we “loose” our controllers in the sense that the configuration gets lost or messed up from labs and edits of various sort.


#2

Hmm :thinking:

I’m not sure we had considered this use case before.

All of the local configuration values are stored in ~/.local/share/juju and the controller information is stored in controllers.yaml


#3

Thanx @thumper!

Well, its a tedious work to have to distribute the configuration for multiple users and some means to get the configuration setup properly is needed from us.

At the moment, we are trying to mitigate this by committing to a git repo the configuration, but it seems not the proper way to do it and its a combersome (and error prone) process to get users started with juju with this approach.

I would like to see some kind of “share my juju nevironment” functionality which would simplify the distribution of models/controllers to users easily. Very similar to the juju register thing which is neat… but doesn’t work in a multiuser setup.


#4

I’m +1 that in theory the idea was that we’d be able to just use juju login to get access to a new controller. The main issue has been SSL trust for that login request. I’m going to spec out what the gaps are and put it here for discussion. I’d like to see how far out we are from making that work and see if maybe we just need some sort of juju login $controller-ip --trust or something that gives you a temp window for ignore the cert issue much as you would when ssh’ing to a fresh host.


#5

@rick_h, I think that option --trust would be widely used and appreciated. Of course, real production controllers should have real certificates, but for other use cases where controllers are less permanent but still shared within teams it would be a nice featre. I have noticed that there is some LetsEncrypt integration but I have not looked at it.

After reading this post, I needed to try this out with a “default” bootstrapped controller using Candid. It actually works, but requires root afaik:

$ juju register 192.168.1.10
Since Juju 2 is being run for the first time, downloading latest cloud information.
Fetching latest public cloud list...
Your list of public clouds is up to date, see `juju clouds`.
Enter a name for this controller: maas-juju-ctl1
^C

Ooops, strace reveals that port 443 was used, but 17070 is default. Let’s try again:

$ juju register 192.168.1.10:17070
Enter a name for this controller: maas-juju-ctl1
ERROR unable to connect to API: x509: certificate signed by unknown authority

Expected, but:

# openssl s_client -connect 192.168.1.10:17070 < /dev/null 2>/dev/null | openssl x509 -text > /etc/ssl/certs/controller.pem
# openssl rehash

$ juju register 192.168.1.10:17070
Enter a name for this controller: maas-juju-ctl1
Opening an authorization web page in your browser.
If it does not open, please open this URL:
https://candid.company.com/login-legacy?did=01888b09c6bf9e38d1174bf5e92f5741463b1edd79dbcbb9a63824ca655225a7
Couldn't find a suitable web browser!
Set the BROWSER environment variable to your desired browser.

Welcome, HALLBACK@company. You are now logged into "maas-juju-ctl1".

There are 2 models available. Use "juju switch" to select
one of them:
  - juju switch hallbackmodel
  - juju switch hallback-pennybeta

Works :slight_smile:


#6

I’ve got a post around this here:


#7

Thanks for mentioning this, that is an awesome feature!

Unfortunately, in this particular case we might have a problem using this feature, since our controllers won’t be accessible from the internet for the HTTP challenge. I tried to figure out how Juju does that, I also know that DNS challenge is a possibility, but old bugs/commits etc suggest HTTP challenge is made, e.g.: https://bugs.launchpad.net/juju/+bug/1743779

Still, it is so cool with Let’s encrypt support built in.