Thursday, 2014-04-17

morganfainbergtopol, eventlet isn't py33 friendly and -infra folks think it wont ever be00:00
dolphmtopol: tupil/asyncio/forgotheothername00:00
topolmorganfainberg, I agree. Just wasnt sure what the replacement would be00:00
dolphmtulip for the less-dyslexic00:00
dolphmtopol: https://code.google.com/p/tulip/00:01
dolphmnotable Author:Guido van Rossum <guido at python.org>00:01
morganfainbergdolphm, trollius00:02
topoldolphm, cool I will take a look at Tulip. Sounds interesting00:02
topolany patches on this yet?  Does it require py33?00:02
*** browne has quit IRC00:03
morganfainbergiirc trollius is the py27/33 compatible version00:04
dolphmtopol: no and ^00:04
* topol topol's boss is informing him he has to step away from this interesting conversation to lay out clothes that are in the dryer :-(00:04
dolphmtopol: you should maybe review your job description with your boss00:05
topoltopol has no comment.  So Is Tulip multithreaded?00:06
* topol dryer needs a few mins to heat up00:06
*** marcoemorais has joined #openstack-keystone00:07
topolso it looks like it is thread friendly00:08
*** gokrokve has joined #openstack-keystone00:08
topolHave any of the other openstack project moved to Tulip or will Keystone be the first?00:09
morganfainbergtopol, don't think anyone has moved there yet00:11
morganfainbergtopol, but i can't say that definitively00:11
*** marcoemorais has quit IRC00:11
dolphmwe'll probably see oslo dep on trollius first00:11
dolphmi also just discovered that enovance wrote trollius00:11
morganfainbergdolphm, yeah.00:12
dolphmalso enovance uses mercuruial00:12
dolphmmercurial*00:12
* morganfainberg doesn't like mercurial00:14
morganfainbergi prefer git00:14
morganfainbergand the git-hg plugin is... well ok but not great00:14
ayoungCan't we skip all that, run in HTTPD and be done with it?  Please?00:20
ayoungmorganfainberg, there is a git plugin for mercurial.  It means you really only have to do git00:21
morganfainbergayoung, it has limitations based on branching differences between the backends00:21
morganfainbergthat is the only real issue i've run into00:21
morganfainberghg's branching makes my head hurt sometimes.00:21
morganfainbergi think that's because i've been using git a lot00:21
ayoungmorganfainberg, yeah, I'd rather not deal with hg, either.  Seems like git is the bettter thought out of the two.00:22
*** ilives has joined #openstack-keystone00:22
morganfainbergayoung, yep. but if you're contributing to tox among other things, hg is the tool used.00:22
ayoungmorganfainberg, NSS, too.  Looks like the Mozilla team switched to mercurial00:22
*** bknudson has joined #openstack-keystone00:23
morganfainbergayoung, boo.00:23
morganfainbergayoung, at least it isn't bzr00:23
ayoungmorganfainberg, at least is isn't CVS, which it was until recently00:23
morganfainbergayoung, not sure, is cvs better or worse than bzr?00:25
topoldolphm, why would we have to deal with mecurial?00:25
morganfainbergtopol, if you're contrbuting due to bugs to the project00:25
topoljust becuase enovance usse it? You think we need to contribute to Tulip?00:25
morganfainbergtopol, and being that OpenStack is OpenStack, we'll probably find bugs and need to fix it.00:26
topolmorganfainberg, K, gotcha00:26
openstackgerritNathan Kinder proposed a change to openstack/keystone: Remove LDAP password hashing code  https://review.openstack.org/8810900:26
topolperhaps dolphm will voluntold a tulip ambassador to have to deal with mercurial???00:27
morganfainbergtopol, hehe00:27
*** ilives has quit IRC00:27
topol(patch submission to Tulip)00:27
dolphmtopol: hopefully we won't have problems with trollius :)00:27
morganfainbergdolphm, ++00:28
*** ilives has joined #openstack-keystone00:28
topoldolphm, does it have a pretty solid track record?00:28
morganfainbergand it isn't exactly hard to find enovance folks if we do have an issue00:28
bknudsonjamielennox: did you have comments on https://review.openstack.org/#/c/82713/ ? stevemar mentioned you had comments on it00:29
topolat least it has an apache2 license00:29
dolphmtopol: i don't know that anyone is using trollius, but hopefully it's just a py2 backport of tulip and doesn't add any untested complexity00:30
jamielennoxbknudson: +A - i was talking with gyee about it a while ago - i think we should have made that core api00:35
*** nkinder has quit IRC00:37
*** theocean154 has joined #openstack-keystone00:45
*** marcoemorais has joined #openstack-keystone00:49
*** marcoemorais1 has joined #openstack-keystone00:51
*** marcoemorais has quit IRC00:54
*** dstanek has joined #openstack-keystone01:01
bknudsondolphm: https://bugs.launchpad.net/python-keystoneclient/+bug/936404 looks like it's about the auth_token middleware01:01
uvirtbotLaunchpad bug 936404 in python-keystoneclient "No handlers could be found for logger "keystoneclient..."" [Low,In progress]01:01
bknudsonnot the keystone cli01:01
bknudsonthat's an old bug.01:02
bknudsonok, then dolphm commented that this still affects the cli.01:03
openstackgerritBrant Knudson proposed a change to openstack/python-keystoneclient: CLI always configures logging  https://review.openstack.org/8809701:05
ayoungjamielennox, so I tested out Jose's kerberos plugin with Apache.  I needed to make a server side change to get it to work:01:09
jamielennoxayoung: ah, i was attempting to do that the other day when i was having all those IPA issues01:10
jamielennoxayoung: wait client side or server side/01:10
ayounghttp://fpaste.org/94829/97028139/01:10
ayoungjamielennox, that change plus a config file edit01:10
ayoungin [auth]01:11
ayoungkerberos=keystone.auth.plugins.external.KerberosDefaultDomain01:11
ayoungmethods=kerberos,password,token01:11
jamielennoxI don't think you want to inherit defaultdomain01:11
ayoungjamielennox, meh, it was just a test.01:11
ayoungjamielennox, if the plugin was external I would have not had to make any change01:12
ayoungmethod='external'  would have worked with the existing set of plugins.01:12
jamielennoxdo you have the link to review handy?01:12
ayoungI'm tempted to make that the standard for the client side01:12
ayoungjamielennox, nope, didn't post it.01:13
ayoungWas still working things out01:13
ayoungI can give you access to the machine if you want, though01:13
jamielennoxi meant his01:13
jamielennoxit seems abandoned01:13
ayoungah...one sec01:14
ayounghttps://review.openstack.org/#/c/74317/01:14
jamielennoxayoung: this was my WIP changes to that patch: http://paste.openstack.org/show/76013/01:16
jamielennoxbut i never got to test it out01:16
openstackgerritRichard Megginson proposed a change to openstack/keystone: better handling for empty/None ldap values  https://review.openstack.org/7600201:17
*** dstanek has quit IRC01:25
ayoungjamielennox, lets not do that01:27
ayoungjamielennox, I really don't want to support Kerberos in Python.01:27
ayoungrichm, Ugh...we need Live LDAP testing in the Gate.  Otherwise, changes like yours never get real testing01:29
richmayoung: did you find something?01:29
ayoungrichm, nope.01:29
richmyeah, same problem with designate + live ipa testing01:30
ayoungrichm, but I rely on the Gate to check "it does what we think it does"01:30
ayoung++01:30
*** dstanek has joined #openstack-keystone01:30
jamielennoxayoung: i thought that was a really good compromise01:30
ayoungrichm, I was hoping to have multi domain backends and then LDAP would be tested alongside the SQL one....01:31
ayoungjamielennox, I don't.  And I don't think it is really needed.01:31
jamielennoxjose would apparently disagree and i can see others wanting to go that way01:31
ayoungI have yet to hear a compelling argument for doing Negotiate or X509Client cert validation in Python code instead of HTTPD01:31
ayoungJose and I chatted about it01:32
ayoungHe didn't realize that you could just mount the "main"  (public) router in a kerberized suburl but return the rest from a non-kerberized in the catalog01:32
ayoungthat is the setup I have on the system I tested this on:01:32
jamielennoxright, using the same endpoint is the main one01:33
ayounghttp://fpaste.org/94833/13976984/  jamielennox01:33
ayoungI need to get a user cert setup and add that in with01:34
ayoungNSS_VerifyClient or whatever the config option is01:34
*** theocean154 has left #openstack-keystone01:34
ayoungNSSVerifyClient require01:34
*** richm has quit IRC01:34
ayoungaccording to the conf file in /etc/httpd/conf.d01:35
*** marcoemorais1 has quit IRC01:46
*** Chicago has quit IRC01:47
*** dstanek has quit IRC01:55
*** amcrn has quit IRC01:56
*** dstanek has joined #openstack-keystone02:05
*** derek_c has quit IRC02:07
*** derek_c has joined #openstack-keystone02:08
topolayoung, did you see Remove LDAP password hashing code https://review.openstack.org/8810902:08
ayoungtopol, click on the link yourself02:09
topolits pulling out code you put in originally but I can remember why you put it in02:09
topolgotcha02:09
openstackgerritLi Ma proposed a change to openstack/keystone: Password trunction makes password insecure  https://review.openstack.org/7732502:09
topolfigured that would happen :-)02:09
topolthats what I get for getting dinner02:10
*** david-lyle has joined #openstack-keystone02:17
*** dstanek has quit IRC02:19
ayoungtopol, actually, I was wondering if CERN was using that02:19
ayoungI suspect not, but worth doing due dilligence02:20
topolayoung, I vaguely recall there being a reason for it. Trying to dig it out of my brain. using git history and git blame to help jog my memory02:21
ayoungtopol, he alludes to it in the commit message:  its for Fake02:22
ayoungall passwords are checked hashed.02:22
ayoungI think simplebind does that02:22
topolits been there a while. I thought it was for something else. But I'll just double check. Its bugging me02:22
ayoungSo we should probably remove the logic from the LDAP password code and put it into Fake, but it might be that some LDAP code we don't know about just passes the password on through02:23
ayoungtopol, nkinder knows LDAP, much better than I do.  He's the manager for the RH DS team....02:23
*** dstanek has joined #openstack-keystone02:23
ayoungor at least he was on the team...need to check the org chart02:23
*** derek_c has quit IRC02:25
topolayoung, so yes it looks like it was put in for the fakeldap: https://github.com/everett-toews/keystone/commit/63437e9dca3b969c917fb138716aa4d3e5fabafa02:26
ayoungtopol, his point is that the LDAP backends may not even allow it, but I would expect the LDAP live tests to barf if that were the case.  Its Red Hat Summit this week, so we can discuss with him early next week02:27
topolso ayoung if its causing nkinder to hit LDAP bugs I think its worth pulling it out once he refactors it to how you recommend02:27
ayoungtopol, I'll ask Jose to take a look, too02:28
*** zhiyan_ is now known as zhiyan02:29
ayoungjamielennox, so...I did yum install mod_nss on the packstack box, and HTTPD refuses to start.  I did the same thing on the devstack box and it worked fine02:30
ayoungso...just to check, I modified the file in conf.modules.d that pulls in nss, put garbage in there and restarted HTTPD,  with no change02:30
jamielennoxayoung: i've never really done anythin with packstack02:31
ayoungthat seems to me to say that the NSS module is not getting added to Apache02:31
ayoungjamielennox, yeah, neither have I02:31
jamielennoxbut i can't see why it's different02:31
ayoungjamielennox, something we are doing in Packstack configuring HTTPD means that mod_nss is not getting added02:31
ayoungthe error indicates that as well:02:31
ayoungInvalid command 'NSSPassPhraseDialog', perhaps misspelled or defined by a module not included in the ser02:32
jamielennoxyea, that sounds like a packagin thing02:33
jamielennoxhmm, the distinction between what is middleware and what is core is a pain in pecan02:34
ayoungjamielennox, so there is a set of module files that are supposed to be parsed in ABC order02:34
openstackgerritA change was merged to openstack/python-keystoneclient: Allow session to return an error response object  https://review.openstack.org/8363002:35
ayoungand nss adds one there. its at the same level as another (10-wsgi.conf)02:35
*** ilives has quit IRC02:35
ayoungbut..the conf.d directory in packstack is crazy02:36
ayoungand...it looks like maybe a Puppetism?02:36
*** ilives has joined #openstack-keystone02:36
ayoungHmm...02:36
ayoungOK,  something pulls all of the module load files into /etc/httpd/conf.d  I suspect Puppet02:38
ayoungI need to selinux relable it02:38
*** dstanek has quit IRC02:38
ayoungjamielennox, I have02:39
ayoung-rw-r--r--. root root system_u:object_r:httpd_config_t:s0 nss.conf02:39
ayoungbut02:39
ayoung-rw-r--r--. root root unconfined_u:object_r:httpd_config_t:s0 nss.load02:39
ayoungits not just restorecon...02:39
openstackgerritA change was merged to openstack/python-keystoneclient: Implement endpoint filtering functionality on the client side.  https://review.openstack.org/8271302:41
jamielennoxayoung: and that fixes it02:46
ayoungjamielennox, still battling selinux02:46
ayoungI did a cp, but that made it unconfined.  I need it to look like the line above02:47
ayoungOK,  doing a mv worked02:48
ayoungjamielennox, yeah, that worked02:48
ayoungARGH.  dleted the wrong file02:49
ayoungbut easy to fix02:49
*** derek_c has joined #openstack-keystone02:50
*** lnxnut_ has joined #openstack-keystone02:51
*** lnxnut has quit IRC02:53
*** mberlin has quit IRC02:56
jamielennoxayoung: can you explain the need for: https://github.com/openstack/keystone/blob/master/keystone/trust/controllers.py#L18603:00
ayoungparanoia03:00
ayoungit went in before RBAC was rock solid03:00
jamielennoxif you've got protected() do you need assert_admin?03:00
ayoungI trust RBAC now, I don't think it was there when the initial call went in.  We can possibly remove that03:01
ayoungI think the idea is that no one should just be listing trusts03:01
ayoungDid I write that?03:01
*** browne has joined #openstack-keystone03:02
ayoungjamielennox, there were close to 100 revisions of that patch and the one that followed with the tests.  My guess is the rationale lies in  the code reviews03:03
jamielennoxayoung: hmm, it looks like the route is allowed if you use the correct user parameters, but if you want to list all you need admin03:06
*** browne has quit IRC03:06
jamielennoxthough the admin enforced by that call is a bit odd03:06
ayoungjamielennox, agreed.  I added in the is_admin check long before the policy check in that tree03:07
jamielennoxis there a way to write that properly now?03:07
ayounghttps://review.openstack.org/#/c/20289/12/keystone/trust/controllers.py  does not have it,  but 13 does03:07
ayoungIt would have to be two different calls03:07
ayoungone for list trusts for the user and one for list all/03:08
jamielennoxor is it something we are stuck with?03:08
jamielennoxayoung: it appears to be the only v3 route that uses that methohd03:10
ayoungjamielennox, what is the issue?03:11
jamielennoxayoung: trying to clean up the controllers to see what i can do with pecan03:11
*** mberlin has joined #openstack-keystone03:12
ayoungjamielennox, I think you can make changes there, so long as we are clear with the API doc.  I suspect that we need two routes, one for the admin list-all, and one for the explicit query-parameter.  But there might be a  way to do it with an addition @protected call for just the admin portion03:12
openstackgerritDolph Mathews proposed a change to openstack/keystone: More notification unit tests  https://review.openstack.org/8165903:13
ayoungif you refactor out the admin call into a public method on the controller, and put a decorator on it, the RBAC evaluated with be first the more permissive one, and then the is_admin one.03:13
ayoungdoes that make sense?03:13
jamielennoxnot particularly - but i'm really not trying to restructure that part of auth, i'm just trying to figure out the exact dependencies of everyhting03:14
ayoungjamielennox, ok, if you need to get rid of the is_admin call, let me know and I can help you with the policy for it.03:17
ayoungOK, I got Horizon NSS SSLifies, just need a redirect for http:  to https:03:18
*** stevemar has joined #openstack-keystone03:20
*** gyee has quit IRC03:23
*** dstanek has joined #openstack-keystone03:27
*** lnxnut_ has quit IRC03:33
*** dstanek has quit IRC03:33
dolphmhttps://pypi.python.org/pypi/python-keystoneclient/0.8.003:38
*** bach has joined #openstack-keystone03:39
*** zhiyan is now known as zhiyan_03:41
*** bach has quit IRC03:48
*** bach has joined #openstack-keystone03:53
*** topol has quit IRC03:58
openstackgerritA change was merged to openstack/keystone: Adding one more check on project_id  https://review.openstack.org/8519903:58
*** bach_ has joined #openstack-keystone03:59
*** bach has quit IRC04:03
*** bach_ has quit IRC04:03
*** bach has joined #openstack-keystone04:03
*** stevemar has quit IRC04:22
*** stevemar has joined #openstack-keystone04:27
stevemarmorganfainberg, i just saw the "WARNING" chat between you and dolphm, hehehe04:28
morganfainberghehehe04:30
*** jamielennox is now known as jamielennox|away04:32
*** chandan_kumar has joined #openstack-keystone04:35
*** harlowja is now known as harlowja_away04:47
*** daneyon_ has joined #openstack-keystone04:48
*** daneyon has quit IRC04:48
*** ilives has quit IRC04:49
*** ilives has joined #openstack-keystone04:50
*** daneyon_ has quit IRC04:53
*** gokrokve has quit IRC04:56
*** gokrokve_ has joined #openstack-keystone05:01
*** gokrokve_ has quit IRC05:03
*** chandan_kumar has quit IRC05:03
*** chandan_kumar has joined #openstack-keystone05:03
*** marcoemorais has joined #openstack-keystone05:21
*** boris-42 has quit IRC05:24
*** jzl-ctrip has joined #openstack-keystone05:26
*** dstanek has joined #openstack-keystone05:29
*** dstanek has quit IRC05:34
*** derek_c has quit IRC05:39
*** zhiyan_ is now known as zhiyan05:41
*** boris-42 has joined #openstack-keystone05:43
*** gokrokve has joined #openstack-keystone05:45
*** praneshp has quit IRC05:45
*** gokrokve has quit IRC05:50
openstackgerritSteve Martinelli proposed a change to openstack/keystone: add dependencies of keystone dev-enviroment  https://review.openstack.org/8047405:51
*** jamielennox|away has quit IRC05:55
*** jamielennox|away has joined #openstack-keystone05:56
*** RockKuo_ has joined #openstack-keystone06:07
*** RockKuo_ has quit IRC06:07
*** RockKuo_Office has joined #openstack-keystone06:07
*** stevemar has quit IRC06:24
openstackgerritA change was merged to openstack/python-keystoneclient: CLI always configures logging  https://review.openstack.org/8809706:27
openstackgerritA change was merged to openstack/python-keystoneclient: Create a V3 Token Generator  https://review.openstack.org/7887806:27
*** praneshp has joined #openstack-keystone06:41
*** gokrokve has joined #openstack-keystone06:45
*** Chicago has joined #openstack-keystone06:50
*** Chicago has joined #openstack-keystone06:50
*** gokrokve has quit IRC06:50
*** bach has quit IRC06:54
*** tomoiaga has joined #openstack-keystone06:54
*** praneshp has quit IRC07:01
openstackgerritMarcos Fermín Lobo proposed a change to openstack/keystone: Unimplemented get roles by group for project list  https://review.openstack.org/7647007:02
*** praneshp has joined #openstack-keystone07:08
*** morganfainberg is now known as morganfainberg_Z07:13
*** dtroyer has quit IRC07:15
*** leseb has joined #openstack-keystone07:18
*** dtroyer has joined #openstack-keystone07:18
*** ilives has quit IRC07:29
*** ilives has joined #openstack-keystone07:29
*** jaosorior has joined #openstack-keystone07:36
*** gokrokve has joined #openstack-keystone07:46
*** derek_c has joined #openstack-keystone07:47
*** gokrokve has quit IRC07:51
*** RockKuo_Office has quit IRC08:00
*** amcrn has joined #openstack-keystone08:00
*** marcoemorais has quit IRC08:07
*** amcrn has quit IRC08:11
*** amcrn has joined #openstack-keystone08:13
openstackgerritwanghong proposed a change to openstack/keystone: let ssl/pki_setup can overwrite existing files  https://review.openstack.org/8820708:20
*** derek_c has quit IRC08:24
*** andreaf has joined #openstack-keystone08:32
*** marekd|away is now known as marekd08:38
*** RockKuo_Office has joined #openstack-keystone08:39
*** chandan_kumar has quit IRC09:08
*** praneshp has quit IRC09:36
jzl-ctripfdsahkljfjklsdajklfjklfdjklsdfjklfsdjkldfs09:42
*** gokrokve has joined #openstack-keystone09:49
*** zhiyan is now known as zhiyan_09:50
*** zhiyan_ is now known as zhiyan09:52
*** gokrokve has quit IRC09:53
*** zhiyan is now known as zhiyan_09:54
openstackgerritJulien Danjou proposed a change to openstack/keystone: tokens: add a Swift backend  https://review.openstack.org/8601609:59
*** marekd is now known as marekd|away10:16
openstackgerritIlya Pekelny proposed a change to openstack/keystone: Sync test_migrations  https://review.openstack.org/8061810:17
openstackgerritIlya Pekelny proposed a change to openstack/keystone: Redundant unique constraint  https://review.openstack.org/8444710:17
openstackgerritIlya Pekelny proposed a change to openstack/keystone: Corresponding `nullable` value.  https://review.openstack.org/8444610:17
openstackgerritIlya Pekelny proposed a change to openstack/keystone: Migration DB_INIT_VERSION in common place  https://review.openstack.org/8801610:17
openstackgerritIlya Pekelny proposed a change to openstack/keystone: Compatible server default value in the models.  https://review.openstack.org/8444510:17
openstackgerritIlya Pekelny proposed a change to openstack/keystone: Explicit foreign key indexes.  https://review.openstack.org/8444410:17
openstackgerritIlya Pekelny proposed a change to openstack/keystone: Make it possible to use multiprocess file locks  https://review.openstack.org/8444810:17
openstackgerritIlya Pekelny proposed a change to openstack/keystone: Comparision of database models and migrations.  https://review.openstack.org/8063010:17
*** zoresvit has joined #openstack-keystone10:19
openstackgerritwanghong proposed a change to openstack/keystone: delete association when delete proj or endpoint  https://review.openstack.org/8755110:22
*** snikitin has quit IRC10:27
*** david-lyle has quit IRC10:35
*** lnxnut has joined #openstack-keystone10:44
*** gokrokve has joined #openstack-keystone10:50
*** gokrokve has quit IRC10:55
*** RockKuo_Office has quit IRC11:07
*** lbragstad has quit IRC11:18
*** gokrokve has joined #openstack-keystone11:50
*** gokrokve has quit IRC11:55
*** thiagop has joined #openstack-keystone12:08
*** gokrokve has joined #openstack-keystone12:09
*** gokrokve has quit IRC12:13
*** dstanek has joined #openstack-keystone12:20
*** mgagne has quit IRC12:31
*** mgagne has joined #openstack-keystone12:33
*** mgagne is now known as Guest7821712:33
*** zhiyan_ is now known as zhiyan12:38
*** dims has quit IRC12:44
*** dims has joined #openstack-keystone12:44
*** lbragstad has joined #openstack-keystone12:48
*** ilives has quit IRC13:07
*** ilives has joined #openstack-keystone13:08
*** gokrokve has joined #openstack-keystone13:10
*** stevemar has joined #openstack-keystone13:11
*** gokrokve has quit IRC13:14
*** zoresvit has quit IRC13:16
*** bach has joined #openstack-keystone13:20
*** bknudson has quit IRC13:32
dolphmOpenStack 2014.1 ("Icehouse") is released! http://lists.openstack.org/pipermail/openstack-announce/2014-April/000225.html13:33
*** chandan_kumar has joined #openstack-keystone13:36
tomoiagagreat13:41
*** bach has quit IRC13:46
*** bknudson has joined #openstack-keystone13:50
openstackgerritDavid Stanek proposed a change to openstack/keystone: Refactor notifications  https://review.openstack.org/8166013:57
*** bach has joined #openstack-keystone14:05
*** gokrokve has joined #openstack-keystone14:11
*** bach_ has joined #openstack-keystone14:12
*** bach has quit IRC14:14
openstackgerritJulien Danjou proposed a change to openstack/keystone: tokens: add a Swift backend  https://review.openstack.org/8601614:15
*** gokrokve has quit IRC14:15
ayoungdolphm, w00t!14:22
dolphmayoung: get your token compression patch re-opened :)14:22
ayoungdolphm, Roger Wilco, Over and Out!14:22
ayoungdolphm, https://review.openstack.org/#/c/71181/   need to do a manual rebase since a bunch of cms code changed14:24
*** gokrokve has joined #openstack-keystone14:27
*** bach_ has quit IRC14:28
*** gokrokve_ has joined #openstack-keystone14:29
*** bach has joined #openstack-keystone14:29
*** chandan_kumar has quit IRC14:31
*** gokrokve has quit IRC14:33
*** jagee has joined #openstack-keystone14:33
*** raildo has joined #openstack-keystone14:34
*** bach has quit IRC14:37
*** derek_c has joined #openstack-keystone14:37
*** topol has joined #openstack-keystone14:37
*** david-lyle has joined #openstack-keystone14:37
openstackgerritIlya Pekelny proposed a change to openstack/keystone: Sync test_migrations  https://review.openstack.org/8061814:37
openstackgerritIlya Pekelny proposed a change to openstack/keystone: Migration DB_INIT_VERSION in common place  https://review.openstack.org/8801614:37
openstackgerritIlya Pekelny proposed a change to openstack/keystone: Make it possible to use multiprocess file locks  https://review.openstack.org/8444814:37
openstackgerritIlya Pekelny proposed a change to openstack/keystone: Comparision of database models and migrations.  https://review.openstack.org/8063014:37
dolphmdstanek: i see you were credited as a speaker at pycon 2014 - were you even there?14:39
openstackgerritJulien Danjou proposed a change to openstack/keystone: tokens: add a Swift backend  https://review.openstack.org/8601614:39
dstanekdolphm: no, i was going to do a joint tutorial, but it turned out i wasn't able to go14:39
dolphmdstanek: i'm watching pyohio version that you actually presented instead14:39
dstanekthat was a fun audience - for whatever reason there were several people that had broken virtual box instalations14:40
dstaneki've been talking about the OWASP Top 10 for too many years now14:41
*** zematynnad has joined #openstack-keystone14:43
bknudsonI think openstack has had every one of those14:46
dolphmi'm sure14:46
dolphmalthough i don't recall any real sql injection that i've been aware of14:46
bknudsonthere was just recently a shell injection14:46
dolphmbknudson: via an HTTP API?14:48
bknudsondolphm: https://bugs.launchpad.net/ossa/+bug/129869814:49
uvirtbotLaunchpad bug 1298698 in glance/havana "[OSSA 2014-012] Remote Code Execution in Sheepdog backend (CVE-2014-0162)" [Undecided,Fix committed]14:49
*** vhoward has left #openstack-keystone14:50
dolphmbknudson: yuck14:50
dolphmmy hobby: skimming stack overflow for code snippets containing vulnerabilities, and looking to see if it's obvious from the user's profile where that code might be running in production14:52
dstanekdolphm: have you found any yet?14:52
dolphmdstanek: of course14:52
dolphmdstanek: they never get accepted as the answer though lol14:53
*** overlayer has joined #openstack-keystone14:54
*** ilives has quit IRC14:55
*** ilives has joined #openstack-keystone14:56
dstanekmaybe the really setup stackoverflow to be a honeypot for security holes14:58
*** chandan_kumar has joined #openstack-keystone14:58
dolphmdstanek: "share your company's proprietary code here that you're not allowed to publish to github" ?15:02
*** thedodd has joined #openstack-keystone15:04
*** tomoiaga has quit IRC15:07
*** raildo has left #openstack-keystone15:08
dolphmor maybe that gists15:11
*** wchrisj_ has joined #openstack-keystone15:16
openstackgerritayoung proposed a change to openstack/python-keystoneclient: remove universal_newlines  https://review.openstack.org/7941115:16
openstackgerritayoung proposed a change to openstack/python-keystoneclient: Compressed Signature and Validation  https://review.openstack.org/7118115:18
*** zematynnad has left #openstack-keystone15:19
*** Anju_ has joined #openstack-keystone15:24
dstanekam i correct in thinking that the purpose of the token revocation list is just an optimization so that services can reject tokens without having to come to Keystone?15:25
*** chandan_kumar has quit IRC15:27
*** derek_c has quit IRC15:27
*** chandan_kumar has joined #openstack-keystone15:28
*** bach has joined #openstack-keystone15:29
dolphmdstanek: i suppose that's half the story...15:30
dstanekdolphm: is there a longer second half?15:30
dolphmdstanek: always!15:31
dolphmdstanek: dstanek: the other half is that our default token duration is longer than people are willing to wait for tokens to naturally expire, so that's why we need a revocation mechanism at all15:31
dolphmdstanek: the third half is that it's not just an optimization - there's not really an offline solution for invalidating PKI tokens15:32
dstanekdolphm: in that particular case can't they just lower the duration?15:33
dolphmdstanek: yeah, but users expect tokens to become invalid within seconds or minutes15:33
dstanekdolphm: that's what i meant by optimization. the server wouldn't have to make an expensive sevice call if the token was in the list15:34
dolphmdstanek: fair enough - then, yes. but the token validation *list* is itself an expensive (heavy) call15:35
dolphmdstanek: or at least it can be, when users are generating thousands of tokens, and then the user gets deleted, for example15:35
*** browne has joined #openstack-keystone15:35
dstanekdolphm: is the list incremental or do we just keep giving that the entire list everytime?15:36
dolphmdstanek: it rotates as revoked tokens expire naturally, if that's what you're asking?15:36
dstanekdolphm: that's part of it; i thinking ore along the lines of a way to say "i got up to X token on the list" and then have the server return only the revoked tokens after that point15:41
*** chandan_kumar has quit IRC15:42
dolphmdstanek: the polling mechanism for token revocation *events* has that built in15:45
dolphmdstanek: but i'd like token revocation events to be loaded on startup via HTTP, and then received via messaging after that15:46
dstanekdolphm: makes sense15:46
dstanekdolphm: i was curious because of this review https://review.openstack.org/#/c/86016/15:46
dolphmdstanek: i think it's GET /v3/OS-REVOKE/revents?since=<last-revocation-time-the-client-saw>15:46
*** overlayer has left #openstack-keystone15:48
dolphmdstanek: i heard someone talking about that recently, i didn't know they were serious15:48
dstanekyeah, no tests yet and no revocation lists15:49
*** richm has joined #openstack-keystone15:49
*** marcoemorais has joined #openstack-keystone15:50
dolphmdstanek: if he's targeting UUID tokens only, you wouldn't need one15:52
dstanekdolphm: how can you tell what he's targeting? or is it just what he uses it for15:52
dolphmdstanek: no revocation support -> probably uuid-only15:53
dstanekdolphm: but i agree you wouldn't need it with ephemeral tokens15:53
dolphmdstanek: and only PKI can become ephemeral15:53
dolphmi'd also rather not introduce any sort of dep on another openstack project15:55
*** gyee has joined #openstack-keystone15:56
openstackgerritBrant Knudson proposed a change to openstack/python-keystoneclient: auth_token middleware hashes tokens with configurable algorithm  https://review.openstack.org/8039815:56
*** nkinder has joined #openstack-keystone15:56
*** dstanek is now known as dstanek_lunch15:57
*** zhiyan is now known as zhiyan_15:59
*** jaosorior has quit IRC16:01
*** chandan_kumar has joined #openstack-keystone16:02
*** nkinder has quit IRC16:03
*** bach_ has joined #openstack-keystone16:03
openstackgerritIlya Pekelny proposed a change to openstack/keystone: Sync test_migrations  https://review.openstack.org/8061816:04
openstackgerritIlya Pekelny proposed a change to openstack/keystone: Sync on-demand database schemas  https://review.openstack.org/8444816:04
openstackgerritIlya Pekelny proposed a change to openstack/keystone: Comparision of database models and migrations.  https://review.openstack.org/8063016:04
*** bach has quit IRC16:06
openstackgerritBrant Knudson proposed a change to openstack/python-keystoneclient: Deprecate admin_token option in auth_token  https://review.openstack.org/8709116:09
*** bach_ has quit IRC16:15
*** marcoemorais has quit IRC16:15
*** marcoemorais has joined #openstack-keystone16:16
openstackgerritBrant Knudson proposed a change to openstack/keystone: More efficient DN list for LDAP role delete  https://review.openstack.org/8715116:16
*** marcoemorais has quit IRC16:16
*** marcoemorais has joined #openstack-keystone16:16
ayoungdstanek_lunch, dolphm a swift backend should be done via the KVS/Dogpile mechanism anyway16:17
dolphmayoung: a swift dogpile driver?16:18
ayoungdolphm, yep16:18
ayoungdolphm, I'm not saying it is a good idea, mind you, just "if you want swift support..."16:19
*** nkinder has joined #openstack-keystone16:19
*** bach has joined #openstack-keystone16:20
dolphmayoung: then they could just include it in swiftclient, since it has nothing to do with keystone16:20
openstackgerritBrant Knudson proposed a change to openstack/python-keystoneclient: Deprecate admin_token option in auth_token  https://review.openstack.org/8709116:20
ayoungdolphm, well, sure.  But if they want to store tokens in Swift for whatever reason, the right path is via KVS and Dogpile16:21
*** Guest78217 is now known as mgagne16:23
*** mgagne has joined #openstack-keystone16:24
*** bach_ has joined #openstack-keystone16:26
*** bach has quit IRC16:28
*** derek_c has joined #openstack-keystone16:29
*** gyee has quit IRC16:29
*** daneyon has joined #openstack-keystone16:34
*** dstanek_lunch has quit IRC16:37
*** bach_ has quit IRC16:40
*** leseb has quit IRC16:40
dolphm461 developers *regularly* working on openstack, crazy http://blog.bitergia.com/2014/04/17/the-openstack-icehouse-release-activity-and-organizations/17:01
*** tomoiaga has joined #openstack-keystone17:03
*** dstanek_lunch has joined #openstack-keystone17:04
nkinderdolphm: where is "regular" defined?17:04
nkinderayoung: ping, re - password hashing17:05
nkinderayoung: so I can't think of anything that would be dependent on Keystone pre-hashing LDAP passwords17:05
nkinderI can think of plenty of failure scenarios though ;)17:05
ayoungnkinder, a dumb ldap server that accepted whatever we handed it?17:06
nkinderayoung: sure, it accepts it17:06
nkinderayoung: what then?17:06
ayoungnkinder, simple bind works?17:06
nkinderayoung: do we coulnt on it then being smart enough to treat the hash right?17:06
nkinderayoung: maybe, maybe not.  Depends on what the server does with it17:06
ayoungnkinder, well, why does the existing code work in live LDAP tests?17:07
nkinderIf the server accepts a pre-hashed password, then it will do the comparison right during the bind (it hashes the clear password from the bind using the same scheme, then compares it)17:07
ayoungI tested with OpenLDAP, and I think that just accepted the password I gave it, and then simplebind does that sha1 salted17:07
nkinderayoung: because it's accepted in 389 DS if you use Directory Manager, and OL can accept it too.17:08
ayoungso if we stop pre-hashing will everything still work?17:08
nkinderayoung: doesn't make it a good idea.  It's more of a legacy style of doing passwords17:08
nkinderayoung: yes, and the passwords will be hashed by the server17:08
ayoungnkinder  which Dir Srvs did you verify the code against?17:08
nkinderayoung: old pam_ldap would do a search for the userPassword value to get the hash, then compare hashes on the client for auth17:08
ayoungI'm most concerned with AD, since Cern uses it for scale17:09
nkinderayoung: oh, AD would be completely hosed with the current code if you let keystone create users or set passwords17:09
ayoungalthought I can't believe they would actually manage users via Keystone17:09
nkinderayoung: AD doesn't use SSHA17:09
nkinderAD uses NTLM17:09
ayoungnkinder, and the LDAP client is smart enought to know that?17:09
ayoungthe Python code does a simple bind....where is the hashing done?17:10
*** dstanek_lunch has quit IRC17:10
ayoungon the far side of the wire?17:10
nkinderthe server17:10
* ayoung sobs17:10
nkinderthe client should never do the hashing17:10
nkindernever ever17:10
*** daneyon has quit IRC17:10
ayoungand, of coure, it would not know the salt17:10
*** daneyon has joined #openstack-keystone17:11
ayoungbut if you do LDAP without TLS...you are sending cleartext passwords.  I guess it wouldn't matter if they were prehashed, though17:11
nkinderayoung: sure, which is why plain LDAP is bad17:11
ayoungUgh.  CAn we skip all this and go right to Kerberos?17:11
nkinderayoung: note that ldapsearch requires you to use an option (-x) to even do a simple bind17:11
nkinderThey try to force SASL (DIGEST-MD5)17:11
ayoungnkinder, BTW:  http://adam.younglogic.com/2014/04/nss-horizon/17:12
nkinderayoung: one step at a time :)17:12
ayoungthat was my latest step...I'17:12
ayoungve shifted gears back to the compressed tokens for a short time17:12
ayoungwant to get the patch functioning...and had a request to do so17:12
*** harlowja_away is now known as harlowja17:12
nkinderayoung: one other point with Keystone's current code.  We only hash LDAP passwords when setting them.  We currently send the clear password to the LDAP server for a bind already.17:13
nkinderayoung: the LDAP password checking method is only used by fakeldap to do a hash check.  Live LDAP doesn't use that.17:14
*** daneyon_ has joined #openstack-keystone17:14
ayoungnkinder, the compression code has a second effect benefit.  It gives the ability to pull the signer info out of the token.  It will allow for having multiple signers, which will clean up some of the HA stuff kashyap is working on17:14
ayoungnkinder, can we do the hashing only in fakeldap?17:15
ayoungI guess we don't need it there....17:15
dolphmnkinder: is it possible that LDAP servers would be re-hashing passwords that are already hashed by keystone?17:15
nkinderayoung: I'd rather rip it out.  It's not testing anything, and I'd prefer to rip out unnecessary crypto.17:15
ayoungOK.  I can get behind this17:15
ayoungdolphm, then simple_bind would fail17:15
nkinderwhoops, dolphm ^^^17:15
ayoungthey would be double hashed17:16
dolphmayoung: correct17:16
nkinderdouble hashing is my fear with AD17:16
*** marcoemorais has quit IRC17:16
ayoungnkinder, no one has filed a bug for it, leaving me to think that no one with AD is managing users from Keystone17:16
nkinderI have seen that occur before when developing on 389 (long ago)17:16
dolphmnkinder: so, by removing double hashing, you're making it so that users with doubly hashed passwords created via keystone can't authenticate anymore?17:16
nkinderayoung: you're likely correct17:16
*** marcoemorais has joined #openstack-keystone17:16
*** derek_c has quit IRC17:16
*** daneyon has quit IRC17:17
nkinderdolphm: no, if LDAP double hashes, then authentication via keystone would fail (keystone doesn't hash during bind)17:17
nkinderdolphm: so the result would be that I could give keystone my hash as the password to bind17:17
dolphmnkinder: i thought you said it was hashing passwords on create AND auth?17:17
dolphmcreate user*17:17
nkinderdolphm: nope, only create/mod17:17
nkinderfakeldap does hash during auth (not live LDAP)17:18
dolphmnkinder: rip it out then!17:18
nkinderyep, that's my conclusion too!17:18
ayoungdolphm, simple_bind passes cleartext password to the server.  THis is what the user passed to Keystone in the token request.  We do no hashing of it.17:18
ayoungdolphm, https://review.openstack.org/#/c/88109/17:19
nkinderyeah, I confirmed all of that with wireshark yesterday too17:19
ayoungnkinder, I kindof figured you had your ducks in a row with this one, but wanted to discuss it with you before ACKing17:19
*** chandan_kumar has quit IRC17:19
ayoungtopol, when you get a chance, read up here, and probably should remove you -1 on https://review.openstack.org/#/c/88109/17:20
nkindertopol: happy to answer any further questions on it for you too17:20
*** therve has joined #openstack-keystone17:27
therveHi17:27
*** gokrokve_ has quit IRC17:28
*** gokrokve has joined #openstack-keystone17:29
openstackgerritNathan Kinder proposed a change to openstack/keystone: Remove LDAP password hashing code  https://review.openstack.org/8810917:36
topolayoung, nkinder Hi17:37
therveThere is fairly ridiculous regression in ceilometer because of the deprecation of the auth fragments17:37
ayoungtherve, "auth fragments?"17:38
dolphmtopol: https://review.openstack.org/#/c/88109/1/keystone/identity/backends/ldap.py17:38
therveayoung, auth_port/auth_host etc?17:38
dolphmjamielennox|away: ^17:38
therveIt seems we should use identity_uri now17:38
dolphmtherve: link?17:38
thervedolphm, http://logs.openstack.org/69/87869/3/check/gate-ceilometer-python27/fbde553/console.html17:38
therveI think we can fix it in ceilo, I just went to give the heads up17:38
topoldolphm, I agree, that was my conclusion as well17:39
therveIt's because we use some custom protocol schemes in the tests17:39
topolIm ok with removing my -117:39
*** jimbaker has quit IRC17:39
therveAnd the keystone middleware uses urljoin which doesn't support those17:39
topolnkinder is very articulate in his comments :-)17:39
topolso Im good17:40
*** thedodd has quit IRC17:40
dolphmtherve: why do the tests do that?17:40
dolphmtherve: i mean, what's the use case they're trying to cover?17:40
openstackgerritayoung proposed a change to openstack/python-keystoneclient: Compressed Signature and Validation  https://review.openstack.org/7118117:40
nkindertopol: ok, great17:41
*** praneshp has joined #openstack-keystone17:41
ayoungdolphm, ^^ passes py33 as well as py27.  Compression is coming!17:41
thervedolphm, Just customizing auth_protocol and see if it's reflected17:41
*** leseb has joined #openstack-keystone17:41
therveThere wasn't any restriction previously on what was possible, now there is17:41
dolphmtherve: and urlparse.urljoin restricts the list of valid protocols?17:42
*** praneshp_ has joined #openstack-keystone17:42
thervedolphm, Yeah17:42
therveIf the protocol is in "uses_relative" it works, otherwise it just returns "/"17:43
*** morganfainberg_Z is now known as morganfainberg17:43
thervedolphm, http://paste.openstack.org/show/76156/17:44
dolphmtherve: weird, the urlparse docs even refer to scheme://17:45
*** praneshp has quit IRC17:45
*** praneshp_ is now known as praneshp17:45
*** leseb has quit IRC17:46
*** jimbaker has joined #openstack-keystone17:46
dolphmtherve: i'd be happy to see a patch that remove the use of urlparse.urljoin, and we can do a 0.8.1 release... but ceilometers tests are much less useful than your pasted use case17:47
morganfainbergdolphm, ++ esp. if urljoin is as broken as described here.17:47
*** gokrokve has quit IRC17:47
thervedolphm, I don't know if it's a problem in practice17:48
dolphmmorganfainberg: yeah, it totally discards the base url for me17:48
therveYou probably shouldn't use anything besides https anyway :)17:48
dolphmjust because it doesn't recognize the scheme17:49
morganfainbergtherve, ++ true17:49
dolphmtherve: agree17:49
*** dstanek has joined #openstack-keystone17:58
*** bach has joined #openstack-keystone18:00
*** bach has quit IRC18:02
*** tomoiaga has left #openstack-keystone18:02
*** ilives has quit IRC18:03
*** ilives has joined #openstack-keystone18:04
*** praneshp has quit IRC18:04
*** gokrokve has joined #openstack-keystone18:04
ayoungso...design issue on the client auth plugin.  Jose's patch has "kerberos" in it.  That becomes the "method"  in the token request.  If we make it "external" it will work with the existing plugins18:09
ayoungbut, when setting up the network connection, if we are using kerberos, we need to add the -negotiate flag18:09
ayoungso we can't just make a generic client side plugin for external.18:10
ayoungIf we do client certs, it will have similar issues...need to explicitly add the client cert into the network setup18:10
ayoung...I'll wait for jamielennox|away to come back.  This is really a discussion he needs to see18:11
*** gokrokve has quit IRC18:13
dolphmayoung: it makes sense to use external plugins on the service side, as far as i can tell. on the client side, plugins should be single-purpose18:14
dolphmthere shouldn't be a OneSizeFitsAllPlugin :)18:14
ayoungdolphm, so the issues is whether it should be one plugin for both Jose's  version of Kerbersos (inside eventlet) and the HTTPD one...assuing we want to support Jose's approach (which I don't)18:15
ayoungdolphm, I think the main distinction is that with "external" auth, it is mostly the set up of the HTTP connection that varies, but the body of the request will be the same18:17
dolphmayoung: from the client perspective?18:17
ayoungdolphm, yeah18:17
ayoungdolphm, there are 2 auth mechanisms we need to support:18:18
ayoungKerberos and X509 Client auth18:18
ayoungfor Kerberos, you set up an HTTP connection with "Negotiate"18:18
ayoungfor X509 Client auth, you set up the HTTP connection and specify the client certificate18:18
dolphmayoung: you could have an AbstractExternalPlugin that knows how to build the body, but doesn't know how to do any form of external auth18:18
ayoungdolphm, so the question is whether we would want end users to distinguish between server side implementations.  For example, if Kerberos is done in eventlet, then we need more processing, and it makes sense to have a specific server side plugin for that18:20
ayoungI am not certain we want to support that.  But I need to confirm with CERN that they don't really need it18:20
dolphmayoung: end users as in api users or deployers? hopefully api users don't need to care18:20
ayoungI had an exchange with Jose that indicated it was not really necessary18:20
*** andreaf_ has joined #openstack-keystone18:21
*** andreaf_ has quit IRC18:23
*** stevemar has quit IRC18:23
*** andreaf_ has joined #openstack-keystone18:23
ayoungdolphm, ok, so just for perspective:  we could do BASIC_AUTH to HTTPD.  This would mean that, instead of putting username and password into the request, it would go into the HTTP header.  Both this form and Kerberos right now would be served by the current "external" plugin.  So all of the differences would be client side to distinguish between them18:23
*** andreaf has quit IRC18:24
ayoungnow, we could even use BASIC_AUTH inside of eventlet.18:24
ayoungIE...do all of the code to pull username and password out of the HTTP envelope and then call identity.authenticate18:24
*** stevemar has joined #openstack-keystone18:24
*** thedodd has joined #openstack-keystone18:25
ayoungI actually did a proof-of-concept of that.  The thing is, I did all of the parsing in middleware, and then the "external" plugin would still execute the same unchanged18:25
ayoungso, I'm still undecided about what the "method" should be if we do kerberos, but I am leaning toward leaving it as "external" regardless of what we call the client side plugin18:26
ayoungJose's implementation made the method "kerberos"18:26
*** praneshp has joined #openstack-keystone18:27
ayounghttps://review.openstack.org/#/c/74317/  but that makes sense based on his approach:  he is doing significantly more server side work18:27
dolphmayoung: the client side plugin "name" doesn't have to have anything to do with the api or the service side plugin18:27
ayoungdolphm, they need to match.18:31
ayoungdolphm, the client side plugin populate the "method"18:31
ayounghttps://review.openstack.org/#/c/74317/11/keystone/auth/plugins/kerberos.py  line 3518:31
dolphmayoung: i was referring to the ClassNameOfThePlugin that the user actually sees - not what's on the wire18:32
ayoungdolphm, correct, and I would like to keep that abstraction clear.18:32
ayoungdolphm, so, here is one approach18:32
ayoungfor each "external" server plugin we have now, we create a subclass that just changes the method name from 'external' to kerberos18:33
dolphmayoung: on the client side, the client.KerberosPlugin can use "methods": ["external"] in a kerberos HTTP request to a keystone service running inside httpd protected by kerberos18:33
ayoungthen,  if the client sends a kerberos request of either form, it works18:33
ayoungdolphm, yes, it can18:33
dolphmayoung: why do you need service-side plugins that swap out the method name for something else?18:34
dolphmayoung: unless the kerberos httpd mod doesn't use REMOTE_USER or something?18:35
ayoungdolphm, here is Jose's server side plugin, which does not user REMOTE_USER18:35
dolphmayoung: i'm ignoring jose's plugin, and assuming we're talking about mod_auth_kerberos (?)18:35
dolphmmod_auth_kerb*18:35
ayoungdolphm, well, that was my initial approach.  I'm OK with that.  It just gets a little confusing if we do include Jose's Kerberos approach.  So, either we need to modify his client patch or change some server side code18:36
*** gyee has joined #openstack-keystone18:37
ayoungMy initial suggestion was that for "external"  you don't even put the method into the auth request.  Jamie pointed out that this is actually tough under the current client plugin approach, as it assumes the auth plugin adds a method to an array18:38
dolphmayoung: it's tough to add "external" ?18:38
ayoungdolphm, adding extenral is not tough.  It would mean that, right now, it would get double processed on the server side, but that is a simple fix18:39
*** gokrokve has joined #openstack-keystone18:39
dolphmayoung: mod_auth_kerb unwraps the kerberos request, sets REMOTE_USER, and the External plugins handle REMOTE_USER -- what gets processed twice?18:40
dolphmor am i missing something18:40
ayoungif we put "external" into the methods, it would get processed once via REMOTE_USER explicit check, and once via processing hte list of methods18:41
ayoungdolphm, https://github.com/openstack/keystone/blob/master/keystone/auth/controllers.py#L41218:41
*** leseb has joined #openstack-keystone18:42
*** chandan_kumar has joined #openstack-keystone18:43
dolphmayoung: mod_auth_kerb *would* set REMOTE_USER, right?18:45
ayoungdolphm, yes18:46
*** leseb has quit IRC18:46
*** leseb has joined #openstack-keystone18:48
*** browne has quit IRC18:50
*** bach has joined #openstack-keystone18:50
*** bach has quit IRC18:55
openstackgerritBrant Knudson proposed a change to openstack/keystone: Refactor test_password_hashed to the backend testers  https://review.openstack.org/8839918:56
bknudson^ could be merged up into the parent commit.18:57
*** dstanek has quit IRC18:57
nkinderbknudson: I was just going to ask you about what you had in mind for test_password_hashed18:58
nkinderbknudson: I don't think there is really anything to do for the live LDAP tests around hashed password tests18:59
nkinderbknudson: ideally, Keystone shouldn't even be allowed to access the password hash from LDAP (it wouldn't be able to with AD for sure)19:00
bknudsonnkinder: on my openldap system the password is different, so we could have a test to check that the password on the create is different than the one from get19:00
nkinderbknudson: we can do that if we want the test to assume that the user that keystone binds as can read the userPassword attribute19:03
nkinderbknudson: in general, it's a good idea to lock that down.  There's no reason to expose the hash unless it's needed (and in this case, we would only need it for a test)19:04
*** erecio has quit IRC19:05
nkinderbknudson: I think it's of limited value.  If the test fails, what can we do in keystone about it?19:05
*** erecio has joined #openstack-keystone19:06
*** YorikSar has joined #openstack-keystone19:08
*** bach has joined #openstack-keystone19:08
*** marcoemorais has quit IRC19:09
*** marcoemorais has joined #openstack-keystone19:10
YorikSartopol: ping19:10
YorikSartopol: Do I remember correctly that you were giving some love to LDAP in Keystone?19:10
YorikSaror was ayoung driving it?..19:11
topolHi YorikSar, long time no talk19:11
topolI did some but others did some as well19:11
topolincluding you :-)19:11
ayoungYorikSar, mostly been taken over by some of my team members19:11
topolcome back to the party YorikSar!19:11
ayoungtopol did the devstack work for LDAP19:11
topolwhat ayoung said :-)19:11
YorikSartopol: I was only throwing every intern I had to that LDAP fire.19:12
YorikSarActually I've recently thrown another one - Sergey Nikitin.19:12
topolI think things are pretty good with LDAP now. Its much more enterprise friendly and usable19:12
topolI have seen Sergey post some patches yes19:13
topolYorikSar so whats going on?19:13
YorikSarYes. And I've suggested him another direction to dig into. He wrote to ML about that.19:13
ayoungYorikSar, I have a few things to work on that make me want to leave LDAP to others19:13
YorikSarI want us to have a gate job running over LDAP.19:14
YorikSarAnd so I think he can make that happen.19:14
YorikSarBut I want someone to write about current state of that direction and I want to tell him who can he ask about current state of LDAP in Keystone's big picture.19:16
openstackgerritayoung proposed a change to openstack/python-keystoneclient: Compressed Signature and Validation  https://review.openstack.org/7118119:17
YorikSarCurrent state of LDAP driver actually makes me sad... I brag that I wrote it but then I'm being asked about what can you do with it and... Well, there's a lot of features missing.19:18
topolayoung is the best candidate for your request if he has time,19:19
ayoungYorikSar, we are going to reduce the features to zero, close the shop and go home.19:19
ayoungWell, maybe not quite19:19
topolYorikSar, even with how identity and assignment have been separated you still need a ton of gaps filled?19:20
ayoungthe goal is for LDAP to be little more than a store of user and group data consumed from some larger organizations store.  The LDAP read/write approach is not really sustainable.19:20
* topol ahh ayoung with his give him a heart atack humor19:20
topolayoung +++19:20
ayoungTry the veal!19:20
topoltwo shows daily. dark on mondays19:21
YorikSarayoung: What do you mean by "more"?19:21
topolYorikSar are you coming to Atlanta?19:22
*** ilives has quit IRC19:22
YorikSartopol: Nope. Noone in community have ever seen me in person but those who dare to come to Russia :)19:22
ayoungYorikSar, um..."little more"  really translates to "less"19:23
topolYorikSar, any of your colleagues coming to Atlanta?19:23
YorikSarayoung: Ok... Now I'm completely confused :)19:23
topolYorikSar, so wha he is saying is we are trying to keep LDAP for doing classic LDAP things (storing users and groups) and not trying to make it do and store stuff it is not accustomed to doing19:25
YorikSartopol: Yeah. I guess, lots of them. You can punch anyone in Miranits t-shirt and there's 50% probability that it'll be someone from my office :)19:25
topolYorikSar, can you send someone that you can brief with your concerns/issues as your ambassador?19:26
YorikSartopol: May be... I just need to find someone with some openings in the schedule.19:26
ayoungYorikSar, we split the identity backend, and my goal at that point was to kill the lDAP assignment backend.  twas on CERN that said "we really need it" or it would be gone19:27
ayoungthat leaves users and groups19:27
ayoungand it turns out that groups should not only come from LDAP, as we need a way to group users in Keystone, even if LDAP is read only19:28
ayoungSo...LDAP really just gives us a little bit of info about users19:28
*** dstanek has joined #openstack-keystone19:28
ayoungGroup data from LDAP tends not to be super-useful in a Keystone context.  But if what you want is there, you can use it19:29
ayoungthe real issue is how are we going to support multiple LDAP servers19:29
YorikSartopol: Actually I think since (it looks like) noone actually doing global changes in LDAP area I think I can drive Sergey to work on it as I think it should be...19:29
ayoungand that issue affects Federation as well19:29
ayoungsent a message about that to openstack-dev a day or so ago19:30
topolYorikSar, what do you mean by "global changes' Can you list some examples?19:31
YorikSarayoung: I must've missed it... But I really wouldn't eliminate assignment driver as well because I know there're customers who use it and we use it ourselves.19:32
ayoungYorikSar, that data is better off in SQL than in LDAP19:33
ayoungbut, I'm willing to listen to counter arguments19:33
YorikSarayoung: Not if all your organisation is already managed in LDAP19:33
ayoungYorikSar, um...no19:33
ayoungLDAP is for data that is multi-application19:33
ayoungKeystone is specific to Openstack19:34
ayoungso, yeah, users and groups from LDAP, but why projects etc?19:34
ayoungYorikSar, it means that Keystone needs to be able to write to LDAP.  To do that right, we should make  it such that the users LDAP ACLs are employued to limit what a user can do in LDAP, but right now we only use a single, admin member.19:35
YorikSarayoung: E.g. we have our internal cloud. We have some customers. We internally create "project" for each customer and it is created in Wiki, bugtracker, Gerrit and OpenStack (all our internal services that are needed by the project).19:35
ayoungYorikSar, you have your Customers in LDAP?19:35
YorikSarayoung: Em... I mean, we have some team that works with a customer. It's united in some group in LDAP.19:36
ayoungYorikSar, ah19:36
YorikSarayoung: So that if you add new member to that team, one gets access to all services.19:37
nkinderYorikSar: that makes sense.  You are using the "project" for other purposes than just Keystone, so you want it centralized somewhere19:37
openstackgerritA change was merged to openstack/keystone: Isolate backend loading  https://review.openstack.org/7429319:37
YorikSarayoung: iirc we have "external" accounts for customers themselves, but that's not relevant here.19:37
ayoungYorikSar, so if you have features for LDAP, write up the BPs and lets get them reviewed19:38
nkinderYorikSar: ...and I can understand why you'd want to just have Keystone leverage it instead of duplicating that info in SQL.19:38
ayoungyep19:38
YorikSarnkinder: Exactly.19:38
YorikSarayoung: Well, this works quite well for our internal cloud (for now).19:38
ayoungnkinder, I guess I would summarize it as "organizations where openstack deployments are central to their business prefer to centralize all Identity in LDAP to synchronize it with Keystone"19:39
YorikSarOne huge example of what's missing for our customers is domains.19:39
nkinderYorikSar: one customer per domain?19:40
nkinderYorikSar: the idea as I understand it is that you would be able to map a Keystone domain to a separate LDAP server (though this could be a separate tree, etc.)19:40
YorikSarayoung: Even if OpenStack wasn't central for our business but just another service we use for dev/qa it would be necessary to keep all those services synchronized.19:40
YorikSarnkinder: Not exactly. I was recently involved in discussion about one customer. They wanted to have one domain per their tenant (I'm running out of dictionary here :( ) so that every one of them could create a number of projects.19:42
YorikSarYou cannot create domains dynamically with current LDAP driver. I think there should be some way to do so though.19:43
ayoungstevemar, do your comments on https://review.openstack.org/#/c/81166/9/keystoneclient/v3/contrib/revoke.py  really call for a -1?19:44
ayoungI don't think any of them need to be addressed.19:44
nkinderYorikSar: There are indeed too many terms... :)19:45
ayoungYorikSar, that would be done in SQL19:45
nkinderYorikSar: so what do you map a customer to in this case (if not a domain)?19:45
ayoungassignment backend supports exactly that.  If you wanted it in LDAP, you could, though,19:45
ayoungdifferent subtree per customer19:45
*** bach_ has joined #openstack-keystone19:45
ayoungyou need a way to make sure one customers's user_ids don't conflict with another19:46
stevemarayoung, i usually -1 whenever i have a question19:46
YorikSarAnd I don't really know what amount of changes are going to appear after hieratchical multitenancy work.19:46
nkinderayoung: I was thinking separate subtree as well19:46
ayoungstevemar, I appreciate that, but do you really want to hold up that patch?  I don't really want to make the changes you suggest.19:46
stevemarayoung, it is no longer holding it19:46
*** zhiyan_ is now known as zhiyan19:46
ayoungnkinder, either in the same or different LDAP servers.19:47
stevemarayoung, i figure if someone does like it, they can ping me :P19:47
ayoungstevemar, cool.   thanks19:47
ayoungstevemar, I want that in before the next time dolphm re-releases the client19:47
YorikSarayoung: But then every new client causes reconfiguration of Keystone.19:47
*** bach_ has quit IRC19:47
ayoungYorikSar, yep.  The way it is written today, that is true.  But we can fix that19:47
*** bach_ has joined #openstack-keystone19:48
*** eyerediskin has joined #openstack-keystone19:48
YorikSarayoung: Yes. And that's what I'm hoping to achieve with Sergey in not-so-long term.19:48
ayoungYorikSar, I could see making the subtree value overridable with something domain specific19:48
nkinderayoung: exactly19:49
ayoungYorikSar, but just solving multiple domains in a single LDAP server does not get the full range of use cases.  I want to have something that works for Multiple LDAP servers, and for Federation (SAML) coming from multiple IdPs as well19:49
nkinderayoung: adding a new domain would create an ou=<domain> container19:49
YorikSarayoung: Are there actual usecases for multiple LDAP servers?19:50
ayoungnkinder, that would be the logical approach, but what if there are two different LDAP servers?  Which one does it create it in?19:50
*** amcrn has quit IRC19:50
*** bach has quit IRC19:50
ayoungYorikSar, yes.  Ask topol about that.  henrynash, too, when he's around19:50
nkinderayoung: we need to support both cases I would think19:50
ayoungYorikSar, Mergers and Acquisitions often lead to multiple LDAP cases19:50
ayoungnkinder, I could see a need for a setup like this:19:50
ayoungOne ldap for employees19:51
nkinderayoung: for the multiple LDAP case (or the federation/SAML case), we would need to have config to map a domain to an IdP19:51
ayoungone for customers19:51
ayoungand some sort of local store for service users19:51
YorikSarayoung: Oh... Ok, I didn't think about that level of legacy...19:51
ayoungnkinder, that is one reason I was considering pulling the domain table out of both the identity and assignment backends19:51
ayoungYorikSar, lots of different classes of implementations19:52
nkinderayoung: and making it purely config?19:52
ayoungnkinder, It should be dynamic.19:52
nkinderayoung: so where would domains be stored?  A new backend?19:52
ayoungnkinder, but I figured leaving it in assignment would work19:53
YorikSarayoung: Are those nested projects going to become replacement for domains?19:53
ayoungwe would need a field in there for "IdP"  and maybe "assignemnt store"19:53
ayoungYorikSar, good questions.  I would say this:19:53
YorikSarBecause if they are then those mappings are going to be very complicated.19:53
ayounga domain should become a project that has no parent19:53
ayoungwe keep the term, because removing terms never happens19:54
YorikSarayoung: But it will be used only for backward compatibility?19:54
*** bach_ has quit IRC19:54
ayoungYorikSar no.  a domain is the top level namespace19:54
*** bach has joined #openstack-keystone19:55
ayoungYorikSar, ok, there is a division in vision here19:55
ayoungI want to keep the term Domain, and say that a single IdP can support multiple domains19:55
YorikSarayoung: I'm just thinking that nested projects can look very good in LDAP. But if we special-case some level, it might make it harder to implement.19:55
ayounga domain will contain users and groups on the identity side19:56
ayoungand on the assignment sid,e a domain will contain projects19:56
ayounga domain can have two different data stores, one for Identity, one for Assignments19:56
ayoungthe simplest case is that everything is in SQL19:57
YorikSarayoung: Hm... And what would be the use of multiple domains within one IdP? Only to store service users in separate backend?19:57
ayoungYorikSar, employees versus partners versus customers?19:58
ayoungYorikSar, IdP as exposed by SAML can be thought of as a crypto version of a pushed LDAP query19:59
ayoungjust a signed document with the results so you don';t need direct access to the server19:59
nkinderayoung: if you're thinking of that in terms of LDAP as the IdP, wouldn't that be multiple trees (or use of filters to identify different classes of users)?19:59
ayoungso M&A with multiple trees in a single LDAP server pushed via SAML makes sense to me19:59
ayoungnkinder, ++ zactly!20:00
nkinderI almost think of that as a separate IdP (that happens to be a different set of entries from the same LDAP server)20:00
ayoungnkinder, way I see it, the only difference between SAML and LDAP is in LDAP, Keystone instigates the query20:00
ayoungso IdP is the server, and Domain is the subtree20:01
*** erecio has quit IRC20:01
YorikSarayoung: So... For example, that customer that wants his customers to create projects and stuff. They can have a separate domain with tree of projects for their customers and a separate domain (probably SQL-based) for admins.20:01
*** erecio has joined #openstack-keystone20:01
nkinderayoung: so to define a LDAP IdP, what info is used?  host, port, bind DN/cred?20:01
nkinderayoung: and domain would specify base DN and filter?20:02
ayoungnkinder, plus filters20:02
ayoungthe tree structure might be different between subtrees in the same LDAP20:02
nkinderayoung: filters where?  In IdP, or domain?20:02
*** stevemar has quit IRC20:03
ayoungthink of a M&A case where they just consolidate to a single LDAP infrastructure but left the origianl org structures intact20:03
nkinderTo me, IdP equals all of the LDAP config (host/port, bind info , base DN + filter)20:03
nkinderdomain is a name that maps to the IdP config20:03
*** eyerediskin has quit IRC20:03
nkinderYou can have multiple IdPs where they are the same LDAP server, but perhaps just a different base DN or filter20:03
ayoungnkinder, true20:04
nkinderit's still a separate IdP20:04
*** eyerediskin has joined #openstack-keystone20:04
YorikSarnkinder: And you can have one IdP looking at several LDAP servers.20:04
ayoungNO!20:04
ayoungYorikSar, no no no no no no no no no20:04
YorikSarayoung: Oh... :(20:04
YorikSarayoung: Then I must've missed smth.20:05
YorikSarayoung: I though M&A case is exactly about that.20:05
ayoungYorikSar, an IdpP is a single point to query20:05
ayoungsplitting across multiple LDAP makes Keystone responsible for providing a facade across them20:06
*** browne has joined #openstack-keystone20:06
ayoungYorikSar, 1 IdP to 1+ Domains20:06
ayoungIf you split across multiple LDAP, each would be its own domain20:07
ayoungmaybe more than one, but a domain would never be spread across multiple IdPs20:07
YorikSarayoung: IdP config for me is like (server creds, tree designations). Why not have separate IdP for each domain with their own trees then?20:08
ayoungYorikSar, Maybe20:09
ayoungIt might be that, for LDAP, that is the way we go.20:09
ayoungRIght now, Multiple Domains can be stored in SQL20:09
ayoungso we have at least one  case where multiple domains are in the same datasources20:09
ayoungWe are not going to remove that abstraction, but it might not be equally distributed20:09
nkinderYorikSar: One IdP is one server as ayoung said20:10
YorikSarayoung: We can make the same trick with SQL actually.20:10
YorikSarayoung: It might make architechture clearer.20:10
ayoungYorikSar, and, for your use case, with LDAP.   I can think of how we make it work that you can create a new LDAP domain in an existing LDAP setup20:11
nkinderayoung: For that case, I see a config option where you say "all domains are just subtree's in this one LDAP server"20:11
*** topol has quit IRC20:12
YorikSarayoung: If we have nested projects, dynamic creation of domains might not be needed at all.20:13
ayoungnkinder, maybe....that seems pretty specific to me, and if we can keep the abstractions clean, we might get something a little more flexible.20:13
ayoungYorikSar, you will need it for users20:13
YorikSarayoung: But we'll need to bind users to those projects so that project admin can manage his users.20:14
dstanekany reason not to +A https://review.openstack.org/#/c/88109/?20:14
ayoungand on the assingment side, a domain can bve thought of as a top level project20:14
nkinderdstanek: I think it's a fabulous patch that should be approved. ;)20:14
ayoungdstanek, done20:14
YorikSarOk, I'm going to sleep now. ayoung, topol, nkinder, thanks for enlightening me on current state of domains. If anyone of you have some info on LDAP gating, please write a reply to Sergey's thread in ML.20:20
ayoung++20:20
nkinderYorikSar: Sure!  I'll take a look at the thread.20:20
*** amcrn has joined #openstack-keystone20:20
nkinderYorikSar: LDAP gating sounds like a great idea20:21
YorikSarThanks20:21
*** chandan_kumar has quit IRC20:22
ayoungnkinder, we'll do it when we can gate in the same run on both SQL and LDAP20:23
eyerediskinhi all. not sure if this bug: https://bugs.launchpad.net/python-keystoneclient/+bug/130918020:28
uvirtbotLaunchpad bug 1309180 in python-keystoneclient "nothing works when only externalURL available" [Undecided,New]20:28
eyerediskincould someone take a look? ^20:28
*** jsidhu has joined #openstack-keystone20:30
ayoungeyerediskin, works as designed20:30
ayoungyou are trying to do an admin operations20:30
*** andreaf_ has quit IRC20:31
*** andreaf_ has joined #openstack-keystone20:31
openstackgerritayoung proposed a change to openstack/python-keystoneclient: Example Initialization scripts  https://review.openstack.org/8268720:32
*** marcoemorais has quit IRC20:32
*** erecio has quit IRC20:32
*** marcoemorais has joined #openstack-keystone20:32
*** erecio has joined #openstack-keystone20:33
bknudsondoes/should keystone require that a user ID can't be the same as a group ID?20:35
bknudsonnot sure how keystone could require that with a read-only ldap20:35
jsidhuusing the REST Identity API, is it possible to get a list of users that have been granted access to a domain?  Dont see a way describing this in the doc: http://api.openstack.org/api-ref-identity-v3.html20:37
jsidhuthe only way i can tihnk of is to test every user id and see if there’s a role for it via /v3/domains/__DOMAIN_ID__/users/__USER_ID__/roles"20:38
*** dstanek has quit IRC20:41
*** dstanek has joined #openstack-keystone20:41
ayoungbknudson, hmmm20:46
ayoungjsidhu, I thought we had that covered20:46
*** bach has quit IRC20:47
ayoungsomething aboiut list roles  with afilter20:47
jsidhuin v3?20:47
bknudsonayoung: jsidhu: GET /v3/role_assignments ?20:47
bknudsonI don't know if that works for domain scope20:48
ayoungbknudson, with ?domain_id=<id> right?20:48
jsidhurole_assignments   <— giggity giggity20:48
jsidhuthank you gentlement20:48
jsidhugentlemen*20:48
ayoungit should20:48
bknudsonscope.domain.id (string)20:48
ayoungjsidhu, there you go calling us names20:48
bknudsonthe docs on http://api.openstack.org/api-ref-identity-v3.html#Role_Calls could use some help here20:49
ayoungROBOT ROLE CALL!20:49
bknudsonCRRROOOOWWWW20:49
jsidhuthank you sirs20:49
jsidhuyes, this is exactly what i needed. thanks20:51
*** Anju_ has quit IRC20:51
*** erecio has quit IRC20:53
ayoungdolphm, you know what would be really cool?  If  recheck ran only those tests that failed.20:55
*** derek_c has joined #openstack-keystone20:56
openstackgerritRichard Megginson proposed a change to openstack/keystone: better handling for empty/None ldap values  https://review.openstack.org/7600220:57
*** marcoemorais has quit IRC20:57
*** marcoemorais has joined #openstack-keystone20:58
*** jagee has quit IRC21:03
*** david-lyle has quit IRC21:04
dolphmayoung: i've assumed that was part of the goal in moving everyone to testrepository, but i'm not sure what the next step is21:04
dstanekayoung: and if elastic recheck would just run them for you21:04
dolphmdstanek: it will, eventually. assuming it recognizes *all* your failures21:04
ayoungdolphm, lets not get personal21:05
dstanekdolphm: i'd be happy if it just ran the builders that failed21:05
dolphmayoung: lol21:05
dstanekdolphm: that could take *forever*21:05
dolphmdstanek: that's also just a limitation of the quality+quantity of queries we feed it21:06
ayoungyeah.  it just would be nice if recheck just quickly ran through the failing tests.21:06
dolphmi'm sure infra would love the reduced load21:06
*** andreaf_ has quit IRC21:06
*** leseb has quit IRC21:09
*** leseb has joined #openstack-keystone21:11
ayoungnkinder, I want to update http://openstack.redhat.com/index.php?title=Keystone_integration_with_IDM  with information about the split backend for assignments.  What is the right way to refer to the Havana release in RDO?21:12
*** gokrokve has quit IRC21:19
*** eyerediskin has left #openstack-keystone21:20
dstanekayoung: this one confuses me https://review.openstack.org/#/c/84444 - is it preparing for a move to Alembic?21:21
dstanekayoung: or is it just handling a difference in the my certain MySQL versions work21:22
ayoungdstanek, I thought it was just dealing with MySQL issues, and using Alembic as an explanation of why21:22
ayoungBut it does look like he's prepping for moving to Alembic21:22
dstanekit's also a little wierd to have the same index twice with 2 different names21:23
ayoungI just saw it as prep work for solving https://bugs.launchpad.net/keystone/+bug/129259121:23
uvirtbotLaunchpad bug 1292591 in keystone "Database models differs from migrations." [Medium,In progress]21:23
ayoung?21:24
ayoungOooh, should he be deleting indexes as well?21:24
ayounghe has the redundant index fix21:25
ayoungdoes that address it?  If so, should probably be in the same patch21:25
ayoungnah, its not a migration21:26
ayoungdstanek, removed my approval, and added a question to that one..21:31
dstanekayoung: the redundant index is different21:31
ayoungdstanek, yep21:32
*** leseb has quit IRC21:32
*** bach has joined #openstack-keystone21:34
openstackgerritRichard Megginson proposed a change to openstack/keystone: better handling for empty/None ldap values  https://review.openstack.org/7600221:34
dstanekayoung: ^ i think that is pretty good, but I'm no LDAP expert21:39
ayoungdstanek, the change to the file removing the override for live LDAP is a good sign21:40
ayoungdstanek, can you tell Red Hat finally assingned people that knew what they were doing RE LDAP?  I expect to be fired at any point now.21:42
ayoungPeople who can type, too.21:43
dstanekayoung: let's hope that doesn't happen.21:43
dstanekit does make me feel like i should actually read the LDAP book i bought so that i have a clue21:44
ayoungdstanek, none of this stuff is in the books21:44
*** bach has quit IRC21:44
dstanekayoung: i know next to nothing about directory services in general, so anything to get me started would be good21:45
ayoungdstanek, I would Highly suggest you install and play with FreeIPA21:45
dstaneki was thinking about setting up an LDAP service to control some of the stuff in my house as a learning experiment21:45
ayoungIts not going to teach you all of the nasty edge cases21:45
ayoungbut it gives you LDAP, Kerberos, DNS, and A Certificate Authority21:46
dstanekayoung: i'll take a look this weekend and start poking around21:46
ayoungdstanek, ++21:46
dstaneki'll need something to do while i'm sitting around at the inlaw's house21:47
ayounglots of good people in #freeipa to help out with N00b questions.  You'll recognize a few of them21:47
*** bach has joined #openstack-keystone21:48
bknudsonwhile LDAP has a lot of features there really only a few that are ever used21:48
bknudsoncreate a user and validate a password21:48
ayoungbknudson, one nice thing about FreeIPA is that it makes a few of them much more attainable.  Like centralized SUDO21:49
bknudsonyes, the real promise is centralization of users21:49
ayoungPlus Kerberos really needs LDAP, and Kerberos is a really powerful SSO21:49
bknudsonand auth stuff21:49
*** bach_ has joined #openstack-keystone21:49
bknudsonif LDAP wasn't invented there'd probably be a web service for this kind of thing21:49
bknudsonbut now we're stuck with it21:50
*** bach_ has quit IRC21:51
*** bach has quit IRC21:53
*** browne has quit IRC21:53
ayoungbknudson, there is an LDAP->web effort I've seen that looks promising21:54
*** bach has joined #openstack-keystone21:55
ayounghttp://marginnotes2.wordpress.com/2013/03/04/opendj-rest-to-ldap-gateway/21:55
ayoungI think edewata worked on that, or something really similar21:55
ayoungbknudson, but FreeIPA is basically that web service:21:56
bknudsonyea, but you'd probably get better results by forgetting LDAP and writing a directory web service from first principles.21:56
richm389 had a DSMLv2 gateway several years ago21:56
ayoungbknudson, no no no no no21:56
ayoungsecond systems syndrome extroidanaire21:56
bknudsonthat sounds suspiciously like XML21:56
richmit is21:56
ayoungbknudson, several years ago, everything was XML21:57
ayoungthese guys have been doing this for a long time21:57
richmDSMLv2 gateway is about 10 years old21:57
ayoungI wasn't kidding when I said I was second string.21:57
bknudsonI worked on IBM LDAP server when I started here... 15 yrs ago.21:57
ayoung389 DS used to be known as Fedora Directory Server.  Before that it was Netscape Directory Server21:57
richmtivoli?21:57
bknudsonrichm: it was eventually renamed to tivoli21:58
richmdid you work with Ellen?21:58
bknudsonrichm: I don't remember an ellen...21:58
bknudsonour group was porting it to iSeries (AS400)21:58
nkinderwe're familiar with the rename-game...21:58
richmcan't remember her last name - she did some work in IETF on ldap21:58
nkindernetscape DS -> iplanet DS -> netscape DS -> fedora DS -> 389 DS21:59
nkinderthen there is the whole other branch from SunDS -> oracle java something something21:59
ayoungnkinder, and we have engineers that worked on it the whole time.  I've only been doing this stuff for, what, four years now.  I'm a neophyte22:00
nkinderrichm: Ellen Stokes?22:01
bknudsonrichm: I think I remember the name... maybe she was a manager of the austin bunch22:02
richmyes22:02
richmin Austin22:02
richmthat's her22:02
*** bach has quit IRC22:03
nkinderayoung: that IdM page needs some work22:03
ayoungnkinder, yep22:03
nkinderayoung: it uses OU entries, which IPA doesn't really play nicely with22:03
ayoungI was just hacking on it22:03
*** bach has joined #openstack-keystone22:04
ayoungnkinder, we need to strike all of the Assignment stuff22:04
nkinderayoung: it's on my list to set up and clean-up22:04
nkinderayoung: feel free to take a pass, but I'll likely be doing the same very soon22:04
ayoungnkinder, let me, and you can edit22:04
ayoungnkinder, I have IPA as a backend to devstack.  But I need to swap my packstack install to use it as well, and that will be interesting on the systemd side of things22:05
ayoungnkinder, plus, CA integration is going to require some work if we want Dogtag to handle the certs22:06
ayoungfor signing22:06
nkinderayoung: what I want that doc to move away from is doing direct LDAP entry creation.  For example, the enabled users group should be created using IPA commands22:06
ayoungnkinder, we can and should drop all of that22:07
ayounguse swql for assignments22:07
ayoungsql22:07
ayoungand then no custom LDAP at all22:07
ayoungthe custom ldap was only needed for the additional schemas, and I would highly recommend we distance ourselves from that22:07
ayoungnkinder, I would love it if we could get away from creating service users at all.  THey should be service principals in IPA22:09
*** bach has quit IRC22:10
ayoungnkinder, which would tie in nicely with the proposal for Tokenless operations.22:12
nkinderayoung: yes, it's a hack around the non-standard "enabled" attribute22:12
ayoungnkinder, actually, we might be able to do away with service users altogether with revoke events22:12
ayoungI don't think there is any operations that will be "admin only" for token validation22:13
ayoungthere are22:13
ayoungwith revocation events, any non-privilidged user can validate tokens22:13
*** browne has joined #openstack-keystone22:14
ayoungmorganfainberg, with ephemeral, can we drop service users?22:15
* ayoung is getting excited about this.22:15
*** ayoung is now known as ayoung-afk22:17
*** lbragstad has quit IRC22:20
*** bknudson has quit IRC22:21
*** david-lyle has joined #openstack-keystone22:23
*** david-lyle has quit IRC22:29
gyeeayoung, nkinder, any plan to resurrect this one? https://review.openstack.org/#/c/47441/22:29
*** zhiyan is now known as zhiyan_22:29
nkindergyee: yes, it needs to be picked back up (just haven't had the time)22:31
nkindergyee: there are quite a few performance related optimizations that could be made around LDAP22:31
gyeenkinder, can you restore it, I can help you along the way22:31
nkindergyee: I was running wireshark yesterday while adding users to keystone and noticed this chain of operations...22:32
gyeewe are seeing anywhere from 3 to 10 seconds per auth, when under load22:32
gyee4 full SSL roundtrips to LDAP per auth at the minimum right now22:32
nkindergyee: bind, search for user by sn, unbind, bind, search for user by cn, unbind, bind, add, unbind22:33
gyeenkinder, if we use dogpile to cache the user_id/user_name to DN mapping that should help quite a bit22:33
gyeeand maintain a persistent session for all the lookups22:33
nkinderconnection pooling would be nice... I know morganfainberg was looking at that a little while ago22:37
gyeeconnection pooling maybe a bit tough in a multiprocess environment22:38
*** thedodd has quit IRC22:42
nkindergyee: you could do a single connection (or pool) per process22:42
openstackgerritRichard Megginson proposed a change to openstack/keystone: better handling for empty/None ldap values  https://review.openstack.org/7600222:43
*** rwsu has quit IRC22:44
nkindergyee: I'll resurrect that one and take a look at cleaning it up22:45
*** rwsu has joined #openstack-keystone22:48
gyeenkinder, thanks22:58
*** wchrisj_ has quit IRC23:02
*** wchrisj has joined #openstack-keystone23:18
*** daneyon_ has quit IRC23:27
*** wchrisj has quit IRC23:28
*** wchrisj has joined #openstack-keystone23:35
*** wchrisj has quit IRC23:38
*** praneshp_ has joined #openstack-keystone23:39
*** praneshp has quit IRC23:40
*** praneshp_ is now known as praneshp23:40
openstackgerritA change was merged to openstack/keystone: Cleanup of test_cert_setup tests  https://review.openstack.org/8455023:41
*** wchrisj has joined #openstack-keystone23:41
*** wchrisj has quit IRC23:44
*** praneshp_ has joined #openstack-keystone23:48
*** praneshp has quit IRC23:50
*** praneshp_ is now known as praneshp23:50

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!