- openldap-bugs - openldap.org

Re: ITS#5075
by ando＠sys-net.it 06 Aug '07

06 Aug '07

ando(a)sys-net.it wrote: > fixed in HEAD; please test. also fixed in re23; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

ITS#5075
by ando＠sys-net.it 06 Aug '07

06 Aug '07

fixed in HEAD; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5075) openldap is not compilable with newest glibc and -D_FORTIFY_SOURCE=2
by jsafranek＠redhat.com 06 Aug '07

06 Aug '07

Full_Name: Jan Safranek Version: 2.3.37 OS: Linux (Fedora rawhide) URL: http://people.redhat.com/jsafrane/openldap-2.3.37-fortify-open.patch Submission from: (NULL) (62.40.79.66) Recently we have integrated glibc 2.6.90 into Fedora Linux distribution and OpenLDAP is not compilable anymore. We use -D_FORTIFY_SOURCE=2 to check for common errors on compile time and this switch causes that open() in fcntl.h is not a function name but a macro in the new glibc headers. Berkeley DB often uses 'something->open(...)' to open database, which is expanded by the compiler using the macro from fcntl.h -> compilation error. Compilation can be easily fixed by using additional braces around open, like '(something->open)(...)'. I do not like open() being macro, but POSIX allows it and glibc guys seems to be quite strict in this. The new glibc shall be released in fall and all major distributions will use it sooner or later, therefore I would suggest to adapt few OpenLDAP sources to it.

1 0

Re: (ITS#5074) slapo-pcache's proxyattrset does not recognize "1.1" to describe an empty attribute set
by ando＠sys-net.it 06 Aug '07

06 Aug '07

zep-openldap-software(a)ni.enate.org wrote: > For an application which specifies LDAP_NO_ATTRS to the attributes parameter of > ldap_search_st(), it seems not possible to cache its results using > slapo-pcache. > > It would be great to be able to define within "overlay pcache", something like: > > proxyattrset 0 (1.1) > > or, simply > > proxyattrset 0 > > Which would match queries which provide LDAP_NO_ATTRS. This would allow the > ability to cache responses for routines which are interested only in the > presence of a result set, but not in the contents of that set, without the > additional overhead of trasnferring the result. I believe there's something odd in pcache's current behavior. In fact, right now "proxyattrset 0" is already a valid directive, but it implies "proxyattrset 0 *", which means all attributes. Unfortunately, this seems to only work if no attribute is requested, while it fails if a "*" is explicitly requested. I've modified the propxycache code in HEAD so that a "1.1" can only explicitly appear in a list if it's the only string. An empty attribute set is no longer valid, to avoid confusion about the meaning of non-explicit attribute sets. A "*" or a "+" can explicitly appear in a proxyattrset statement, resulting in the expected behavior. Use both to indicate that all attributes are in the set. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5073) Syncrepl spinlock
by ando＠sys-net.it 06 Aug '07

06 Aug '07

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.37 > OS: Linux > URL: > Submission from: (NULL) (71.202.148.128) > > > If you create a syncrepl master that serves the "" base, and then set up a > syncrepl consumer to pull down "dc=example,dc=com", which does *not* exist on > the master, the replica will sit at 100% CPU, endlessly trying to add nothing. I'm not observing this with either re23 nor HEAD. The initial search correctly fails with noSuchObject, and then both slapds sit at 0% CPU. Can you give further details? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5074) slapo-pcache's proxyattrset does not recognize "1.1" to describe an empty attribute set
by zep-openldap-software＠ni.enate.org 04 Aug '07

04 Aug '07

Full_Name: Mike Malsman Version: 2.3.33 OS: FreeBSD 6 URL: Submission from: (NULL) (65.12.196.28) For an application which specifies LDAP_NO_ATTRS to the attributes parameter of ldap_search_st(), it seems not possible to cache its results using slapo-pcache. It would be great to be able to define within "overlay pcache", something like: proxyattrset 0 (1.1) or, simply proxyattrset 0 Which would match queries which provide LDAP_NO_ATTRS. This would allow the ability to cache responses for routines which are interested only in the presence of a result set, but not in the contents of that set, without the additional overhead of trasnferring the result.

