(ITS#9535) -ldb incorrectly added to SLAPD_LIBS with modular build
by quanah＠openldap.org
Full_Name: Quanah Gibson-Mount
Version: 2.4.47
OS: N/A
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.148.239)
configure.in has the following section handling the BDB library:
if test $ol_enable_bdb/$ol_enable_hdb != no/no; then
OL_BERKELEY_DB
if test $ol_cv_berkeley_db = no ; then
AC_MSG_ERROR(BDB/HDB: BerkeleyDB not available)
fi
AC_DEFINE(HAVE_BERKELEY_DB,1,
[define this if Berkeley DB is available])
dnl $ol_cv_lib_db should be yes or -ldb
dnl (it could be no, but that would be an error
if test $ol_cv_lib_db != yes ; then
BDB_LIBS="$BDB_LIBS $ol_cv_lib_db"
fi
SLAPD_LIBS="$SLAPD_LIBS \$(BDB_LIBS)"
ol_link_bdb=yes
fi
This has the effect of always attempting to link the slapd binary with the BDB
library. This block should instead be:
if test $ol_enable_bdb/$ol_enable_hdb != no/no; then
OL_BERKELEY_DB
if test $ol_cv_berkeley_db = no ; then
AC_MSG_ERROR(BDB/HDB: BerkeleyDB not available)
fi
AC_DEFINE(HAVE_BERKELEY_DB,1,
[define this if Berkeley DB is available])
dnl $ol_cv_lib_db should be yes or -ldb
dnl (it could be no, but that would be an error
if test $ol_cv_lib_db != yes ; then
BDB_LIBS="$BDB_LIBS $ol_cv_lib_db"
fi
dnl link BDB library to slapd with static backend
if test $ol_enable_bdb/$ol_enable_hdb != mod/mod; then
SLAPD_LIBS="$SLAPD_LIBS \$(BDB_LIBS)"
fi
ol_link_bdb=yes
fi
4 years, 2 months
(ITS#9534) openldap bug
by 349020753＠qq.com
Full_Name: perfy
Version: 2.4.44
OS: centos 7 64bit
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (1.202.220.123)
(1)I have enabled the dynlist moudle as follows:
[root@test01 cn=schema]# pwd
/etc/openldap/slapd.d/cn=config/cn=schema
[root@test01 cn=schema]# ll
total 84
-rw-r-----. 1 ldap ldap 1283 Dec 18 17:50 cn={0}corba.ldif
-rw-r-----. 1 ldap ldap 3625 Dec 18 17:50 cn={10}ppolicy.ldif
-rw-r-----. 1 ldap ldap 1523 Dec 18 17:50 cn={11}collective.ldif
-rw------- 1 ldap ldap 2727 Dec 18 17:37 cn={12}sudo.ldif
-rw------- 1 ldap ldap 1013 Dec 19 01:16 cn={13}ldapns.ldif
-rw-r-----. 1 ldap ldap 15546 Dec 18 17:50 cn={1}core.ldif
-rw-r-----. 1 ldap ldap 11363 Dec 18 17:50 cn={2}cosine.ldif
-rw-r-----. 1 ldap ldap 4489 Dec 18 17:50 cn={3}duaconf.ldif
-rw-r-----. 1 ldap ldap 1693 Dec 18 17:50 cn={4}dyngroup.ldif
-rw-r-----. 1 ldap ldap 2857 Dec 18 17:50 cn={5}inetorgperson.ldif
-rw-r-----. 1 ldap ldap 2589 Dec 18 17:50 cn={6}java.ldif
-rw-r-----. 1 ldap ldap 1519 Dec 18 17:50 cn={7}misc.ldif
-rw-r-----. 1 ldap ldap 6495 Dec 18 17:50 cn={8}nis.ldif
-rw-r-----. 1 ldap ldap 1323 Dec 18 17:50 cn={9}openldap.ldif
[root@test01 cn=config]# cat cn=module{0}.ldif
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 e9c5e751
dn: cn=module{0}
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib64/openldap
olcModuleLoad: {0}dynlist.la
olcModuleLoad: {1}ppolicy.la
structuralObjectClass: olcModuleList
entryUUID: 78bc6ce2-972e-1038-9a09-0b17f1a1373f
creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
createTimestamp: 20181218163402Z
entryCSN: 20181220075834.004947Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20181220075834Z
[root@test01 cn=config]# cat
olcDatabase\=\{2\}bdb/olcOverlay\=\{0\}dynlist.ldif
dn: olcOverlay={0}dynlist
objectClass: olcOverlayConfig
objectClass: olcDynamicList
olcOverlay: {0}dynlist
olcDlAttrSet: {0}inetOrgPerson labeledURI
olcDlAttrSet: {1}groupOfURLs memberURL member
structuralObjectClass: olcDynamicList
entryUUID: 0ff96984-972f-1038-9a0b-0b17f1a1373f
creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
createTimestamp: 20181218163815Z
entryCSN: 20181221095210.059382Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
[root@test01 cn=schema]# ldapsearch -LLL -x -D "cn=Manager,dc=kb,dc=com" -b
"dc=kb,dc=com" -w1234 "ou=dbhost"
dn: ou=dbhost,ou=servers,dc=kb,dc=com
objectClass: organizationalUnit
objectClass: hostObject
ou: dbhost
host: test04
[root@test01 cn=config]# ldapsearch -LLL -x -D "cn=Manager,dc=kb,dc=com" -b
"dc=kb,dc=com" -w1234 "uid=zhangsan"
dn: uid=zhangsan,ou=People,dc=kb,dc=com
objectClass: posixAccount
objectClass: inetOrgPerson
objectClass: shadowAccount
objectClass: hostObject
cn: zhangsan
sn: zhangsan
uid: zhangsan
uidNumber: 10007
homeDirectory: /home/zhangsan
loginShell: /bin/bash
gecos: DBA Manager
shadowLastChange: 17889
gidNumber: 10011
labeledURI: ldap:///ou=dbhost,ou=servers,dc=kb,dc=com?host
userPassword:: e01ENX00UXJjT1VtNldhdStWdUJYOGcrSVBnPT0=
host: test04
(2)When I search the hostname "test04" by the filter
"(&(uid=zhangsan)(host=test04))", no any result is return. The corrent
result
should return the DN "dn: uid=zhangsan,ou=People,dc=kb,dc=com". But the result
is
empty. Is it a bug ?
[root@test01 cn=config]# ldapsearch -LLL -x -D "cn=Manager,dc=kb,dc=com" -b
"dc=kb,dc=com" -w1234 "(&(uid=zhangsan)(host=test04))"
4 years, 3 months
(ITS#9533) openldap bug
by 349020753＠qq.com
Full_Name: perfy
Version: 2.4.44
OS: centos 7 64bit
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (1.202.220.123)
(1)I have enabled the dynlist moudle as follows:
[root@test01 cn=schema]# pwd
/etc/openldap/slapd.d/cn=config/cn=schema
[root@test01 cn=schema]# ll
total 84
-rw-r-----. 1 ldap ldap 1283 Dec 18 17:50 cn={0}corba.ldif
-rw-r-----. 1 ldap ldap 3625 Dec 18 17:50 cn={10}ppolicy.ldif
-rw-r-----. 1 ldap ldap 1523 Dec 18 17:50 cn={11}collective.ldif
-rw------- 1 ldap ldap 2727 Dec 18 17:37 cn={12}sudo.ldif
-rw------- 1 ldap ldap 1013 Dec 19 01:16 cn={13}ldapns.ldif
-rw-r-----. 1 ldap ldap 15546 Dec 18 17:50 cn={1}core.ldif
-rw-r-----. 1 ldap ldap 11363 Dec 18 17:50 cn={2}cosine.ldif
-rw-r-----. 1 ldap ldap 4489 Dec 18 17:50 cn={3}duaconf.ldif
-rw-r-----. 1 ldap ldap 1693 Dec 18 17:50 cn={4}dyngroup.ldif
-rw-r-----. 1 ldap ldap 2857 Dec 18 17:50 cn={5}inetorgperson.ldif
-rw-r-----. 1 ldap ldap 2589 Dec 18 17:50 cn={6}java.ldif
-rw-r-----. 1 ldap ldap 1519 Dec 18 17:50 cn={7}misc.ldif
-rw-r-----. 1 ldap ldap 6495 Dec 18 17:50 cn={8}nis.ldif
-rw-r-----. 1 ldap ldap 1323 Dec 18 17:50 cn={9}openldap.ldif
[root@test01 cn=config]# cat cn=module{0}.ldif
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 e9c5e751
dn: cn=module{0}
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib64/openldap
olcModuleLoad: {0}dynlist.la
olcModuleLoad: {1}ppolicy.la
structuralObjectClass: olcModuleList
entryUUID: 78bc6ce2-972e-1038-9a09-0b17f1a1373f
creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
createTimestamp: 20181218163402Z
entryCSN: 20181220075834.004947Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20181220075834Z
[root@test01 cn=config]# cat olcDatabase\=\{2\}bdb/olcOverlay\=\{0\}dynlist.ldif
dn: olcOverlay={0}dynlist
objectClass: olcOverlayConfig
objectClass: olcDynamicList
olcOverlay: {0}dynlist
olcDlAttrSet: {0}inetOrgPerson labeledURI
olcDlAttrSet: {1}groupOfURLs memberURL member
structuralObjectClass: olcDynamicList
entryUUID: 0ff96984-972f-1038-9a0b-0b17f1a1373f
creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
createTimestamp: 20181218163815Z
entryCSN: 20181221095210.059382Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
[root@test01 cn=schema]# ldapsearch -LLL -x -D "cn=Manager,dc=kb,dc=com" -b
"dc=kb,dc=com" -w1234 "ou=dbhost"
dn: ou=dbhost,ou=servers,dc=kb,dc=com
objectClass: organizationalUnit
objectClass: hostObject
ou: dbhost
host: test04
[root@test01 cn=config]# ldapsearch -LLL -x -D "cn=Manager,dc=kb,dc=com" -b
"dc=kb,dc=com" -w1234 "uid=zhangsan"
dn: uid=zhangsan,ou=People,dc=kb,dc=com
objectClass: posixAccount
objectClass: inetOrgPerson
objectClass: shadowAccount
objectClass: hostObject
cn: zhangsan
sn: zhangsan
uid: zhangsan
uidNumber: 10007
homeDirectory: /home/zhangsan
loginShell: /bin/bash
gecos: DBA Manager
shadowLastChange: 17889
gidNumber: 10011
labeledURI: ldap:///ou=dbhost,ou=servers,dc=kb,dc=com?host
userPassword:: e01ENX00UXJjT1VtNldhdStWdUJYOGcrSVBnPT0=
host: test04
(2)When I search the hostname "test04" by the filter
"(&(uid=zhangsan)(host=test04))", no any result is return. The corrent result
should return the DN "dn: uid=zhangsan,ou=People,dc=kb,dc=com". But no result is
empty. Is it a bug ?
[root@test01 cn=config]# ldapsearch -LLL -x -D "cn=Manager,dc=kb,dc=com" -b
"dc=kb,dc=com" -w1234 "(&(uid=zhangsan)(host=test04))"
4 years, 3 months
(ITS#9532) Ambiguos documentation for default LogLevel
by dpa-openldap＠aegee.org
Full_Name: Дилян Палаузов
Version: 2.4.47
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (46.5.16.188)
If LogLevel is not specified, does it default to 0 or to 256 (stats)?
The documentation says default is stats in:
man/man5/slapd.conf.5:691:The loglevel defaults to \fBstats\fP.
guide/admin/tuning.sdf:121:The default of {{loglevel stats}} (256) is really the
best bet. There's a corollary to
guide/admin/tuning.sdf-141-The default syslog level is stats (256) which logs
the basic parameters of each
And the default for loglevel 0 is defined at:
man/man5/slapd-config.5:630:In fact, if no olcLogLevel (or a 0 level) is
defined, no logging occurs,
man/man5/slapd-config.5-631-so at least the
man/man5/slapd-config.5-632-.B none
man/man5/slapd-config.5-633-level is required to have high priority messages
logged.
Here mixed feelings:
guide/admin/slapdconfig.sdf-193-\Default:
guide/admin/slapdconfig.sdf-194-
guide/admin/slapdconfig.sdf:195:E: loglevel stats
guide/admin/slapdconfig.sdf-196-
guide/admin/slapdconfig.sdf:197:Basic stats logging is configured by default.
However, if no loglevel is
guide/admin/slapdconfig.sdf-198-defined, no logging occurs (equivalent to a 0
level).
guide/admin/slapdconfig.sdf-199-
guide/admin/slapdconf2.sdf-237-
guide/admin/slapdconf2.sdf-238-\Default:
guide/admin/slapdconf2.sdf-239-
guide/admin/slapdconf2.sdf:240:E: olcLogLevel stats
guide/admin/slapdconf2.sdf-241-
guide/admin/slapdconf2.sdf:242:Basic stats logging is configured by default.
However, if no olcLogLevel is
guide/admin/slapdconf2.sdf-243-defined, no logging occurs (equivalent to a 0
level).
guide/admin/slapdconf2.sdf-244-
I suggest describing all default values at a single place.
4 years, 3 months
Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by hyc＠symas.com
Thorsten Glaser wrote:
> Howard Chu dixit:
>
>> Thanks to the wonderful geniuses at Microsoft, not all the world
>> uses LP64. IL32 is a thing. And this code works on those platforms.
>
> These changes do not break LLP64 (this is the correct name
> for the 64-bit Windows model).
Yes, they do, but you're clearly too stupid to understand that, despite having
had it explained to you multiple times. Your patch tries to store the value
of a long long into a buffer only large enough for a long. That is fucking stupid.
Bye.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
4 years, 3 months
Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by tg＠mirbsd.de
Howard Chu dixit:
>Thanks to the wonderful geniuses at Microsoft, not all the world
>uses LP64. IL32 is a thing. And this code works on those platforms.
These changes do not break LLP64 (this is the correct name
for the 64-bit Windows model).
>If you're going to submit a patch, submit a correct one. It's that
The buffer size is a separate issue from this. Feel free
to fix it, now that you found it.
The patch I submit fixed your software on systems where
time_t doesn=E2=80=99t fit into a long, all of them, and that
*will* include 64-bit Windows at least in 2038, except
some architectures need these fixes right now. They don=E2=80=99t
break anything else before 2038, and afterwards, nothing
new is broken worsely either.
>simple. If you refuse to do that, then go away.
You know what, I=E2=80=99ll just do that and leave you to fix
your software on your own, clearly you are oh so utterly
competent in doing that.
//mirabilos
--=20
=E2=80=9CIt is inappropriate to require that a time represented as
seconds since the Epoch precisely represent the number of
seconds between the referenced time and the Epoch.=E2=80=9D
=09-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2
4 years, 3 months
Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by hyc＠symas.com
Thorsten Glaser wrote:
> Howard Chu dixit:
>=20
>> This patch of yours *introduces a bug*. If you wanted to actually *fix=
*
>> something you should have made sure the malloc'd buffer - which only h=
appens
>> 2 lines above the lines you change - was large enough to store a long =
long.
>=20
> That=E2=80=99s not a new bug, then.
> That=E2=80=99s a completely separate Y2038 issue of *yours* that
> will happen on all platforms, and has nothing to do with
> long vs. long long, since a long on an LP64 platform *is*
> already as wide as a long long.
Thanks to the wonderful geniuses at Microsoft, not all the world
uses LP64. IL32 is a thing. And this code works on those platforms.
Far more machines than have ever or ever will run X32. If you want
patches for your obscure system adopted, you have to make sure not
to break anything else.
> In addition to that, use of snprintf will prevent this
> from being worse than a mere truncation.
If you're going to submit a patch, submit a correct one. It's that simple=
.
If you refuse to do that, then go away.
--=20
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
4 years, 3 months
Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by tg＠mirbsd.de
Howard Chu dixit:
>This patch of yours *introduces a bug*. If you wanted to actually *fix*
>something you should have made sure the malloc'd buffer - which only happe=
ns
>2 lines above the lines you change - was large enough to store a long long=
=2E
That=E2=80=99s not a new bug, then.
That=E2=80=99s a completely separate Y2038 issue of *yours* that
will happen on all platforms, and has nothing to do with
long vs. long long, since a long on an LP64 platform *is*
already as wide as a long long.
In addition to that, use of snprintf will prevent this
from being worse than a mere truncation.
bye,
//mirabilos
--=20
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.=09=09-- Andreas Bogk =C3=BCber boehm-gc in d.a.s.r
4 years, 3 months
Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by hyc＠symas.com
Thorsten Glaser wrote:
> I know my way *very* well around the time_t issue because
> I=E2=80=99ve been having them on MirBSD/i386 years before x32 even
> existed, and am experienced in how to fix them.
>From here it only looks like you're experienced in how to break things.
This patch of yours *introduces a bug*. If you wanted to actually *fix*
something you should have made sure the malloc'd buffer - which only happ=
ens
2 lines above the lines you change - was large enough to store a long lon=
g.
That's just plain sloppy. It's as careless as submitting a patch to
fix a no-op, and just wasting my time.
+--- a/contrib/slapd-modules/smbk5pwd/smbk5pwd.c
++++ b/contrib/slapd-modules/smbk5pwd/smbk5pwd.c
+@@ -605,7 +605,7 @@ static int smbk5pwd_exop_passwd(
+ keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) );
+ keys[0].bv_len =3D snprintf(keys[0].bv_val,
+ LDAP_PVT_INTTYPE_CHARS(long),
+- "%ld", slap_get_time());
++ "%lld", (long long)slap_get_time());
+ BER_BVZERO( &keys[1] );
+
+ ml->sml_desc =3D ad_sambaPwdLastSet;
+@@ -627,7 +627,7 @@ static int smbk5pwd_exop_passwd(
+ keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) );
+ keys[0].bv_len =3D snprintf(keys[0].bv_val,
+ LDAP_PVT_INTTYPE_CHARS(long),
+- "%ld", slap_get_time() + pi->smb_must_change);
++ "%lld", (long long)slap_get_time() + (long long)pi->s=
mb_must_change);
+ BER_BVZERO( &keys[1] );
+
+ ml->sml_desc =3D ad_sambaPwdMustChange;
+@@ -650,7 +650,7 @@ static int smbk5pwd_exop_passwd(
+ keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) );
+ keys[0].bv_len =3D snprintf(keys[0].bv_val,
+ LDAP_PVT_INTTYPE_CHARS(long),
+- "%ld", slap_get_time() + pi->smb_can_change);
++ "%lld", (long long)slap_get_time() + (long long)pi->s=
mb_can_change);
+ BER_BVZERO( &keys[1] );
+
+ ml->sml_desc =3D ad_sambaPwdCanChange;
--=20
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
4 years, 3 months
Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by tg＠debian.org
Howard Chu dixit:
>You might have correctly identified a Y2038 issue. You certainly have not
>written a correct fix for it.
Please drop this condescending attitude.
I may or may not have discovered a Y2038 issue, but I do know
for sure I=E2=80=99ve correctly fixed a problem on all architectures
in which a time_t does not fit into a long.
Consider this:
#ifdef TEST1
typedef long foo_t;
#else
typedef long long foo_t;
#endif
foo_t bla =3D 1L;
printf("%ld, %ld\n", bla, 2L);
This is _supposed_ to display =E2=80=9C1, 2=E2=80=9D but will display =E2=
=80=9C1, 0=E2=80=9D
on little endian platforms (big endian being worse off).
I know my way *very* well around the time_t issue because
I=E2=80=99ve been having them on MirBSD/i386 years before x32 even
existed, and am experienced in how to fix them.
bye,
//mirabilos
--=20
16:47=E2=8E=9C=C2=ABmika:#grml=C2=BB .oO(mira ist einfach gut....) 23:=
22=E2=8E=9C=C2=ABmikap:#grml=C2=BB
mirabilos: und dein bootloader ist geil :) 23:29=E2=8E=9C=C2=ABmikap:#gr=
ml=C2=BB und ich
finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann
gleich mal auf usb-stick installieren=09-- Michael Prokop =C3=BCber MirOS b=
sd4grml
4 years, 3 months