Re: OpenLDAP under 6.8 - no intermediate certs in chain

2020-11-16 Thread Paul B. Henson

On 11/16/2020 6:52 AM, Stuart Henderson wrote:


...actually I have now added a workaround to the databases/openldap port
in 6.8-stable to disable TLS 1.3, so either rebuild or wait for -stable
packages and it should fix things.


Cool, I was actually already building from source in order to enable 
modules. I updated my ports tree and rebuilt, looks good now, thanks 
much for the quick fix.


It still does behave a little bit differently; under 6.7 it was 
including the root CA in the chain sent by the server, under 6.8 it is 
only including the intermediate, not the root. Which I actually prefer, 
as sending the root is a waste of time, the client needs to have that 
itself anyway in order to validate the chain in the first place.




Re: OpenLDAP under 6.8 - no intermediate certs in chain

2020-11-16 Thread Paul B. Henson

On 11/16/2020 2:30 AM, Stuart Henderson wrote:


Yes OpenLDAP is broken with TLS 1.3 server-side unless you have that
commit (or build LibreSSL with TLS 1.3 server support disabled). As far
as I can tell there's no method to disable TLS 1.3 via config.


Hmm, yah, you can disable old versions, but I don't think there is any 
way to disable newer ones.




Re: OpenLDAP under 6.8 - no intermediate certs in chain

2020-11-16 Thread Paul B. Henson

On 11/15/2020 10:18 PM, Brad Smith wrote:

I remember seeing this commit recently. Not sure if this is your problem 
or not.


https://marc.info/?l=openbsd-cvs=160511882917510=2


That definitely looks like it, thanks for the pointer.



Re: OpenLDAP under 6.8 - no intermediate certs in chain

2020-11-16 Thread Stuart Henderson
On 2020-11-16, Stuart Henderson  wrote:
> Yes OpenLDAP is broken with TLS 1.3 server-side unless you have that
> commit (or build LibreSSL with TLS 1.3 server support disabled). As far
> as I can tell there's no method to disable TLS 1.3 via config.

...actually I have now added a workaround to the databases/openldap port
in 6.8-stable to disable TLS 1.3, so either rebuild or wait for -stable
packages and it should fix things. 




Re: OpenLDAP under 6.8 - no intermediate certs in chain

2020-11-16 Thread Stuart Henderson
On 2020-11-16, Brad Smith  wrote:
> On 11/16/2020 12:08 AM, Paul B. Henson wrote:
>> I just updated one of my servers running 6.7 to 6.8, and am having a
>> problem with openldap. I have the intermediate cert and root CA in a
>> file referenced by the openldap config:
>>
>> TLSCACertificateFile/etc/openldap/cabundle.crt
>>
>> Under 6.7 with the openldap port from that version, this results in the
>> chain being served:
>>
>> Certificate chain
>>   0 s:CN = ldap-netsvc.pbhware.com
>> i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
>>   1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
>> i:O = Digital Signature Trust Co., CN = DST Root CA X3
>>   2 s:O = Digital Signature Trust Co., CN = DST Root CA X3
>> i:O = Digital Signature Trust Co., CN = DST Root CA X3
>>
>> However, under 6.8 with the newer openldap 2.4.53 port, only the server
>> cert itself is being served, not the intermediate or root:
>>
>> Certificate chain
>>   0 s:CN = ldap-netsvc.pbhware.com
>> i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
>>
>> This of course causes clients to fail to validate the server cert :(.
>>
>> I'm running openldap 2.4.53 on other operating systems and as far as I
>> know there's no change in behavior with it. So I'm guessing there's an
>> interoperability issue between openbsd libressl and openldap that's
>> causing this problem?
>>
>> Do I need to configure something differently? Any other suggestions?
>>
>> Thanks much...
>
>
> I remember seeing this commit recently. Not sure if this is your problem 
> or not.
>
> https://marc.info/?l=openbsd-cvs=160511882917510=2
>
>

Yes OpenLDAP is broken with TLS 1.3 server-side unless you have that
commit (or build LibreSSL with TLS 1.3 server support disabled). As far
as I can tell there's no method to disable TLS 1.3 via config.




Re: OpenLDAP under 6.8 - no intermediate certs in chain

2020-11-16 Thread Brad Smith

On 11/16/2020 12:08 AM, Paul B. Henson wrote:

I just updated one of my servers running 6.7 to 6.8, and am having a
problem with openldap. I have the intermediate cert and root CA in a
file referenced by the openldap config:

TLSCACertificateFile/etc/openldap/cabundle.crt

Under 6.7 with the openldap port from that version, this results in the
chain being served:

Certificate chain
  0 s:CN = ldap-netsvc.pbhware.com
i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
  1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
  2 s:O = Digital Signature Trust Co., CN = DST Root CA X3
i:O = Digital Signature Trust Co., CN = DST Root CA X3

However, under 6.8 with the newer openldap 2.4.53 port, only the server
cert itself is being served, not the intermediate or root:

Certificate chain
  0 s:CN = ldap-netsvc.pbhware.com
i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

This of course causes clients to fail to validate the server cert :(.

I'm running openldap 2.4.53 on other operating systems and as far as I
know there's no change in behavior with it. So I'm guessing there's an
interoperability issue between openbsd libressl and openldap that's
causing this problem?

Do I need to configure something differently? Any other suggestions?

Thanks much...



I remember seeing this commit recently. Not sure if this is your problem 
or not.


https://marc.info/?l=openbsd-cvs=160511882917510=2



Re: openldap port mdb support

2017-08-06 Thread Stuart Henderson
On 2017/08/05 21:39, Paul B. Henson wrote:
> I took a look at the patch in head; you should assign the failure code to rc
> before calling Debug, as it refers to rc...

Thanks, fixed.

On 2017/08/05 21:40, Paul B. Henson wrote:
> On Sat, Aug 05, 2017 at 12:35:24AM +, Stuart Henderson wrote:
> 
> > The ports@ list is a better venue for ports-related queries,
> > please see this: https://marc.info/?l=openbsd-ports=150157643516239=2
> 
> Ah, ok, thanks for the pointer.
> 
> > This is not preventing programs from running.
> 
> Hmm, I could've sworn I got that message and then slapd failed to start.
> Dunno, maybe I got confused. Once I'm done working with openldap mdb I'll
> start over from scratch and try again and see what happens.
> 
> Thanks for the info...

There have been other problems which occurred at the same time as
the icu warnings resumed (triggered by the switch to clang for base
and all but a very small number of ports) - if you run into it again,
if there's any debug information or backtrace available, that would
be interesting.




Re: openldap port mdb support

2017-08-03 Thread Paul B. Henson
On Mon, Jul 10, 2017 at 07:34:11AM +, Stuart Henderson wrote:

> Feel free to try it, I believe the required patch to force MDB_WRITEMAP
> is still in there..but I don't think there were any major changes upstream
> since the last attempt so I wouldn't hold out too much hope for it working
> straight off.

Hmm, as you said, trying to use mdb resulted in crashes. My initial debugging
led to the cause of this as a NULL mdb environment, and ironically the
root cause of that turned out to be the OpenBSD specific MDB_WRITEMAP
patch 8-/.

if ( !(flags & MDB_WRITEMAP) ) {
Debug( LDAP_DEBUG_ANY,
LDAP_XSTRING(mdb_db_open) ": database \"%s\" does not 
have writemap. "
"This is required on systems without unified buffer 
cache.\n",
be->be_suffix[0].bv_val, rc, 0 );
goto fail;
}

There are two problems with it; first, it accesses the local flags variable
before it is initialized to mdb->mi_dbenv_flags shortly thereafter, so the
value checked is random and the if block nondeterministically triggers, and
second, it doesn't assign a failure value to rc before it jumps to fail, so
the function returns successfully but with a closed be, and the code keeps
going but later segfaults because of the NULL mdb environment.

I updated the patch and moved the check to be after the flags initialization:

flags = mdb->mi_dbenv_flags;

and added an assignment to rc on failure:

rc = MDB_INCOMPATIBLE;

I then tweaked the mdb test suite to always enable MDB_WRITEMAP, and so far
it's been running for 20 minutes with no errors, crashes, or failures.

Right now it's compiled "-O0 -ggdb", if everything keeps looking good, I'll
recompile it normally and do more testing.



Re: openldap port mdb support

2017-07-10 Thread Stuart Henderson
On 2017-07-10, Paul B. Henson  wrote:
> mdb has been disabled in the openldap port since it looks like
> 2015/02/16, I was wondering if anyone has tried it since then to see if
> maybe the issues with it have been resolved? The other backends are
> deprecated upstream, it would be nice to get mdb working under openbsd.
>
> I'm going to try enabling it and running through the tests and see how
> things turn out but I was just curious if anyone else had worked with it
> in the past couple of years.
>
> Thanks...
>
>

Feel free to try it, I believe the required patch to force MDB_WRITEMAP
is still in there..but I don't think there were any major changes upstream
since the last attempt so I wouldn't hold out too much hope for it working
straight off.

(Without MDB_WRITEMAP, mdb assumes mmap and file access can be intermixed
without syncs, which isn't the case on OpenBSD).




Re: OpenLDAP and filesystem permission

2017-04-28 Thread Marcus MERIGHI
hello, 

ros...@ghweb.de (Markus Rosjat), 2017.04.27 (Thu) 12:59 (CEST):
> I basically want to know if its okay to set permission on a file or
> directory for a LDAP user even if there is no local user on this machine.
> 
> Hope someone understand what I mean, background is setting up a mailserver
> with usermanagement over LDAP. The naive way for me would be creating a
> local user with the same name like the one in the LDAP db. So I can set the
> permissions on the Maildirs for the local user.
> This leaves me with maintaining LDAP and Local user but if I could just use
> only the LDAP user this would be nice ( it works at least in my test env)
> but is this considerd secure or should I stick with the LDAP+local User
> approach?

have you seen ypldap(8), might help with your ldap<->local problem by
going yp(8).

Marcus

> regards
> 
> -- 
> Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de
> 
> G+H Webservice GbR Gorzolla, Herrmann
> K??nigsbr??cker Str. 70, 01099 Dresden
> 
> http://www.ghweb.de
> fon: +49 351 8107220   fax: +49 351 8107227
> 
> Bitte pr??fen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before
> you print it, think about your responsibility and commitment to the
> ENVIRONMENT
> 
> 
> !DSPAM:5901cf1b9705213319748!
> 



Re: openldap password fails to update

2014-03-09 Thread Stéphane Guedon
Le samedi 8 mars 2014, 16:14:53 Matthew Weigel a écrit :
 On 03/08/2014 03:11 PM, Stéphane Guedon wrote:
  when I use 127.0.0.1 in php scripts, I can use ldap.
  if the script is running with 'localhost' then, no ldap data...
 
  Any idea why ?
  I have checked host resolution...
  telnet localhost ldap gives the good behavior

 Is PHP running inside a chroot?  Does that chroot have an /etc/hosts
 with an entry for localhost?

you get it ! By copying the hosts system file in the nginx/php chroot,
I am now able to log in.

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]



Re: openldap password fails to update

2014-03-09 Thread Stéphane Guedon
Le samedi 8 mars 2014, 14:20:23 Matthew Weigel a écrit :
 On 03/08/2014 12:16 PM, Stéphane Guedon wrote:
  I am looking through logs and config since the beginning of the
  day... Actually, asking help on forums or mailing lists is always
  my last step in solving problems...

 We try to help.

 But... giving detailed descriptions of the problem, and showing
 relevant configs and logs the first time, goes a long way to
 helping people help you.

 Reading manuals helps too. Among others, ypldap(8), ypldap.conf(5),
 login.conf(5), login_ldap(8) from ports, and whatever manuals for
 OpenLDAP.
  But why can't I authenticate (using ssh or login) on the system ?
  Do I really have to go through ypldap ? Sounds not efficient to
  have an intermediate !

 There are two separate mechanisms: how user information is looked
 up, and how users are authenticated. You provide zero details on
 how ypldap or login_ldap are configured, so it's hard to guess
 whether you have some configuration wrong. I can say it works for
 me.

Because when beginning, I just tried to auth with ldap alone !
Now that I try with ldap + ypldap, it works.

Thanks Guys ! I solved it...


 The user lookup is configured (via +:: entries in /etc/passwd and
 /etc/group) to use YP routines. Thus the user is looked up in ypldap
 when they attempt to login, which is configured to identify the
 user's login class as ldap. The ldap login class is configured in
 login.conf to authenticate via login_ldap talking to the LDAP
 server, which is configured to have the appropriate users.

 This is what I meant by that's a lot more moving parts than just
 passwords in LDAP.

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]



Re: openldap password fails to update

2014-03-08 Thread Stuart Henderson
On 2014-03-07, Stéphane Guedon steph...@22decembre.eu wrote:
 But when I try to change this user password it fails :

 # ldappasswd  -x -v -D uid=test,ou=users,dc=22decembre,dc=eu \
 -w somesecret -s anothersec
 ldap_initialize( DEFAULT )
 Result: Other (e.g., implementation specific) error (80)
 Additional info: password hash failed

What is password-hash set to in slapd.conf on the server?

I think there is a bug with password-hash {CRYPT}, if you use this
you can try password-hash {SSHA} for now, or (probably better)
encrypt the password locally and change it using ldapmodify (or
ldapvi, etc).

 slappasswd never gives the same result !

That's expected for salted hashes.

 Does any of you can suggest what's wrong ? Do you need other 
 information ?

It won't necessarily help, but you should always mention versions (or
dates if building from source) of any relevant software and what machine
architecture you use in any problem report.



Re: openldap password fails to update

2014-03-08 Thread Stéphane Guedon
Le samedi 8 mars 2014, 12:23:19 Stuart Henderson a écrit :
 On 2014-03-07, Stéphane Guedon steph...@22decembre.eu wrote:
  But when I try to change this user password it fails :
 
  # ldappasswd  -x -v -D uid=test,ou=users,dc=22decembre,dc=eu \
  -w somesecret -s anothersec
  ldap_initialize( DEFAULT )
  Result: Other (e.g., implementation specific) error (80)
  Additional info: password hash failed

 What is password-hash set to in slapd.conf on the server?

 I think there is a bug with password-hash {CRYPT}, if you use this
 you can try password-hash {SSHA} for now, or (probably better)
 encrypt the password locally and change it using ldapmodify (or
 ldapvi, etc).

  slappasswd never gives the same result !

 That's expected for salted hashes.

  Does any of you can suggest what's wrong ? Do you need other
  information ?

 It won't necessarily help, but you should always mention versions
 (or dates if building from source) of any relevant software and
 what machine architecture you use in any problem report.

Thanks everybody from the list...
I changed the standard hash yesterday and now, password update works.
But I am still having problems with other parts of the ldap...

Notably, the user fails to auth and do login (with openbsd login
system AND webpages) eventhough password is correct according to ldap
itself !

By the way, anybody use the light ldapd daemon included in base ? can
we update password with it ?

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]



Re: openldap password fails to update

2014-03-08 Thread Matthew Weigel
On Mar 8, 2014, at 6:29 AM, Stéphane Guedon steph...@22decembre.eu wrote:

 Notably, the user fails to auth and do login (with openbsd login
 system AND webpages) eventhough password is correct according to ldap
 itself !

That's a lot more moving parts than just passwords in LDAP. Have you checked
your configuration of all those moving parts? Looked at logs? You don't even
mention what else you're using, much less how they've been configured or what
their logs report.

I am using ypldap from base and login_ldap from ports; your mileage may vary.

 By the way, anybody use the light ldapd daemon included in base ? can
 we update password with it ?

I use it. It does not currently support the modify password extended operation
(what ldappasswd relies on). I am working on a patch for it but I haven't
finished it and it requires a bit more refactoring than just processing one
new request.

Until that's done I rely on a short Perl script I wrote. It's a pretty simple
kind of thing to do; it is more a codification of a particular policy than a
technically challenging problem.
--
Matthew Weigel



Re: openldap password fails to update

2014-03-08 Thread Stéphane Guedon
Le samedi 8 mars 2014, 09:09:08 Matthew Weigel a écrit :
 On Mar 8, 2014, at 6:29 AM, Stéphane Guedon
steph...@22decembre.eu wrote:
  Notably, the user fails to auth and do login (with openbsd login
  system AND webpages) eventhough password is correct according to
  ldap itself !

 That's a lot more moving parts than just passwords in LDAP.

Yes, but passwords are the first things to change to secure your
users/install.

I am currently working on  a little webpage in python to allow easy
ldap management (add/remove users and groups, passwords update).

 Have you
 checked your configuration of all those moving parts? Looked at
 logs? You don't even mention what else you're using, much less how
 they've been configured or what their logs report.

I am looking through logs and config since the beginning of the day...
Actually, asking help on forums or mailing lists is always my last
step in solving problems...

