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.
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.
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.
@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
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.: Bug #1743779 “let's encrypt juju controllers no longer work” : Bugs : juju
Still, it is so cool with Let’s encrypt support built in.
@rick_h What Is the “typical” way of distributing controller/cloud information in a multiuser setup currently without on-prem jaas?
We have tried “onboarding” a few people and the process is to say the least tedious and has a number of “pitholes” before a new user can get going.
Things like:
Getting hold of correct “controller.yaml” and “cloud.yaml”
Making sure the “correct” credentials are set as default (set-default-credential) or the client will throw “ERROR”
setting some/any default model for a user - or the client will throw “ERROR”
We are working slowly towards a better end-user-experience getting a “first-time-user” to be able to do:
juju create-model
juju deploy
… but we are struggling.
Our current “getting-started” document is about 3 pages.
Either we do something horribly wrong (which could very well be the case) or some work should perhaps be put into making a multiuser setup somewhat more straight forward.
The credentials are going to be the hardest thing I believe. I think it depends on how “ready to roll” you want to make it ahead of time.
Path 1 - users do it all
The admin creates the user account and grants the access for add-model to the new user. The register command that’s printed out is sent to the user.
They then need instructions are how to add the credentials after they register and set the password. It might be reference to a valid credentials yaml file that can be linked to the user (email a link, or attach, or …)
The user then does juju add-credential -f ...
This is best if there’s unique credentials generated per user.
Path 2 - admins do all the hard work
The other way to go is have the admins create the account, grant it access, then use the register command themselves to create an initial password for the new user account and load the credentials.
The end user is then given a valid juju login $ip:$port -c $localname -u $username. As long as they have the password they will get a local cache of info setup and the account can be setup with as much detail/info as needed.
This doesn’t apply for us since we have a “candid” server which has the users password already set in our local ActiveDirectory.
The controller “superuser”(s) just do “juju grant USER@corporate login” + "juju grant USER@corporate add-model
(The juju grant add-model isn’t documented btw )
… so, the superuser never gets a register command to send to a user (as this post initially described).
The process so far is something like this:
Admin bootstrap the candid enabled controller.
Admin does “juju grant USER@corporate login”
Admin does “juju grant USER@corporate add-model” (For those users that has cloud-logins/credentials)
Now, USER, needs to get relevant information which currently is:
USER runs “juju” once to get .local/share/juju/ directory with defaults.
copy a controller.yaml + cloud.yaml
… or USER must modify/replace controller.yaml + clouds.yaml
USER must run "juju switch somecontroller
USER must run “juju add credential” corresponding to the contents of the yamls.
USER must run “juju update-credentials …” (a few times if vsphere due to getting logged out all the time)
USER must run “juju set-default-credentials …”
USER must run “juju login -u USER@corporate”
USER must run “juju switch somemodel” (or juju status will throw ERROR)
… I might miss out on some detail above, but consider a new user of juju. The experience so far from 2 experienced devopsers in our company needed significant assistance from me and @xinyuem to get going with this. I hope we are doing something horribly wrong.
This feels like something I need to try out… but wasn’t this related to the discussion with @hallback above (requires root privilegues for the user at the client side)?
No root required. We’ve done work in 2.6 for login so it should just work to get the user setup. They’ll be asked to trust the cert fingerprint during their first login but that’s it.
On the controller, the admin issued: “juju grant USER@corporate superuser”
Then, I tried to login:
$ juju login 10.104.129.39:17070 -c iuba-vmware -u USER@corporate
Controller “10.104.129.39:17070” presented a CA cert that could not be verified.
CA fingerprint: [4D:1C:43:1E:E0:04:8F:19:90:5B:1B:38:0D:9F:C6:D4:60:F8:A2:B9:51:1C:06:9E:66:97:41:59:AB:3B:5E:2F]
Trust remote controller? (y/N): y
ERROR cannot log into “10.104.129.39:17070”: invalid entity name or password (unauthorized access)
Hmm, it failed. Lets try with admin.
$ juju login 10.104.129.39:17070 -c iuba-vmware -u admin
Controller “10.104.129.39:17070” presented a CA cert that could not be verified.
CA fingerprint: [4D:1C:43:1E:E0:04:8F:19:90:5B:1B:38:0D:9F:C6:D4:60:F8:A2:B9:51:1C:06:9E:66:97:41:59:AB:3B:5E:2F]
Trust remote controller? (y/N): y
Enter password:
Welcome, admin. You are now logged into “iuba-vmware”.
There are 2 models available. Use “juju switch” to select
one of them:
juju switch controller
juju switch default
So, now I logout admin:
juju logout
… and try login with the “normal” username (USER@corporate)
Hmm, the thing I think that is missing is getting the user account know in candid first. I wonder if @martin-hilton has any insight into that first load of the user into Candid and how we might seed that. Does the user need to make sure to first log into the Candid login webpage? Then would the juju login succeed?
In the first example it doesn’t look like it is getting as far as talking to candid. It looks like juju (It doesn’t look like JIMM if it’s at 17070) is rejecting the user based on not knowing the username. If you repeat with --debug we might be able to tell where it’s getting stuck.
I think the gap is that you have to make sure that the controller knows about the user so we have to run the add-user command with the @corporate (or actually external?) user.
So I think the steps need to be
juju add-user USER@external
juju grant USER@external login
juju grant USER@external add-model
We’ll have a go on this. @xinyuem is also looking at this.
A question on the “external” - what is this for really as we are in fact using “scania” here instead of “corporate” and/or “external” as I just changed that to make it more general to the post. What would the meaning of that name be?
I’m not sure. I think at one point in time the idea was there would be users across federated identity back ends so you’d have rick@canonical and bob@scania. In the end, I think the @external is currently tied as a hint that “user that’s not a native juju account” so that we’re not trying to match the username/password in the local juju db but lean on the external identity provider.
Ah, I see. I think we’ll stay with “scania” then since this might go with your original thought and after all, we are authenticating with our company ActiveDirectory LDAP backend.