1 0

(ITS#5073) Syncrepl spinlock
by quanah＠OpenLDAP.org 03 Aug '07

03 Aug '07

Full_Name: Quanah Gibson-Mount Version: 2.3.37 OS: Linux URL: Submission from: (NULL) (71.202.148.128) If you create a syncrepl master that serves the "" base, and then set up a syncrepl consumer to pull down "dc=example,dc=com", which does *not* exist on the master, the replica will sit at 100% CPU, endlessly trying to add nothing. --Quanah

1 0

(ITS#5072) Possibly incorrect certificateExactAssertion()
by ando＠sys-net.it 03 Aug '07

03 Aug '07

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.35) Submitted by: ando A certificate in certificateExactAssertion GSER form should be something like (wrapped for readability) { serialNumber 3, issuer rdnSequence:email=ca@example.com,cn=example ca,o=example,st=xx,c=us } according to RFC4523 & RFC3687, as far as I understand it. However, OpenLDAP HEAD uses the form { serialNumber 3, issuer "email=ca(a)example.com,cn=example ca,o=example,st=xx,c=us" } Note the quotes around the DN and the missing "rdnSequence:" prefix. p.

1 0

Re: (ITS#5069) SyncRepl on request
by bgmilne＠staff.telkomsa.net 03 Aug '07

03 Aug '07

On Wednesday 01 August 2007 23:53:22 hadmut(a)danisch.de wrote: > Full_Name: Hadmut Danisch > Version: 2.3.35 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.180.64.215) > > > This is an enhancement request: > > When having a distributed LDAP structure with a master and several SyncRepl > clients, the clients can do the SyncRepl only on fixed refresh intervals > (e.g. type=refreshOnly, > interval=00:00:20:00) > > However, there are many situations where this is inappropriate, e.g. on > dial-on connections, roaming notebooks, and things like that. > > Therefore, slapd should have a client mode where the SyncRepl process is > performed only on request, but then immediately. There should be an > external trigger to pull, e.g. send a signal oder do a special LDAP > request. slapd should then start a SyncRepl. > > E.g. this could be put in scripts run at connect-time (pppd provides that > kind of scripting), or when notebook autoconfiguration detects (e.g. with > tools like guessnet) that it is connected to the home network to update > it's local slapd. While I'm not saying this feature should not be implemented, I note that there are other solutions for doing off-line authentication on (e.g.) laptops that don't expose the whole DIT (but only credentials that have already been used on the client).

1 0

Re: (ITS#5070) Issues in X.509 certificate parsing
by ando＠sys-net.it 03 Aug '07

03 Aug '07

Kurt Zeilenga wrote: > This and other RFC 4511 BER restrictions do not apply to > BER/DER-encoded attribute values, such as certificates. A cleaner and simpler solution is in HEAD for those serials that fit into a long long, when it's available. Otherwise, arbitrary precision support is required (OpenSSL's bignum, GNU's GMP or so). Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5071) ;binary issue
by kurt＠OpenLDAP.org 02 Aug '07

02 Aug '07

On Aug 2, 2007, at 11:01 PM, ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re23 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.72.89.40) > > > I've noticed an issue related to operating on certificates with/ > without ;binary, > as detailed in the table below > > slapadd filter requested attrs > > | ;binary | no ;binary | ;binary | > no ;binary > -------------+--------------+--------------+-------------- > +--------------- > ;binary | results | results | returned | returned > -------------+--------------+--------------+-------------- > +--------------- > no ;binary | no results | results | not returned | returned > > So it seems that if data is loaded with ;binary then search > operations work > regardless of having specified ;binary in search filters or in > requested > attributes, while if data is loaded without, then search operations > only work if > ;binary is omitted. RFC 4523 states that ;binary MUST be used when > transferring > certificates, so perhaps slapd should be either liberal enough to > allow any > combination, or strict enough to prevent those data types from > working without > ;binary. The bug is in allowing a certificate to be loaded without ;binary. -- Kurt

1 0

(ITS#5071) ;binary issue
by ando＠sys-net.it 02 Aug '07

02 Aug '07

Full_Name: Pierangelo Masarati Version: HEAD/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) I've noticed an issue related to operating on certificates with/without ;binary, as detailed in the table below slapadd filter requested attrs | ;binary | no ;binary | ;binary | no ;binary -------------+--------------+--------------+--------------+--------------- ;binary | results | results | returned | returned -------------+--------------+--------------+--------------+--------------- no ;binary | no results | results | not returned | returned So it seems that if data is loaded with ;binary then search operations work regardless of having specified ;binary in search filters or in requested attributes, while if data is loaded without, then search operations only work if ;binary is omitted. RFC 4523 states that ;binary MUST be used when transferring certificates, so perhaps slapd should be either liberal enough to allow any combination, or strict enough to prevent those data types from working without ;binary. p.

1 0

Re: (ITS#5070) Issues in X.509 certificate parsing
by kurt＠OpenLDAP.org 02 Aug '07

02 Aug '07

On Aug 2, 2007, at 10:48 PM, ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > >> I've an issue with X.509 certificate parsing in HEAD/re24. The >> certificate, >> according to OpenSSL, has a SerialNumber c8:5b:9a:dd:ea:bf:f9:fa >> and HEAD fails >> to parse it because it is an integer with length equal to 9, which >> is larger >> than sizeof(ber_int_t), as tested in ber_getnint() at decode.c: >> 254. The DER >> encoded value is: 2 9 0 200 91 154 221 234 191 249 250. >> Seems to be time >> to get past the sizeof(ber_int_t) limitation... > > ... which would violate RFC 4511 where it states that INTEGER means > from > 0 up to 2^31-1... This and other RFC 4511 BER restrictions do not apply to BER/DER-encoded attribute values, such as certificates. > I have a simple solution for this problem, at the > cost of partially violating rfc 4523: if an integer is larger than > 2^31-1, it could be represented in the certificateExactMatch > normalization in hexadecimal form, much like OpenSSL does. This would > increase interoperability with OpenSSL and be at least self- > consistent, > since all serialNumbers that large would be consistently expanded that > way. Another solution, preserving the decimal representation, would > probably require some arbitrary precision support from external > libraries. If there's consensus, I'd post my simple patch. > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- > > >

1 0

Re: (ITS#5070) Issues in X.509 certificate parsing
by ando＠sys-net.it 02 Aug '07

02 Aug '07

ando(a)sys-net.it wrote: > I've an issue with X.509 certificate parsing in HEAD/re24. The certificate, > according to OpenSSL, has a SerialNumber c8:5b:9a:dd:ea:bf:f9:fa and HEAD fails > to parse it because it is an integer with length equal to 9, which is larger > than sizeof(ber_int_t), as tested in ber_getnint() at decode.c:254. The DER > encoded value is: 2 9 0 200 91 154 221 234 191 249 250. Seems to be time > to get past the sizeof(ber_int_t) limitation... ... which would violate RFC 4511 where it states that INTEGER means from 0 up to 2^31-1... I have a simple solution for this problem, at the cost of partially violating rfc 4523: if an integer is larger than 2^31-1, it could be represented in the certificateExactMatch normalization in hexadecimal form, much like OpenSSL does. This would increase interoperability with OpenSSL and be at least self-consistent, since all serialNumbers that large would be consistently expanded that way. Another solution, preserving the decimal representation, would probably require some arbitrary precision support from external libraries. If there's consensus, I'd post my simple patch. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5070) Issues in X.509 certificate parsing
by ando＠sys-net.it 02 Aug '07

02 Aug '07

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I've an issue with X.509 certificate parsing in HEAD/re24. The certificate, according to OpenSSL, has a SerialNumber c8:5b:9a:dd:ea:bf:f9:fa and HEAD fails to parse it because it is an integer with length equal to 9, which is larger than sizeof(ber_int_t), as tested in ber_getnint() at decode.c:254. The DER encoded value is: 2 9 0 200 91 154 221 234 191 249 250. Seems to be time to get past the sizeof(ber_int_t) limitation... p.

1 0

Re: (ITS#5064) Issues with openldap 2.2 (Error 34 Invalid DN syntax )
by bgmilne＠staff.telkomsa.net 02 Aug '07

02 Aug '07

On Friday 27 July 2007 17:19:26 pbrinette(a)cc.in2p3.fr wrote: > > 1) both 2.0 and 2.2 are ancient. OpenLDAP 2.3 is mature, and 2.4 is > > about to exit beta stage. Unless the problem is related to a real > > software bug, and it persists either in HEAD/2.4 or in 2.3 code, this > > ITS will be closed. > > Currently, I've no mean to use an openldap 2.3 unless exists an RPM > update package for RHEL 4 (or CentOS). There is no update from RHEL or CentOS, but there are these (mine): http://staff.telkomsa.net/packages/rhel4/openldap/ Since you can install them in parallel, the upgrade path is quite easy ... (slapcat|slapadd2.3 after configuration). There is also: http://staff.telkomsa.net/packages/rhel3/openldap/ Regards, Buchan

1 0

(ITS#5069) SyncRepl on request
by hadmut＠danisch.de 01 Aug '07

01 Aug '07

Full_Name: Hadmut Danisch Version: 2.3.35 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.180.64.215) This is an enhancement request: When having a distributed LDAP structure with a master and several SyncRepl clients, the clients can do the SyncRepl only on fixed refresh intervals (e.g. type=refreshOnly, interval=00:00:20:00) However, there are many situations where this is inappropriate, e.g. on dial-on connections, roaming notebooks, and things like that. Therefore, slapd should have a client mode where the SyncRepl process is performed only on request, but then immediately. There should be an external trigger to pull, e.g. send a signal oder do a special LDAP request. slapd should then start a SyncRepl. E.g. this could be put in scripts run at connect-time (pppd provides that kind of scripting), or when notebook autoconfiguration detects (e.g. with tools like guessnet) that it is connected to the home network to update it's local slapd. regards Hadmut

1 0

Re: (ITS#5067) olcLogLevel value is incorrect
by ando＠sys-net.it 30 Jul '07

30 Jul '07

Quanah Gibson-Mount wrote: > --On Tuesday, July 31, 2007 4:35 AM +0000 ando(a)sys-net.it wrote: > >> quanah(a)zimbra.com wrote: >>> Full_Name: Quanah Gibson-Mount >>> Version: 2.3.37 >>> OS: NA >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (66.92.25.194) >>> >>> >>> When using cn=config with a slapd.conf driven slapd, the value for >>> olcLogLevel is not correct: >>> >>> ldapsearch -LLL -x -h build -b "cn=config" -s base -D "cn=config" -W >>> olcLogLevel >>> Enter LDAP Password: >>> dn: cn=config >>> olcLogLevel: None >>> >>> However: >>> >>> grep loglevel conf/slapd.conf >>> loglevel 32768 >>> >>> And the logging that is happening is actually for level 32768. >>> Modifying the loglevel works, and once that is done, the right loglevel >>> is shown. However, this makes it impossible to know what loglevel is >>> set via a remote query unless it has been changed. >> >>> From slapd.conf(5), loglevel: >> 32768 (0x8000 none) only messages that get logged >> whatever log level is set >> >> Seems to be correct. > > Yet if I modify it to be "256", then olcLogLevel is "256". If I modify > it to be "32768", then it is "32768". That's because in EMIT the loglevel goes through loglevel2bvarray(), which turns the level into an array of pretty values. You're supposed to modify the loglevel by adding multiple values, each with the descriptive name of the level you're using. The use of loglevel with OR'ed integers is stylistically deprecated. > So if the loglevel setting in > slapd.conf is "32768", then that is what it should match. In any case, > "None" has the unfortunate ring of sounding like an unset value. In LDAP, if the value were unset, the attribute would be missing, which is what you get if, for example, you set loglevel to 0. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5067) olcLogLevel value is incorrect
by quanah＠zimbra.com 30 Jul '07

30 Jul '07

--On Tuesday, July 31, 2007 4:35 AM +0000 ando(a)sys-net.it wrote: > quanah(a)zimbra.com wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.3.37 >> OS: NA >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (66.92.25.194) >> >> >> When using cn=config with a slapd.conf driven slapd, the value for >> olcLogLevel is not correct: >> >> ldapsearch -LLL -x -h build -b "cn=config" -s base -D "cn=config" -W >> olcLogLevel >> Enter LDAP Password: >> dn: cn=config >> olcLogLevel: None >> >> However: >> >> grep loglevel conf/slapd.conf >> loglevel 32768 >> >> And the logging that is happening is actually for level 32768. >> Modifying the loglevel works, and once that is done, the right loglevel >> is shown. However, this makes it impossible to know what loglevel is >> set via a remote query unless it has been changed. > >> From slapd.conf(5), loglevel: > 32768 (0x8000 none) only messages that get logged > whatever log level is set > > Seems to be correct. Yet if I modify it to be "256", then olcLogLevel is "256". If I modify it to be "32768", then it is "32768". So if the loglevel setting in slapd.conf is "32768", then that is what it should match. In any case, "None" has the unfortunate ring of sounding like an unset value. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5067) olcLogLevel value is incorrect
by ando＠sys-net.it 30 Jul '07

30 Jul '07

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.37 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (66.92.25.194) > > > When using cn=config with a slapd.conf driven slapd, the value for olcLogLevel > is not correct: > > ldapsearch -LLL -x -h build -b "cn=config" -s base -D "cn=config" -W > olcLogLevel > Enter LDAP Password: > dn: cn=config > olcLogLevel: None > > However: > > grep loglevel conf/slapd.conf > loglevel 32768 > > And the logging that is happening is actually for level 32768. Modifying the > loglevel works, and once that is done, the right loglevel is shown. However, > this makes it impossible to know what loglevel is set via a remote query unless > it has been changed. >From slapd.conf(5), loglevel: 32768 (0x8000 none) only messages that get logged whatever log level is set Seems to be correct. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5068) buglet in charray.c
by quanah＠zimbra.com 30 Jul '07

30 Jul '07

--On July 30, 2007 9:28:06 PM +0000 mb(a)g10code.com wrote: > Full_Name: Marcus Brinkmann > Version: 2.1.30 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (87.123.156.61) OpenLDAP 2.1 is no longer a supported release. The current release branch is OpenLDAP 2.3. Please do not file ITSes on dead releases. Thanks. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5068) buglet in charray.c
by mb＠g10code.com 30 Jul '07