here is my config :


include schema/core.schema
include schema/cosine.schema
include schema/inetorgperson.schema
include schema/misc.schema
include schema/nis.schema
include schema/openldap.schema

loglevel256

pidfile run/slapd.pid
argsfilerun/slapd.args
allow   bind_v2
password-hash   {SHA}

###
# BDB database definitions
###

databasebdb
suffix  dc=22decembre,dc=eu
rootdn  cn=admin,dc=22decembre,dc=eu

access to dn.base= by * read
access to dn.base=cn=Subschema by * read

#access to attrs=userpassword
#  by self   write
#   by anonymous  auth
#  by *  none

#rootpw secret
rootpw  {SSHA}vdszl5a7z9UlAU6iHU0xlKJCY+Tpgmv+

# 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
index   uid eq
index   uidNumber   eq
index   gidNumber   eq
index   memberUid   eq
index   homeDirectory   eq
index   loginShell  eq
index   cn,gn,mail  pres,eq,sub

##

I have tried to disable all acl (so default policy : everything
readable). But still no possible to logon.

Here is what I get when trying to using the login_ldap with debugging
:

# /usr/local/libexec/auth/login_-ldap -d -s login stephane ldap
Password:
load_ssl_certs says:
cacert none
cacertdir none
usercert none
userkey none
parse_server_line buf = localhost
parse_server_line port == NULL, will use default
parse_server_line mode == NULL, will use default
host localhost, port 389, version 3
setting cert info
clearing ssl set
connect success!
set version to 3
defaults:
basedn ou=users,dc=22decembre,dc=eu
binddn none
bindpw none
set timeout sec 60, usec 6
set noref 0
set keepcreds 0
bind success!
usearch:
ufilter ((objectclass=posixAccount)(uid=stephane))
scope: sub
0: search (ou=users,dc=22decembre,dc=eu, ((objectclass=posixAccount)
(uid=stephane)))
1: msgid 0, type 64
1: SEARCH_ENTRY userdn uid=stephane,ou=users,dc=22decembre,dc=eu
1: msgid 1, type 65
1: returning userdn = uid=stephane,ou=users,dc=22decembre,dc=eu
userdn uid=stephane,ou=users,dc=22decembre,dc=eu
user bind failed, dn: uid=stephane,ou=users,dc=22decembre,dc=eu
reject



 I am using ypldap from base and login_ldap from ports; your mileage
 may vary.
  By the way, anybody use the light ldapd daemon included in base ?
  can we update password with it ?

 I use it. It does not currently support the modify password extended
 operation (what ldappasswd relies on). I am working on a patch for
 it but I haven't finished it and it requires a bit more refactoring
 than just processing one new request.

Ok, so I think I will check ldapd from time to time...

 --
 Matthew Weigel

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]



Re: openldap password fails to update

2014-03-08 Thread Stéphane Guedon
Le samedi 8 mars 2014, 17:21:26 Stéphane Guedon a écrit :
 Le samedi 8 mars 2014, 09:09:08 Matthew Weigel a écrit :
  On Mar 8, 2014, at 6:29 AM, Stéphane Guedon
 
 steph...@22decembre.eu wrote:
   Notably, the user fails to auth and do login (with openbsd login
   system AND webpages) eventhough password is correct according to
   ldap itself !
  
  That's a lot more moving parts than just passwords in LDAP.
 
 Yes, but passwords are the first things to change to secure your
 users/install.
 
 I am currently working on  a little webpage in python to allow easy
 ldap management (add/remove users and groups, passwords update).
 
  Have you
  checked your configuration of all those moving parts? Looked at
  logs? You don't even mention what else you're using, much less how
  they've been configured or what their logs report.
 
 I am looking through logs and config since the beginning of the
 day... Actually, asking help on forums or mailing lists is always
 my last step in solving problems...
 
 here is my config :
 
 
 include schema/core.schema
 include schema/cosine.schema
 include schema/inetorgperson.schema
 include schema/misc.schema
 include schema/nis.schema
 include schema/openldap.schema
 
 loglevel256
 
 pidfile run/slapd.pid
 argsfilerun/slapd.args
 allow   bind_v2
 password-hash   {SHA}
 
 
 ### # BDB database definitions
 
 ###
 
 databasebdb
 suffix  dc=22decembre,dc=eu
 rootdn  cn=admin,dc=22decembre,dc=eu
 
 access to dn.base= by * read
 access to dn.base=cn=Subschema by * read
 
 #access to attrs=userpassword
 #  by self   write
 #   by anonymous  auth
 #  by *  none
 
 #rootpw secret
 rootpw  {SSHA}vdszl5a7z9UlAU6iHU0xlKJCY+Tpgmv+
 
 # 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
 index   uid eq
 index   uidNumber   eq
 index   gidNumber   eq
 index   memberUid   eq
 index   homeDirectory   eq
 index   loginShell  eq
 index   cn,gn,mail  pres,eq,sub
 
 ##
 
 I have tried to disable all acl (so default policy : everything
 readable). But still no possible to logon.
 
 Here is what I get when trying to using the login_ldap with
 debugging
 
 
 # /usr/local/libexec/auth/login_-ldap -d -s login stephane ldap
 Password:
 load_ssl_certs says:
 cacert none
 cacertdir none
 usercert none
 userkey none
 parse_server_line buf = localhost
 parse_server_line port == NULL, will use default
 parse_server_line mode == NULL, will use default
 host localhost, port 389, version 3
 setting cert info
 clearing ssl set
 connect success!
 set version to 3
 defaults:
 basedn ou=users,dc=22decembre,dc=eu
 binddn none
 bindpw none
 set timeout sec 60, usec 6
 set noref 0
 set keepcreds 0
 bind success!
 usearch:
 ufilter ((objectclass=posixAccount)(uid=stephane))
 scope: sub
 0: search (ou=users,dc=22decembre,dc=eu,
 ((objectclass=posixAccount) (uid=stephane)))
 1: msgid 0, type 64
 1: SEARCH_ENTRY userdn uid=stephane,ou=users,dc=22decembre,dc=eu
 1: msgid 1, type 65
 1: returning userdn = uid=stephane,ou=users,dc=22decembre,dc=eu
 userdn uid=stephane,ou=users,dc=22decembre,dc=eu
 user bind failed, dn: uid=stephane,ou=users,dc=22decembre,dc=eu
 reject

when using the one in /usr/libexec/auth/login_... instead of 
/usr/local/libexec... it works !

and I can start ypldap !

But why can't I authenticate (using ssh or login) on the system ? Do I 
really have to go through ypldap ? Sounds not efficient to have an 
intermediate !

And still having problem with my php scripts, which I am debugging 
now.

Thanks for your help and answers. Please continue if you have any idea 
! :D

 
  I am using ypldap from base and login_ldap from ports; your
  mileage
  may vary.
  
   By the way, anybody use the light ldapd daemon included in base
   ?
   can we update password with it ?
  
  I use it. It does not currently support the modify password
  extended operation (what ldappasswd relies on). I am working on a
  patch for it but I haven't finished it and it requires a bit more
  refactoring than just processing one new request.
 
 Ok, so I think I will check ldapd from time to time...
 
  --
  Matthew Weigel



Re: openldap password fails to update

2014-03-08 Thread Matthew Weigel
On 03/08/2014 12:16 PM, Stéphane Guedon wrote:

 I am looking through logs and config since the beginning of the
 day... Actually, asking help on forums or mailing lists is always
 my last step in solving problems...

We try to help.

But... giving detailed descriptions of the problem, and showing relevant
configs and logs the first time, goes a long way to helping people help you.

Reading manuals helps too. Among others, ypldap(8), ypldap.conf(5),
login.conf(5), login_ldap(8) from ports, and whatever manuals for OpenLDAP.

 But why can't I authenticate (using ssh or login) on the system ? Do I 
 really have to go through ypldap ? Sounds not efficient to have an 
 intermediate !

There are two separate mechanisms: how user information is looked up,
and how users are authenticated. You provide zero details on how ypldap
or login_ldap are configured, so it's hard to guess whether you have
some configuration wrong. I can say it works for me.

The user lookup is configured (via +:: entries in /etc/passwd and
/etc/group) to use YP routines. Thus the user is looked up in ypldap
when they attempt to login, which is configured to identify the user's
login class as ldap. The ldap login class is configured in login.conf to
authenticate via login_ldap talking to the LDAP server, which is
configured to have the appropriate users.

This is what I meant by that's a lot more moving parts than just
passwords in LDAP.
-- 
 Matthew Weigel
 hacker
 unique  idempot . ent



Re: openldap password fails to update

2014-03-08 Thread Stuart Henderson
On 2014-03-08, Stéphane Guedon steph...@22decembre.eu wrote:
 Notably, the user fails to auth and do login (with openbsd login
 system AND webpages) eventhough password is correct according to ldap
 itself !

How are you doing ldap authentication? (i.e. what software are you
using, and how does it authenticate? attempt binding as the user trying
to login, or looking up the password via a high-privileged account?

I'm using login-ldap from packages for ldap password auth, this works
fine for me against passwords stored in openldap.

I have this in login.conf:

ldap:\
:auth=-ldap:\
:x-ldap-server=127.0.0.1:\
:x-ldap-timeout=5:\
:x-ldap-basedn=ou=user,dc=exaple,dc=com:\
:x-ldap-filter=((objectclass=posixAccount)(uid=%u)):\
:tc=default:

and set the login class to ldap on accounts which should use this as their
password source (e.g. class is the 5th field in master.passwd if using
statically configured accounts with ldap passwords, or 'fixed attribute
class ldap' in ypldap.conf if doing it that way).



Re: openldap password fails to update

2014-03-08 Thread Stéphane Guedon
Le samedi 8 mars 2014, 19:16:07 Stéphane Guedon a écrit :
 Le samedi 8 mars 2014, 17:21:26 Stéphane Guedon a écrit :
  Le samedi 8 mars 2014, 09:09:08 Matthew Weigel a écrit :
   On Mar 8, 2014, at 6:29 AM, Stéphane Guedon
 
  steph...@22decembre.eu wrote:
Notably, the user fails to auth and do login (with openbsd
login
system AND webpages) eventhough password is correct according
to
ldap itself !
  
   That's a lot more moving parts than just passwords in LDAP.
 
  Yes, but passwords are the first things to change to secure your
  users/install.
 
  I am currently working on  a little webpage in python to allow
  easy
  ldap management (add/remove users and groups, passwords update).
 
   Have you
   checked your configuration of all those moving parts? Looked at
   logs? You don't even mention what else you're using, much less
   how
   they've been configured or what their logs report.
 
  I am looking through logs and config since the beginning of the
  day... Actually, asking help on forums or mailing lists is always
  my last step in solving problems...
 
  here is my config :
 
  
  include schema/core.schema
  include schema/cosine.schema
  include schema/inetorgperson.schema
  include schema/misc.schema
  include schema/nis.schema
  include schema/openldap.schema
 
  loglevel256
 
  pidfile run/slapd.pid
  argsfilerun/slapd.args
  allow   bind_v2
  password-hash   {SHA}
 
  ##
  ## ### # BDB database definitions
  ##
  ## ###
 
  databasebdb
  suffix  dc=22decembre,dc=eu
  rootdn  cn=admin,dc=22decembre,dc=eu
 
  access to dn.base= by * read
  access to dn.base=cn=Subschema by * read
 
  #access to attrs=userpassword
  #  by self   write
  #   by anonymous  auth
  #  by *  none
 
  #rootpw secret
  rootpw  {SSHA}vdszl5a7z9UlAU6iHU0xlKJCY+Tpgmv+
 
  # 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
  index   uid eq
  index   uidNumber   eq
  index   gidNumber   eq
  index   memberUid   eq
  index   homeDirectory   eq
  index   loginShell  eq
  index   cn,gn,mail  pres,eq,sub
 
  ##
 
  I have tried to disable all acl (so default policy : everything
  readable). But still no possible to logon.
 
  Here is what I get when trying to using the login_ldap with
  debugging
 
 
  # /usr/local/libexec/auth/login_-ldap -d -s login stephane ldap
  Password:
 
  load_ssl_certs says:
  cacert none
  cacertdir none
  usercert none
  userkey none
 
  parse_server_line buf = localhost
  parse_server_line port == NULL, will use default
  parse_server_line mode == NULL, will use default
  host localhost, port 389, version 3
  setting cert info
  clearing ssl set
  connect success!
  set version to 3
 
  defaults:
  basedn ou=users,dc=22decembre,dc=eu
  binddn none
  bindpw none
 
  set timeout sec 60, usec 6
  set noref 0
  set keepcreds 0
  bind success!
 
  usearch:
  ufilter ((objectclass=posixAccount)(uid=stephane))
  scope: sub
 
  0: search (ou=users,dc=22decembre,dc=eu,
  ((objectclass=posixAccount) (uid=stephane)))
  1: msgid 0, type 64
  1: SEARCH_ENTRY userdn uid=stephane,ou=users,dc=22decembre,dc=eu
  1: msgid 1, type 65
  1: returning userdn = uid=stephane,ou=users,dc=22decembre,dc=eu
  userdn uid=stephane,ou=users,dc=22decembre,dc=eu
  user bind failed, dn: uid=stephane,ou=users,dc=22decembre,dc=eu
  reject

 when using the one in /usr/libexec/auth/login_... instead of
 /usr/local/libexec... it works !

 and I can start ypldap !

 But why can't I authenticate (using ssh or login) on the system ? Do
 I really have to go through ypldap ? Sounds not efficient to have
 an intermediate !

 And still having problem with my php scripts, which I am debugging
 now.

found the thing...

when I use 127.0.0.1 in php scripts, I can use ldap.
if the script is running with 'localhost' then, no ldap data...

Any idea why ?
I have checked host resolution...
telnet localhost ldap gives the good behavior

# netstat -at|grep ldap
tcp  0  0  localhost.29434localhost.ldap
TIME_WAIT
tcp  0  0  *.ldap *.*
LISTEN
tcp  0  0  localhost.ldap *.*
LISTEN
tcp6 0  0  *.ldap *.*
LISTEN
tcp6 0  0  localhost.ldap *.*
LISTEN
0xfe812e35d938 dgram   0  0 0xfe812de95288
0x00x00x0 /var/openldap-data/dev/log



 Thanks for your help and answers. Please 

Re: openldap password fails to update

2014-03-08 Thread Matthew Weigel
On 03/08/2014 03:11 PM, Stéphane Guedon wrote:

 when I use 127.0.0.1 in php scripts, I can use ldap.
 if the script is running with 'localhost' then, no ldap data...
 
 Any idea why ?
 I have checked host resolution...
 telnet localhost ldap gives the good behavior

Is PHP running inside a chroot?  Does that chroot have an /etc/hosts
with an entry for localhost?

-- 
 Matthew Weigel
 hacker
 unique  idempot . ent



Re: openldap password fails to update

2014-03-07 Thread Matthew Weigel

On 03/07/2014 04:22 AM, Stéphane Guedon wrote:


# ldappasswd  -x -v -D uid=test,ou=users,dc=22decembre,dc=eu \
-w somesecret -s anothersec
ldap_initialize( DEFAULT )
Result: Other (e.g., implementation specific) error (80)
Additional info: password hash failed


I'm sorry, it's not clear that this is an OpenBSD problem.  See, for 
example, 
http://www.openldap.org/lists/openldap-technical/200902/msg00186.html



There's another thing strange, maybe related to the problem :
slappasswd never gives the same result !

# slappasswd
New password:
Re-enter new password:
{SSHA}8ip4+k3gVAN6Gggf2szhJxo052sI3Fyc
# slappasswd
New password:
Re-enter new password:
{SSHA}JvduTI/JAX1G9AhtlCYEjNHl/6DbE6hs


The whole point of salting is to make the hash different each time.  A 
random salt is used to alter the hash and then that salt is added to the 
end of the hashed string before being base64-encoded to give you the 
hash you see.

--
 Matthew Weigel
 hacker
 unique  idempot . ent



Re: openldap-2.4.36 server

2013-11-11 Thread Stuart Henderson
On 2013-11-10, Predrag Punosevac punoseva...@gmail.com wrote:
 Hi Misc,

 I am playing with OpenLDAP and I have a question about OpenLDAP server.
 I see in ports OpenLDAP server version 2.3.43 and the client version
 2.4.36 even though current release is 2.4.37. Is there a particular
 reason besides lack of man power and interest why the server is not
 updated to 2.4.36 or newer? I have hard time believing that 2.4.36 in
 the base due to licensing. Am I missing something obvious as usual?

 Predrag



Both the 2.3.x and 2.4.x servers are available, the old one is because
some people had big problems with the bdb database backend.

As far as the client is concerned, only 2.4.x is available; there
haven't been any complaints about this client version, and many ports
depend on it, so carrying 2 versions would cause a lot of problems
in ports.

2.4.x is at 2.4.36 because 2.4.37 has only been out for 2 weeks and it 
takes time for people to notice the release, prepare the update, and test
it.



Re: openldap-2.4.36 server

2013-11-10 Thread Jérémie Courrèges-Anglas
Predrag Punosevac punoseva...@gmail.com writes:

 Hi Misc,

Hi,

this is a question for ports@.

 I am playing with OpenLDAP and I have a question about OpenLDAP server.
 I see in ports OpenLDAP server version 2.3.43 and the client version
 2.4.36 even though current release is 2.4.37. Is there a particular
 reason besides lack of man power and interest why the server is not
 updated to 2.4.36 or newer?

On -current i386:
$ pkg_info -Q openldap
openldap-client-2.4.36 (installed)
openldap-server-2.3.43p13
openldap-server-2.4.36
openldap-server-2.4.36-aci

 I have hard time believing that 2.4.36 in
 the base due to licensing.

There's ldapd in base if you want to give it a try.

 Am I missing something obvious as usual?

Well... ;)

-- 
jca | PGP : 0x06A11494 / 61DB D9A0 00A4 67CF 2A90  8961 6191 8FBF 06A1 1494



Re: openldap-2.4.36 server

2013-11-10 Thread Predrag Punosevac
j...@wxcvbn.org (J??r??mie Courr??ges-Anglas) wrote:

 Predrag Punosevac punoseva...@gmail.com writes:

  Hi Misc,

 Hi,

 this is a question for ports@.


I was not sure but I didn't want to cross post.

  I am playing with OpenLDAP and I have a question about OpenLDAP server.
  I see in ports OpenLDAP server version 2.3.43 and the client version
  2.4.36 even though current release is 2.4.37. Is there a particular
  reason besides lack of man power and interest why the server is not
  updated to 2.4.36 or newer?

 On -current i386:
 $ pkg_info -Q openldap
 openldap-client-2.4.36 (installed)
 openldap-server-2.3.43p13
 openldap-server-2.4.36
 openldap-server-2.4.36-aci

  I have hard time believing that 2.4.36 in
  the base due to licensing.

 There's ldapd in base if you want to give it a try.


I just came across Stuard's answer to somebody and wanted to apologize
for the noise. I should have better investigate the license instead of
making assumption. I do appreciate your quick pointers though. 

Most Kind Regards,
Predrag

  Am I missing something obvious as usual?

 Well... ;)

 -- 
 jca | PGP : 0x06A11494 / 61DB D9A0 00A4 67CF 2A90  8961 6191 8FBF 06A1 1494



