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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 : [email protected] >>> Unsubscribe : https://launchpad.net/~openstack >>> More help : https://help.launchpad.net/ListHelp >>> >> >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp >> >> > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
