Open Stack

Apparently the trunk docs.  I could have sworn that wasn't what I 
bookmarked.  In any case, maybe explicitly marking trunk docs as 
newer-than-latest would help?

( 
http://docs.openstack.org/trunk/openstack-compute/admin/content/reference-for-ldap-config-options.html)

On 03/04/2013 05:09 PM, Dolph Mathews wrote:
> Yes, this feature just landed during grizzly-m3.
>
> Which docs are you referring to? The variable wasn't included in 
> folsom's etc/keystone.conf.sample, for example.
>
>
> -Dolph
>
>
> On Mon, Mar 4, 2013 at 3:35 PM, Steven Presser <spresse1 at jhu.edu 
> <mailto:spresse1 at jhu.edu>> wrote:
>
>     The answer would appear to be that this flag doesn't do anything
>     in the Folsom release.  Apprently this was fixed by:
>     https://bugs.launchpad.net/keystone/+bug/1122181
>
>     Unless I'm misreading something.  Could we perhaps update the docs
>     to reflect the fact that this isn't available in releases yet?
>
>
>     On 03/04/2013 04:08 PM, Steven Presser wrote:
>>     This is what came out of my logs.  I've bolded what looks
>>     relevant to me:
>>
>>     LDAP init: url=ldap://typhon.acm.jhu.edu
>>     2013-03-04 16:06:01    DEBUG [keystone.common.ldap.core] LDAP
>>     bind: dn=cn=admin,ou=OpenStack,dc=acm,dc=jhu,dc=edu
>>     2013-03-04 16:06:01    DEBUG [keystone.common.ldap.core] LDAP
>>     search: dn=ou=Users,ou=OpenStack,dc=acm,dc=jhu,dc=edu, *scope=1*,
>>     query=(objectClass=inetOrgPerson)
>>
>>     Unless I'm reading that very wrong, my scope search request is
>>     being ignored.  Time to dive into the code, I suppose.
>>
>>     Steve
>>
>>     On 03/04/2013 10:15 AM, Dolph Mathews wrote:
>>>     I'd suggest enabling debug=True in keystone.conf and comparing
>>>     the LDAP queries being issued (shown in logs) against what
>>>     you're expecting.
>>>
>>>     I believe that [ldap] query_scope=sub does in fact expand
>>>     queries to apply to subtrees, beyond just a single level (as the
>>>     default value is query_scope=one).
>>>
>>>
>>>     -Dolph
>>>
>>>
>>>     On Sun, Mar 3, 2013 at 12:05 PM, Steven Presser
>>>     <spresse1 at jhu.edu <mailto:spresse1 at jhu.edu>> wrote:
>>>
>>>         Hey all,
>>>             I have some questions about using the LDAP backend for
>>>         keystone.  I'm in what seems to be an odd situation.  I have
>>>         an organization-wide DLAP directory that already exists.
>>>          All of our users will have access to OpenStack, so we want
>>>         to tie directly into this directory.  However, we can't have
>>>         service accounts mixed in with the regular users, at least
>>>         not in any way that might result in you being able to log in
>>>         to a service account.  For neatness, the directory admin
>>>         would prefer that all the OpenStack stuff be off in its own
>>>         OU (and has allocated us one so we can do that).
>>>             In that OU, I've set up the recommended schema from
>>>         http://docs.openstack.org/trunk/openstack-compute/admin/content/configuring-keystone-for-ldap-backend.html
>>>         (changing it to my domain, obviously).  I then aliased all
>>>         our users in to ou=Users.  The relevant part of my
>>>         keystone.conf currently looks like:
>>>
>>>         [ldap]
>>>         url = ldap://[host]
>>>         user = cn=admin,ou=OpenStack,dc=acm,dc=jhu,dc=edu
>>>         password = [password]
>>>         suffix = dc=acm,dc=jhu,dc=edu
>>>         use_dumb_member = False
>>>         allow_subtree_delete = False
>>>         query_scope = sub
>>>
>>>         As near as I can tell, this should correspond to this query:
>>>         $ ldapsearch -x  -D
>>>         cn=admin,ou=OpenStack,dc=acm,dc=jhu,dc=edu -w [password]  -b
>>>         dc=acm,dc=jhu,dc=edu '(objectclass=inetOrgPerson)' -s sub
>>>
>>>         Which returns my aliased users correctly.  (that is, it
>>>         returns "dn: uid=[uid],ou=People,dc=acm,dc=jhu,dc=edu" for
>>>         each user).
>>>
>>>         I really can't figure out whats going on here.  Logically,
>>>         this should work, but (obviously) doesn't.  Anyone have some
>>>         advice for me?   My suspicion is that query_scope=sub isn't
>>>         doing what I expect.  (Returning search results from within
>>>         a subtree)
>>>
>>>         Oh, finally, I have DEREF always enabled in ldap.conf.
>>>
>>>         Thanks,
>>>         Steve
>>>
>>>
>>>
>>>         _______________________________________________
>>>         Mailing list: https://launchpad.net/~openstack
>>>         <https://launchpad.net/%7Eopenstack>
>>>         Post to     : openstack at lists.launchpad.net
>>>         <mailto:openstack at lists.launchpad.net>
>>>         Unsubscribe : https://launchpad.net/~openstack
>>>         <https://launchpad.net/%7Eopenstack>
>>>         More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>>
>>     _______________________________________________
>>     Mailing list:https://launchpad.net/~openstack  <https://launchpad.net/%7Eopenstack>
>>     Post to     :openstack at lists.launchpad.net  <mailto:openstack at lists.launchpad.net>
>>     Unsubscribe :https://launchpad.net/~openstack  <https://launchpad.net/%7Eopenstack>
>>     More help   :https://help.launchpad.net/ListHelp
>
>     _______________________________________________
>     Mailing list: https://launchpad.net/~openstack
>     <https://launchpad.net/%7Eopenstack>
>     Post to     : openstack at lists.launchpad.net
>     <mailto:openstack at lists.launchpad.net>
>     Unsubscribe : https://launchpad.net/~openstack
>     <https://launchpad.net/%7Eopenstack>
>     More help   : https://help.launchpad.net/ListHelp
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130304/20f7b3ca/attachment.html>