Re: (ITS#8060) mdb_from_db (bdb import)

2019-05-17 Thread quanah
--On Tuesday, February 17, 2015 5:07 PM + gra...@gmail.com wrote:

> Full_Name: Jonathan Graehl
> Version: n/a
> OS: n/a
> URL:
> ftp://ftp.openldap.org/incoming/0001-mdb_from_db-new-options-bugfix.patch
> Submission from: (NULL) (104.174.227.200)
>
>
> (see 0001-mdb_from_db-new-options-bugfix.patch)
>
> mdb_from_db utility for direct import from Berkeley DB to mdb
>
> Apparently this can only be distributed in binary form using older
> berkeley db versions, but building the utility from source for bulk
> import should be fine.

Hello,

This submission is missing a required IPR, as noted at 


An IPR is necessary to consider this work.

Regards,
Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:







Re: (ITS#8986) [PATCH] Fix union semun undefined from FreeBSD 12 onward

2019-05-17 Thread quanah
--On Friday, May 17, 2019 5:30 PM + khng...@gmail.com wrote:

> Bump.

I've added this to the review list.

--Quanah



--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:







Re: (ITS#8986) [PATCH] Fix union semun undefined from FreeBSD 12 onward

2019-05-17 Thread khng300
Bump.

Ka Ho





Re: (ITS#9024) [PATCH] Fix union semun undefined from FreeBSD 12 onward

2019-05-17 Thread quanah
--On Friday, May 17, 2019 5:02 PM + khng...@gmail.com wrote:

> Full_Name: Ka Ho Ng
> Version: mdb.master
> OS: FreeBSD 12.0-RELEASE
> URL: ftp://ftp.openldap.org/incoming/Ka-Ho-Ng-190517.patch
> Submission from: (NULL) (2001:470:fa95:1300::3)
>
> By the way, please help close ITS#8986 as this version is a resend of the
> patch.

The correct path is to follow up to your original ITS, not submit a new 
one.  This ITS will be closed.

--Quanah



--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:







(ITS#9024) [PATCH] Fix union semun undefined from FreeBSD 12 onward

2019-05-17 Thread khng300
Full_Name: Ka Ho Ng
Version: mdb.master
OS: FreeBSD 12.0-RELEASE
URL: ftp://ftp.openldap.org/incoming/Ka-Ho-Ng-190517.patch
Submission from: (NULL) (2001:470:fa95:1300::3)


Starting from __FreeBSD_version 1200059 union semun definition was removed
from userspace headers in order to comply with POSIX. In order to resurrect
the defintion we need to define _WANT_SEMUN before including sys/sem.h for
__FreeBSD_version >= 1200059.

I tried to touch as small amount of code as possible here to avoid interfering
with other platforms I do not use.

By the way, please help close ITS#8986 as this version is a resend of the patch.



RE: (ITS#9023) crash using ppolicy chaining from slave to master

2019-05-17 Thread quanah
--On Friday, May 17, 2019 4:09 PM + "AYANIDES, JEAN-PHILIPPE" 
 wrote:

>
>
> Hello Quanah,
>
> I am not very familiar with gdb. Can you help me doing that?


Start slapd on the server that's crashing
Get the process ID of slapd

gdb /path/to/slapd PID

For example, if slapd is located in /usr/sbin, and the process ID is 1234:

gdb /usr/sbin/slapd 1234

At the (gdb) prompt, enter the command "cont" to continue execution

Run your operation that causes slapd to crash.  This should drop you back 
to the (gdb) prompt.

Then run the command:

thr apply all bt full

This will provide the full backtrace.

--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:







RE: (ITS#9023) crash using ppolicy chaining from slave to master

2019-05-17 Thread jpayanides
--_000_AM0PR0202MB355359CC89C5DBD53D8FAB09BA0B0AM0PR0202MB3553_
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

Hello Quanah,

I am not very familiar with gdb. Can you help me doing that?


De : Quanah Gibson-Mount 
Envoy=E9 : vendredi 17 mai 2019 16:58:59
=C0 : AYANIDES, JEAN-PHILIPPE; openldap-its@OpenLDAP.org
Objet : Re: (ITS#9023) crash using ppolicy chaining from slave to master

--On Friday, May 17, 2019 3:50 PM + jpayani...@prosodie.com wrote:

> Full_Name: JPh Ayanides
> Version: 2.4.47
> OS: Linux Debian
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (195.46.216.78)
>
>
> Hello, I cannot succeed in making the following configuration to work.
> Instead of that, openldap crashes.
>
> I have 2 openldap servers in master-slave: the slave is installed on a
> machine named rada, and a master is installed on another machine named
> simby. The ppolicy is activated on rada and simby, and I use chain and
> updateref in order to sync failures in ppolicy coming from rada back to
> simby. When I test that feature, with trying a bind with a wrong
> password,  openldap on the slave crashes. I failed in understanding why,
> even with gdb.

Ensure you have debugging symbols installed, and provide a full backtrace
of all threads from gdb.

--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:


This message contains information that may be privileged or confidential an=
d is the property of the Capgemini Group. It is intended only for the perso=
n to whom it is addressed. If you are not the intended recipient, you are n=
ot authorized to read, print, retain, copy, disseminate, distribute, or use=
 this message or any part thereof. If you receive this message in error, pl=
ease notify the sender immediately and delete all copies of this message.

--_000_AM0PR0202MB355359CC89C5DBD53D8FAB09BA0B0AM0PR0202MB3553_
Content-Type: text/html; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable








Hello Quanah,
I am not very familiar with gdb. =
Can you help me doing that?





De : Quanah Gibson-Mount =
t;qua...@symas.com
Envoy=E9 : vendredi 17 mai 2019 16:58:59
=C0 : AYANIDES, JEAN-PHILIPPE; openldap-its@OpenLDAP.org
Objet : Re: (ITS#9023) crash using ppolicy chaining from slave to ma=
ster



--On Friday, May 17, 2019 3:50 PM  jpayan=
i...@prosodie.com wrote:

 Full_Name: JPh Ayanides
 Version: 2.4.47
 OS: Linux Debian
 URL: ftp://ftp.openldap.org/incoming/;>ftp://ftp.openldap.o=
rg/incoming/
 Submission from: (NULL) (195.46.216.78)


 Hello, I cannot succeed in making the following configuration to work.=

 Instead of that, openldap crashes.

 I have 2 openldap servers in master-slave: the slave is installed on a=

 machine named rada, and a master is installed on another machine named=

 simby. The ppolicy is activated on rada and simby, and I use chain and=

 updateref in order to sync failures in ppolicy coming from rada back t=
o
 simby. When I test that feature, with trying a bind with a wrong
 password, openldap on the slave crashes. I failed in understandi=
ng why,
 even with gdb.

Ensure you have debugging symbols installed, and provide a full backtrace <=
br>
of all threads from gdb.

--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
http://www.symas.com;>http://www.symas.com



This message contains in=
formation that may be privileged or confidential and is the property of the=
 Capgemini Group. It is intended only for the person to whom it is addresse=
d. If you are not the intended recipient, you are not authorized to read, p=
rint, retain, copy, disseminate, distribute, or use this message or any par=
t thereof. If you receive this message in error, please notify the sender i=
mmediately and delete all copies of this message.


--_000_AM0PR0202MB355359CC89C5DBD53D8FAB09BA0B0AM0PR0202MB3553_--






Re: (ITS#9023) crash using ppolicy chaining from slave to master

2019-05-17 Thread quanah
--On Friday, May 17, 2019 3:50 PM + jpayani...@prosodie.com wrote:

> Full_Name: JPh Ayanides
> Version: 2.4.47
> OS: Linux Debian
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (195.46.216.78)
>
>
> Hello, I cannot succeed in making the following configuration to work.
> Instead of that, openldap crashes.
>
> I have 2 openldap servers in master-slave: the slave is installed on a
> machine named rada, and a master is installed on another machine named
> simby. The ppolicy is activated on rada and simby, and I use chain and
> updateref in order to sync failures in ppolicy coming from rada back to
> simby. When I test that feature, with trying a bind with a wrong
> password,  openldap on the slave crashes. I failed in understanding why,
> even with gdb.

Ensure you have debugging symbols installed, and provide a full backtrace 
of all threads from gdb.

--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:







(ITS#9023) crash using ppolicy chaining from slave to master

2019-05-17 Thread jpayanides
Full_Name: JPh Ayanides
Version: 2.4.47
OS: Linux Debian
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (195.46.216.78)


Hello, I cannot succeed in making the following configuration to work. Instead
of that, openldap crashes.

I have 2 openldap servers in master-slave: the slave is installed on a machine
named rada, and a master is installed on another machine named simby. The
ppolicy is activated on rada and simby, and I use chain and updateref in order
to sync failures in ppolicy coming from rada back to simby. When I test that
feature, with trying a bind with a wrong password,  openldap on the slave
crashes. I failed in understanding why, even with gdb.

Here is the configuration of rada:
---

allow bind_v2
sizelimit size.hard=1
sizelimit size.soft=500
# Schema and objectClass definitions
include /appli/openldap/etc/openldap/schema/core.schema
include /appli/openldap/etc/openldap/schema/cosine.schema
include /appli/openldap/etc/openldap/schema/nis.schema
include /appli/openldap/etc/openldap/schema/inetorgperson.schema
include /appli/openldap/etc/openldap/schema/ppolicy.schema
pidfile /appli/openldap-preprod/var/run/slapd.pid

argsfile   /appli/openldap-preprod/var/run/slapd.args
loglevel-1

conn_max_pending 250
idletimeout 600

timelimit time.soft=60
timelimit time.hard=60

modulepath  /appli/openldap/libexec/openldap
moduleload  back_bdb
moduleload  ppolicy
moduleload  back_ldap
moduleload  pw-sha2

password-hash  {SSHA512}

TLSVerifyClient never
TLSCertificateKeyFile /appli/openldap-preprod/etc/private/auth.gdr.key
TLSCertificateFile/appli/openldap-preprod/etc/certs/auth.gdr.crt
TLSCACertificatePath /appli/openldap-preprod/etc/ca/

overlay   chain
chain-uri ldaps://simby.example:637
chain-idassert-bind   bindmethod="simple"
  binddn="uid=mirrormode,dc=example"
  credentials="secret"
  mode="self"
  tls_reqcert=allow
chain-tls none
chain-return-errorTRUE

databasebdb

suffix  "dc=example"
rootdn  "cn=admin,dc=example"
rootpw  {SSHA}XX

dbconfig set_cachesize 0 12800 0
dbconfig set_lk_max_objects 1500
dbconfig set_lk_max_locks 1500
dbconfig set_lk_max_lockers 1500

directory   "/appli/openldap-preprod/var/openldap-data"


index objectClass,entryCSN,entryUUIDeq,pres
index ou,cn,mail,surname,givenname  eq,pres,sub
index uidNumber,gidNumber,loginShelleq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntryeq,pres,sub

overlay ppolicy
ppolicy_default "cn=pwdDefault,ou=policies,dc=example"
ppolicy_hash_cleartext
ppolicy_use_lockout
ppolicy_forward_updates

lastmod on

syncrepl rid=002
provider=ldap://simby.example:390
binddn="uid=mirrormode,dc=example"
credentials=secret
bindmethod=simple
searchbase="dc=example"
schemachecking=off
type=refreshAndPersist
retry="60 +"
tls_cacert="/appli/openldap-preprod/etc/ca/CADSI.pem"
tls_reqcert=allow
starttls=yes

updateref ldaps://simby.example:637

access to attrs=userPassword
by dn="cn=admin,dc=example" write
by dn="cn=acadmin,dc=example" write
by dn="uid=mirrormode,dc=example" read
by dn="uid=rsasecureid,dc=example" auth
by anonymous auth
by dn="uid=test,ou=People,dc=example" none
by * none

access to attrs=shadowLastChange
by dn="cn=admin,dc=example" write
by dn="uid=mirrormode,dc=example" read
by dn="uid=test,ou=People,dc=example" none
by * read

access to dn="uid=test,ou=People,dc=example"
by dn="cn=admin,dc=example" write
by * read


database monitor
access to * by * read


-
and here is the configuration file on the master:


allow bind_v2

sizelimit size.hard=1
sizelimit size.soft=500

include /appli/openldap/etc/openldap/schema/core.schema
include /appli/openldap/etc/openldap/schema/cosine.schema
include /appli/openldap/etc/openldap/schema/nis.schema
include /appli/openldap/etc/openldap/schema/inetorgperson.schema
include /appli/openldap/etc/openldap/schema/ppolicy.schema

pidfile /appli/openldap-preprod/var/run/slapd.pid
argsfile   /appli/openldap-preprod/var/run/slapd.args
loglevel -1

modulepath  /appli/openldap/libexec/openldap
moduleload  back_bdb
moduleload  syncprov
moduleload  ppolicy
moduleload  pw-sha2

password-hash  {SSHA512}

TLSCertificateKeyFile /appli/openldap-preprod/etc/private/simby.example.key
TLSCertificateFile/appli/openldap-preprod/etc/certs/simby.example.pem
TLSCACertificatePath  /appli/openldap-preprod/etc/ca

TLSverifyClient never