30 Jul '07

Full_Name: Marcus Brinkmann Version: 2.1.30 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.123.156.61) This fixes a warning and seems locally correct. I did not check the expected semantics of this code. Thanks, Marcus. diff -ru openldap2-2.1.30-orig/libraries/libldap/charray.c openldap2-2.1.30/libraries/libldap/charray.c --- openldap2-2.1.30-orig/libraries/libldap/charray.c 2003-03-03 18:10:04.000000000 +0100 +++ openldap2-2.1.30/libraries/libldap/charray.c 2007-07-30 23:24:30.000000000 +0200 @@ -183,7 +183,7 @@ i = 1; for ( s = str; *s; s++ ) { - if ( ldap_utf8_strchr( brkstr, s ) != NULL ) { + if ( ldap_utf8_strchr( brkstr, *s ) != NULL ) { i++; } }

1 0

(ITS#5067) olcLogLevel value is incorrect
by quanah＠zimbra.com 30 Jul '07

30 Jul '07

Full_Name: Quanah Gibson-Mount Version: 2.3.37 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.92.25.194) When using cn=config with a slapd.conf driven slapd, the value for olcLogLevel is not correct: ldapsearch -LLL -x -h build -b "cn=config" -s base -D "cn=config" -W olcLogLevel Enter LDAP Password: dn: cn=config olcLogLevel: None However: grep loglevel conf/slapd.conf loglevel 32768 And the logging that is happening is actually for level 32768. Modifying the loglevel works, and once that is done, the right loglevel is shown. However, this makes it impossible to know what loglevel is set via a remote query unless it has been changed.

1 0

Re: Contribution: Active Directory Password Cache (ITS#5042)
by s.hetze＠linux-ag.de 30 Jul '07

30 Jul '07

Hi Gavin, I just uploaded a patch for my contribution as Sebastian-Hetze-070630.patch (sorry for the wrong date) The adpwc as contributed has a dependency to samba3.schema to be present, which is fixed with this patch. The patch also makes adpwc fold realm names to upper case since AD stores them mixed case and gives tickets upper case. I introduced a new config option adpw-cache-keep-realm-case to keep the old behaviour if needed. It looks like I cannot add this patch to ticket #5042, so I ask you to attach it if possible. Thanx alot, Sebastian On Thu, Jul 19, 2007 at 09:48:58AM +0000, Gavin Henry wrote: > Hi, > > This looks like it is in the correct format for our contrib section. Just > testing is needed. As I don't have access to an Active Directory server I can't > test. > > Anyone else? > > Gavin. -- Sebastian Hetze Mitglied des Vorstands Linux Information Systems AG Ehrenbergstr. 19, D-10245 Berlin Fon: +49 30 726238-0, Fax: +49 30 726238-99 s.hetze(a)linux-ag.com, http://www.linux-ag.com ---------------------------------------------------------- Sitz der Gesellschaft: Stefan-George-Ring 8, 81929 München Amtsgericht München: HRB 128 019 Vorstand: Rudolf Strobl, Sebastian Hetze Aufsichtsrat: Michael Tarabochia (Vorsitzender)

1 0

(ITS#5066) ldap error :server down
by jalali_azam＠yahoo.com 30 Jul '07

30 Jul '07

Full_Name: Azam Jalali Version: 2.2.29 OS: windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.207.237.38) I installed openldap 2.2.9 and set sldap.conf as following: /////////////////////////////////////////////////////////////////////////// ucdata-path ./ucdata include ./schema/core.schema include ./schema/cosine.schema include ./schema/inetorgperson.schema include ./schema/nis.schema include ./schema/dyngroup.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap:/root.openldap.org pidfile ./run/slapd.pid argsfile ./run/slapd.args # Load dynamic backend modules: # modulepath ./libexec/openldap # moduleload back_bdb.la # moduleload back_ldap.la # moduleload back_ldbm.la # moduleload back_passwd.la # moduleload back_shell.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=my-domain,dc=com" rootdn "cn=Manager,dc=my-domain,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory ./data # Indices to maintain index objectClass eq access to attr=userpassword by anonymous auth by self write by dn="cn=Manager,dc=my-domain,dc=com" write by * none access to * by dn="cn=Manager,dc=my-domain,dc=com" write by users write by self write by * read by * write /////////////////////////////////////////////////////////////////////////// After running some query on this openldap i got ldap error:server down. This event occurs every time i reinstalled it and ran some query on it? How i fix this error? Thanks in advance Azam Jalali

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs