Juju controllers with Candid

juju
1

Looking for some help using Candid with Juju and MAAS.

I have managed to create a juju controller for a MAAS instance with CANDID. We use our company LDAP/ActiveDirectory.

This is how we bootstrapped it:

juju bootstrap my-maas beta1
–config identity-url=https://10.6.5.82:8081
–config identity-public-key=i9zsvCkISgdPryiYWwgMyLsro9d+IhywZBDVl+9PzmA=
–config allow-model-access=true

I have managed to login.

erik@bionic-dev-1:~$ juju login -u sssler@corporate Opening an authorization web page in your browser. If it does not open, please open this URL: https://10.6.5.82:8081/login-legacy?did=3dc9a8689f762c4a358896233aac80dd05a9114b4063aad2106e9f00e55c7163 Couldn’t find a suitable web browser! Set the BROWSER environment variable to your desired browser.

I can use it and create models etc.

erik@bionic-dev-1:~$ juju status Model Controller Cloud/Region Version SLA Timestamp test1 beta1 sss 2.4.7 unsupported 14:09:53+01:00

Model “SSSLER@corporate/test1” is empty. erik@bionic-dev-1:~$ juju switch test1 beta1:SSSLER@corporate/test1 (no change)

I now move on, as admin, and give Johan login permissions to the controller:

erik@bionic-dev-1:~$ juju login -u admin -c beta1 please enter password for admin on beta1: Welcome, admin. You are now logged into “beta1”.

There are 3 models available. Use “juju switch” to select one of them:

  • juju switch controller
  • juju switch default
  • juju switch SSSLER@corporate/test1 erik@bionic-dev-1:~$

Adds his login grant:

erik@bionic-dev-1:~$ juju grant jhacxc@corporate login

I then logout and login in back as my regular user, the below shows that I’m now acting as my regular user.

erik@bionic-dev-1:~$ juju whoami Controller: beta1 Model: test1 User: SSSLER@corporate

Now I add Johans access to the test1 model:

juju grant jhacxc@corporate read test1

Johan manages to login:

juju login -u jhacxc@corporate Opening an authorization web page in your browser. If it does not open, please open this URL: https://10.6.5.82:8081/login-legacy?did=18a0433283d4e0ee3af1a48a48ccbb1804001d624caf12a44c081e40e13b096d Couldn’t find a suitable web browser! Set the BROWSER environment variable to your desired browser.

But the problem now is that he can’t see the model “test1” which he was granted read permissions to above.

hallback@t1000:~/.local/share/juju$ juju models Controller: beta1

Model Cloud/Region Status Access Last connection

There are no models available. You can add models with “juju add-model”, or you can ask an administrator or owner of a model to grant access to that model with “juju grant”.

Are we doing this the right way and have found a bug? We have fought a bit with this, but to no success yet. Johan here is also known as @hallback

erik@bionic-dev-1:~$ juju version 2.4.7-bionic-amd64

2 Likes
2

s/Now I add Johans credentials to the test1 model/Grant Johan access to the model/

1 Like
3

It looks to me like you’ve done everything correctly here. I did a similar exercise using lxd and the candid snap and it worked for me, here’s a transcript of what I did in case you spot a difference:


$ /snap/bin/juju bootstrap localhost localhost --config identity-url=http://boober:8081 --config identity-public-key=gBz+g7zylpiNUZUZEEcc7/T6+P38xXzYpIXccxCZXWU= --config allow-model-access=true --no-gui
Creating Juju controller "localhost" on localhost/localhost
Looking for packaged Juju agent version 2.4.7 for amd64
To configure your system to better support LXD containers, please see: https://github.com/lxc/lxd/blob/master/doc/production-setup.md
Launching controller instance(s) on localhost/localhost...
 - juju-425e00-0 (arch=amd64)          
Installing Juju agent on bootstrap instance
Juju GUI installation has been disabled
Waiting for address
Attempting to connect to 10.3.1.25:22
Connected to 10.3.1.25
Running machine configuration script...
Bootstrap agent now started
Contacting Juju controller at 10.3.1.25 to verify accessibility...
Bootstrap complete, "localhost" controller now available
Controller machines are in the "controller" model
Initial model "default" added
$ /snap/bin/juju change-user-password 
new password: 
type new password again: 
Your password has been changed.
$ /snap/bin/juju grant user1@external add-model
$ /snap/bin/juju grant user2@external login
$ /snap/bin/juju logout 
Logged out. You are still logged into 7 controllers.
$ /snap/bin/juju login -u user1@external
Opening an authorization web page in your browser.
If it does not open, please open this URL:
http://boober:8081/login-legacy?did=f487cbf2735539d63bcb13139864912e38e8212894927011df5c5c0c02e3ed9c
Created new window in existing browser session.
Welcome, user1@external. You are now logged into "localhost".

