openstack team mailing list archive

[Dolph Mathews <dolph.mathews@xxxxxxxxx>]

On that note, I very much like how docs.python.org does it, where not only
is the current page's version prominently specified at the top of the page,
but it also serves as an easy way to switch to another version of the docs,
e.g.: http://docs.python.org/2/tutorial/


-Dolph


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

>  Anne,
>     Yes that would.  What I think might be a better revision is putting
> the version somewhere prominently on the page (say, the upper right hand
> corner, above "<prev|up|next>").
>
> Steve
>
>
> On 03/04/2013 05:26 PM, Anne Gentle wrote:
>
> 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
>>
>>
>