Re: OpenLDAP 2.3/pam_ldap/nss_ldap: not working in FreeBSD 7.0-PRE!
Sorry for the late reply ... On Fri, 26.10.2007 at 20:16:45 +0200, O. Hartmann wrote: All right, here I am. nss_ldap.conf and ldap.conf are located in /usr/local/etc and are identical (link). I copied all tags I use and deleted commented out tags: Seems ok to me, though I don't claim to be an expert. The slapd.conf is this, comments roped: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/inetorgperson.schema # additional schema include /usr/local/share/examples/samba/LDAP/samba.schema pidfile /var/run/openldap/slapd.pid argsfile/var/run/openldap/slapd.args logfile /var/log/slapd.log loglevel512 loglevel is a bitmask. It you want to have lots of debugging try 255 and run a tail -f /var/log/debug.log sizelimit unlimited allow bind_v2 modulepath /usr/local/libexec/openldap moduleload back_bdb everse-lookup off typo I guess? NSCD is up and running, my nsswitch.conf looks like this: Please try without nscd first, it's just another possible source of problems. group: cache ldap[ unavail=continue notfound=continue ] files passwd: cache ldap [ unavail=continue notfound=continue ] files #group_compat: nis hosts: compat networks: files #passwd_compat: nis shells: files services: compat services_compat: nis protocols: files rpc: files And I changed some lines in /etc/pam.d/sshd,login,system,other like this *commented out due to system gets stuck forever when enab;ed nss_ldap/pam_ldap): I'm using softbind and a short timeout in ldap.conf/nss_ldap.conf to avoid this unresponsiveness. # Bind/connect timelimit bind_timelimit 3 # Reconnect policy: hard (default) will retry connecting to # the software with exponential backoff, soft will fail # immediately. #bind_policy hard bind_policy soft Also, make NSS work first, then turn to configuring PAM (at least, that's what I would do) Some errors from console: (At boot time) Oct 26 17:00:36 gauss kernel: Oct 26 17:00:36 gauss slapd[757]: nss_ldap: could not search LDAP server - Server is unavailable Expected. slapd want to change its user to ldap:ldap, which it needs to look up the UID for. Chicken Egg. That's why I need to use soft bind+timeout on my (disconnected) laptop here. Oct 26 11:59:08 gauss kernel: Oct 26 11:59:08 gauss cron[13480]: nss_ldap: could not search LDAP server - Server is unavailable Oct 26 12:41:44 gauss kernel: Oct 26 12:41:44 gauss login: nss_ldap: could not search LDAP server - Server is unavailable That seems broken then. Is slapd running? Can you ldapsearch -Lx -h localhost? What's /var/log/debug.log telling you? Can you id(1) some ldap users? Does the output of 'getent group' and 'getent passwd' look reasonable? One point: what is about compile time options of OpenLDAP? Does LDAP forces itself using SSL although not configured explicitely in slapd.conf? No. It is purely optional. You would need certificates before it can even possibly start working anyways. nss_ldap-1.257 === openldap-client-2.3.38 openldap-server-2.3.38 pam_ldap-1.8.2 My other computer is running with nss_ldap-1.257 and showing no problems either. Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenLDAP 2.3/pam_ldap/nss_ldap: not working in FreeBSD 7.0-PRE!
On Sun, 21.10.2007 at 18:26:55 +0200, O. Hartmann wrote: At this point it seems senseless to try out what's going wrong and I need some hints or tipps. I read about others successfully running OpenLDAP on FBSD 6 and 5, but no one seems running OpenLDAP based services on FBSD 7. I do. It's working just fine ... P.S. If someone wants me to offer config details and/or log excerpts, please contact me. Well, we/I would need your ldap.conf, nss_ldap.conf (should be a link to ldap.conf) and slapd.conf, as well as pam.d stuff and nsswitch.conf. Some actual error messages would be fine too. Your should run tcpdump in some window to actuall see what's going on. It also helps to turn on massive debugging in slapd.conf and tail(1)ing /var/log/debug.log I'm running the following versions on 7-CURRENT from 30. September nss_ldap-1.256 openldap-sasl-client-2.3.38 openldap-server-2.3.38 pam_ldap-1.8.2 Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Has the port collection become to large to handle.
fbsd wrote: Modify the master make code to post a count to a special purpose FreeBSD website by passing it a cookie. Now every time a any user runs the port make install that special purpose FreeBSD website will be accessed counting how many times that port is really executed. Then use that count per new release of FreeBSD to determine the ports that go into the commonly used category. I always thought of such a scheme too. Like the afterboot-manpage (IIRC) on OpenBSD, where people are encouraged to mail their dmesg output to the developers. The comments from one of the maintainers about the fact that the maintainers are not allowed to build the official packages is a policy that can easily be changed. Hell no. Putting the burden on maintainers to build packages for various architectures and releases is completely utopical. Not to mention the fact, that they would have to build them in sandboxes much like the package build cluster. configure script often pick up random libraries to link against, if these are not recorded as @pkgdep then the package is mostly useless for other people. Its more important to have timely packages available then the security of waiting for the mass package build done once per new FreeBSD version release. Packages are built on a regular basis, I suggest you get more familiar with the package building and RE process before starting heated discussions on ports@ This also allows the maintainer to build different versions of the package for each different version of major dependents such as php4/5 apache1/2 mysql3/4/5 whatever. The mass package build process does not allow this flexibility. I already wrote my thoughts about a FLAVOUR system, where multiple packages are built per port. Sadly, people seem to think that slave ports are the way to go. But not only do they eat up precious inodes, increase the fake count of ports/packages available, and increase INDEX build times. They are also only deemed worthy for important ports, whatever that means. If you would commit a slave port for every port that can be built with mysql XOR postgresql, you get an unmaintainable mess. Not to mention that you violate the one fact in one place rule. Having duplicate ports, that are almost the same scattered throughout the ports system is obviously not helpful. The resources and time needed for performing the secure massive package built must impact the release timeline of new FreeBSD releases. Doing away with it may streamline many other different internal release process. There is a dedicated package build cluster, it does in no way interfere the RE process. Please read up on the mentioned topics, thanks. Ulrich Spoerlein -- PGP Key ID: 20FEE9DD Encrypted mail welcome! Fingerprint: AEC9 AF5E 01AC 4EE1 8F70 6CBD E76E 2227 20FE E9DD Which is worse: ignorance or apathy? Don't know. Don't care. pgp00wOvajCdU.pgp Description: PGP signature
How to reliably measure user time (getrusage(2))
Hi all, I need to measure the time spent in user mode for rather short-lived processes. Sadly the results vary highly % while true;do \time -p woptsa tsplib/pla7397/pla7397.tsp 21|sed -n /user/p;done user 1.13 user 0.67 user 0.65 user 0.65 user 0.64 user 0.65 % while true;do \time -p woptsa tsplib/pla7397/pla7397.tsp 21|sed -n /user/p;sleep 1;done user 1.22 user 0.87 user 0.75 user 0.67 user 0.86 user 0.74 % while true;do \time -p woptsa tsplib/pla7397/pla7397.tsp 21|sed -n /user/p;sleep 3;done user 1.24 user 1.23 user 1.27 user 1.27 user 1.10 user 1.19 I fail to see how sleeping or waiting between consecutive runs could affect user time. Everything from page faults to I/O is handled inside the kernel, so it shouldn't affect user-time, no? The only library function not taking constant time I could think of would be malloc(3), is that a possibility? Inside the program I'm using getrusage(2) to measure the time my program is executing. kern.hz is set to 1000, this is on a 5-STABLE 1.5GHz Pentium-M. What to do? Ulrich Spoerlein -- PGP Key ID: F0DB9F44 Encrypted mail welcome! Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44 Ok, which part of Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn. didn't you understand? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