Re: openldap on OBSD amd64 5.2

2013-01-14 Thread Claudio Jeker
On Mon, Jan 14, 2013 at 05:41:36PM -0200, Friedrich Locke wrote:
 Hi,
 
 i am trying to get openldap running, but my experience has been not that
 good.
 I have built and installed from ports. I can get it up and running but as
 soon as qmail tries to bind into it, it begins to consume memory up to all
 my available memory.
 
 I asked for help in the openldap mailing list and they got baffled, pretty
 baffled.
 I was told that in linux some special flags need to be supplied to BDB in
 order to get it working well.
 What about OpenBSD ? Have you tryied qmail-ldap + openldap on OBSD ? Faced
 anything similar ?
 I am aware that this problem persist from about two years ago, when i tried
 to get them working and the same problem arose.
 I waited beleving it would be fixed in a near future ...
 
 I am really interested in get it solved, although i have no knownledge on
 BDB internals ..
 
 I am willing to hear 
 

Install openldap-server-2.3.43 and use LDBM. BDB on 64bit archs is borked.
We have the old version exactly for that around.

-- 
:wq Claudio



Re: openldap on OBSD amd64 5.2

2013-01-14 Thread Vijay Sankar

Quoting Friedrich Locke friedrich.lo...@gmail.com:


Hi,

i am trying to get openldap running, but my experience has been not that
good.
I have built and installed from ports. I can get it up and running but as
soon as qmail tries to bind into it, it begins to consume memory up to all
my available memory.

I asked for help in the openldap mailing list and they got baffled, pretty
baffled.
I was told that in linux some special flags need to be supplied to BDB in
order to get it working well.
What about OpenBSD ? Have you tryied qmail-ldap + openldap on OBSD ? Faced
anything similar ?
I am aware that this problem persist from about two years ago, when i tried
to get them working and the same problem arose.
I waited beleving it would be fixed in a near future ...

I am really interested in get it solved, although i have no knownledge on
BDB internals ..

I am willing to hear 

Thanks in advance.




I have been using OpenLDAP on OpenBSD (OpenLDAP 2.4.12 on OpenBSD 4.7  
i386 as well as OpenLDAP 2.4.26 on OpenBSD 4.9 amd64) without any  
problems for a few years now.


I use sendmail as MTA and use the LDAP database for vacation, address  
books, distribution lists, etc. OpenLDAP also is used to authorize  
Windows users. dovecot users, iphone and blackberry users etc. I use  
BDB so that syncrepl etc. works well.


Since knowledgeable people have mentioned that there are problems with  
newer versions of LDAP, I wonder if it is advisable for you to use the  
older versions on OpenBSD to run OpenLDAP. Not sure, just a thought.  
Since the ports.tar.gz file is on the CD, you may be able to build the  
older packages even though they are obsolete and not available at the  
OpenBSD FTP site.


Vijay


Vijay Sankar, M.Eng., P.Eng.
ForeTell Technologies Limited
vsan...@foretell.ca

-
This message was sent using ForeTell-POST 4.9



Re: openldap on OBSD amd64 5.2

2013-01-14 Thread Friedrich Locke
Hi,

sounds strange. Claudio said it was borked for amd64.
Are you using BDB ? Which version ?

On Mon, Jan 14, 2013 at 8:10 PM, Vijay Sankar vsan...@foretell.ca wrote:

 Quoting Friedrich Locke friedrich.lo...@gmail.com:

  Hi,

 i am trying to get openldap running, but my experience has been not that
 good.
 I have built and installed from ports. I can get it up and running but as
 soon as qmail tries to bind into it, it begins to consume memory up to all
 my available memory.

 I asked for help in the openldap mailing list and they got baffled, pretty
 baffled.
 I was told that in linux some special flags need to be supplied to BDB in
 order to get it working well.
 What about OpenBSD ? Have you tryied qmail-ldap + openldap on OBSD ? Faced
 anything similar ?
 I am aware that this problem persist from about two years ago, when i
 tried
 to get them working and the same problem arose.
 I waited beleving it would be fixed in a near future ...

 I am really interested in get it solved, although i have no knownledge on
 BDB internals ..

 I am willing to hear 

 Thanks in advance.



 I have been using OpenLDAP on OpenBSD (OpenLDAP 2.4.12 on OpenBSD 4.7 i386
 as well as OpenLDAP 2.4.26 on OpenBSD 4.9 amd64) without any problems for a
 few years now.

 I use sendmail as MTA and use the LDAP database for vacation, address
 books, distribution lists, etc. OpenLDAP also is used to authorize Windows
 users. dovecot users, iphone and blackberry users etc. I use BDB so that
 syncrepl etc. works well.

 Since knowledgeable people have mentioned that there are problems with
 newer versions of LDAP, I wonder if it is advisable for you to use the
 older versions on OpenBSD to run OpenLDAP. Not sure, just a thought. Since
 the ports.tar.gz file is on the CD, you may be able to build the older
 packages even though they are obsolete and not available at the OpenBSD FTP
 site.

 Vijay


 Vijay Sankar, M.Eng., P.Eng.
 ForeTell Technologies Limited
 vsan...@foretell.ca

 --**---
 This message was sent using ForeTell-POST 4.9



Re: openldap on OBSD amd64 5.2

2013-01-14 Thread Vijay Sankar

I am using db-4.6.21p4

Quoting Friedrich Locke friedrich.lo...@gmail.com:


Hi,

sounds strange. Claudio said it was borked for amd64.
Are you using BDB ? Which version ?

On Mon, Jan 14, 2013 at 8:10 PM, Vijay Sankar vsan...@foretell.ca wrote:


Quoting Friedrich Locke friedrich.lo...@gmail.com:

 Hi,


i am trying to get openldap running, but my experience has been not that
good.
I have built and installed from ports. I can get it up and running but as
soon as qmail tries to bind into it, it begins to consume memory up to all
my available memory.

I asked for help in the openldap mailing list and they got baffled, pretty
baffled.
I was told that in linux some special flags need to be supplied to BDB in
order to get it working well.
What about OpenBSD ? Have you tryied qmail-ldap + openldap on OBSD ? Faced
anything similar ?
I am aware that this problem persist from about two years ago, when i
tried
to get them working and the same problem arose.
I waited beleving it would be fixed in a near future ...

I am really interested in get it solved, although i have no knownledge on
BDB internals ..

I am willing to hear 

Thanks in advance.




I have been using OpenLDAP on OpenBSD (OpenLDAP 2.4.12 on OpenBSD 4.7 i386
as well as OpenLDAP 2.4.26 on OpenBSD 4.9 amd64) without any problems for a
few years now.

I use sendmail as MTA and use the LDAP database for vacation, address
books, distribution lists, etc. OpenLDAP also is used to authorize Windows
users. dovecot users, iphone and blackberry users etc. I use BDB so that
syncrepl etc. works well.

Since knowledgeable people have mentioned that there are problems with
newer versions of LDAP, I wonder if it is advisable for you to use the
older versions on OpenBSD to run OpenLDAP. Not sure, just a thought. Since
the ports.tar.gz file is on the CD, you may be able to build the older
packages even though they are obsolete and not available at the OpenBSD FTP
site.

Vijay


Vijay Sankar, M.Eng., P.Eng.
ForeTell Technologies Limited
vsan...@foretell.ca

--**---
This message was sent using ForeTell-POST 4.9







Vijay Sankar, M.Eng., P.Eng.
ForeTell Technologies Limited
vsan...@foretell.ca

-
This message was sent using ForeTell-POST 4.9



Re: openldap on OBSD amd64 5.2

2013-01-14 Thread Stuart Henderson
On 2013-01-14, Claudio Jeker cje...@diehard.n-r-g.com wrote:
 On Mon, Jan 14, 2013 at 05:41:36PM -0200, Friedrich Locke wrote:
 Hi,
 
 i am trying to get openldap running, but my experience has been not that
 good.
 I have built and installed from ports. I can get it up and running but as
 soon as qmail tries to bind into it, it begins to consume memory up to all
 my available memory.
 
 I asked for help in the openldap mailing list and they got baffled, pretty
 baffled.
 I was told that in linux some special flags need to be supplied to BDB in
 order to get it working well.
 What about OpenBSD ? Have you tryied qmail-ldap + openldap on OBSD ? Faced
 anything similar ?
 I am aware that this problem persist from about two years ago, when i tried
 to get them working and the same problem arose.
 I waited beleving it would be fixed in a near future ...
 
 I am really interested in get it solved, although i have no knownledge on
 BDB internals ..
 
 I am willing to hear 
 

 Install openldap-server-2.3.43 and use LDBM. BDB on 64bit archs is borked.
 We have the old version exactly for that around.


I'm running 2.4.33 with BDB on amd64 and haven't seen this problem but
my current use of it is not exactly heavyweight though, just mail routing,
password, antispam config for a few hundred user accounts (using
dovecot/postfix/amavis).

I haven't run qmail-ldap for at least 10 years but your description
as soon as qmail tries to bind into it, it begins to consume memory
suggests that maybe it works with other clients - is that correct?
any idea what qmail-ldap is doing differently?

If you haven't already got reasonable logs you can add
'local4.* /var/log/ldap' to /etc/syslog.conf, touch /var/log/ldap,
/etc/rc.d/syslogd reload - iirc this is enough to get binds/queries
logged and might help shed some light.



Re: openldap and openbsd

2011-06-30 Thread Stuart Henderson
On 2011-06-29, Stuart Henderson s...@spacehopper.org wrote:
 On 2011-06-29, Remco re...@d-compu.dyndns.org wrote:

 Apart from the other advise you got I think you need to set the KRB5_KTNAME
 environment variable to tell slapd where to find your LDAP keytab, e.g.:
 (yeah, I edited the default slapd rc script, I don't know if there's a
 better way)

 this will cause you hassle when you update the packages.

 see rc.d(8) for the correct way to handle this.

ah, sorry I thought you were changing flags not environment.
even so, editing the rc script provided by the package will
cause problems, you could copy it under another name though...



Re: openldap and openbsd

2011-06-29 Thread Janne Johansson
2011/6/28 Friedrich Locke friedrich.lo...@gmail.com

 Dear list members,

 i have just installed openldap from ports (OpenBSD 4.9/amd64) and i am
 testing it. My doubt is:

 It seems to me that openldap should be run as user x and group y
 accordingly the ports collection. The problem is that i want to use
 kerberos authentication. The system (OS context) is just doing
 kerberos, but the keytab file is permited acess only to root.

 How could i run openldap as another user not root and provide it with
 a ldap/x.y.z ticket?

 How have you done so?


You make a specific keytab for openldap, of course readable by the ldap
daemon user.
There is no need to stick all keytabs in the host keytab file.

-- 
 To our sweethearts and wives.  May they never meet. -- 19th century toast



Re: openldap and openbsd

2011-06-29 Thread Remco
Friedrich Locke wrote:

 Dear list members,
 
 i have just installed openldap from ports (OpenBSD 4.9/amd64) and i am
 testing it. My doubt is:
 
 It seems to me that openldap should be run as user x and group y
 accordingly the ports collection. The problem is that i want to use
 kerberos authentication. The system (OS context) is just doing
 kerberos, but the keytab file is permited acess only to root.
 
 How could i run openldap as another user not root and provide it with
 a ldap/x.y.z ticket?
 
 How have you done so?
 
 Thanks for sharing you experience.
 
 Best regards.

Apart from the other advise you got I think you need to set the KRB5_KTNAME
environment variable to tell slapd where to find your LDAP keytab, e.g.:
(yeah, I edited the default slapd rc script, I don't know if there's a
better way)

gw:~# cat /etc/rc.d/slapd
#!/bin/sh
#
# $OpenBSD: slapd.rc,v 1.3 2011/01/13 15:41:40 pea Exp $

daemon=env KRB5_KTNAME=/some_path/ldap.keytab /usr/local/libexec/slapd
daemon_flags=-u _openldap

 /etc/rc.d/rc.subr

rc_reload=NO

rc_pre() {
/usr/bin/install -d -o _openldap /var/run/openldap
}

rc_cmd $1



Re: openldap and openbsd

2011-06-29 Thread Stuart Henderson
On 2011-06-29, Remco re...@d-compu.dyndns.org wrote:

 Apart from the other advise you got I think you need to set the KRB5_KTNAME
 environment variable to tell slapd where to find your LDAP keytab, e.g.:
 (yeah, I edited the default slapd rc script, I don't know if there's a
 better way)

this will cause you hassle when you update the packages.

see rc.d(8) for the correct way to handle this.



Re: openldap and openbsd

