[14:08] <nvucinic> hi guys, i have disable_root: 0 and ssh_pwauth: 1, and after cloud init passes i cannot log into instance with my root pwd, or over ssh 
[15:57] <smoser> nvucinic, it should be supported.
[18:28] <smoser> nvucinic, its a bug. its a result of sshd config being changed in 14.04 to disallow root login by default
[18:28] <smoser> it went from
[18:28] <smoser>  PermitRootLogin without-password
[18:28] <smoser> to
[18:28] <smoser> err.  from
[18:28] <smoser>  PermitRootLogin yes
[18:28] <smoser> to
[18:28] <smoser>  PermitRootLogin without-password
[18:28] <smoser> harlowja, around ?
[18:28] <harlowja> sup dawg
[18:29] <smoser> for some work i'm doing on containersa nd openstack...
[18:29] <harlowja> uh oh
[18:29] <smoser> i need to store some information for a user in the db
[18:30] <smoser> here. http://paste.ubuntu.com/8507232/
[18:31] <harlowja> hmmm
[18:32] <harlowja> so this would be like a keystone addition?
[18:32] <harlowja> or a nova + keystone one
[18:32] <smoser> well, i think so. i think that s  where that information would make sense to store.
[18:32] <smoser> well, nova uwell, nova needs to store and retrice that information about a user *somewhere*
[18:32] <smoser> in a per-az way.
[18:33] <harlowja> ya
[18:33] <smoser> i assumed that keystone would make sense, but if you tihnk something better , thats fine too.
[18:33] <harlowja> seems like keystone, although i don't know how much knowledge keystone has of nova azs
[18:34] <harlowja> i'd say bug the keystone guys :-P
[18:34] <harlowja> wonder if they have any input
[18:35] <smoser> well, i'm assuming that i can get my own az
[18:36] <smoser> ie, the nova system would be able to know that of itself, and maintain it itself.
[18:37] <smoser> {'az1': {'subuid': [1,2,3], 'subgid', [5,6,7]}, 'az2': {...}}
[18:38] <harlowja> sure, nova i guess can have that
[18:47] <smoser> so is there some similar code that i could look at / base off of that needs to lock and update a keystone value ?
[18:51] <harlowja> hmmm
[18:51] <harlowja> not sure :-/
[19:23] <smoser> thanks for reading, harlowja.
[19:23] <harlowja> :)
[20:33] <nvucinic> smoser: yes, but i am using it on centos 6, and still i cannot login even through console after cloud init 
[20:34] <nvucinic> not ssh, console.
[20:35] <smoser> nvucinic, i'd need more info to debug. 
[20:35] <smoser> you might try adding a backdoor user
[20:36] <smoser> logging in as hat user, and then watching it fail for root
[20:36] <smoser> theres a fair shot that https://code.launchpad.net/~smoser/+junk/backdoor-image
[20:36] <smoser> will allow you to backdoor an image vairly easiy
[20:39] <nvucinic> smoser: i can login as root with key 
[20:40] <nvucinic> but first password that is setup on image before cloud init is not working anymore 
[20:40] <nvucinic> i am using "golden template"  for all instalation and cloud init for network configuration on first boot 
[20:41] <nvucinic> so after cloud init gets initilized i cannot login with root password that setup on template 
[20:41] <smoser> are you sure you could log in with password before ?
[20:43] <nvucinic> yup, 100% sure 
[20:43] <nvucinic> after cloud init i can login only via ssh key 
[20:43] <nvucinic> password for root fails at console and ssh 
[20:55] <smoser> nvucinic, please file a bug. maybe harlowja can look at it . i dont have a setup access to centos that i could easily poke at.
[20:55] <smoser> i'm not sure what it would be doing that would lock root out. other than if you have 'user' to 'root' .
[20:55] <smoser> and lock_passwd for that.
[20:59] <nvucinic> i can paste your tommorow whole config 
[21:58] <harlowja> nvucinic if u can get the logs, the config that would be great
[21:58] <harlowja> *cloud-init logs without secret stuff in them
[21:58] <harlowja> that'd help figure out whats happening