openldap-software

openldap-software@openldap.org

2719 discussions

Re: logging
by Gavin Henry 08 Dec '07

08 Dec '07

> Same old story. You get perfectly good (and usually accurate) docs bundled > with the source code. Why people start by searching the web, which is only > going to return inaccurate/outdated cruft, written by people who aren't > intimately familiar with the subject matter, just doesn't make any sense, > and > it really discourages/frustrates/pisses off those of us writing the docs > (and > the code). +1 > Ignorance isn't a particular crime of course, nobody can know everything. > But > for the most part, LDAP is for sysadmins, and sysadmins have to have > problem > solving skills to be able to perform their jobs. It's not about knowing > everything, it's about knowing how to find out what you need to know. That > means knowing efficient processes for finding answers - knowing where to > look, > how to look, or how and what to ask. Basic problem solving. > Life is short, time is limited for every one of us. Make the most of the > time > available to you, don't waste it. Don't we know it.

1 0

Re: 2.4.6 prov/con, delta-syncrepl and auditContext
by Gavin Henry 08 Dec '07

08 Dec '07

<quote who="Pierangelo Masarati"> > Gavin Henry wrote: >> <quote who="Aaron Richton"> >>> In the spirit of starting with the obvious, do you find auditContext >>> under >>> cn=Subschema? >> >> I'll check ;-) >> >> But why would this attribute get into the normal data dir? > > that attribute is added to the producer to provide a pointer to the > database that contains the log. The attributeType itself is defined by > slapo-accesslog(5), so the overlay should be present (but does not need > to be instantiated; just compiled in or, if built as module, loaded) in > the consumer in order to have that attribute defined. Why would I need to load the accesslog overlay on the consumer? I never have before. The only thing that mentions accesslog is the normal delta-syncrepl directives: logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog etc. I'm confused here. Is it a 2.4 change?

6 8

Is there a way to limit number of active connections?
by Alina Dubrovska 08 Dec '07

08 Dec '07

Hello, Is there some way to configure maximum number of active connections to OpenLDAP server? Thnaks, Alina.

4 4

Re: logging
by Howard Chu 08 Dec '07

08 Dec '07

Joseph Dickson wrote: > A quick preface -- I appreciate the work that everyone puts forth on the > OpenLDAP project, including the documentation. OpenLDAP does a great > job of allowing me to spend my time on things that are interesting and > important to my particular situation, rather than fighting with a server. > > However, I do tend to speak up when I hear folks talk about the > documentation that exists as being adequate... I think the best evidence > that this is not the case is that, on this list, I consistently see the > same 4 or 5 people answering the questions which pertain to the OpenLDAP > server itself. I don't think that proves your point; the vast majority of people using OpenLDAP already figured out how to do everything they want with it and never come here in the first place. All you're seeing is that a small segment of the population actually takes the pains to answer questions. > I would suggest that at least keeping a recent version of the > documentation on the project website would help a great deal. I don't > agree that the best place for the documentation to live is with the > code, at least not for the user. With 2.4 we've put procedures in place to update the online docs whenever a new release is uploaded. As for docs living with the code - if you're using a prebuilt distro, the docs obviously live wherever the distro packager put them. If you built it yourself, the docs get installed when you install the binaries. I don't see your point. >> When you're looking for a software feature, the manpages and Admin >> Guide should be your first resort. Pretty much every feature is >> documented. Some features exist that are undocumented; most of them >> are intentionally so, so don't give them a second thought. A web >> search should be your last resort. > Could you give me an example of a feature that remains undocumented > intentionally? NO. (just kidding) > This seems like a bad philosophy on the face of it, so I > must be missing something.. Ok, for example, there are various options in different sections of code that can only be enabled by explicitly defining certain macros at compile time. They're not documented anywhere; if you look in the source code they're obvious though. These tend to be extra debug functions that developers can use while working on related code. Most people will never need them; developers who need them can use them easily enough. > In general, I just wanted to remind everyone that OpenLDAP's > documentation isn't great, and saying that it is doesn't really help. > Compare to the documentation of other projects (for example, Postgres), > I think we can agree that there's quite a bit of room for improvement. > I know it would be better for me to step up and begin writing rather > than rubbing salt in the wound, as it were, but sadly my free time is > already devoted to other things so the best I can do at this point is > try to remind people that there is work to be done on the documentation. Your reminder is less than worthless, because it just gives people an excuse to continue to not rely on the existing docs, instead of using them and helping to fix their shortcomings. It also fails to acknowledge the tremendous amount of work that continues to be done on actually improving the docs. (E.g., the 2.4 Admin Guide which is over 100 pages longer than the 2.3 Guide.) And it belabors the obvious - everybody actually contributing to the OpenLDAP codebase is already keenly aware of the need for improvement. If they thought the status quo was fine, they wouldn't be writing contributions in the first place. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Recursive access control for groups
by Alina Dubrovska 08 Dec '07