2011-06-29 Thread Remco
Stuart Henderson wrote:

 On 2011-06-29, Remco re...@d-compu.dyndns.org wrote:

 Apart from the other advise you got I think you need to set the
 KRB5_KTNAME environment variable to tell slapd where to find your LDAP
 keytab, e.g.: (yeah, I edited the default slapd rc script, I don't know
 if there's a better way)
 
 this will cause you hassle when you update the packages.
 
 see rc.d(8) for the correct way to handle this.

Thanks for the pointer though I'm not sure what you were hinting at. On my
4.9 system I couldn't really find a way to override the daemon line in a rc
script. However, I found out that it's possible to define a class in
login.conf named after the script, and the script will pick that up, e.g.:
#
# OpenLDAP
#
slapd:\
:setenv=KRB5_KTNAME=/some_path/ldap.keytab:\
:tc=daemon:

Hopefully this is useful to the OP (and others as well).



Re: openldap and openbsd

2011-06-28 Thread Jeremie Courreges-Anglas
Friedrich Locke friedrich.lo...@gmail.com writes:

 How could i run openldap as another user not root and provide it with
 a ldap/x.y.z ticket?

Use kadmin and ktadd -k.
Remember that openldap (and only openldap) should only
have read access to the new keytab.



Re: OpenLDAP

2011-01-10 Thread Remi Locherer

Hi Friedich

It's in current: http://marc.info/?l=openbsd-portsm=129440451210138w=2

Regards,
Remi

On 01/11/2011 12:56 AM, Friedrich Locke wrote:


Hi folks,

is there plan for openbsd support openldap with recent version(s) of bdb ?

Thanks in advance,

Gustavo.




Re: OpenLDAP w/o bdb okay?

2009-05-06 Thread Dan
Henning Brauer(lists-open...@bsws.de)@2009.01.06 14:42:09 +0100:
 * Toni Mueller openbsd-m...@oeko.net [2009-01-06 12:25]:
   openldap is still a piece of shit, but the ldbm backend is probably the
   sanest one.
  
  This pattern comes up often, but almost noone suggests an alternative
  LDAP server package.
 
 I am not aware of any. Lack of options doesn't make openldap better.

How about OpenDS? Fedora Directory Server? Both are pukable on the
keyboard? Apache DS?

Yeah, I know OpenDS is Java and so is ApacheDS...



Re: OpenLDAP w/o bdb okay?

2009-01-18 Thread Henning Brauer
* dan-openbsd-m...@ourbrains.org dan-openbsd-m...@ourbrains.org [2009-01-16 
19:38]:
 Henning Brauer(lists-open...@bsws.de)@2009.01.06 14:42:09 +0100:
  I am not aware of any. Lack of options doesn't make openldap better.
 
 There is an option for people who have very basic LDAP needs - tinyldap
 from fefe.de. It's high quality but lacks many features at the time.

fefe code is never an option. don't get me started on the quality
argument...

-- 
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg  Amsterdam



Re: OpenLDAP w/o bdb okay?

2009-01-16 Thread dan-openbsd-misc
Henning Brauer(lists-open...@bsws.de)@2009.01.06 14:42:09 +0100:
 I am not aware of any. Lack of options doesn't make openldap better.

There is an option for people who have very basic LDAP needs - tinyldap
from fefe.de. It's high quality but lacks many features at the time.



Re: OpenLDAP w/o bdb okay?

2009-01-07 Thread Toni Mueller
On Tue, 06.01.2009 at 06:27:17 -0500, ppruett-lists ppru...@webengr.com wrote:
 Actually a lot linux users suggest using mysql for the non relational  
 authentication tables


 ;)


I knew you've got to be kidding!


-- 
Kind regards,
--Toni++



Re: OpenLDAP w/o bdb okay?

2009-01-07 Thread Toni Mueller
Hi,

On Tue, 06.01.2009 at 14:42:09 +0100, Henning Brauer lists-open...@bsws.de 
wrote:
 * Toni Mueller openbsd-m...@oeko.net [2009-01-06 12:25]:
  This pattern comes up often, but almost noone suggests an alternative
  LDAP server package.
 I am not aware of any. Lack of options doesn't make openldap better.

agreed, but it makes bashing openldap sort of futile.


-- 
Kind regards,
--Toni++



Re: OpenLDAP w/o bdb okay?

2009-01-06 Thread Rubin
Henning Brauer wrote:
 * Philip Guenther guent...@gmail.com [2009-01-06 00:40]:
 On Mon, Jan 5, 2009 at 11:15 AM, Claudio Jeker cje...@diehard.n-r-g.com 
 wrote:
 ...
 Any DB that needs human help after a crash is in my opinion a bad choice.
 So that would rule out the ldbm backend, no?  Last I checked the libc
 btree code, a crash while writing out a page split would corrupt the
 subtree.
 
 I am using openldap with ldbm backend in an not exactly small
 installation for 9 or 10 years now. I have never ever experienced a
 broken database. never.

I second that,

5+ years of ldbm backend usage without any problems. We've had
poweroutages, disks running full, all sorts of mischief, but never a
problem with corrupt ldbm databases. Ever. I *did* have thee times of
huge trouble with bdb as a backend. Two times with unexpected halts of
the system after which the slapd process would simply not be able to
read the bdb files anymore and one time with a prickly problem where I
needed to upgrade my database because bdb was updated on that system
(not a major release mind you, 4.x to 4.newer_x).

I know this is all not very scientific evidence regarding the stability
and robustness of bdb, but I guess it is hard to forget the pain that
came from using bdb in the couple of times I had to or did so
unknowingly. Mind you, the last time I've used bdb is 4 years ago.
Things might have changed these days.

 trying bdb lead to disasters all over the place. but admittedly that
 was many many many moons ago.
 
 openldap is still a piece of shit, but the ldbm backend is probably the
 sanest one.



Re: OpenLDAP w/o bdb okay?

2009-01-06 Thread ppruett-lists

 Here's an untested tarball of an updated openldap port, split into
 directories for 2.3 and 2.4: http://spacehopper.org/tmp/openldap.tgz



This issue has been kicked around for maybe two years, it has been on 
the misc list before,

https://kerneltrap.org/mailarchive/openbsd-misc/2007/5/20/149916/thread

I think trying the port with packages 2.3.* and 2.4.* for openldap maybe 
a solution.

test port at http://spacehopper.org/tmp/openldap.tgz

On a AMD64 dual,
So far it compiled and made the packages, after I uncommented the 
subpackage for 2.4 in the Makefile.

(Did you leave # in front of 2.4 for a reason Stuart?)



BTW expected:
# pkg_add openldap-server-2.4.12.tgz
Can't install openldap-server-2.4.12 because of conflicts 
(openldap-client-2.3.43)

/usr/sbin/pkg_add: openldap-server-2.4.12:Fatal error

As expected php5-ldap-5.2.6 and phpldapadmin-1.1.0.5 had to be uninstalled
to uninstall the openldap-client-2.3.43
Good news, the packages php5-ldap and phpldapadmin did not complain after
reinstalling with openldap 2.4.12 package.

Of note, the 2.4.12 package install complained about
/var/openldap-data/DB_CONFIG could not be installed


After some sleep, will endeavor to test on a small scale.







# pkg_add ./openldap-server-2.4.12.tgz
openldap-client-2.4.12: complete
File /var/openldap-data/DB_CONFIG could not be 
installed:*  | 94%

   No such file or directory
openldap-server-2.4.12: complete
--- openldap-server-2.4.12 ---
To start slapd, configure it in /etc/openldap/slapd.conf then add
the following line to /etc/rc.conf.local:

slapd_flags=-u _openldap

and to /etc/rc.local (be sure to start it _before_ any daemon that may
need it):

if [ $slapd_flags != NO -a -x /usr/local/libexec/slapd ]; then
   install -d -o _openldap /var/run/openldap
   /usr/local/libexec/slapd $slapd_flags
   echo -n ' slapd'
fi
#



Re: OpenLDAP w/o bdb okay?

2009-01-06 Thread ppruett-lists

 This pattern comes up often, but almost noone suggests an alternative
 LDAP server package



Actually a lot linux users suggest using mysql for the non relational 
authentication tables

;)



Re: OpenLDAP w/o bdb okay?

2009-01-06 Thread Toni Mueller
Hi,

On Tue, 06.01.2009 at 01:08:27 +0100, Henning Brauer lists-open...@bsws.de 
wrote:
 I am using openldap with ldbm backend in an not exactly small
 installation for 9 or 10 years now. I have never ever experienced a
 broken database. never.

my last encounter with ldbm, a few years back, drove me to bdb really
fast, because my - though small - installation(s) seem to behave the
opposite way. In any case, knowing how to repair a broken ldbm database
would be a good thing. With bdb, there is dbX.Y_recover, which worked
nicely for me when I needed it.

Having said that, bdb appears to be the prerequisite for the ability to
modify existing object's DNs.

 openldap is still a piece of shit, but the ldbm backend is probably the
 sanest one.

This pattern comes up often, but almost noone suggests an alternative
LDAP server package.


-- 
Kind regards,
--Toni++



Re: OpenLDAP w/o bdb okay?

2009-01-06 Thread Stuart Henderson
Moving this to po...@. Reply-To/MFT set, please honour it.

On 2009/01/06 06:11, ppruett-lists wrote:
  Here's an untested tarball of an updated openldap port, split into
  directories for 2.3 and 2.4: http://spacehopper.org/tmp/openldap.tgz



 This issue has been kicked around for maybe two years, it has been on  
 the misc list before,
 https://kerneltrap.org/mailarchive/openbsd-misc/2007/5/20/149916/thread

 I think trying the port with packages 2.3.* and 2.4.* for openldap 
 maybe a solution.
 test port at http://spacehopper.org/tmp/openldap.tgz

 On a AMD64 dual,
 So far it compiled and made the packages, after I uncommented the  
 subpackage for 2.4 in the Makefile.
 (Did you leave # in front of 2.4 for a reason Stuart?)

Yes. The most important thing at first is to know that this
doesn't break 2.3. And actually now I think about it again, it's
going to cause problems for the 37 depending ports, we probably
need to install the libraries and headers into subdirectories
and change all those ports to pick up the right ones. *Ugh*.
Can anyone think of a better way I've missed?



Re: OpenLDAP w/o bdb okay?

2009-01-06 Thread Henning Brauer
* Toni Mueller openbsd-m...@oeko.net [2009-01-06 12:25]:
  openldap is still a piece of shit, but the ldbm backend is probably the
  sanest one.
 
 This pattern comes up often, but almost noone suggests an alternative
 LDAP server package.

I am not aware of any. Lack of options doesn't make openldap better.

-- 
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg  Amsterdam



Re: OpenLDAP w/o bdb okay?

2009-01-05 Thread tico
Damn, forgot to send my response to list:
Message-ID: 49624a88.3020...@raapid.net
Date: Mon, 05 Jan 2009 11:59:36 -0600
From: tico tico-o...@raapid.net
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: P.Pruett ppru...@webengr.com
Subject: Re: OpenLDAP w/o bdb okay?
References: 49620b86.4020...@webengr.com
In-Reply-To: 49620b86.4020...@webengr.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Responses inline:

P.Pruett wrote:
 For OpenBSD 4.4 and current the flavor bdb is broken on openldap
 BROKEN=OpenLDAP 2.3 is incompatible with Berkeley DB 4.6

 Most past articles have strongly suggested haveing openldap use bdb
 as its storage method.  
If by most articles, you mean most of the Linux HOWTO articles, you'll 
notice that most of them are ancient now and were written by people with 
an almost pathological need for premature optimization and 
overly-complex initial installs.

I've yet to encounter an LDAP environment where there
a) was a disk I/O bottleneck due to locking that was solvable by BDB
b) that was not more sanely solvable by scaling out to replicated slapd 
servers
c) with or without moving the dataset onto a memory filesystem
d) or sectioning the dataset into one chunk per group of servers.

If you actually need any of the above, you probably know or should know 
way more about the bottlenecks in your LDAP environment than any of us 
do, much less the clueless retards writing HOWTO articles.

Note that I'm *not* saying that I hate BDB, just that I haven't found 
what it solves in the real world, and having data in BDB means that 
*when* corruption occurs, it's more of a pain in the ass to recover from 
than an LDIF/LDBM. This has happened to me several times, and I've found 
that the resulting error messages have been less than verbose, and less 
than helpful.
 Seeing that even the current port is not ready
 to implement OpenLDAP 2.4 suggests that using openldap without bdb may
 not be so terrible.
Thank god.
Now I don't have to double-check my installs to make sure they don't 
include BDB.

 Staying with openbsd is the choice, so we have to use a non bdb openldap
 on openbsd 4.4 or current for now.  Having always used the bdb flavor 
 because literature suggested, I wonder
 what problems for performance or maitenance in production will arise
 by not using flavor bdb for openldap?

Run your own benchmarks using your own dataset.

If your LDAP environment is anything at all like the majority I've seen 
you will not notice any difference whatsoever (except you'll be free 
from BDB corruption during a crash).

Cheers
-Tico



Re: OpenLDAP w/o bdb okay?

2009-01-05 Thread Philip Guenther
On Mon, Jan 5, 2009 at 5:30 AM, P.Pruett ppru...@webengr.com wrote:
 For OpenBSD 4.4 and current the flavor bdb is broken on openldap
 BROKEN=OpenLDAP 2.3 is incompatible with Berkeley DB 4.6

 Most past articles have strongly suggested haveing openldap use bdb
 as its storage method.  Seeing that even the current port is not ready
 to implement OpenLDAP 2.4 suggests that using openldap without bdb may
 not be so terrible.

 Staying with openbsd is the choice, so we have to use a non bdb openldap
 on openbsd 4.4 or current for now.  Having always used the bdb flavor
 because literature suggested, I wonder
 what problems for performance or maitenance in production will arise
 by not using flavor bdb for openldap?

What's your support strategy?  That is, when something goes wrong,
what's your plan for restoring stability and confidence that it'll
work in the future?  If your LDAP use is read-only or
write-almost-never, then there isn't much to go wrong and just
restore from last week's backup is probably a viable strategy.

If your LDAP use is write-heavy, or you're planning on using
replication, then IMHO you should be looking first to the OpenLDAP
mailing lists for support for OpenLDAP.  What you'll learn there is
that they basically have no interest in back-ldbm.  For example:

http://www.openldap.org/lists/openldap-software/200810/msg00154.html

I know there are people using back-ldbm successfully, but if it blows
up shortly before you do a backup, what's your plan for recovering the
lost changes?  How confident will you be that it won't happen again
the next day?  The support you'll get from the OpenLDAP people will be
told you so; switch to bdb!

So, what to do?  My experience is that compiling BDB and OpenLDAP
yourself isn't hard, but I had to do stuff like that all the time back
when I was a sysadmin and have been using BDB professionally for
years, so your mileage may vary.  The key thing is to figure out how
you're going to support your setup.


Philip Guenther



Re: OpenLDAP w/o bdb okay?

2009-01-05 Thread ppruett-lists
If your LDAP environment is anything at all like the majority I've seen 
you will not notice any difference whatsoever (except you'll be free 
from BDB corruption during a crash).
  


Yep since I am not write heavy then the non bdb could be okay,
but as an afore mentioned in this thread I am concerned that The LDBM 
backend  is now obsolete for openldap since 2.4.12.

http://www.openldap.org/lists/openldap-software/200810/msg00154.html



Re: OpenLDAP w/o bdb okay?

2009-01-05 Thread ppruett-lists

For OpenBSD 4.4 and current the flavor bdb is broken on openldap
BROKEN=OpenLDAP 2.3 is incompatible with Berkeley DB 4.6



So, what to do?  My experience is that compiling BDB and OpenLDAP
yourself isn't hard, 


yep, I remember compiling apache back in the  middle 90's
For security and laziness, I have been trying to use the ports this 
decade tho ;)


 If your LDAP use is write-heavy, or you're planning on using 
replication


I was using openldap for the password auth for sendmail smtpauth and 
cyrus-imap

on an older openbsd server and was looking to upgrade then saw this issue.
Hmmm. The passwords don't change often, because that customer has a 
small mail server for just three domains
but they could change if one of the hundred or so users changes their 
email password, but that is very

infrequent. ... So we are not write heavy.

However, I saw your link to the issue that lbm is removed from openldap 
2.4.12...  arggg..
geez  I really don't like using a storage method that is not used going 
forward.


So choices for those with older openbsd port of openldap with bdb flavor 
are:

* don't upgrade ( bad choice)
* upgrade to openbsd 4.4 or current using the official port and renter 
data storing in the obsolete backend ldbm (ughhh)

* Or go ahead and make a port for openldap 2.4.13 for current openbsd  :(

Since in the above situation the ldap is not write heavy and changes 
little I could just use the obsolete storage method.
But first I'll see how ugly it is to compile OpenLDAP 2.4.13 on current 
or 4.4...  


thanks for the input.



Re: OpenLDAP w/o bdb okay?

2009-01-05 Thread Claudio Jeker
On Mon, Jan 05, 2009 at 01:46:30PM -0500, ppruett-lists wrote:
 If your LDAP environment is anything at all like the majority I've 
 seen you will not notice any difference whatsoever (except you'll be 
 free from BDB corruption during a crash).
   

 Yep since I am not write heavy then the non bdb could be okay,
 but as an afore mentioned in this thread I am concerned that The LDBM  
 backend  is now obsolete for openldap since 2.4.12.
 http://www.openldap.org/lists/openldap-software/200810/msg00154.html


And do you think that your bdb based database will work over an update?
I think I had to reimport and sometimes even fixup my database un updates
because something changed and the old DB was just not working anymore.

Any DB that needs human help after a crash is in my opinion a bad choice.
If a servers freaks out and reboots for whatever reason I expect that the
database will recover from this event without having to recover, repair or
optimize datasets.

-- 
:wq Claudio



Re: OpenLDAP w/o bdb okay?

2009-01-05 Thread Vijay Sankar

P.Pruett wrote:

For OpenBSD 4.4 and current the flavor bdb is broken on openldap
BROKEN=OpenLDAP 2.3 is incompatible with Berkeley DB 4.6

Most past articles have strongly suggested haveing openldap use bdb
as its storage method.  Seeing that even the current port is not ready
to implement OpenLDAP 2.4 suggests that using openldap without bdb may
not be so terrible.

Staying with openbsd is the choice, so we have to use a non bdb openldap
on openbsd 4.4 or current for now.  Having always used the bdb flavor 
because literature suggested, I wonder

what problems for performance or maitenance in production will arise
by not using flavor bdb for openldap?

I am still using openldap-server-2.3.33p1-bdb on openbsd 4.2 for the 
following reasons:


1) With ldbm, I was not able to do a slapcat etc. without stopping the 
ldap server. But with bdb, I did not experience any problems using 
slapcat while ldap server was running.
2) Replication worked better for me (3 slave servers using slurpd etc.) 
with bdb
3) syncrepl in test environment also seemed to work better with bdb (and 
not ldbm)


