Re: OpenLDAP under 6.8 - no intermediate certs in chain
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
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
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
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
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
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
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
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
On 2017-07-10, Paul B. Hensonwrote: > 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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/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
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
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
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
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
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?
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?
* 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?
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?
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?
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?
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?
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?
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?
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?
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?
* 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?
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?
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?
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?
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?
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?
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?
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?
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?
* 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
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
--- 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
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
* 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
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
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
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
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
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
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
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)
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
--- 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
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
* 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
--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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
* 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
* 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
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
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
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
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
* 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)
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
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
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
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
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