| === frankban|afk is now known as frankban | ||
| === freyes__ is now known as freyes | ||
| === freyes__ is now known as freyes | ||
| === frankban is now known as frankban|afk | ||
| === TikTok is now known as michealb | ||
| bdx | cory_fu: ran into this yet http://paste.ubuntu.com/25969059/ ? | 18:34 |
|---|---|---|
| cory_fu | bdx: I have not. | 18:36 |
| cory_fu | bdx: Do you have the latest copy of that PR? The line numbers from your stack trace don't match up. | 18:38 |
| bdx | oooh | 18:38 |
| bdx | I may not in that case | 18:38 |
| cory_fu | bdx: Though, I'm guessing it's still an issue. I think we need to check for a None result from relation_factory | 18:38 |
| cory_fu | bdx: Is there anything in the log file that syas "Unable to determine role and interface for relation" or "No RelationFactory found in ..."? | 18:39 |
| bdx | cory_fu: totally is http://paste.ubuntu.com/25969142/ | 18:42 |
| bdx | or something to that effect 2017-11-15 18:22:24 ERROR juju-log Unable to find implementation for relation: requires of juju-info | 18:43 |
| bdx | oh I think I see it | 18:43 |
| bdx | the juju-info relation is defined in the beats-base layer | 18:43 |
| cory_fu | bdx: Ok, easy fix. That just means that you're not pulling in the juju-info interface layer, but I could see not really needing it, so we should handle that case gracefully | 18:43 |
| cory_fu | Does the beats-base layer not pull the interface layer in for it, then? Maybe it just handles it manually. juju-info is a trivial relation anyway | 18:44 |
| bdx | cory_fu: https://github.com/jamesbeedy/layer-beats-base/blob/master/metadata.yaml#L6 | 18:44 |
| bdx | I'm wondering if I pull juju-info into the top layer if it would make a difference | 18:45 |
| bdx | right | 18:45 |
| cory_fu | bdx: Yeah, it's because it's missing the interface:juju-info in https://github.com/jamesbeedy/layer-beats-base/blob/master/layer.yaml | 18:46 |
| cory_fu | But I can't really claim that that's wrong, given how trivial juju-info is | 18:46 |
| bdx | right | 18:46 |
| bdx | cory_fu: adding juju-info fixed | 18:54 |
| bdx | thanks | 18:54 |
| bdx | I should have caught that | 18:54 |
| cory_fu | bdx: NP, I appreciate you bringing it up, because I think it's an issue in the PR that needs to be fixed | 18:58 |
| bdx | np, I filed a bug for you | 18:58 |
| R_P_S | hi, I created a juju controller on a temporary machine. I'd like to be able to login as admin/superuser on another machine. How do I find the registration string for the superuser to register the controller on the 2nd machine? | 19:58 |
| rick_h | R_P_S: there isn't one. You have to add a new user and grant them admin rights and login as that new user. | 20:08 |
| * rick_h wonders if we got working the juju login to an ip address | 20:09 | |
| R_P_S | so the superuser can be removed then once this alternate user is added? | 20:09 |
| rick_h | R_P_S: hmmm, honestly I've never tried. You might need to give the new user superuser access so you've got one superuser in the system...but not sure | 20:10 |
| R_P_S | yeah, that's precisely what I'm worried about losing... superuser access | 20:10 |
| R_P_S | trying to remove single point of failure, but I can't assume the instance I used to create the controller will survive forever | 20:10 |
| rick_h | R_P_S: so I wonder if you can do this, the admin's password is written out in one of the cache files, you can do `juju login -u admin $ipofcontroller` I think | 20:11 |
| rick_h | R_P_S: well that's what the HA is for and yea, add additional users, give them superuser, etc. | 20:11 |
| rick_h | R_P_S: to be honest, back up .local/share/juju and you're ok | 20:11 |
| rick_h | R_P_S: so .local/share/juju/credentials.yaml has the auto generated admin credentials for the controller | 20:13 |
| R_P_S | ok... | 20:15 |
| R_P_S | how does HA of the controller (not gotten there yet) save the credentials on a completely arbitrary machine? | 20:15 |
| rick_h | R_P_S: sorry, I just meant as far as being resilient. ha controllers is good stuff, but yea doesn't effect the client end | 20:16 |
| rick_h | so summary: 1) create new users, register them so you can login with them as username/password's you know | 20:16 |
| R_P_S | ok, got it... message just lost in translation :) | 20:16 |
| rick_h | 2) you might be able to login as admin on another machine using the generated password | 20:16 |
| rick_h | 3) ignore me, HA doesn't effect clients at all and I got confused mid-stream :) | 20:17 |
| R_P_S | looks like I can create another superuser | 20:20 |
| rick_h | definitely https://jujucharms.com/docs/stable/users | 20:20 |
| R_P_S | hum, so the admin user never gets logged out? just tried a manual logout and for an error "preventing account loss" due to no password | 20:23 |
| R_P_S | so each registration string is just password setting, along with configuration of the controller? | 20:25 |
| rick_h | R_P_S: hmm, so the password should be the generated one. It's auto used generally | 20:25 |
| rick_h | R_P_S: yea, it sets up a new account so you can give them a unique password and get the controller info cached | 20:25 |
| R_P_S | weird, so I tried creating a 2nd user account, and going through the registration flow I needed to enter in a different controller name | 20:27 |
| rick_h | R_P_S: right, because it's on the same machine. There's a single controller cache | 20:28 |
| R_P_S | but then it said secret key for user "abc" not found | 20:28 |
| rick_h | hmm, hmm, not sure on that bit | 20:29 |
| R_P_S | so to create a 2nd user, say for testing permissions and using logout/login between the users, how would I complete the registration for the 2nd user? wipe .cache? | 20:29 |
| rick_h | R_P_S: well I'd just create a lxd container or something to setup a second home basically | 20:30 |
| rick_h | R_P_S: you could probably do it by changing the $JUJU_DATA path or something to keep them separate | 20:30 |
| rick_h | or actually, given that just another user on the local system so there's two $HOME or something | 20:30 |
| R_P_S | yeah, I was thinking just a different user on the linux box itself... but that seems... clumsy | 20:31 |
| R_P_S | hum, so I remove-user the 2nd dummy account, and now it cannot be recreated. does the controller seriously permanently blacklist that username? | 20:34 |
| rick_h | yes, due to the auditing effects usernames are use once | 20:36 |
| R_P_S | that seems strange then to have both remove-user and disable-user when the functionality is the same, but the former also "blacklists" the user. | 20:38 |
| R_P_S | bit of a tangent, but it seems that any company would want to delete users after turnover to keep the list from growing unwieldly, but then a rehire would be forced to get a new username | 20:39 |
| rick_h | well but if they were auditing who did what when, especially around the turn over time it's best to keep them split. It's reasonable the new person is unlikely to have the same name. If the same person is rehired, well then I grant you | 20:41 |
| R_P_S | so, it turns out there's an extra permissions level - owner. tried to disable the admin account, but the error just states "cannot disable controller model owner" | 20:41 |
| rick_h | ah, right. I'm working on defining some work to get rid of that | 20:42 |
| rick_h | it's something that's outlived it's usefulness as things scale long term, it's on the todo list to clean up but only defining the work at this point | 20:42 |
| R_P_S | is it safe to "lose" the admin account once other superusers have been created? | 20:43 |
| rick_h | yes, there's nothing the admin can do that a user with superuser permissions cannot | 20:44 |
| R_P_S | or should the .local/share/juju be permanently backed up for the admin user | 20:44 |
| R_P_S | ah, ok | 20:44 |
| rick_h | it's why I started with "add new accounts" as it's usually the best path long term to give users proper accounts with permissions and manage them vs continue to use the special "admin" account | 20:44 |
| R_P_S | I'm still working with a conjure-up demo... I'm about to wipe the last of it and try to build it properly | 20:45 |
| rick_h | cool stuff | 20:45 |
| R_P_S | I was surprised by the lax security of conjure-up though, didn't request VPC info.... it'd been so long since I'd created an instance in ec2-classic I'd forgotten it was there and trying to figure out why the VPC wasn't specified on the isntance | 20:46 |
| R_P_S | actually, while I have you here... after creating instances via juju, can I modify the security groups? seeing 0.0.0.0/0 ingress ssh makes me want to cry | 20:47 |
| rick_h | so you can specify the vpc details during bootstrap with --vpc-id | 20:47 |
| rick_h | as far as that goes, it's a feature folks have requested but to do things like juju run and juju ssh/scp clients outside need ssh access so it's not currently able to be blocked out | 20:48 |
| R_P_S | yeah, I'd found vpc specification in the docs since conjure-up | 20:48 |
| rick_h | I think you can leverage a vpc to help lock that down somewhat, bdx might have more details around that | 20:48 |
| R_P_S | juju ssh uses external IPs? | 20:49 |
| rick_h | yes, because a controller can host many models, and the client is not on the same network, it tries to use external addresses to help map to the machines | 20:49 |
| R_P_S | oh dear | 20:49 |
| rick_h | you can have model access but no controller access so you can't ssh through/onto the controllers themselves as a user on a model | 20:49 |
| R_P_S | that completely breaks the idea of bastion hosts, VPCs and even AWS security group <-> security group references | 20:51 |
| rick_h | it's not going and sticking elastic ips on all the instances or anything | 20:52 |
| R_P_S | I'd like to both assume and enforce the client being on the same network (VPC+peering) as any instance created by juju, including the controller itself. | 20:54 |
| R_P_S | now, this scope is for kubernetes... | 20:55 |
| R_P_S | it sounds like I should be putting absolutely everything except the load balancer in the public subnet... | 20:56 |
| R_P_S | master, workers, etcd,easyrsa all in private subnet? then they wouldn't have a publuic IP and juju ssh would work off the internal IP? | 20:57 |
| R_P_S | doh... logic inverted 2 lines up. everything except load balance in private subnet | 20:57 |
| R_P_S | I think I may just need to try this out now... rebuild controller in VPC and see what happens | 20:58 |
| R_P_S | but I believe the question technically still stands. If the client (bastion host) has ACLd to the SG containing all the juju instances for private subnet instances, that can be changed and juju won't complain? | 20:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!