All the testing was done a while ago and it is highly likely that I had 
made major mistakes at that time. So I will try to set up 2.3.43 on 4.4 
-current and verify this.


--
Vijay Sankar, M.Eng., P.Eng.
ForeTell Technologies Limited
E-Mail: vsan...@foretell.ca



Re: OpenLDAP w/o bdb okay?

2009-01-05 Thread Stuart Henderson
On 2009-01-05, ppruett-lists ppru...@webengr.com wrote:

 So choices for those with older openbsd port of openldap with bdb flavor 
 are:
 * don't upgrade ( bad choice)
 * upgrade to openbsd 4.4 or current using the official port and renter 
 data storing in the obsolete backend ldbm (ughhh)
 * Or go ahead and make a port for openldap 2.4.13 for current openbsd  :(

Here's an untested tarball of an updated openldap port, split into
directories for 2.3 and 2.4: http://spacehopper.org/tmp/openldap.tgz

Done at p2k8 but I don't run ldap myself any more and haven't had much
incentive to setup a test environment. Please test and report back,
I think it would be useful to get this in.



Re: OpenLDAP w/o bdb okay?

2009-01-05 Thread Philip Guenther
On Mon, Jan 5, 2009 at 11:15 AM, Claudio Jeker cje...@diehard.n-r-g.com wrote:
...
 Any DB that needs human help after a crash is in my opinion a bad choice.

So that would rule out the ldbm backend, no?  Last I checked the libc
btree code, a crash while writing out a page split would corrupt the
subtree.


 If a servers freaks out and reboots for whatever reason I expect that the
 database will recover from this event without having to recover, repair or
 optimize datasets.

So write-ahead-logging is ruled out because the database has to rerun
the tail of the log?  Then I don't think OpenLDAP has any databases
that will satisfy you.


Philip Guenther



Re: OpenLDAP w/o bdb okay?

2009-01-05 Thread Henning Brauer
* Philip Guenther guent...@gmail.com [2009-01-06 00:40]:
 On Mon, Jan 5, 2009 at 11:15 AM, Claudio Jeker cje...@diehard.n-r-g.com 
 wrote:
 ...
  Any DB that needs human help after a crash is in my opinion a bad choice.
 
 So that would rule out the ldbm backend, no?  Last I checked the libc
 btree code, a crash while writing out a page split would corrupt the
 subtree.

I am using openldap with ldbm backend in an not exactly small
installation for 9 or 10 years now. I have never ever experienced a
broken database. never.

trying bdb lead to disasters all over the place. but admittedly that
was many many many moons ago.

openldap is still a piece of shit, but the ldbm backend is probably the
sanest one.

-- 
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg  Amsterdam



Re: OpenLDAP

2008-10-21 Thread Philip Guenther
On Tue, Oct 21, 2008 at 12:33 PM, John Nietzsche
[EMAIL PROTECTED] wrote:
 i would like to know if openldap (in ports collection) will be shipped
 with suport for BDB in openbsd 4.4 ports infra structure?

Since the release is frozen, UTSL:

http://www.openbsd.org/cgi-bin/cvsweb/ports/databases/openldap/Makefile?rev=1.85;content-type=text%2Fplain

.if ${FLAVOR:L:Mbdb}
BROKEN= OpenLDAP 2.3 is incompatible with Berkeley DB 4.6



Re: OpenLDAP

2008-09-08 Thread my mail
--- On Wed, 9/3/08, Philip Guenther [EMAIL PROTECTED] wrote:

 From: Philip Guenther [EMAIL PROTECTED]
 Subject: Re: OpenLDAP
 To: John Nietzsche [EMAIL PROTECTED]
 Cc: misc misc@openbsd.org
 Date: Wednesday, September 3, 2008, 6:00 PM
 On Wed, Sep 3, 2008 at 4:15 AM, John Nietzsche
 [EMAIL PROTECTED] wrote:
  is there any chance the next openbsd release holds an
 unbroken OpenLDAP?
 
 I presume you're referring to the port/packages
 version.  The answer
 depends on whose definition of unbroken you
 prefer.
 
 The last word I heard from the OpenLDAP maintainers was
 that the ldbm
 backend was considered unsuitable for (their definition of)
 production
 use.  Indeed, it's not supported in OpenLDAP 2.4. 
 It's not robust if
 slapd or the machine crash at an inopportune time during a
 database
 change and has performance issues during writes:
 there's just one big
 reader/writer lock for the database, so any write blocks
 all readers.
 As a result, using it in a deployment where writes
 frequently occur
 seems unwise.  The OpenLDAP people will certainly give you
 little
 sympathy if/when a problem occurs there.  For a read-only,
 or
 write-rarely situation, it would seem to be okay, in which
 case the
 port/package should serve you.
 
 If you're building a write-often setup, then you would
 seem to need
 the bdb or hdb backend.  For that, the current port/package
 will not
 serve you.  I'm not a ports maintainer, but upgrading
 the port from
 OpenLDAP 2.3.x to 2.4.x in time for 4.4 seems extremely
 unlikely.  For
 all I know, the deadline for such a change may have passed
 months ago.
  So, if you need the bdb backend, you would need to build
 OpenLDAP
 2.4.x yourself.  In my experience, of compiling OpenLDAP,
 it basically


i have look here, http://openports.se/databases/openldap, it say the flavour is 
bdb

Flavors:
bdb enable the bdb and hdb backends

so i can use ldap with bdb backends in OpenBSD 4.4 eh?

thx



Re: OpenLDAP

2008-09-08 Thread Rogier Krieger
On Mon, Sep 8, 2008 at 09:58, my mail [EMAIL PROTECTED] wrote:
 so i can use ldap with bdb backends in OpenBSD 4.4 eh?

Take a look at the port's Makefile [1] which apparently will be in
4.4-release. Excerpt below to save you the searching. If you intended
your remark as sarcasm, it's more likely to pollute the archives
rather than help.

.if ${FLAVOR:L:Mbdb}
BROKEN= OpenLDAP 2.3 is incompatible with Berkeley DB 4.6


If you want to use bdb as a backend, you'll likely have to compile
OpenLDAP manually (see Philip Guenther's earlier post [2] in this
thread, for instance). For extra credit: provide diffs to update the
port to deal with 2.4 :)

Cheers,

Rogier


References:
1. OpenBSD CVSweb - ports/databases/openldap/Makefile (r1.85)
http://www.openbsd.org/cgi-bin/cvsweb/ports/databases/openldap/Makefile?rev=1.85content-type=text/x-cvsweb-markup
2. MARC.info - OpenBSD-misc, 'Re: OpenLDAP' by Philip Guenther (2008/09/03)
http://marc.info/?l=openbsd-miscm=122046507630763w=2

-- 
If you don't know where you're going, any road will get you there.



Re: OpenLDAP

2008-09-03 Thread Henning Brauer
* John Nietzsche [EMAIL PROTECTED] [2008-09-03 13:22]:
 is there any chance the next openbsd release holds an unbroken OpenLDAP?

I'd say the chance of ever having an unbroken OpenLDAP release on any
OS is pretty damn low.

that said, openldap works as well on openbsd as it does on other oses.
the only thing that does not work in 4.4 is the bdb backend. but then,
the bdb backend has almost ever been terrible, so you are better off
using another one anyway. i recommend ldbm. you will have to use
slapcat and slapadd to convert your database.

-- 
Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED]
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg  Amsterdam



Re: OpenLDAP

2008-09-03 Thread Nick Guenther
On Wed, Sep 3, 2008 at 7:15 AM, John Nietzsche [EMAIL PROTECTED] wrote:
 Hi,

 is there any chance the next openbsd release holds an unbroken OpenLDAP?

 Thanks in advance.

And how is it broken exactly? I was able to install it just a month
ago and I didn't see anything obviously wrong.

-Nick
p.s. passive aggression gets you nowhere here. I learned that the hard way.



Re: OpenLDAP

2008-09-03 Thread John Nietzsche
I am in need for performance. Is replacing bdb with ldbm a good ideia?

Thanks once more.

On Wed, Sep 3, 2008 at 10:28 AM, Henning Brauer [EMAIL PROTECTED] wrote:
 * John Nietzsche [EMAIL PROTECTED] [2008-09-03 13:22]:
 is there any chance the next openbsd release holds an unbroken OpenLDAP?

 I'd say the chance of ever having an unbroken OpenLDAP release on any
 OS is pretty damn low.

 that said, openldap works as well on openbsd as it does on other oses.
 the only thing that does not work in 4.4 is the bdb backend. but then,
 the bdb backend has almost ever been terrible, so you are better off
 using another one anyway. i recommend ldbm. you will have to use
 slapcat and slapadd to convert your database.

 --
 Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED]
 BS Web Services, http://bsws.de
 Full-Service ISP - Secure Hosting, Mail and DNS Services
 Dedicated Servers, Rootservers, Application Hosting - Hamburg  Amsterdam



Re: OpenLDAP

2008-09-03 Thread bofh
On Wed, Sep 3, 2008 at 9:28 AM, Nick Guenther [EMAIL PROTECTED] wrote:

 On Wed, Sep 3, 2008 at 7:15 AM, John Nietzsche [EMAIL PROTECTED]
 wrote:
  Hi,
 
  is there any chance the next openbsd release holds an unbroken OpenLDAP?


Since openbsd doesn't include ldap, I would guess that any (future) ldap
software that openbsd may write would be unbroken.

 Thanks in advance.

p.s. passive aggression gets you nowhere here. I learned that the hard way.


But it's so much fun to watch on the side! :)



-- 
http://www.glumbert.com/media/shift
http://www.youtube.com/watch?v=tGvHNNOLnCk
This officer's men seem to follow him merely out of idle curiosity. --
Sandhurst officer cadet evaluation.
Securing an environment of Windows platforms from abuse - external or
internal - is akin to trying to install sprinklers in a fireworks factory
where smoking on the job is permitted. -- Gene Spafford
learn french: http://www.youtube.com/watch?v=j1G-3laJJP0feature=related



Re: OpenLDAP

2008-09-03 Thread Ted Unangst
On 9/3/08, John Nietzsche [EMAIL PROTECTED] wrote:
 I am in need for performance. Is replacing bdb with ldbm a good ideia?

Is working faster than not working?



Re: OpenLDAP

2008-09-03 Thread Dorian Büttner

John Nietzsche schrieb:

I am in need for performance. Is replacing bdb with ldbm a good ideia?

Thanks once more.

On Wed, Sep 3, 2008 at 10:28 AM, Henning Brauer [EMAIL PROTECTED] wrote:
  

* John Nietzsche [EMAIL PROTECTED] [2008-09-03 13:22]:


is there any chance the next openbsd release holds an unbroken OpenLDAP?
  

I'd say the chance of ever having an unbroken OpenLDAP release on any
OS is pretty damn low.

that said, openldap works as well on openbsd as it does on other oses.
the only thing that does not work in 4.4 is the bdb backend. but then,
the bdb backend has almost ever been terrible, so you are better off
using another one anyway. i recommend ldbm. you will have to use
slapcat and slapadd to convert your database.

--
Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED]
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg  Amsterdam