08 Dec '07

Hello, We need to configure recursive access control for groups in OpenLDAP server. I will describe in details. Currently we allow members of "System Administrator" group to modify specific attributes by defining an ACL: access to attrs=employeeType,employeeNumber by self write *by group/groupOfUniqueNames/uniqueMember="cn=System Administrator,ou=groups,dc=domain,dc=com" write* by * read The problem is that we need to handle also nested memberships. If some group is specified as a uniqueMember of "System Administrator" group, then access should be granted to all sub-group members and so on recursively. In the following example both users (user1 and user2) must be able to modify attributes: dn: cn=System Administrator,ou=groups,dc=domain,dc=com uniqueMember: cn=user1,ou=users,dc=domain,dc=com uniqueMember: cn=Sub Group,ou=groups,dc=domain,dc=com dn: cn=Sub Group,ou=groups,dc=domain,dc=com uniqueMember: cn=user2,ou=users,dc=domain,dc=com It should be possible to create new group, add it as uniqueMember to "System Administrator" group and then all new group members automatically must be granted access to attributes. I have found the following solution, which uses Sets syntax: access to attrs=employeeType,employeeNumber by self write * by set="[cn=System Administrator,ou=groups,dc=domain,dc=com]/uniqueMember* & user" write* by * read At first glance it worked as expected, but then problems started to appear... We have two OpenLDAP instances and now there are two different problems. *First instance* (2.3.38) - After including some group in "System Administrator" and performing some operations, then after some time OpenLDAP crashes! *Second instance* (2.3.27) - OpenLDAP doesn't crash, but operations (e.g. search) are very slow (un-acceptable)! I can provide more details if necessary. So, my questions are: 1) Is ACL with subject: *by set="[cn=System Administrator,ou=groups,dc=domain,dc=com]/uniqueMember* & user" write* valid for our situation? 2) Maybe there is another way to achieve our goal (that would be easier to apply rather than investigating current problems)? 3) Could please somebody assist in problems with new configuration (crash on 1st instance and poor performance on 2nd) ? By the way, we are using quite advanced configuration, with ppolicy, refint, unique, accesslog overlays enabled. So probably there are dependencies or incompatibilities between them... That is very urgent and critical for our project, we really need to solve this problem as soon as possible! Please help!!! Thanks a lot in advance, Alina.

3 3

Re: chain and ppolicy question
by Gavin Henry 07 Dec '07

07 Dec '07

<quote who="Tony Earnshaw"> > Gavin Henry skrev, on 06-12-2007 23:13: > >>> My site is implementing ppolicy on a 4-server OpenLDAP/RHEL5 setup. I >>> have a problem with chaining referrals from the 3 slaves to the master. >>> I followed the slapo-chain man page and chaining works: >>> >>> moduleload back_ldap.la >>> >>> overlay chain >>> >>> chain-uri "ldaps://mercurius.intern" >>> chain-idassert-bind bindmethod="simple" >>> binddn="cn=proxy,dc=barlaeus,dc=nl" >>> credentials="secret" >>> chain-return-error true >>> >>> cn=proxy,dc=barlaeus,dc=nl is the rootdn on all servers, thus also on >>> the master. >>> >>> The rootdn is not able to update passwords. I have no idea why the >>> rootdn shouldn't be able to update passwords (PASSMOD). However, it >>> seems to me that the chaining from the slave should be carried out as >>> the actual user and not rootdn. I can find nothing in slapo-chain or >>> slapd-ldap that lists this possibility. >>> >>> Can anyone here help with this? >>> >> >> What are you logs/-d saying? > > It's been a while since and up to now I've only had logs going back 5 > days (I've increased this to 21 days now, but that doesn't help here). > > Basically, the rootdn bound, issued a PASSMOD instruction for > userPassword and got a reply tag=103 error=0; it then did a MOD > instruction for shadowLastChange and got the same. userPassword wasn't > changed, but shadowLastChange was. > > By having the slave server connect directly to the provider instead of > using the consumer's chain function, all happens as expected, so that's > the workaround at the present- but it's far from optimal. The slave connect directly to the provider? What does that mean? Surely the slave issues a referral and the client follows it? > > Best, > > --Tonni > > -- > Tony Earnshaw > Email: tonni at hetnet dot nl >

2 1

size limit by ip?
by Patrick Radtke 07 Dec '07

07 Dec '07