There are no models available. You can add models with
"juju add-model", or you can ask an administrator or owner
of a model to grant access to that model with "juju grant".
$ /snap/bin/juju add-model model1
Uploading credential 'localhost/user1@external/localhost' to controller
Added 'model1' model on localhost/localhost with credential 'localhost' for user 'user1'
$ /snap/bin/juju deploy ubuntu
Located charm "cs:ubuntu-12".
Deploying charm "cs:ubuntu-12".
$ /snap/bin/juju grant user2@external read model1
$ /snap/bin/juju logout
Logged out. You are still logged into 7 controllers.
$ /snap/bin/juju login -u user2@external
Opening an authorization web page in your browser.
If it does not open, please open this URL:
http://boober:8081/login-legacy?did=83718f1dfddc5c0385b246bd923ce7cee4f9c7c5a45643503077e6672710b558
Created new window in existing browser session.
Welcome, user2@external. You are now logged into "localhost".

Current model set to "user1@external/model1".
$ /snap/bin/juju models 
Controller: localhost

Model                   Cloud/Region         Status     Machines  Access  Last connection
user1@external/model1*  localhost/localhost  available         1  -       never connected

$ /snap/bin/juju whoami 
Controller:  localhost
Model:       user1@external/model1
User:        user2@external
$ /snap/bin/juju status
Model   Controller  Cloud/Region         Version  SLA          Timestamp
model1  localhost   localhost/localhost  2.4.7    unsupported  16:52:30Z

App     Version  Status       Scale  Charm   Store       Rev  OS      Notes
ubuntu           maintenance      1  ubuntu  jujucharms   12  ubuntu  

Unit       Workload     Agent      Machine  Public address  Ports  Message
ubuntu/0*  maintenance  executing  0        10.3.1.251             (install) installing charm software

Machine  State    DNS         Inst id        Series  AZ  Message
0        started  10.3.1.251  juju-07412b-0  bionic      Running

The only suggestion I have is to run a juju show-model test1 as SSSLER@corporate that will include a list of all granted users and ensure that jhacxc@corporate is really in there. If they are then I suspect you’ve found a juju bug of some sort.

2 Likes
4

The clear difference, is that you grant “add-model” rights to the user, which according to documentation, will require keys/credentials for the underlying cloud. (I only grant “read”)

For the external user to create models from the controller, they must have credentials for that provider, for example, GCE or AWS. Any models created by this user will use these credentials.

In our setup, Johan does not have access to the underlying cloud yet. Hence, I only grant Johan “login” + “read” for him to just be able to “see” stuff. Thats good enough for a first step.

Also, our underlying cloud is MAAS, not LXD.

6

I can confirm that my user had been granted access to the model, but you pointed us in the right direction. As soon as we granted access to JHACXC@corporate instead of jhacxc@corporate, things started working immediately.

7

Yes! As @hallback pointed out, the case sensitivity mattered here.

Eg. The account: jhacxc@corporate is NOT = JHACXC@corporate

Is this (being case sensitive) the intended functionality since it adds a bit confusion and is error prone since it is not always case sensitivity. @Dmitrii would perhaps know?

8

I think we have to match case as not all identity providers will promise not to match case. I know it’s kind of a pain in the MS/AD world, but not sure how best to be flexible and correct.

1 Like
9

My thoughts exactly @rick_h and likely not easy to work around. But, I am no expert in the identity domains.

10

So now that you’ve got this all figured out it’s time to turn this into a tutorial and Juju Show demo next Wed? wink wink

1 Like
11

@rick_h - Let us try put this down into a tutorial and when its ready, I’ll definitely go through it during a juju-show. Let me come back to you on this topic.

1 Like
12

hi ,
i try to deploy OPNFV platform with juju, but I get the following error when I try to setup
can you help me?

ERROR cannot deploy bundle: cannot add relation between “ntp:juju-info” and “nodes:juju-info”: cannot add relation “ntp:juju-info nodes:juju-info”: principal and subordinate applications’ series must match
11:00:02 DEBUG cmd supercommand.go:459 error stack:
cannot add relation “ntp:juju-info nodes:juju-info”: principal and subordinate applications’ series must match

github.com/juju/juju/cmd/juju/application/bundle.go:692: cannot add relation between “ntp:juju-info” and “nodes:juju-info”
github.com/juju/juju/cmd/juju/application/deploy.go:720: cannot deploy bundle

13

Koksalbo, that’s kind of a different thread of stuff there. Why don’t you please setup a new discourse post with your question.

In this case, you’ll find that when ntp was deployed it was deployed with one series (maybe xenial, or trusty) and the other charm, nodes, is a different series (again maybe it’s bionic) and so they can’t relate to each other. You need to make sure they match and have the same series. You can deploy ntp multiple times, once for each series you need if you support different series in your workloads.

juju deploy ntp --series=xenial
juju deploy ntp-bionic --series=bionic

Something along those lines. HTH and please do split off into its own post.