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