Is it possible to control the size limit based on the ip address? man slapd.conf *limits* <*who*> <*limit*> *[*<*limit*> *[...]] *The argument *who* can be any of anonymous | users | [dn[.<style>]=]<pattern> | group[/oc[/at]]=<pattern> Which doesn't look like the 'who' can be an ip address, but I just want to confirm that is the case (since the 'who' in slapd.access support peername.ip and I'm hoping that that the underlying code for both 'who's is the same :) Basically we have software running on a host that is unable to authenticate (due to 3rd party software) and we need to increase the size limits for queries coming from it, without increasing that limit for all anonymous binds. Are there alternative ways of doing this? Possibly setting up a server with back-ldap running, only allowing access from the specific ip address and letting the back-ldap server bind to real servers as an authorized account? Or is there a way to map ip address to an identity that can be used in the limits control. We're running 2.3.24. thanks, Patrick

3 2

Re: Recursive access control for groups
by Gavin Henry 07 Dec '07

07 Dec '07

<quote who="Alina Dubrovska"> > Gavin, > > Thank you for reply and suggestion about support services! > However, I'm looking forward that somebody from the list is familiar with > sets syntax for defining an ACL and would be able to determine if ACL like > this is correct: > > *access to attrs=employeeType,employeeNumber > by self write > by set="[cn=System > Administrator,ou=groups,dc=domain,dc=com]/uniqueMember* & user" write > by * read* Switch on ACL debugging and run slapd by hand to check. > > So, we have a parent group (groupOfUniqueNames, "System Administrator") > and > all members should be granted access permission to modify specific > attributes. Then we need to have ability to add new child groups in > runtime, > so that all child group members would be automatically granted the same > set > of permissions as parent group. Without modifying slapd.conf and > restarting > server of course. > > Probably there is some important nuance with sets syntax or maybe there is > any another alternative solution? > > Because as I mentioned, with stated ACL we have performance issues on one > OpenLDAP instance and fatal crash on another... Sets are somewhat experimental. Well crashes shouldn't happen, so that should be a bug report via http://www.openldap.org/its. Please read http://www.openldap.org/doc/admin24/troubleshooting.html for submitting proper bug reports.

1 0

Re: Re[2]: slave-to-master replica
by Gavin Henry 07 Dec '07

07 Dec '07

Thanks. And now your logs? More info, more info.... <quote who="A Molchanov"> > > > -----Original Message----- > From: Gavin Henry <ghenry(a)suretecsystems.com> > To: A Molchanov <vip43(a)mail.ru> > Date: Thu, 06 Dec 2007 20:31:25 +0000 > Subject: Re: slave-to-master replica > > > A Molchanov wrote: >> Hellow, its about for ldap-2.3 replication with syncrepl >> I need slave-to-master replica, have making slapd.conf like >> http://www.openldap.org/faq/data/cache/1434.html... but it's not >> working. > > Hi, > > Can we see your config? > >> Its even imposable to make changes on the slave directly,.. > > A slave is readonly > >> I hope anybody have a working sample, ..please show me > > More info needed. > > > > yes, thanks, my ldap version 2.3-27 > my slapd.conf is: > > ---master: > ------- > authz-policy to > > authz-regexp cn=admin > cn=admin,dc=firm,dc=ru > > #authz-regexp cn=slave1.firm.ru > cn=slave1.firm.ru,ou=IT,dc=firm,dc=ru > > access to attrs=authzTo > by * read stop > > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > ---------- > > and slave: > -------- > overlay chain > chain-uri ldaps://master.firm.ru > chain-idassert-bind bindmethod=simple > binddn="cn=admin,dc=firm,dc=ru" > mode=self > chain-idassert-authzFrom "*" > chain-return-error TRUE > > syncrepl rid=5 > provider=ldap://192.168.0.1 > bindmethod=simple > binddn="cn=admin,dc=firm,dc=ru" > credentials=ghbrjkmysqcthdth > searchbase="dc=firm,dc=ru" > scope=sub > schemachecking=on > type=refreshAndPersist > retry="50 +" > updateref ldap://192.168.0.1 > --------- > .that is the subject of the help )) >

1 0

chain and ppolicy question
by Tony Earnshaw 07 Dec '07

07 Dec '07

OpenLDAP 2.3.38. My site is implementing ppolicy on a 4-server OpenLDAP/RHEL5 setup. I have a problem with chaining referrals from the 3 slaves to the master. I followed the slapo-chain man page and chaining works: moduleload back_ldap.la overlay chain chain-uri "ldaps://mercurius.intern" chain-idassert-bind bindmethod="simple" binddn="cn=proxy,dc=barlaeus,dc=nl" credentials="secret" chain-return-error true cn=proxy,dc=barlaeus,dc=nl is the rootdn on all servers, thus also on the master. The rootdn is not able to update passwords. I have no idea why the rootdn shouldn't be able to update passwords (PASSMOD). However, it seems to me that the chaining from the slave should be carried out as the actual user and not rootdn. I can find nothing in slapo-chain or slapd-ldap that lists this possibility. Can anyone here help with this? Best, --Tonni -- Tony Earnshaw Email: tonni at hetnet dot nl

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software