How get controllers.yaml from existing controller

@rick_h

$ juju add-user USER@scania
ERROR failed to create user: invalid user name “USER@scania”

$ juju add-user USER@scania “Mr Smith” --debug --verbose
09:56:18 INFO juju.cmd supercommand.go:57 running juju [2.6.8 gc go1.10.4]
09:56:18 DEBUG juju.cmd supercommand.go:58 args: []string{"/snap/juju/8873/bin/juju", “add-user”, “KONSMH@scania”, “Mr Smith”, “–debug”, “–verbose”}
09:56:18 INFO juju.juju api.go:67 connecting to API addresses: [10.104.129.59:17070 10.104.129.39:17070 10.104.129.138:17070]
09:56:18 DEBUG juju.api apiclient.go:1092 successfully dialed “wss://10.104.129.39:17070/api”
09:56:18 INFO juju.api apiclient.go:624 connection established to “wss://10.104.129.39:17070/api”
09:56:18 DEBUG juju.api monitor.go:35 RPC connection died
ERROR failed to create user: invalid user name “USER@scania”
09:56:18 DEBUG cmd supercommand.go:496 error stack:
failed to create user: invalid user name “USER@scania”
/build/juju/parts/juju/go/src/github.com/juju/juju/api/usermanager/client.go:60:

https://github.com/juju/juju/blob/develop/api/usermanager/client.go#L39

… so back at [1]

The add-user command is for dealing only with local users on a controller.

As @rick_h mentioned above, the idea was always for an identity provider to managage external users, like the @scania part. I had always thought that the part after the @ would be configurable. Not sure if that bit was implemented.

So, the way to get the USER@scania would be to use candid.

Local users can’t have the @ sign.

1 Like

Yes, we do have candid, integrated with AD, but the thing is that we’re trying to figure out how to get the juju client setup for a controller without having to copy or edit yaml files.

The ‘juju register’ way was super, but that doesnt work with candid.

I would have thought that the juju login command would work for that.

Given an unconfigured juju client?

Yes. The login command hits an unauthenticated endpoint to initiate download of the server CA Cert, and the user is authenticated. There are some caveats…

  • the machine needs to have routability to the controller
  • the controller should be configured with candid
  • the special user everyone@external should be granted login and add-model permissions

The external user should not be added as per @rick_h’s post above. everyone@external is a special user that exists for the purpose of configuring general perissions until Juju gets proper RBAC security.

NOTE: you should use “@external” here even though you use “@scania” for the candid entries because “everyone@external” is a hard-coded string in Juju just now.

1 Like

YES! Finally!

I can confirm that this works acceptably good.

So, admin or a superuser in the controller does this on the controller:

juju grant everyone@external login
juju grant everyone@external add-model

Then the “juju-client” does:

juju login controller-ip-or-hostname:17070 -c name-of-controller

Note! The client must not provide the username at login (will error) but instead uses the URL login provided by candid for that.

Login succeed!

After this, adding cloud and credentials is needed to be able to “juju add-model” as:

juju add-cloud … (cloud name must match exactly the cloud name in the controller)
juju add-credential …
juju update-credentials …
juju add-model …
… etc

As a follow up question: Is there a way to extract the cloud names from the controller since that is important for the subsequent “juju add-cloud” to make sure the name of the clouds are exactly the same on the client as on the controller…

This is by all means great news for the simplified way of adding in new users to a/the Juju infrastructure. Thanx alot for taking us there!

Nice! Glad you found a path. Can you give an example of what you mean by “the client must not provide the username at login”? Do you mean providing the username argument to the login command?

As for the clouds, you should be able to use something like

juju list-clouds --format=yaml

The one thing you’ll hit is a bug that I’ve asked @nammn to look into as part of his onboarding:

Clearly that’s going to be a pain point and we’re looking to have that adjusted for 2.7.

Yes, it fails with en error if you do

juju login controller-ip-or-hostname:17070 -c name-of-controller -u USER@corporate

You must instead do:

juju login controller-ip-or-hostname:17070 -c name-of-controller

… and provide the username through the candid browser dialog.