slapd.conf(5) has a section dedicated to backends - actually, regarding 
bdb and ldbm, the opposite is true but you may want to check the other 
options like sql (however, I don't know if that info is appropriate).
For example, man slapd-sql. Or something like 'apropos slapd' will also 
yield some hints.




Re: OpenLDAP

2008-09-03 Thread Philip Guenther
On Wed, Sep 3, 2008 at 4:15 AM, John Nietzsche [EMAIL PROTECTED] wrote:
 is there any chance the next openbsd release holds an unbroken OpenLDAP?

I presume you're referring to the port/packages version.  The answer
depends on whose definition of unbroken you prefer.

The last word I heard from the OpenLDAP maintainers was that the ldbm
backend was considered unsuitable for (their definition of) production
use.  Indeed, it's not supported in OpenLDAP 2.4.  It's not robust if
slapd or the machine crash at an inopportune time during a database
change and has performance issues during writes: there's just one big
reader/writer lock for the database, so any write blocks all readers.
As a result, using it in a deployment where writes frequently occur
seems unwise.  The OpenLDAP people will certainly give you little
sympathy if/when a problem occurs there.  For a read-only, or
write-rarely situation, it would seem to be okay, in which case the
port/package should serve you.

If you're building a write-often setup, then you would seem to need
the bdb or hdb backend.  For that, the current port/package will not
serve you.  I'm not a ports maintainer, but upgrading the port from
OpenLDAP 2.3.x to 2.4.x in time for 4.4 seems extremely unlikely.  For
all I know, the deadline for such a change may have passed months ago.
 So, if you need the bdb backend, you would need to build OpenLDAP
2.4.x yourself.  In my experience, of compiling OpenLDAP, it basically
works, but keep your eyes open: support for what you build will need
to be more dependent on yourself and the openldap mailing lists and
less on the openbsd lists (and not at all on the ports list, of
course, though they would probably be interested in your experiences).
 OpenLDAP has a test suite: run it and pay attention to the results.
Subscribe to the OpenLDAP lists and pay attention to discussions of
issues that may affect your setup.

Someone else mentioned the sql backend.  The OpenLDAP people
apparently consider it only appropriate for gatewaying from existing
SQL databases where the SQL interface is the primary use, and not as a
primary backend for storing your main LDAP data, as SQL is a poor
match for storing LDAP data.  You should consult the OpenLDAP lists
for further details if seriously considering that route.


Note that this situation, where the packages that are provided by or
associated with the OS have a limited applicability, is not limited to
OpenBSD.  The OpenLDAP people have few good words to say about the
RedHat openldap server package; they often recommend that people
experiencing problems with them to ditch that rpm and install the rpm
created by one of the OpenLDAP maintainers.


Philip Guenther



Re: OpenLDAP and BDB: i am desperated

2008-09-02 Thread Stuart Henderson
On 2008-09-02, John Nietzsche [EMAIL PROTECTED] wrote:
 i have just installed OpenBSD and i would like to use it (the server
 with OpenBSD) as a directory services. When i try to install openldap
 from ports i am prevented with the following message:

===  openldap-client-2.3.39 is marked as broken: OpenLDAP 2.3 is
 incompatible with Berkeley DB 4.6.

 I have installed all possible combinations fo bdb version, one each
 time and both version at the same time.

 What's my error ?

Until OpenLDAP is updated to a 2.4 version, you need to use a
non-bdb flavor of OpenLDAP.



Re: openldap-server on 4.3? (newbie)

2008-08-14 Thread Stuart Henderson
On 2008-08-14, Ross Tucker [EMAIL PROTECTED] wrote:
 I am trying to set my new OpenBSD 4.3 installation up as a PDC for a
 windows network. I am following directions from
 http://www.kernel-panic.it/openbsd/pdc/pdc2.html but I cannot get
 openldap-server to build from the ports, because the bdb flavor is
 marked broken in 4.3! In the tutorial, he just continues on without
 explaining what to do. What ought I do to get openldap-server to
 build?

Don't use the bdb flavor. Just set PKG_PATH appropriately as per
FAQ15.2.2 and pkg_add openldap-server for the normal LDBM version.
I don't see much point for what you want in building your own package
from the port, you might as well use the ones that are already built.

Berkeley(/Sleepycat/Oracle) DB broke the API mid-release-cycle (4.6.3
or something, earlier 4.6.x were OK), OpenLDAP added support for the new
version to 2.4 _only_, not 2.3 (which was until recently the release
they deemed stable).



Re: slapd hangs, was: Re: OpenLDAP and Berkeley DB 4.6

2008-08-06 Thread my mail
--- On Tue, 8/5/08, Marc Balmer [EMAIL PROTECTED] wrote:

 From: Marc Balmer [EMAIL PROTECTED]
 Subject: Re: slapd hangs, was: Re: OpenLDAP and Berkeley DB 4.6
 To: Toni Mueller [EMAIL PROTECTED]
 Cc: misc@openbsd.org

 ports@, and CC the maintainer (in this case, me).
 
  
  
  TIA!
  


openldap + dbd is broken isn't right?
i have read in this article [1], he said the bdb flavor, providing support for 
the bdb and hdb backends, is marked as broken on OpenBSD 4.3




[1]http://www.kernel-panic.it/openbsd/pdc/pdc2.html#pdc-2.2



slapd hangs, was: Re: OpenLDAP and Berkeley DB 4.6

2008-08-05 Thread Toni Mueller
Hi,

On Sun, 09.03.2008 at 16:31:27 +, Stuart Henderson [EMAIL PROTECTED] 
wrote:
 You have several recommended options:
 
 - dump your database, uninstall, install the unFLAVORed version
 and restore your database.

I tried that, but now run into the problem that now, slapd can't be
stopped. Maybe it has something to do that the server in question runs
as a syncrepl client together with TLS (master is
openldap-server-2.3.33p1-bdb on 4.2). In any case, the only way to get
slapd down seems to be to kill -9 it, which is _very_ugly_ for other
reasons. My other slapd instances don't have such a problem.

At the end of the log, it says

--
daemon: shutdown requested and initiated.
slapd shutdown: waiting for 2 threads to terminate
--

which points to a handful of tickets in the OpenLDAP tracker.

It would be very nice if you could suggest something with less impact
than backporting 2.3.43 from -current.

In any case, I'd like to know whether you'd prefer such problems to be
reported on misc@, ports@ (I didn't do that to keep clutter out while
approaching freeze), or upstream's tracker directly.


TIA!


Kind regards,
--Toni++



Re: slapd hangs, was: Re: OpenLDAP and Berkeley DB 4.6

2008-08-05 Thread Marc Balmer
* Toni Mueller wrote:
 Hi,
 
 On Sun, 09.03.2008 at 16:31:27 +, Stuart Henderson [EMAIL PROTECTED] 
 wrote:
  You have several recommended options:
  
  - dump your database, uninstall, install the unFLAVORed version
  and restore your database.
 
 I tried that, but now run into the problem that now, slapd can't be
 stopped. Maybe it has something to do that the server in question runs
 as a syncrepl client together with TLS (master is
 openldap-server-2.3.33p1-bdb on 4.2). In any case, the only way to get
 slapd down seems to be to kill -9 it, which is _very_ugly_ for other
 reasons. My other slapd instances don't have such a problem.
 
 At the end of the log, it says
 
 --
 daemon: shutdown requested and initiated.
 slapd shutdown: waiting for 2 threads to terminate
 --
 
 which points to a handful of tickets in the OpenLDAP tracker.
 
 It would be very nice if you could suggest something with less impact
 than backporting 2.3.43 from -current.
 
 In any case, I'd like to know whether you'd prefer such problems to be
 reported on misc@, ports@ (I didn't do that to keep clutter out while
 approaching freeze), or upstream's tracker directly.

ports@, and CC the maintainer (in this case, me).

 
 
 TIA!
 
 
 Kind regards,
 --Toni++



Re: OpenLDAP and Berkeley DB 4.6

2008-03-10 Thread Quanah Gibson-Mount
--On Sunday, March 09, 2008 11:13 PM +0800 Dongsheng Song 
[EMAIL PROTECTED] wrote:



Since OpenLDAP 2.3 is incompatible[1] with Berkeley DB 4.6,
so I must stick to BDB 4.5 or upgrade to OpenLDAP 2.4 ?


Yes.

--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration



Re: OpenLDAP and Berkeley DB 4.6

2008-03-09 Thread Stuart Henderson
On 2008-03-09, Dongsheng Song [EMAIL PROTECTED] wrote:
 Since OpenLDAP 2.3 is incompatible[1] with Berkeley DB 4.6,

it is incompatible with DB 4.6.3 and up (where they quietly
broke the API). 4.6.2 and below are ok.

 so I must stick to BDB 4.5 or upgrade to OpenLDAP 2.4 ?

You have several recommended options:

- dump your database, uninstall, install the unFLAVORed version
and restore your database.

- stick with what you are already using and wait for OpenLDAP 2.4
to become stable and get added to ports. dump/upgrade/restore.

another which is less-recommended:

- dump your database, uninstall, build your own OpenLDAP 2.4
(it is not in ports yet), restore your database. moving to a 2.4
version when it hits ports will involve some extra work removing
the installed files which will conflict.

and another which seems like a really bad idea to me:

- dump your database, uninstall DB/OpenLDAP, build your own DB
=4.6.2 and OpenLDAP 2.3, restore. I think this is likely to cause
all sorts of confusion with anything else using DB on the box.

 [1] http://www.openbsd.org/cgi-bin/cvsweb/ports/databases/openldap/Makefile

we discussed things and took the path which means pkg_add updates
don't break an existing working -bdb installation.



Re: openldap with dbv4 crash

2008-01-02 Thread Liviu Daia
On 1 January 2008, Daniel [EMAIL PROTECTED] wrote:
 Vijay Sankar mrta:
[...]
  there's support in 2.4 but iirc it's not a simple thing to
  backport.
 Why should we backport the db4.6 support? We just need to use 2.4.
[...]

(1) Historically, upgrading existing OpenLDAP databases to new formats
has always been a PITA;

(2) The 2.4 branch is still unstable; historically, previous branches
haven't become (somewhat) usable until about minor version 20; and
guess what: the new branch is not exactly less complex than the
older ones;

(3) Historically, none of the new brances have been backward compatible;
many applications don't support 2.6 yet.

Regards,

Liviu Daia

-- 
Dr. Liviu Daia  http://www.imar.ro/~daia



Re: openldap with dbv4 crash

2008-01-02 Thread Vijay Sankar
On December 31, 2007 06:59:06 am Vijay Sankar wrote:
 On December 30, 2007 08:03:09 pm Stuart Henderson wrote:
 On December 29, 2007 11:23:19 am Daniel wrote:
  Hi (again, sorry, now with Subject)!
 
  Anyone experiencing or experienced segfaults with openldap using
  the bdb backed? I'm using -current ports tree, and built the
  openldap-{client,server}, dbv4 and cyrus-sasl2 packages from
  there.
 
  openldap 2.3 doesn't support newer db 4.6 versions (should fail the
  regression tests).
 
  there's support in 2.4 but iirc it's not a simple thing to backport.

 Thanks very much for this information. Not sure how to help, but I am not
 seeing any seg faults so far. If there is something helpful for me to do,
 please advise. It is not clear from Daniel's message as to whether there is
 any specific thing that causes the seg fault or whether slapd just simply
 does not start.

 To verify I restarted slapd with a -d -1 and here is some of the output.

 /usr/local/libexec/slapd -d -1
 @(#) $OpenLDAP: slapd 2.3.33 (Dec 12 2007 04:19:57) $

 @i386new.ports.openbsd.org:/usr/obj/i386/openldap-2.3.33-bdb/build-i386-bdb
/servers/slapd daemon_init: null
 daemon_init: listen on ldap:///
 daemon_init: 1 listeners to open...
 ldap_url_parse_ext(ldap:///)
 daemon: listener initialized ldap:///
 daemon_init: 2 listeners opened
 slapd init: initiated server.
 slap_sasl_init: initialized!
 bdb_back_initialize: initialize BDB backend
 bdb_back_initialize: Berkeley DB 4.6.21: (September 27, 2007)
 hdb_back_initialize: initialize HDB backend
 hdb_back_initialize: Berkeley DB 4.6.21: (September 27, 2007)
 perl backend open
 reading config file /etc/openldap/slapd.conf
 line 5 (include /etc/openldap/schema/core.schema)
 reading config file /etc/openldap/schema/core.schema
 .
 .
 .
 ..
 line 87 (database   bdb)
 bdb_db_init: Initializing BDB database
 line 88 (suffix dc=sankars,dc=local)

  dnPrettyNormal: dc=sankars,dc=local

 = ldap_bv2dn(dc=sankars,dc=local,0)
 = ldap_bv2dn(dc=sankars,dc=local)=0
 = ldap_dn2bv(272)
 = ldap_dn2bv(dc=sankars,dc=local)=0
 = ldap_dn2bv(272)
 = ldap_dn2bv(dc=sankars,dc=local)=0
  dnPrettyNormal: dc=sankars,dc=local, dc=sankars,dc=local
 line 89 (rootdn cn=ldapadmin,dc=sankars,dc=local)

  dnPrettyNormal: cn=ldapadmin,dc=sankars,dc=local

 = ldap_bv2dn(cn=ldapadmin,dc=sankars,dc=local,0)
 = ldap_bv2dn(cn=ldapadmin,dc=sankars,dc=local)=0
 = ldap_dn2bv(272)
 = ldap_dn2bv(cn=ldapadmin,dc=sankars,dc=local)=0
 = ldap_dn2bv(272)
 = ldap_dn2bv(cn=ldapadmin,dc=sankars,dc=local)=0
  dnPrettyNormal: cn=ldapadmin,dc=sankars,dc=local,
 cn=ldapadmin,dc=sankars,dc=local
 line 93 (rootpw ***)
 line 97 (directory  /var/sankars.local)
 line 104 (access to attrs=userPasswordby
 dn=cn=sambaadmin,dc=sankars,dc=local readby
 dn=cn=syncuser,dc=sankars,dc=local writeby * auth)

  dnNormalize: cn=sambaadmin,dc=sankars,dc=local

 = ldap_bv2dn(cn=sambaadmin,dc=sankars,dc=local,0)
 = ldap_bv2dn(cn=sambaadmin,dc=sankars,dc=local)=0
 = ldap_dn2bv(272)
 = ldap_dn2bv(cn=sambaadmin,dc=sankars,dc=local)=0

 Normally I use packages. But some time ago, I was able to use syncrepl with
 OpenLDAP 2.3.33 and used the following ./configure command to build from
 source.

 env CPPFLAGS=-I/usr/local/include/db4 -I/usr/local/include/sasl \
 LDFLAGS=-L/usr/local/lib/db4 -L/usr/local/share/libtool/libltdl
 -L/usr/local/lib/sasl2 -L/usr/local/lib\ ./configure \
 --prefix=/usr/local \
 --enable-slapd \
 --enable-cleartext \
 --enable-crypt \
 --enable-rewrite \
 --enable-wrapper \
 --with-cyrus-sasl=yes \
 --enable-spasswd \
 --enable-dnssrv \
 --enable-ldap \
 --enable-ldbm \
 --enable-bdb \
 --enable-meta \
 --enable-null \
 --enable-passwd \
 --disable-ipv6 \
 --disable-shell \
 --enable-slurpd \
 --enable-overlays=mod \
 --with-tls \
 --disable-sql

 Is this correct? Should I make any changes? Please let me know.

 Thanks very much,

 Vijay

I hate to waste developer and port maintainer time, so apologize in advance 
for this long message. Anyways, if there is anything useful I can do to help, 
please let me know.

I am puzzled about why I don't seem to have any problems with OpenLDAP 
2.3.33p2 on

kern.version=OpenBSD 4.2-current (GENERIC.MP) #0: Thu Dec 27 13:53:57 CST 2007
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC.MP

with 

db-4.6.21   Berkeley DB package, revision 4
openldap-server-2.3.33p2-bdbOpen source LDAP software (server)

The OP said that his ./configure command was almost the same as what I did 
above but did not bother to say what the difference was. I followed the 
settings that Marc Balmer had in ports and so I wonder whether that is why I 
haven't seen any problems yet.

Usually, I have problems even when no one else has any issues so I am 
surprised to not have had a crash or any problems at all when I should have 
had seg faults! I am using all the samba-related schemas PLUS 

Re: openldap with dbv4 crash

2008-01-02 Thread Daniel
On Wed, 2 Jan 2008 11:13:26 -0600
Vijay Sankar [EMAIL PROTECTED] wrote:

 On December 31, 2007 06:59:06 am Vijay Sankar wrote:
 
  env CPPFLAGS=-I/usr/local/include/db4 -I/usr/local/include/sasl \
  LDFLAGS=-L/usr/local/lib/db4 -L/usr/local/share/libtool/libltdl
  -L/usr/local/lib/sasl2 -L/usr/local/lib\ ./configure \
  --prefix=/usr/local \
  --enable-slapd \
  --enable-cleartext \
  --enable-crypt \
  --enable-rewrite \
  --enable-wrapper \
  --with-cyrus-sasl=yes \
  --enable-spasswd \
  --enable-dnssrv \
  --enable-ldap \
  --enable-ldbm \
  --enable-bdb \
  --enable-meta \
  --enable-null \
  --enable-passwd \
  --disable-ipv6 \
  --disable-shell \
  --enable-slurpd \
  --enable-overlays=mod \
  --with-tls \
  --disable-sql
 
[...]
 
 The OP said that his ./configure command was almost the same as what
 I did above but did not bother to say what the difference was. I
 followed the settings that Marc Balmer had in ports and so I wonder
 whether that is why I haven't seen any problems yet.
Okay then:

./configure \
--prefix=/usr/local --sysconfdir=/etc --localstatedir=/var \
--enable-shared --disable-static \
--enable-rewrite --without-cyrus-sasl --disable-ipv6 \
--enable-ldap --with-tls=openssl

Basically no backends were compiled in except bdb,hdb,monitor,relay and
ldap.
But really, I don't think these configure options are relevant,
because the crash happens with the db-4.6 libraries (according to gdb).

 
 Usually, I have problems even when no one else has any issues so I am 
 surprised to not have had a crash or any problems at all when I
 should have had seg faults! I am using all the samba-related schemas
 PLUS slurpd and I am still not seeing segfaults with OpenLDAP
 2.3.33p2 and DB 4.6.  I am not new to OpenBSD (have used it since 2.8
 and have the CD's to prove it :) but don't know whether I have
 somehow made a mistake in compiling userland or whether there is some
 other issue involved that is making use of older versions of DB4.
Can you try executing ldd(1) on slapd. Is it linked against the 4.6 db
libraries?


Daniel



Re: openldap with dbv4 crash

2008-01-01 Thread Daniel

Vijay Sankar mrta:

On December 30, 2007 08:03:09 pm Stuart Henderson wrote:

On December 29, 2007 11:23:19 am Daniel wrote:

Hi (again, sorry, now with Subject)!

Anyone experiencing or experienced segfaults with openldap using
the bdb backed? I'm using -current ports tree, and built the
openldap-{client,server}, dbv4 and cyrus-sasl2 packages from there.

openldap 2.3 doesn't support newer db 4.6 versions (should fail the
regression tests).

Yes, indeed, looking at this commit:
http://www.openldap.org/devel/cvsweb.cgi/configure.diff?r1=1.598.2.40r2=1.598.2.41hideattic=1sortbydate=0



there's support in 2.4 but iirc it's not a simple thing to backport.

Why should we backport the db4.6 support? We just need to use 2.4.



Thanks very much for this information. Not sure how to help, but I am not 
seeing any seg faults so far. If there is something helpful for me to do, 
please advise. It is not clear from Daniel's message as to whether there is 
any specific thing that causes the seg fault or whether slapd just simply 
does not start. 

Below I will write down how to reproduce the crash on an i386 machine,
openldap compiled from ports, with FLAVOR=bdb.

Start with a fresh database directory, use the stock DB_CONFIG options,
and of course the bdb backend. Add just the root dn, with the
domaincomponent attributes ie. dn: dc=domain,dc=com, and a rootdn
account. Now test it with a simple ldapsearch command (eg. filter
(objectclass=*), it succeeds. Exit from slapd, then restart it, with the
same slapd.conf as before. Now do that simple ldapsearch again, and then
slapd will segfault. Doing a not so informative gdb with slapd, it shows
that it crashes with the libdb libraries. Changing the database backend
to ldbm solves the problem, what also supports this theory.
In the above example, it doesn't matter if one use TLS or not.

With openldap-2.4, one can not use the ldbm backend anymore, but there
is no need to, because the bdb backend is working with it.

[...]

Normally I use packages. But some time ago, I was able to use syncrepl with 
OpenLDAP 2.3.33 and used the following ./configure command to build from 
source.


env CPPFLAGS=-I/usr/local/include/db4 -I/usr/local/include/sasl \ 
LDFLAGS=-L/usr/local/lib/db4 -L/usr/local/share/libtool/libltdl -L/usr/local/lib/sasl2 -L/usr/local/lib\

./configure \
--prefix=/usr/local \
--enable-slapd \
--enable-cleartext \
--enable-crypt \
--enable-rewrite \ 
--enable-wrapper \ 
--with-cyrus-sasl=yes \

--enable-spasswd \
--enable-dnssrv \
--enable-ldap \
--enable-ldbm \
--enable-bdb \
--enable-meta \
--enable-null \
--enable-passwd \
--disable-ipv6 \
--disable-shell \
--enable-slurpd \
--enable-overlays=mod \
--with-tls \
--disable-sql

Is this correct? Should I make any changes? Please let me know.

Same here, almost.



Thanks very much,

Vijay




Re: openldap with dbv4 crash

2008-01-01 Thread Stuart Henderson
On 2008/01/01 13:27, Daniel wrote:
 there's support in 2.4 but iirc it's not a simple thing to backport.
 Why should we backport the db4.6 support? We just need to use 2.4.

Well, you mentioned one reason why not just upgrade:

 With openldap-2.4, one can not use the ldbm backend anymore, but there
 is no need to, because the bdb backend is working with it.

I think some people won't be keen on switching backend, at least
without a bunch of testing on multiple arch, due to past stability
problems (see the misc@ archives).



Re: openldap with dbv4 crash

2007-12-31 Thread Vijay Sankar
On December 30, 2007 08:03:09 pm Stuart Henderson wrote:
On December 29, 2007 11:23:19 am Daniel wrote:
 Hi (again, sorry, now with Subject)!

 Anyone experiencing or experienced segfaults with openldap using
 the bdb backed? I'm using -current ports tree, and built the
 openldap-{client,server}, dbv4 and cyrus-sasl2 packages from there.

 openldap 2.3 doesn't support newer db 4.6 versions (should fail the
 regression tests).

 there's support in 2.4 but iirc it's not a simple thing to backport.

Thanks very much for this information. Not sure how to help, but I am not 
seeing any seg faults so far. If there is something helpful for me to do, 
please advise. It is not clear from Daniel's message as to whether there is 
any specific thing that causes the seg fault or whether slapd just simply 
does not start. 

To verify I restarted slapd with a -d -1 and here is some of the output.

/usr/local/libexec/slapd -d -1
@(#) $OpenLDAP: slapd 2.3.33 (Dec 12 2007 04:19:57) $

@i386new.ports.openbsd.org:/usr/obj/i386/openldap-2.3.33-bdb/build-i386-bdb/servers/slapd
daemon_init: null
daemon_init: listen on ldap:///
daemon_init: 1 listeners to open...
ldap_url_parse_ext(ldap:///)
daemon: listener initialized ldap:///
daemon_init: 2 listeners opened
slapd init: initiated server.
slap_sasl_init: initialized!
bdb_back_initialize: initialize BDB backend
bdb_back_initialize: Berkeley DB 4.6.21: (September 27, 2007)
hdb_back_initialize: initialize HDB backend
hdb_back_initialize: Berkeley DB 4.6.21: (September 27, 2007)
perl backend open
reading config file /etc/openldap/slapd.conf
line 5 (include /etc/openldap/schema/core.schema)
reading config file /etc/openldap/schema/core.schema
.
.
.
..
line 87 (database   bdb)
bdb_db_init: Initializing BDB database
line 88 (suffix dc=sankars,dc=local)
 dnPrettyNormal: dc=sankars,dc=local
= ldap_bv2dn(dc=sankars,dc=local,0)
= ldap_bv2dn(dc=sankars,dc=local)=0
= ldap_dn2bv(272)
= ldap_dn2bv(dc=sankars,dc=local)=0
= ldap_dn2bv(272)
= ldap_dn2bv(dc=sankars,dc=local)=0
 dnPrettyNormal: dc=sankars,dc=local, dc=sankars,dc=local
line 89 (rootdn cn=ldapadmin,dc=sankars,dc=local)
 dnPrettyNormal: cn=ldapadmin,dc=sankars,dc=local
= ldap_bv2dn(cn=ldapadmin,dc=sankars,dc=local,0)
= ldap_bv2dn(cn=ldapadmin,dc=sankars,dc=local)=0
= ldap_dn2bv(272)
= ldap_dn2bv(cn=ldapadmin,dc=sankars,dc=local)=0
= ldap_dn2bv(272)
= ldap_dn2bv(cn=ldapadmin,dc=sankars,dc=local)=0
 dnPrettyNormal: cn=ldapadmin,dc=sankars,dc=local, 
cn=ldapadmin,dc=sankars,dc=local
line 93 (rootpw ***)
line 97 (directory  /var/sankars.local)
line 104 (access to attrs=userPasswordby 
dn=cn=sambaadmin,dc=sankars,dc=local readby 
dn=cn=syncuser,dc=sankars,dc=local writeby * auth)
 dnNormalize: cn=sambaadmin,dc=sankars,dc=local
= ldap_bv2dn(cn=sambaadmin,dc=sankars,dc=local,0)
= ldap_bv2dn(cn=sambaadmin,dc=sankars,dc=local)=0
= ldap_dn2bv(272)
= ldap_dn2bv(cn=sambaadmin,dc=sankars,dc=local)=0

Normally I use packages. But some time ago, I was able to use syncrepl with 
OpenLDAP 2.3.33 and used the following ./configure command to build from 
source.

env CPPFLAGS=-I/usr/local/include/db4 -I/usr/local/include/sasl \ 
LDFLAGS=-L/usr/local/lib/db4 -L/usr/local/share/libtool/libltdl 
-L/usr/local/lib/sasl2 -L/usr/local/lib\
./configure \
--prefix=/usr/local \
--enable-slapd \
--enable-cleartext \
--enable-crypt \
--enable-rewrite \ 
--enable-wrapper \ 
--with-cyrus-sasl=yes \
--enable-spasswd \
--enable-dnssrv \
--enable-ldap \
--enable-ldbm \
--enable-bdb \
--enable-meta \
--enable-null \
--enable-passwd \
--disable-ipv6 \
--disable-shell \
--enable-slurpd \
--enable-overlays=mod \
--with-tls \
--disable-sql

Is this correct? Should I make any changes? Please let me know.

Thanks very much,

Vijay

-- 
Vijay Sankar, M.Eng., P.Eng.
President  CEO
ForeTell Technologies Limited
59 Flamingo Avenue, Winnipeg, MB Canada R3J 0X6
Phone: +1 204 885 9535, E-Mail: [EMAIL PROTECTED]



Re: openldap with dbv4 crash

2007-12-31 Thread Vijay Sankar

Quoting Vijay Sankar [EMAIL PROTECTED]:


On December 30, 2007 08:03:09 pm Stuart Henderson wrote:

   On December 29, 2007 11:23:19 am Daniel wrote:
Hi (again, sorry, now with Subject)!
   
Anyone experiencing or experienced segfaults with openldap using
the bdb backed? I'm using -current ports tree, and built the
openldap-{client,server}, dbv4 and cyrus-sasl2 packages from

there.


openldap 2.3 doesn't support newer db 4.6 versions (should fail the
regression tests).

there's support in 2.4 but iirc it's not a simple thing to backport.


Thanks very much for this information. Not sure how to help, but I am not
seeing any seg faults so far. If there is something helpful for me to do,
please advise. It is not clear from Daniel's message as to whether there is
any specific thing that causes the seg fault or whether slapd just simply
does not start.

To verify I restarted slapd with a -d -1 and here is some of the output.

/usr/local/libexec/slapd -d -1
@(#) $OpenLDAP: slapd 2.3.33 (Dec 12 2007 04:19:57) $



@i386new.ports.openbsd.org:/usr/obj/i386/openldap-2.3.33-bdb/build-i386-bdb/s
ervers/slapd

daemon_init: null
daemon_init: listen on ldap:///
daemon_init: 1 listeners to open...
ldap_url_parse_ext(ldap:///)
daemon: listener initialized ldap:///
daemon_init: 2 listeners opened
slapd init: initiated server.
slap_sasl_init: initialized!
bdb_back_initialize: initialize BDB backend
bdb_back_initialize: Berkeley DB 4.6.21: (September 27, 2007)
hdb_back_initialize: initialize HDB backend
hdb_back_initialize: Berkeley DB 4.6.21: (September 27, 2007)
perl backend open
reading config file /etc/openldap/slapd.conf
line 5 (include /etc/openldap/schema/core.schema)
reading config file /etc/openldap/schema/core.schema
.
.
.
..
line 87 (database   bdb)
bdb_db_init: Initializing BDB database
line 88 (suffix dc=sankars,dc=local)

dnPrettyNormal: dc=sankars,dc=local

= ldap_bv2dn(dc=sankars,dc=local,0)
= ldap_bv2dn(dc=sankars,dc=local)=0
= ldap_dn2bv(272)
= ldap_dn2bv(dc=sankars,dc=local)=0
= ldap_dn2bv(272)
= ldap_dn2bv(dc=sankars,dc=local)=0
 dnPrettyNormal: dc=sankars,dc=local, dc=sankars,dc=local
line 89 (rootdn cn=ldapadmin,dc=sankars,dc=local)

dnPrettyNormal: cn=ldapadmin,dc=sankars,dc=local

= ldap_bv2dn(cn=ldapadmin,dc=sankars,dc=local,0)
= ldap_bv2dn(cn=ldapadmin,dc=sankars,dc=local)=0
= ldap_dn2bv(272)
= ldap_dn2bv(cn=ldapadmin,dc=sankars,dc=local)=0
= ldap_dn2bv(272)
= ldap_dn2bv(cn=ldapadmin,dc=sankars,dc=local)=0
 dnPrettyNormal: cn=ldapadmin,dc=sankars,dc=local,
cn=ldapadmin,dc=sankars,dc=local
line 93 (rootpw ***)
line 97 (directory  /var/sankars.local)
line 104 (access to attrs=userPasswordby
dn=cn=sambaadmin,dc=sankars,dc=local readby
dn=cn=syncuser,dc=sankars,dc=local writeby * auth)

dnNormalize: cn=sambaadmin,dc=sankars,dc=local

= ldap_bv2dn(cn=sambaadmin,dc=sankars,dc=local,0)
= ldap_bv2dn(cn=sambaadmin,dc=sankars,dc=local)=0
= ldap_dn2bv(272)
= ldap_dn2bv(cn=sambaadmin,dc=sankars,dc=local)=0

Normally I use packages. But some time ago, I was able to use syncrepl with
OpenLDAP 2.3.33 and used the following ./configure command to build from
source.

env CPPFLAGS=-I/usr/local/include/db4 -I/usr/local/include/sasl \
LDFLAGS=-L/usr/local/lib/db4 -L/usr/local/share/libtool/libltdl
-L/usr/local/lib/sasl2 -L/usr/local/lib\
./configure \
--prefix=/usr/local \
--enable-slapd \
--enable-cleartext \
--enable-crypt \
--enable-rewrite \
--enable-wrapper \
--with-cyrus-sasl=yes \
--enable-spasswd \
--enable-dnssrv \
--enable-ldap \
--enable-ldbm \
--enable-bdb \
--enable-meta \
--enable-null \
--enable-passwd \
--disable-ipv6 \
--disable-shell \
--enable-slurpd \
--enable-overlays=mod \
--with-tls \
--disable-sql

Is this correct? Should I make any changes? Please let me know.

Thanks very much,

Vijay


I also wanted to add the following to my previous message from slapd
debug . . .
.
.
.
1.2.36.79672281.1.13.3 (rdnMatch): 2.5.13.1
(distinguishedNameMatch): matchingRuleUse: ( 2.5.13.1 NAME
'distinguishedNameMatch' APPLIES ( creatorsName $ modifiersName $
subschemaSubentry $ namingContexts $ aliasedObjectName $
distinguishedName $ seeAlso $ olcDefaultSearchBase $ olcRootDN $
olcSchemaDN $ olcSuffix $ olcUpdateDN $ olcDbACLAuthcDn $
olcDbIDAssertAuthcDn $ member $ owner $ roleOccupant $ manager $
documentAuthor $ secretary $ associatedName $ dITRedirect ) )
2.5.13.0 (objectIdentifierMatch): matchingRuleUse: ( 2.5.13.0
NAME 'objectIdentifierMatch' APPLIES ( supportedControl $
supportedExtension $ supportedFeatures $ supportedApplicationContext ) )
slapd startup: initiated.
backend_startup_one: starting cn=config
config_back_db_open
config_build_entry: cn=config
config_build_entry: cn=include{0}
config_build_entry: cn=include{1}
config_build_entry: cn=include{2}
config_build_entry: cn=include{3}
config_build_entry: cn=include{4}
config_build_entry: cn=schema
config_build_entry: cn={0}core
config_build_entry: cn={1}cosine

Re: openldap with dbv4 crash

2007-12-30 Thread Daniel
On Sat, 29 Dec 2007 15:49:20 -0600
Vijay Sankar [EMAIL PROTECTED] wrote:

 On December 29, 2007 02:15:15 pm Daniel wrote:
  On Sat, 29 Dec 2007 13:41:06 -0600
 
  Vijay Sankar [EMAIL PROTECTED] wrote:
   On December 29, 2007 11:23:19 am Daniel wrote:
Hi (again, sorry, now with Subject)!
   
Anyone experiencing or experienced segfaults with openldap using
the bdb backed? I'm using -current ports tree, and built the
openldap-{client,server}, dbv4 and cyrus-sasl2 packages from
there.
   
I will certanly provide much more info, I just want to know if
there are other people out there who are experiencing this same
behaviour.
   
Thanks!
   
Daniel
  
   No problems here so far, my test servers are running -current as
   of Thu Dec 27 13:53:57 CST 2007. slapd and slurpd are OK and
   replication is also working well. No seg faults yet.
 
  Can you tell me which FLAVOR are you using with dbv4 and openldap?
 
  Daniel
 
 Hopefully I did not misunderstand your question.
 
 Here is what I did: 
 
 env FLAVOR=bdb make package
 
 ls -l /usr/ports/packages/i386/all/openld*
 
 -rw-r--r--  3 root  wheel  1244876 Dec 27 14:41
 openldap-client-2.3.33p0.tgz -rw-r--r--  3 root  wheel   916837 Dec
 27 14:44 openldap-server-2.3.33p2-bdb.tgz
 
 Then I just did a pkg_add for openldap-server-2.3.33p2-bdb.tgz. The
 db package was db-4.6.21.
 
Same here, but I get reproducible segfault :\
And it is caused by dbv4 unfortunately.
I would have tried with a newer openldap (2.3.40), but from 2.3.39,
openldap doesn't support db-4.6, only 4.2-4.5. So I'm kind of stuck
here. I think I going to have to try out openldap 2.4.

Daniel



Re: openldap with dbv4 crash

2007-12-30 Thread Stuart Henderson
   On December 29, 2007 11:23:19 am Daniel wrote:
Hi (again, sorry, now with Subject)!
   
Anyone experiencing or experienced segfaults with openldap using
the bdb backed? I'm using -current ports tree, and built the
openldap-{client,server}, dbv4 and cyrus-sasl2 packages from there.

openldap 2.3 doesn't support newer db 4.6 versions (should fail the
regression tests).

there's support in 2.4 but iirc it's not a simple thing to backport.



Re: openldap with dbv4 crash

2007-12-29 Thread Vijay Sankar
On December 29, 2007 11:23:19 am Daniel wrote:
 Hi (again, sorry, now with Subject)!

 Anyone experiencing or experienced segfaults with openldap using the bdb
 backed? I'm using -current ports tree, and built the
 openldap-{client,server}, dbv4 and cyrus-sasl2 packages from there.

 I will certanly provide much more info, I just want to know if there
 are other people out there who are experiencing this same behaviour.

 Thanks!

 Daniel

No problems here so far, my test servers are running -current as of Thu Dec 27 
13:53:57 CST 2007. slapd and slurpd are OK and replication is also working 
well. No seg faults yet.


-- 
Vijay Sankar, M.Eng., P.Eng.
President  CEO
ForeTell Technologies Limited
59 Flamingo Avenue, Winnipeg, MB Canada R3J 0X6
Phone: +1 204 885 9535, E-Mail: [EMAIL PROTECTED]



Re: openldap with dbv4 crash

2007-12-29 Thread Vijay Sankar
On December 29, 2007 02:15:15 pm Daniel wrote:
 On Sat, 29 Dec 2007 13:41:06 -0600

 Vijay Sankar [EMAIL PROTECTED] wrote:
  On December 29, 2007 11:23:19 am Daniel wrote:
   Hi (again, sorry, now with Subject)!
  
   Anyone experiencing or experienced segfaults with openldap using
   the bdb backed? I'm using -current ports tree, and built the
   openldap-{client,server}, dbv4 and cyrus-sasl2 packages from there.
  
   I will certanly provide much more info, I just want to know if there
   are other people out there who are experiencing this same behaviour.
  
   Thanks!
  
   Daniel
 
  No problems here so far, my test servers are running -current as of
  Thu Dec 27 13:53:57 CST 2007. slapd and slurpd are OK and replication
  is also working well. No seg faults yet.

 Can you tell me which FLAVOR are you using with dbv4 and openldap?

 Daniel

Hopefully I did not misunderstand your question.

Here is what I did: 

env FLAVOR=bdb make package

ls -l /usr/ports/packages/i386/all/openld*

-rw-r--r--  3 root  wheel  1244876 Dec 27 14:41 openldap-client-2.3.33p0.tgz
-rw-r--r--  3 root  wheel   916837 Dec 27 14:44 
openldap-server-2.3.33p2-bdb.tgz

Then I just did a pkg_add for openldap-server-2.3.33p2-bdb.tgz. The db package 
was db-4.6.21.

Vijay



Re: openldap with dbv4 crash

2007-12-29 Thread Daniel
On Sat, 29 Dec 2007 13:41:06 -0600
Vijay Sankar [EMAIL PROTECTED] wrote:

 On December 29, 2007 11:23:19 am Daniel wrote:
  Hi (again, sorry, now with Subject)!
 
  Anyone experiencing or experienced segfaults with openldap using
  the bdb backed? I'm using -current ports tree, and built the
  openldap-{client,server}, dbv4 and cyrus-sasl2 packages from there.
 
  I will certanly provide much more info, I just want to know if there
  are other people out there who are experiencing this same behaviour.
 
  Thanks!
 
  Daniel
 
 No problems here so far, my test servers are running -current as of
 Thu Dec 27 13:53:57 CST 2007. slapd and slurpd are OK and replication
 is also working well. No seg faults yet.
 
 
Can you tell me which FLAVOR are you using with dbv4 and openldap?

Daniel



Re: openldap -- syncrepl and dynamic backend modules (SOLVED)

2007-05-28 Thread Vijay Sankar
On Saturday 26 May 2007 14:14, Vijay Sankar wrote:
 I have been using the openldap (openldap-server-2.3.33p1-bdb) from
 ports and it works great when I use slurpd for replication.

 I would like to use syncrepl instead of slurpd, just to see what the
 benefits are. However I don't know how to enable the dynamic backend
 modules since they are not installed in /usr/local/libexec/openldap.
 I tried to modify the Makefile with --enable-overlays
 and --enable-modules but those attempts went down in flames.

 Is it possible to use syncrepl with openldap-server-2.3.33p1 on
 OpenBSD 4.1? What are the steps? Please let me know if you are able
 to help.

Just in case someone searches these archives looking to see how to do 
syncrepl with OpenLDAP on OpenBSD, here is what I had to do to add all 
the overlays, and backends, and so on. Normally I prefer using only the 
packages that are on the OpenBSD CD or using ports. I compiled OpenLDAP 
from source only because I do not know how to enable the dynamic 
modules and overlays when OpenLDAP is installed from packages -- so 
quite possibly there are much simpler ways of doing this and probably 
there are many good reasons why the ports maintainer did not want to 
enable overlays (if that is indeed the case). I will be grateful for 
any corrections/suggestions or if you have any thoughts on what other 
approaches would have been more appropriate than the stuff below.

Here is the configure command I used:

env CPPFLAGS=-I/usr/local/include/db4 -I/usr/local/include/sasl \ 
LDFLAGS=-L/usr/local/lib/db4 \
-L/usr/local/share/libtool/libltdl \
-L/usr/local/lib/sasl2 -L/usr/local/lib \
./configure \
--prefix=/usr/local \
--enable-slapd \
--enable-cleartext \
--enable-crypt \
--enable-rewrite \ 
--enable-wrapper \ 
--with-cyrus-sasl=yes \
--enable-spasswd \
--enable-dnssrv \
--enable-ldap \
--enable-ldbm \
--enable-bdb \
--enable-meta \
--enable-null \
--enable-passwd \
--disable-ipv6 \
--disable-shell \
--enable-slurpd \
--enable-overlays=mod \
--with-tls \
--disable-sql

Did a 'make depend' after the command above completed successfully and 
then a 'make test' to verify that everything especially syncrepl 
(test017 for refresh, test018 for persist, test019 for cascade, test043 
for delta-syncrepl) works properly for the different backends on 
OpenBSD 4.1.

Vijay



 Thanks very much,

 Vijay

-- 
Vijay Sankar
ForeTell Technologies Limited
59 Flamingo Avenue, Winnipeg, MB, Canada R3J 0X6
Phone: +1 (204) 885-9535, E-Mail: [EMAIL PROTECTED]



Re: OpenLDAP question

2007-05-23 Thread Mathieu Sauve-Frankel
On Mon, May 21, 2007 at 07:29:45AM +0200, Henning Brauer wrote:
 * Uv Pzaf [EMAIL PROTECTED] [2007-05-20 23:12]:
  I wonder why OpenBSD packages (i.e. openldap-server-2.3.24.tgz) still
  uses ldbm as database backend especially since the OpenLDAP folks are
  stating that this is no good any more:
  (http://www.openldap.org/faq/data/cache/756.htm) and not bdb or hdb.
 
 because ldbm works fine, very much opposed to the other two you mention.

This is not entirely true. I know for a fact mcbride@ has run into some
serious problems with ldbm and openldap in -current. Something about it
just completely losing one out of a every 150 queries. Switching to the
stable version of OpenLDAP and bdb solved his problem. 

-- 
Mathieu Sauve-Frankel



Re: OpenLDAP question

2007-05-22 Thread Henning Brauer
* Bryan Irvine [EMAIL PROTECTED] [2007-05-21 09:01]:
 Older versions of bdb went bad a fairly regular basis. I had DB's go
 corrupt as often as once a day under older verson of OL using bdb.
 This hasn't been a problem for a while though.  I havn't had a db go
 bad in 2 years, even after power failures.

aha, that is good news.
tried it sth nasty like a sparc64 too? :)

-- 
Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED]
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg  Amsterdam



Re: OpenLDAP question

2007-05-22 Thread Henning Brauer
* Dave Harrison [EMAIL PROTECTED] [2007-05-21 08:26]:
 Henning Brauer wrote:
  * Uv Pzaf [EMAIL PROTECTED] [2007-05-20 23:12]:
  I wonder why OpenBSD packages (i.e. openldap-server-2.3.24.tgz) still
  uses ldbm as database backend especially since the OpenLDAP folks are
  stating that this is no good any more:
  (http://www.openldap.org/faq/data/cache/756.htm) and not bdb or hdb.
  
  because ldbm works fine, very much opposed to the other two you mention. 
 
 My personal experiences with ldbm were equally fine, I recommend you use it
 unless you are performing frequent writes, or are in need of high performance
 lookups.  Once I started making regular writes, ldbm started to  pack it in
 rather frequently (db corruption) so I went to bdb, however bdb takes careful
 tuning to get right.

now that is funny, in the, what, 5 years? of using openldap/ldbm, i 
have never seen database corruption. trying to use bdb, pretty much 
immediately.


-- 
Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED]
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg  Amsterdam



Re: OpenLDAP question

2007-05-22 Thread Dave Harrison
Henning Brauer wrote:
 * Dave Harrison [EMAIL PROTECTED] [2007-05-21 08:26]:
 Henning Brauer wrote:
 * Uv Pzaf [EMAIL PROTECTED] [2007-05-20 23:12]:
 I wonder why OpenBSD packages (i.e. openldap-server-2.3.24.tgz) still
 uses ldbm as database backend especially since the OpenLDAP folks are
 stating that this is no good any more:
 (http://www.openldap.org/faq/data/cache/756.htm) and not bdb or hdb.
 because ldbm works fine, very much opposed to the other two you mention. 
 My personal experiences with ldbm were equally fine, I recommend you use it
 unless you are performing frequent writes, or are in need of high performance
 lookups.  Once I started making regular writes, ldbm started to  pack it in
 rather frequently (db corruption) so I went to bdb, however bdb takes careful
 tuning to get right.
 
 now that is funny, in the, what, 5 years? of using openldap/ldbm, i 
 have never seen database corruption. trying to use bdb, pretty much 
 immediately.

As I said, depends on how you're using it.

After a year, as the usage grew, I found ldbm was corrupting regularly and bdb
solved the problem nicely.  3 years later, bdb is still perfectly fine.

Obviously the other, valid, concern is what the OpenLDAP project intends to 
support.

With this kind of thing I think the mantra of YMMV is probably wise.



Re: OpenLDAP question

2007-05-22 Thread Uv Pzaf
I still want to push this little points directly from the OpenLDAP faq:

* back-ldbm is /obsolete/ and /should not be used/.

*As a historical note, the back-ldbm code is a direct descendant of the
original University of Michigan code. The age of the code and its
byzantine data structures were becoming unmaintainable, and since
back-bdb has proven itself to be more reliable, the decision was made to
delete back-ldbm from the code base.

*While BerkeleyDB supports this generic interface, it also offers a much
richer API that has a lot more power and a lot more complexity. back-bdb
is written specifically for the Berkeley DB /Transactional Data Store/
API. That is, back-bdb uses BDB's most advanced features to offer
transactional consistency, durability, fine-grained locking, and other
features that offer improved concurrency, reliability, and useability.
//

Dave Harrison wrote:
 Henning Brauer wrote:
   
 * Dave Harrison [EMAIL PROTECTED] [2007-05-21 08:26]:
 
 Henning Brauer wrote:
   
 * Uv Pzaf [EMAIL PROTECTED] [2007-05-20 23:12]:
 
 I wonder why OpenBSD packages (i.e. openldap-server-2.3.24.tgz) still
 uses ldbm as database backend especially since the OpenLDAP folks are
 stating that this is no good any more:
 (http://www.openldap.org/faq/data/cache/756.htm) and not bdb or hdb.
   
 because ldbm works fine, very much opposed to the other two you mention. 
 
 My personal experiences with ldbm were equally fine, I recommend you use it
 unless you are performing frequent writes, or are in need of high 
 performance
 lookups.  Once I started making regular writes, ldbm started to  pack it in
 rather frequently (db corruption) so I went to bdb, however bdb takes 
 careful
 tuning to get right.
   
 now that is funny, in the, what, 5 years? of using openldap/ldbm, i 
 have never seen database corruption. trying to use bdb, pretty much 
 immediately.
 

 As I said, depends on how you're using it.

 After a year, as the usage grew, I found ldbm was corrupting regularly and bdb
 solved the problem nicely.  3 years later, bdb is still perfectly fine.

 Obviously the other, valid, concern is what the OpenLDAP project intends to 
 support.

 With this kind of thing I think the mantra of YMMV is probably wise.



Re: OpenLDAP question

2007-05-21 Thread Dave Harrison
Henning Brauer wrote:
 * Uv Pzaf [EMAIL PROTECTED] [2007-05-20 23:12]:
 I wonder why OpenBSD packages (i.e. openldap-server-2.3.24.tgz) still
 uses ldbm as database backend especially since the OpenLDAP folks are
 stating that this is no good any more:
 (http://www.openldap.org/faq/data/cache/756.htm) and not bdb or hdb.
 
 because ldbm works fine, very much opposed to the other two you mention. 

My personal experiences with ldbm were equally fine, I recommend you use it
unless you are performing frequent writes, or are in need of high performance
lookups.  Once I started making regular writes, ldbm started to  pack it in
rather frequently (db corruption) so I went to bdb, however bdb takes careful
tuning to get right.

There also seems to be lots of noise about ldbm support becoming deprecated in
the 2.4+ releases of OpenLDAP.  You should review the OpenLDAP lists to research
this more if that's of concern.



Re: OpenLDAP question

2007-05-21 Thread Bryan Irvine

On 5/20/07, Dave Harrison [EMAIL PROTECTED] wrote:

Henning Brauer wrote:
 * Uv Pzaf [EMAIL PROTECTED] [2007-05-20 23:12]:
 I wonder why OpenBSD packages (i.e. openldap-server-2.3.24.tgz) still
 uses ldbm as database backend especially since the OpenLDAP folks are
 stating that this is no good any more:
 (http://www.openldap.org/faq/data/cache/756.htm) and not bdb or hdb.

 because ldbm works fine, very much opposed to the other two you mention.

My personal experiences with ldbm were equally fine, I recommend you use it
unless you are performing frequent writes, or are in need of high performance
lookups.  Once I started making regular writes, ldbm started to  pack it in
rather frequently (db corruption) so I went to bdb, however bdb takes careful
tuning to get right.


Older versions of bdb went bad a fairly regular basis. I had DB's go
corrupt as often as once a day under older verson of OL using bdb.
This hasn't been a problem for a while though.  I havn't had a db go
bad in 2 years, even after power failures.

I forget specifically what versions of openldap and bdb had this
problem but it went away with the versions from ports on 3.7.

--Bryan



Re: OpenLDAP question

2007-05-20 Thread Henning Brauer
* Uv Pzaf [EMAIL PROTECTED] [2007-05-20 23:12]:
 I wonder why OpenBSD packages (i.e. openldap-server-2.3.24.tgz) still
 uses ldbm as database backend especially since the OpenLDAP folks are
 stating that this is no good any more:
 (http://www.openldap.org/faq/data/cache/756.htm) and not bdb or hdb.

because ldbm works fine, very much opposed to the other two you mention.

-- 
Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED]
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg  Amsterdam



Re: openLDAP Unrecognized database type (bdb)

2007-02-12 Thread Vijay Sankar
On Monday 12 February 2007 09:27, Antonis Faragitakis wrote:
 Hi all,


 im trying to install openldap-server-2.3.11p4.tgz (i386) and
 openldap-client-2.3.11p4.tgz (i386) under OpenBSD3.9. After
 i've configured my slapd.conf im trying to start the server (slapd -d4 )
 but the i get the following error:
 # /usr/local/libexec/slapd -d 4
 @(#) $OpenLDAP: slapd 2.3.11 (Mar 1 2006 13:27:09) $
 @i386.ports.openbsd.org:/usr/obj/i386/openldap-2.3.11/build-i386/servers/sl
apd daemon_init: null
 Unrecognized database type (bdb)
 /etc/openldap/slapd.conf: line 79: database failed init (bdb)!
 slapd stopped.
 connections_destroy: nothing to destroy.

 anyone else had the same error?
 any solution(s) ?

FWIW, there is a newer version of the package --  
openldap-server-2.3.11p5.tgz -- and IIRC it works better than 
openldap-server-2.3.11p4.tgz on OpenBSD 3.9. 

Also, if you are using bdb as the backend database, you have to install the 
bdb flavor of openldap-server from ports. If you prefer to use package 
instead of ports, you have to use ldbm as the backend database.



 Thanks
 Atnonis


 !DSPAM:1,45d08784138061220213263!

-- 
Vijay Sankar
ForeTell Technologies Limited
59 Flamingo Avenue, Winnipeg, MB, Canada R3J 0X6
Phone: +1 (204) 885-9535, E-Mail: [EMAIL PROTECTED]



Re: Openldap

2006-12-13 Thread Toni Mueller
Hi,

On Fri, 08.12.2006 at 10:02:37 -0800, Bryan Irvine [EMAIL PROTECTED] wrote:
 I've been running 2.2.27 (with db4 FWIW) since august-ish of last year
 with zero corruption problems.

please also be sure to enable the sync option on bdb databases. I've
only experienced data loss when slapd went down uncontrolled, but
db_recover fixed most of it (AAARRRGGHH - still!).


Best,
--Toni++



Re: Openldap

2006-12-08 Thread Marc Balmer

Dr. Harry Knitter wrote:

Am Montag, 4. Dezember 2006 20:23 schrieb Bryan Irvine:

I have installed the following binaries:
openldap-server-2.3.24
openldap-client-2.3.24
db-4.2.52p8
OS is OpenBSD 4.0

You need to install openldap-server-2.3.24-bdb

If installed from ports use env FLAVOR=bdb make install to get it, or if
you used packages then use the bdb version.

--Bryan



I installed the package. However, on the mirror I used I don4t find any bdb 
version.


On a side note, some people obersved data corruption or even data loss 
when using the bdb backend.  The gdbm backends on the other hand, is stable.




Re: Openldap

2006-12-08 Thread Bryan Irvine

 I installed the package. However, on the mirror I used I don4t find any bdb
 version.

On a side note, some people obersved data corruption or even data loss
when using the bdb backend.  The gdbm backends on the other hand, is stable.



I don't remember the specific details, but there was a version of
openldap where that happened a lot. I was having to restore from
backups about once a week. IIRC it was 2.2.24 (and earlier?).

I've been running 2.2.27 (with db4 FWIW) since august-ish of last year
with zero corruption problems.

YMMV though.  I only have a few tens-of-thousands of lookups a day and
roughly 5 writes.  So my server may not be the best comparison.

--Bryan



Re: Openldap

2006-12-05 Thread Dr. Harry Knitter
Am Montag, 4. Dezember 2006 20:23 schrieb Bryan Irvine:
  I have installed the following binaries:
  openldap-server-2.3.24
  openldap-client-2.3.24
  db-4.2.52p8
  OS is OpenBSD 4.0

 You need to install openldap-server-2.3.24-bdb

 If installed from ports use env FLAVOR=bdb make install to get it, or if
 you used packages then use the bdb version.

 --Bryan


I installed the package. However, on the mirror I used I don4t find any bdb 
version.

Harry



  1   2   >