https://bugs.openldap.org/show_bug.cgi?id=8758
--- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
(In reply to mirror(a)koddos.net from comment #2)
> Hello,
>
> Yes we still are interested. We run mirrors in Hong Kong and the
> Netherlands. We can setup both locations if you wish.
Hi Martin,
That sounds great. The server for rsync is www.openldap.org and the module
name is OpenLDAP-ftp
Let me know the links to the mirrors they are configured and I will add them to
the website.
Regards,
Quanah
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8614
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Test suite fails when using |Remove ability to build
|--with-threads=no |non-threaded slapd
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8614
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|CONFIRMED |IN_PROGRESS
Assignee|bugs(a)openldap.org |quanah(a)openldap.org
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=6151
--- Comment #20 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
(In reply to Howard Chu from comment #9)
> > a) cosine.schema (== RFC1274)
> > cosine4524.schema (== RFC4524)
> > mutually exclusive (Kurt does not like this)
> >
> > b) cosine4524.schema (== RFC4524)
> > cosine.schema (== RFC1274 - RFC4524)
> > the latter includes the former
> >
> > c) cosine4524.schema (== RFC4524)
> > cosine1274.schema (== RFC1274 - RFC4524)
> >
> > (there might be more)
>
> Yes, cosine.schema wrapping cosine4524.schema and cosine1274.schema might be
> best.
Sounds like (d) is the best option then:
cosine4524.schema
cosine1274.schema
cosine.schema
?
Michael, do you want to update your patch for this?
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8376
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|quanah(a)openldap.org |bugs(a)openldap.org
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8376
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|IN_PROGRESS |CONFIRMED
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9255
Bug ID: 9255
Summary: make fails in 2.4.50 due to missing Debug1/Debug3
symbols
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: marcosbd(a)vmware.com
Target Milestone: ---
We're finding an issue building OpenLDAP due to missing Debug1/Debug3 symbols:
Entering subdirectory libldap
make[2]: Entering directory
'/bitnami/blacksmith-sandox/openldap-2.4.50/libraries/libldap'
/bin/sh ../../libtool --mode=link gcc -Wl,-z,relro,-z,now,--as-needed
-DLDAP_CONNECTIONLESS -DLDAP_USE_NON_BLOCKING_TLS
-Wl,-rpath=/opt/bitnami/openldap/lib -L/opt/bitnami/openldap/lib -o apitest
apitest.o libldap.la ../../libraries/liblber/liblber.la
../../libraries/liblutil/liblutil.a -lsasl2 -lssl -lcrypto -lcrypt -lresolv
gcc -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--as-needed -DLDAP_CONNECTIONLESS
-DLDAP_USE_NON_BLOCKING_TLS -Wl,-rpath=/opt/bitnami/openldap/lib -o
.libs/apitest apitest.o -L/opt/bitnami/openldap/lib ./.libs/libldap.so
/bitnami/blacksmith-sandox/openldap-2.4.50/libraries/liblber/.libs/liblber.so
../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a
-lsasl2 -lssl -lcrypto -lcrypt -lresolv -Wl,--rpath
-Wl,/opt/bitnami/openldap/lib
/usr/bin/ld: ./.libs/libldap.so: undefined reference to `Debug1'
/usr/bin/ld: ./.libs/libldap.so: undefined reference to `Debug3'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:309: apitest] Error 1
make[2]: Leaving directory
'/bitnami/blacksmith-sandox/openldap-2.4.50/libraries/libldap'
make[1]: *** [Makefile:296: all-common] Error 1
make[1]: Leaving directory
'/bitnami/blacksmith-sandox/openldap-2.4.50/libraries'
make: *** [Makefile:312: all-common] Error 1
We see that in master there are a lot of references to those symbols, but in
the OPENLDAP_REL_ENG_2_4_50 tag of the repo it only appears in two places.
It looks like this issue was caused by commit 7cf7aa3141 in ITS#8650.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9254
Bug ID: 9254
Summary: Datatypes boudary check on slapadd
Product: OpenLDAP
Version: 2.4.42
Hardware: All
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: c.dosio(a)gmail.com
Target Milestone: ---
The import of an LDIF file containing a passwordPolicy objectClass where the
attribute pwdMaxAge was populated as 50000000000000 (while the max value of
that attribute should be 315360000) went fine but any editing of values on that
objectClass would make slapd hang until brutally killed (it goes into error 8
where apparently the operation is waiting to be executed, but even after
several hours it would still be frozen).
The only way I managed to solve the situation was to take e previous dump,
change the value to something within the value's range, and restore it. BTW I
couldn't manage to run slapcat (neither with the -c flag) to have a full dump.
There are three issues in my opinion:
1. Shouldn't slapadd make some checks on data type values and eventually either
give an error or change an exceeding value to the minimum/maximum value of the
range?
2. Shouldn't slapd manage the exceeding value instead of freezing (in a way
coherent to point 1)?
3. Shouldn't slapcat be forced to skip over the problem of an out of range
value at least if run with the "-c" flag?
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9253
Bug ID: 9253
Summary: Access not retained when last examined olcAccess has a
"break" control
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: kop(a)karlpinc.com
Target Milestone: ---
When the last examined olcAccess control is "break" then it does not
matter what access rights have been granted by the rules, access is
denied.
Reproduce by having a database with a single access rule:
to attrs=userPassword by anonymous =x
Note that ldapwhoami successfully does a simple bind.
Then, modify so that the single existing access rule is:
to attrs=userPassword by anonymous =x break
Users can no longer do a simple bind.
You will see similar behavior with SASL binds, or any number
of access rules. Access is denied when the the last examined access
control is "break".
The problem is at line 309 of: servers/slapd/acl.c
(In master/HEAD, and probably all versions)
--
You are receiving this mail because:
You are on the CC list for the bug.