openstack team mailing list archive

[Anne Gentle <anne@xxxxxxxxxxxxx>]

I've been wondering whether we should have docs.openstack.org/master/ to
match expectations, would that have helped in your case? Thanks for
clarifying.

Anne


On Mon, Mar 4, 2013 at 4:22 PM, Steven Presser <spresse1@xxxxxxx> wrote:

>  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@xxxxxxx> 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@xxxxxxx> 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
>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>