Re: LDAP server gone - impossible to login locally!
Olivier Nicole wrote: Last June, we had to shutdown our openldap server every night, I noticed that a simple halt(8) would leave the bdb backend database in a corrupted state. As mentioned in the man page, halt(8) should not be used for regular shutting down of the system. shutdown(8) is preferred for several reasons, not the least of which is that it will call /etc/rc.shutdown which will (among other things) run through your rc.d scripts in reverse order with the 'stop' argument so that those services get clean shutdowns. If you want to turn the power off as well the -p option exists for this purpose. hth, Doug -- This .signature sanitized for your protection ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: LDAP server gone - impossible to login locally!
Daniel O'Connor wrote: On Wed, 23 Sep 2009, Erik Norgaard wrote: This sounds like the correct solution, AFAIK it's the same concept as for NIS, first check local files, then ldap. You don't want your root credentials possibly be leaked accross the network. On the other hand you don't want or need user accounts in the local files. Default first check local files which is fast, then fall back on ldap if the user is not found. Actually I wrote them the wrong way, how odd! I actually have.. group: cache ldap files passwd: cache ldap files I had issues with the order 'files ldap' too, that's why I choosed 'ldap files'. I think that if it fails ldap, it does so very quickly - it certainly did this morning when I rebooted uncleanly. I believe I did try it as cache files ldap but I had some issues, I can't recall what they were though. I had quite a bit of difficulty getting it to work acceptably so when it did I left it alone :) On a related note, why is slapd so damn fragile? It's a righteous pain in the bum the way you have to run db_recover-X.Y /var/db/openldap-data if slapd fails to start. Yes, this is a lot of pain. I have had issues the same way and never figured out what the reason was. /var/ is very often corrupted after a crash, power failure or unclean reboot. Maybe not slpad is that fragile, but db47 is. It wouldn't be so bad if it logged anything, but even with full logging it gives a very cryptic message and if you have logging disabled (which is recommended for performance!) it won't say _anything_. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: LDAP server gone - impossible to login locally!
On a related note, why is slapd so damn fragile? It's a righteous pain in the bum the way you have to run db_recover-X.Y /var/db/openldap-data if slapd fails to start. Yes, this is a lot of pain. I have had issues the same way and never figured out what the reason was. /var/ is very often corrupted after a crash, power failure or unclean reboot. Maybe not slpad is that fragile, but db47 is. Last June, we had to shutdown our openldap server every night, I noticed that a simple halt(8) would leave the bdb backend database in a corrupted state. It worked well if I /usr/local/etc/rc.d/slapd stop and sync(8) a couple of type before I halt(8). After that I wrote a small script that would take a backup of the ldap data every 2 hours and keep 5 days of backup. It seems that Berkeley DB has a lot of options that need to be configured to be working optimally with openldap. Maybe soft-update should be desactivated from the filesystem where the db files reside. Bests, Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: LDAP server gone - impossible to login locally!
On Wed, 23 Sep 2009, O. Hartmann wrote: Daniel O'Connor wrote: On Wed, 23 Sep 2009, Erik Norgaard wrote: This sounds like the correct solution, AFAIK it's the same concept as for NIS, first check local files, then ldap. You don't want your root credentials possibly be leaked accross the network. On the other hand you don't want or need user accounts in the local files. Default first check local files which is fast, then fall back on ldap if the user is not found. Actually I wrote them the wrong way, how odd! I actually have.. group: cache ldap files passwd: cache ldap files I had issues with the order 'files ldap' too, that's why I choosed 'ldap files'. Can you remember any details why? I can't :) On a related note, why is slapd so damn fragile? It's a righteous pain in the bum the way you have to run db_recover-X.Y /var/db/openldap-data if slapd fails to start. Yes, this is a lot of pain. I have had issues the same way and never figured out what the reason was. /var/ is very often corrupted after a crash, power failure or unclean reboot. Maybe not slpad is that fragile, but db47 is. Yes, although openldap's handling of a bad DB is quite poor IMO.. That said I haven't had the nerve to look at the code. I had a quick look to see if there was a more robust looking backend but nothing jumped out at me. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: LDAP server gone - impossible to login locally!
On Tue, 22 Sep 2009, O. Hartmann wrote: I run into trouble with FreeBSD and LDAP on a regular basis! Sometimes it is necessary to log in onto a bunch of servers with no LDAP service responding, due to service, crash, eletrically disconnetion, whatever. The problem is: I can't. Using all prerequisits from ports (pam_ldap/nss_ldap/ldap as most recent) my /etc/nsswitch.conf looks like this as it has been the most reasonable (and only working!) solution for the past 2 years: passwd: ldap [unavail=continue notfound=continue] files [success=return notfound=return] I just have passwd: cache files ldap group: cache files ldap and I can login as root locally without any delay. That said my LDAP server is on the same machine so perhaps it fails faster. I am using uri ldapi://%2fvar%2frun%2fopenldap%2fldapi/ to connect to. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: LDAP server gone - impossible to login locally!
On Tue, 22 Sep 2009, 11:53 +, O. Hartmann wrote: Hello, I run into trouble with FreeBSD and LDAP on a regular basis! Sometimes it is necessary to log in onto a bunch of servers with no LDAP service responding, due to service, crash, eletrically disconnetion, whatever. The problem is: I can't. Using all prerequisits from ports (pam_ldap/nss_ldap/ldap as most recent) my /etc/nsswitch.conf looks like this as it has been the most reasonable (and only working!) solution for the past 2 years: passwd: ldap [unavail=continue notfound=continue] files [success=return notfound=return] The same for group. Intention is to have root- or wheel-group access of local managed service users without timeouts due to irresponsible LDAP servers. But it does not work! If the LDAP service is not available, FreeBSD 8.0/AMD64-RC1 (most recent source/build) does nothing for approx. 120 seconds and sometimes much longer when trying to login as root from console. In some cases, the same box under the very same conditions refuses login due to a timeout, very strange. After a couple of time and lots of questiosn, the above showed nsswitch.conf entries were evaluated as those which should work, but exchanging 'ldap' and 'files' results in a never-can-login-situation, when LDAP isn't responsible. Is there a way to shorten the timeouts and if yes, where to look for? 2 minutes for a login within services sessions is too much, a waste of time. Our network is very fast, so 30 seconds should be enough ... I've only recently started playing with LDAP but it sounds to me like you probably have one of the 'hard' options set for the reconnect policy in your nss_ldap.conf file. I use 'bind_policy soft' so that if the LDAP server isn't available we fail over to the next nsswitch service immediately. I don't think further discussion of this thread belongs on the freebsd-current list. Hope this helps. -- John Marshall pgpEO2ABkokeG.pgp Description: PGP signature
Re: LDAP server gone - impossible to login locally!
John Marshall wrote: On Tue, 22 Sep 2009, 11:53 +, O. Hartmann wrote: Hello, I run into trouble with FreeBSD and LDAP on a regular basis! Sometimes it is necessary to log in onto a bunch of servers with no LDAP service responding, due to service, crash, eletrically disconnetion, whatever. The problem is: I can't. Using all prerequisits from ports (pam_ldap/nss_ldap/ldap as most recent) my /etc/nsswitch.conf looks like this as it has been the most reasonable (and only working!) solution for the past 2 years: passwd: ldap [unavail=continue notfound=continue] files [success=return notfound=return] The same for group. Intention is to have root- or wheel-group access of local managed service users without timeouts due to irresponsible LDAP servers. But it does not work! If the LDAP service is not available, FreeBSD 8.0/AMD64-RC1 (most recent source/build) does nothing for approx. 120 seconds and sometimes much longer when trying to login as root from console. In some cases, the same box under the very same conditions refuses login due to a timeout, very strange. After a couple of time and lots of questiosn, the above showed nsswitch.conf entries were evaluated as those which should work, but exchanging 'ldap' and 'files' results in a never-can-login-situation, when LDAP isn't responsible. Is there a way to shorten the timeouts and if yes, where to look for? 2 minutes for a login within services sessions is too much, a waste of time. Our network is very fast, so 30 seconds should be enough ... I've only recently started playing with LDAP but it sounds to me like you probably have one of the 'hard' options set for the reconnect policy in your nss_ldap.conf file. I use 'bind_policy soft' so that if the LDAP server isn't available we fail over to the next nsswitch service immediately. I don't think further discussion of this thread belongs on the freebsd-current list. Hope this helps. bind_policy soft is a bad solution. When you have network lags, you have chance to get flapping connection error. http://www.liquidx.net/blog/2006/04/03/nss_ldap-undocumented-nss_reconnect_tries/ nss_reconnect_sleeptime 0 nss_reconnect_maxsleeptime 1 nss_reconnect_maxconntries 1 WBR ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: LDAP server gone - impossible to login locally!
Daniel O'Connor wrote: On Tue, 22 Sep 2009, O. Hartmann wrote: I run into trouble with FreeBSD and LDAP on a regular basis! Sometimes it is necessary to log in onto a bunch of servers with no LDAP service responding, due to service, crash, eletrically disconnetion, whatever. The problem is: I can't. Using all prerequisits from ports (pam_ldap/nss_ldap/ldap as most recent) my /etc/nsswitch.conf looks like this as it has been the most reasonable (and only working!) solution for the past 2 years: passwd: ldap [unavail=continue notfound=continue] files [success=return notfound=return] I just have passwd: cache files ldap group: cache files ldap and I can login as root locally without any delay. That said my LDAP server is on the same machine so perhaps it fails faster. I am using uri ldapi://%2fvar%2frun%2fopenldap%2fldapi/ to connect to. This sounds like the correct solution, AFAIK it's the same concept as for NIS, first check local files, then ldap. You don't want your root credentials possibly be leaked accross the network. On the other hand you don't want or need user accounts in the local files. Default first check local files which is fast, then fall back on ldap if the user is not found. BR, Erik -- Erik Nørgaard Ph: +34.666334818/+34.915211157 http://www.locolomo.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: LDAP server gone - impossible to login locally!
On Wed, 23 Sep 2009, Erik Norgaard wrote: This sounds like the correct solution, AFAIK it's the same concept as for NIS, first check local files, then ldap. You don't want your root credentials possibly be leaked accross the network. On the other hand you don't want or need user accounts in the local files. Default first check local files which is fast, then fall back on ldap if the user is not found. Actually I wrote them the wrong way, how odd! I actually have.. group: cache ldap files passwd: cache ldap files I think that if it fails ldap, it does so very quickly - it certainly did this morning when I rebooted uncleanly. I believe I did try it as cache files ldap but I had some issues, I can't recall what they were though. I had quite a bit of difficulty getting it to work acceptably so when it did I left it alone :) On a related note, why is slapd so damn fragile? It's a righteous pain in the bum the way you have to run db_recover-X.Y /var/db/openldap-data if slapd fails to start. It wouldn't be so bad if it logged anything, but even with full logging it gives a very cryptic message and if you have logging disabled (which is recommended for performance!) it won't say _anything_. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: LDAP server gone - impossible to login locally!
On 9/22/09, Daniel O'Connor docon...@gsoft.com.au wrote: On Wed, 23 Sep 2009, Erik Norgaard wrote: This sounds like the correct solution, AFAIK it's the same concept as for NIS, first check local files, then ldap. You don't want your root credentials possibly be leaked accross the network. On the other hand you don't want or need user accounts in the local files. Default first check local files which is fast, then fall back on ldap if the user is not found. Actually I wrote them the wrong way, how odd! I actually have.. group: cache ldap files passwd: cache ldap files I think that if it fails ldap, it does so very quickly - it certainly did this morning when I rebooted uncleanly. I believe I did try it as cache files ldap but I had some issues, I can't recall what they were though. I had quite a bit of difficulty getting it to work acceptably so when it did I left it alone :) On a related note, why is slapd so damn fragile? It's a righteous pain in the bum the way you have to run db_recover-X.Y /var/db/openldap-data if slapd fails to start. I run OpenLDAP on a few boxes. I don't recall the power failures or rude shutdowns to ever give me problems... Course, I don't have anything hi-traffic, so I would definately have time for softupdates to flush to disk before a crash is inevitable. I've marked this thread, it's been useful already with the '[unavail=continue notfound=continue]' pieces after the ldap dictionary in nsswitch.conf Now I have another command, db_recover It wouldn't be so bad if it logged anything, but even with full logging it gives a very cryptic message and if you have logging disabled (which is recommended for performance!) it won't say _anything_. To have OpenLDAP logging, you have to insert local4.* statements in syslog.conf, touch the given file, and restart syslog. Any logging that OpenLDAP would need to send, is then recorded in syslog. Why they picked 4, of 1 through 7, I'm not sure. I'd help you with that, if you'd like. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: LDAP server gone - impossible to login locally!
On Wed, 23 Sep 2009, Tim Judd wrote: On a related note, why is slapd so damn fragile? It's a righteous pain in the bum the way you have to run db_recover-X.Y /var/db/openldap-data if slapd fails to start. I run OpenLDAP on a few boxes. I don't recall the power failures or rude shutdowns to ever give me problems... Course, I don't have anything hi-traffic, so I would definately have time for softupdates to flush to disk before a crash is inevitable. This isn't high traffic, it's basically read only. I've marked this thread, it's been useful already with the '[unavail=continue notfound=continue]' pieces after the ldap dictionary in nsswitch.conf man nsswitch.conf :) Now I have another command, db_recover You can benefit from my torn out hair from when I went looking for it :) disabled (which is recommended for performance!) it won't say _anything_. To have OpenLDAP logging, you have to insert local4.* statements in syslog.conf, touch the given file, and restart syslog. Any logging that OpenLDAP would need to send, is then recorded in syslog. Why they picked 4, of 1 through 7, I'm not sure. Thanks, I've enabled it, normally I just fish through all.log :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
