389-users November 2015

389-users@lists.fedoraproject.org

28 participants
32 discussions

Announcing 389 Directory Server version 1.3.3.14
by Noriko Hosoi 19 Nov '15

19 Nov '15

389 Directory Server 1.3.3.14 The 389 Directory Server team is proud to announce 389-ds-base version 1.3.3.14. Fedora packages are available from the Fedora 21 repositories. The new packages and versions are: * 389-ds-base-1.3.3.14-1 A source tarball is available for download at Download Source <http://www.port389.org/binaries/389-ds-base-1.3.3.14.tar.bz2> Highlights in 1.3.3.14 * Various bugs are fixed. Installation and Upgrade See Download <http://www.port389.org/docs/389ds/download.html> for information about setting up your yum repositories. To install, use *yum install 389-ds* yum install 389-ds After install completes, run *setup-ds-admin.pl* to set up your directory server. setup-ds-admin.pl To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run *setup-ds-admin.pl -u* to update your directory server/admin server/console information. setup-ds-admin.pl -u See Install_Guide <http://www.port389.org/docs/389ds/legacy/install-guide.html> for more information about the initial installation, setup, and upgrade See Source <http://www.port389.org/docs/389ds/development/source.html> for information about source tarballs and SCM (git) access. Feedback We are very interested in your feedback! Please provide feedback and comments to the 389-users mailing list: https://admin.fedoraproject.org/mailman/listinfo/389-users as well as https://admin.fedoraproject.org/updates/389-ds-base-1.3.3.14-1.fc21 <https://admin.fedoraproject.org/updates/389-ds-base-1.3.3.14-1.fc21>. If you find a bug, or would like to see a new feature, file it in our Trac instance: https://fedorahosted.org/389 Detailed Changelog since 1.3.3.13 * Ticket 47553 - Automated the verification procedure * Ticket 47957 - Add replication test suite for a wait async feature * Ticket 47976 - deadlock in mep delete post op * Ticket 47978 - Deadlock between two MODs on the same entry between entry cache and backend lock * Ticket 48192 - Individual abandoned simple paged results request has no chance to be cleaned up * Ticket 48208 - CleanAllRUV should completely purge changelog * Ticket 48226 - In MMR, double free coould occur under some special condition * Ticket 48264 - Ticket 47553 tests refactoring * Ticket 48266 - Fractional replication evaluates several times the same CSN * Ticket 48266 - coverity issue * Ticket 48266 - do not free repl keep alive entry on error * Ticket 48266 - Online init crashes consumer * Ticket 48273 - Update lib389 tests for new valgrind functions * Ticket 48283 - many attrlist_replace errors in connection with cleanallruv * Ticket 48284 - free entry when internal add fails * Ticket 48299 - pagedresults - when timed out, search results could have been already freed. * Ticket 48304 - ns-slapd - LOGINFO:Unable to remove file * Ticket 48305 - perl module conditional test is not conditional when checking SELinux policies * Ticket 48325 - Add lib389 test script * Ticket 48325 - Replica promotion leaves RUV out of order * Ticket 48338 - SimplePagedResults – abandon could happen between the abandon check and sending results http://www.port389.org/docs/389ds/releases/release-1-3-3-14.html

1 0

Announcing 389 Directory Server version 1.3.4.5
by Noriko Hosoi 19 Nov '15

19 Nov '15

389 Directory Server 1.3.4.5 The 389 Directory Server team is proud to announce 389-ds-base version 1.3.4.5. Fedora packages are available from the Fedora 22, 23 and Rawhide repositories. The new packages and versions are: * 389-ds-base-1.3.4.5-1 Source tarballs are available for download at Download 389-ds-base Source <http://www.port389.org/binaries/389-ds-base-1.3.4.5.tar.bz2> and Download nunc-stans Source <http://www.port389.org/binaries/nunc-stans-0.1.5.tar.bz2>. Highlights in 1.3.4.5 * Various bugs are fixed. Installation and Upgrade See Download <http://www.port389.org/docs/389ds/download.html> for information about setting up your yum repositories. To install, use *yum install 389-ds* yum install 389-ds After install completes, run *setup-ds-admin.pl* to set up your directory server. setup-ds-admin.pl To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run *setup-ds-admin.pl -u* to update your directory server/admin server/console information. setup-ds-admin.pl -u See Install_Guide <http://www.port389.org/docs/389ds/legacy/install-guide.html> for more information about the initial installation, setup, and upgrade See Source <http://www.port389.org/docs/389ds/development/source.html> for information about source tarballs and SCM (git) access. Feedback We are very interested in your feedback! Please provide feedback and comments to the 389-users mailing list: https://admin.fedoraproject.org/mailman/listinfo/389-users as well as https://admin.fedoraproject.org/updates/389-ds-base-1.3.4.5-1.fc22 <https://admin.fedoraproject.org/updates/389-ds-base-1.3.4.5-1.fc22> and https://admin.fedoraproject.org/updates/389-ds-base-1.3.4.5-1.fc23 <https://admin.fedoraproject.org/updates/389-ds-base-1.3.4.5-1.fc23>. If you find a bug, or would like to see a new feature, file it in our Trac instance: https://fedorahosted.org/389 Detailed Changelog since 1.3.4.4 * Ticket 47511 - bashisms in 389-ds-base admin scripts * Ticket 47553 - Automated the verification procedure * Ticket 47761 - Added a few testcases to the basic testsuite * Ticket 47957 - Add replication test suite for a wait async feature * Ticket 47976 - deadlock in mep delete post op * Ticket 47978 - Deadlock between two MODs on the same entry between entry cache and backend lock * Ticket 48188 - segfault in ns-slapd due to accessing Slapi_DN freed in pre bind plug-in * Ticket 48192 - Individual abandoned simple paged results request has no chance to be cleaned up * Ticket 48204 - update lib389 test scripts for python 3 * Ticket 48217 - cleanallruv - fix regression with server shutdown * Ticket 48226 - In MMR, double free coould occur under some special condition * Ticket 48227 - rpm.mk doesn’t build srpms for 389-ds and nunc-stans * Ticket 48254 - Shell CLI fails with usage errors if an argument containing white spaces is given * Ticket 48264 - Ticket 47553 tests refactoring * Ticket 48266 - Fractional replication evaluates several times the same CSN * Ticket 48266 - coverity issue * Ticket 48266 - do not free repl keep alive entry on error * Ticket 48266 - Online init crashes consumer * Ticket 48267 - Add config setting to MO plugin to add objectclass * Ticket 48273 - Update lib389 tests for new valgrind functions * Ticket 48276 - initialize free_flags in reslimit_update_from_entry() * Ticket 48279 - Check NULL reference in nssasl_mutex_lock etc. (saslbind.c) * Ticket 48283 - many attrlist_replace errors in connection with cleanallruv * Ticket 48284 - free entry when internal add fails * Ticket 48298 - ns-slapd crash during ipa-replica-manage del * Ticket 48299 - pagedresults - when timed out, search results could have been already freed. * Ticket 48304 - ns-slapd - LOGINFO:Unable to remove file * Ticket 48305 - perl module conditional test is not conditional when checking SELinux policies * Ticket 48311 - nunc-stans: Attempt to release connection that is not acquired * Ticket 48316 - Perl-5.20.3-328: Use of literal control characters in variable names is deprecated * Ticket 48325 - Add lib389 test script * Ticket 48325 - Replica promotion leaves RUV out of order * Ticket 48338 - SimplePagedResults – abandon could happen between the abandon check and sending results * Ticket 48339 - Share nsslapd-threadnumber in the case nunc-stans is enabled, as well. * Ticket 48344 - acl - regression - trailing ‘, (comma)’ in macro matched value is not removed. * Ticket 48348 - Running /usr/sbin/setup-ds.pl fails with Can’t locate bigint.pm, plus two warnings http://www.port389.org/docs/389ds/releases/release-1-3-4-5.html

1 0

Upgrading to Centos 7...
by Derek Belcher 19 Nov '15

19 Nov '15

Hi guys! What version of 389ds is the equivalent to the RHDS packages? Currently I am on Centos 6 and planning on upgrading all of my severs to Centos 7 to get the newer 389ds packages, here is a list of my current packages: # cat /etc/issue CentOS release 6.2 (Final) # rpm -qa 389* 389-ds-console-1.2.6-1.el6.noarch 389-ds-1.2.2-1.el6.noarch 389-ds-base-libs-1.2.11.15-48.el6_6.x86_64 389-dsgw-1.1.11-1.el6.x86_64 389-admin-console-1.1.8-1.el6.noarch 389-ds-console-doc-1.2.6-1.el6.noarch 389-console-1.1.7-1.el6.noarch 389-admin-1.1.35-1.el6.x86_64 389-admin-console-doc-1.1.8-1.el6.noarch 389-adminutil-1.1.19-1.el6.x86_64 389-ds-base-1.2.11.15-48.el6_6.x86_64 I would like to know the current supported packages or stable versions for Centos 7 that are equal to the RHDS versions, I just dont want to be on the bleeding edge. Does that make sense? Also is there an upgrade path that I need to be following, any caveats that I need to be cognizant of? thank you!

3 3

Re: [Fedora-directory-users] dirsrv on IPv6 and dirsrv-admin on IPv4
by Fortunato 17 Nov '15

17 Nov '15

Thanks! That's the conf file used by the httpd.worker service. -----Original Message----- >From: Peter Green <peter.green(a)bexleyitsolutions.co.uk> >Sent: Apr 23, 2009 4:07 AM >To: Fortunato <fortunato.montresor(a)earthlink.net>, "General discussion list for the Fedora Directory server project." <fedora-directory-users(a)redhat.com> >Subject: Re: [Fedora-directory-users] dirsrv on IPv6 and dirsrv-admin on IPv4 > >Hi, > >Have you tried changing the "Listen" directive in the >file /etc/dirsrv/admin-serv/console.conf? > >>From the file itself: > >[quote] ># ># Listen: Allows you to bind Apache to specific IP addresses and/or ># ports, in addition to the default. See also the <VirtualHost> ># directive. ># ># Change this to Listen on specific IP addresses as shown below to ># prevent Apache from glomming onto all bound IP addresses (0.0.0.0) ># e.g. "Listen 12.34.56.78:80" ># ># To allow connections to IPv6 addresses add "Listen [::]:80" ># >Listen 0.0.0.0:9830 >[/quote] > >You will need to restart the admin server component afterwards. A quick >"service dirsrv-admin restart" will suffice on Red Hat-based systems. > >HTH, > >Pete > >On Wed, 2009-04-22 at 18:47 -0700, Fortunato wrote: >> Hello, >> >> According to netstat, it looks like the ns-slapd is listening on the IPv6 address but the dirsrv process is on IPv4. Is there a quick way to put dirsrv on IPv6 as well? >> >> # netstat -tlpn >> Active Internet connections (only servers) >> Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name >> tcp 0 0 0.0.0.0:9830 0.0.0.0:* LISTEN 2591/httpd.worker >> tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 2158/rpcbind >> tcp 0 0 0.0.0.0:34129 0.0.0.0:* LISTEN 2171/rpc.statd >> tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 2902/sshd >> tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 2919/sendmail: acce >> tcp 0 0 :::389 :::* LISTEN 2491/ns-slapd >> tcp 0 0 :::111 :::* LISTEN 2158/rpcbind >> tcp 0 0 :::22 :::* LISTEN 2902/sshd >> >> Thanks in advance, >> >> -- >> Fedora-directory-users mailing list >> Fedora-directory-users(a)redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >-- >Peter Green B.Sc. (Hons) M.B.C.S. >Director / Technical Lead >Bexley I.T. Solutions Ltd. > >M: +44 (0) 7908 135 070 >

1 0

Re: [Fedora-directory-users] problems w/ admin server, local.conf
by MJD Shop Account 17 Nov '15

17 Nov '15

I've seen the same issues, except I dont' think I've gotten the error about using the cert8.db; but generally I'm using the same *db files as for the DS itself, so I copy and rename them. The PSET error I see all the time. It's one reason I'm hoping to script this setup. Even when it seems to be working (as it is now), I notice things like the config operational attribute for the cert nssPersonalitySSL says 'blank', while the http config files have the right value. -----Original Message----- >From: Dennis De Marco <ddemarco(a)seisint.com> >Sent: Jun 20, 2007 10:48 AM >To: MJD Shop Account <mjdshop(a)earthlink.net>, "General discussion list for the Fedora Directory server project." <fedora-directory-users(a)redhat.com> >Subject: Re: [Fedora-directory-users] problems w/ admin server, local.conf > >I've had other issues with SSL and the admin server, these seem to stick >me the most. These seem to happen with the ssl shell scripts, or by >hand. > >When clicking on 'Manager Certificates ' under the task menu for Fedora >Admin server you get an error that the cert8.db could not be found. > > >The fix is : > ># cd /opt/fedora-ds/alias ># ../shared/bin/certutil -N -d . -P admin-serv-[LDAPINSTANCE]- > >Also when installing a certificate, then going to configure and manage >encryption. Selecting using SSL and RSA will give me a PSET error. > >Then the certificate will not be listed in the drop down box. By >clicking various checkboxes on and off it will stick with a bla k >certificate. > >You need to make sure that the NSSNickName is set with your server-cert >in /opt/fedora-ds/admin/admin-serv/config. If not the error log will say >something with 'blank' certificate. > >Also, double verify the nssLPersonalitySSL: is not blank attribute at > ># RSA, encryption, config >dn: cn=RSA,cn=encryption,cn=config >nsSSLToken: internal (software) >nsSSLPersonalitySSL: server-cert >nsSSLActivation: on >objectClass: top >objectClass: nsEncryptionModule >cn: RSA > > >- Dennis > >On Mon, 2007-06-18 at 18:10 -0400, MJD Shop Account wrote: >> I've set up a few FDS 1.0.4 servers now and have problems every time getting certain things right with the admin server. I run into problems using either the console or just ldif file (which I prefer, for scripting). Here's the typical problem: when I try to set nsAdminAccessHosts, I use an ldif file. I can see the new value is set in the operational attributes, but it doesn't always make it into /opt/fedora-ds/admin-server/config/local.conf. The admin server logs indicate it is using the old values. >> >> I looked at file permissions, on one server I had owner:group as ldap:root, another has root:root, a third had ldap:ldap. That one was not getting updated, I changed it to root:root and restarted things and that seemed to update local.conf. >> >> Now I'm building a new server and it's not updating. I get this error in the admin server error log: >> [warn] Unable to bind as LocalAdmin to populate LocalAdmin tasks into cache. >> >> This was similar to the server I fixed, but I already have root:root permissions on that file. >> >> I went and looked at the server that originally had root:root, and while it has been functioning OK, it too doesn't have the correctly updated values for nsAdminAccessHosts in local.conf and shows the same error in its logs from awhile back (March). So, I tried, for a test, setting the owner:group to ldap:root. When I did this and restarted admin server, I got this error: >> [error] server reached MaxClients setting, consider raising the MaxClients setting >> >> This on a server that should not have anyone connected to the admin server... >> >> So I set it back to root:root and had neither error on restarting (but the attribute value is still wrong). On all servers, there is an httpd process under ldap user id and two under root user id (one of the two of the two root processes is the parent to the other root and to the ldap process). >> >> Sometime ago I tried to find out what triggers the re-writing of local.conf, as Richard said it was best to use the console for updating these values, where some magic makes it do that. Richard suggested looking in the logs to see what was happening, but I found no clues there. If anyone has one... >> >> Maybe the permissions need to match the method; would it be different running a root script at the command prompt vs. using the java console from a windows machine and connecting as the cn=dirmgr user? >> >> Thanks, >> MJD >> >> -- >> Fedora-directory-users mailing list >> Fedora-directory-users(a)redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users > >This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. >

1 0

Re: [Fedora-directory-users] root certificate for use with startconsole
by MJD Shop Account 17 Nov '15

17 Nov '15

This worked great, thanks. I was able to copy and use the db files under Windows with no problem. -----Original Message----- >From: Richard Megginson <rmeggins(a)redhat.com> >Sent: Jun 18, 2007 2:54 PM >To: MJD Shop Account <mjdshop(a)earthlink.net>, "General discussion list for the Fedora Directory server project." <fedora-directory-users(a)redhat.com> >Subject: Re: [Fedora-directory-users] root certificate for use with startconsole > >MJD Shop Account wrote: >> How can I import the root certificate into my keystore used for startconsole? I would like to put it into my ~/.fedora-console/*db files. I'm assuming if I do so, that I won't need to accept new certificates that were issued by that root authority (they'll be automatically trusted). >> >You should be able to use the certutil program, with a -d >~/.fedora-console argument, and no -P argument. See >http://directory.fedoraproject.org/wiki/Howto:SSL#Import_the_CA_cert_into_a… >> I would like to do this under both Linux and Windows. If I need to use the utilities under Linux, should I be able to copy the resulting *db files to my Windows machine for use with the java console there? Or would the format be wrong? >> >The format is supposed to be platform and architecture independent. So >you should be able to just copy them to Windows. Make sure you set >binmode on in your Windows file transfer utilities so it won't try to >convert \n to \r\n when copying the files to Windows. >> Thanks, >> MJD >> >> -- >> Fedora-directory-users mailing list >> Fedora-directory-users(a)redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>

1 0

[Fedora-directory-users] constructing attribute from two others
by MJD Shop Account 17 Nov '15

17 Nov '15

Hi all, I am looking to make use of the password passthru module for authentication, but have been considering the best way to do so without modifying schema. Ultimately I may anyway, but here's the situation and question: I need to construct an identity to use for kerberos authentication, where the kerberos user principle will be the same as the 'uid' attribute already defined for the person + @ + the AD domain. The AD domain will be one of potentially 4 values depending on region; in my case really just one of two: "na.example.com" or "eu.example.com". So, can I construct an attribute on the fly which is built from two other attributes? I have already worked out that I can probably benefit from using a classic cosAttribute, defining 'locality' for each user as being 'NA' or 'EU' or possibly more specific values (what is locality generally used for? city? state? country?) and having a template which then defines the 'domain' attribute based on that locality. Maybe it is just as easy to store the domain attribute per user directly. Maybe I just make the locality equal to the proper domain. But I also can consider doing something where the domain would depend upon the range that the uidNumber is in, except I don't know how to do so. Sort of like a cosAttribute, but the value depends on the range of uidNumber, not a specific value. A bit like using a view. Any ideas? -M

1 0

Re: [Fedora-directory-users] ldap too many connections from clients? following ldap even for local accounts?
by MJD Shop Account 17 Nov '15

17 Nov '15

I tried playing with this under RH4 and thought it was not work, although it turns out I needed to reboot to get it recognized (is there a way to re-load pam after changing system-auth?) Changing the pam_unix.so line to 'sufficient' instead of 'required' worked in either the case of having the pam_succeed_if.so' line present or commented out. Leaving that line in, and leaving the pam_unix.so as 'required' also worked, but taking out pam_succeed_if.so and leaving pam_unix.so 'required' failed. And, I'm pretty sure having both pam_succeed_if.so present and having pam_unix.so 'required' failed too, until I rebooted. That is to say, given the machine was up and talking to ldap, if I just unplugged the network cable without rebooting, it failed for me. Since this was the setup before (ie not an issue with PAM recognizing a change) this still concerns me, but at least I know a reboot will get me out of any bind of not being able to log in as root. By the way, you might have noticed I had pam_deny.so commented out. I forget why, but I remember testing and thinking either it didn't work with that in, or made no sense to me. Would I be right in suspecting I should be adding it back in if I make pam_unix.so sufficient instead of required? If I don't will it allow anyone in? If I understand what's going on now, since nsswitch.conf has, for instance, 'passwd' with 'files ldap', the PAM setup is hitting ldap twice, once via pam_unix.so which sees the ldap by way off the nsswitch.conf nss_ldap.so, and then again if it were to invoke pam_ldap.so directly. This seems somewhat redundant, but I don't see a way out of it since I'm pretty sure all hell breaks loose if you don't have ldap in nsswitch.conf (since most regular users are defined on the ldap directory). ULtimately my goal is this: system accounts like root and other locally defined accounts take precedence over ldap, if they are defined locally and have a local password, it does not need to go through ldap or kerberos. On the other hand, because we are transitioning account management, I do have local accounts for users with locked local passwords, and I want the kerberos password to be effective. This seems to work in the current setup, I guess I need to verify it still does if I make this change. -----Original Message----- >From: George Holbert <gholbert(a)broadcom.com> >Sent: Mar 8, 2007 1:33 AM >To: MJD Shop Account <mjdshop(a)earthlink.net>, "General discussion list for the Fedora Directory server project." <fedora-directory-users(a)redhat.com> >Subject: Re: [Fedora-directory-users] ldap too many connections from clients? following ldap even for local accounts? > >For RHEL3, >change: >account required /lib/security/$ISA/pam_unix.so broken_shadow >to: >account sufficient /lib/security/$ISA/pam_unix.so broken_shadow > >Keep in mind that this will make the account stack succeed in most cases >before it hits pam_ldap, which means pam_ldap won't be used for enforcing >account policy. See below for an alternate method, if this matters for you. > >For RHEL4, disconnected root login _should_ already be working, beause of >the extra line: >account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 >quiet > >As you can probably tell, this line makes the stack succeed if the user's >uid is less than 100, which is of course true for root. > >The alternate RHEL3 fix would be to manually compile and deploy >pam_succeed_if.so on your RHEL3 clients, and use the same system-auth you >currently have on your RHEL4 clients. > > >----- Original Message ----- >From: "MJD Shop Account" <mjdshop(a)earthlink.net> >To: "George Holbert" <gholbert(a)broadcom.com>; "General discussion list for >the Fedora Directory server project." <fedora-directory-users(a)redhat.com> >Sent: Wednesday, March 07, 2007 8:13 PM >Subject: Re: [Fedora-directory-users] ldap too many connections from >clients? following ldap even for local accounts? > > >> My RH3 system-auth is as follows: >> #%PAM-1.0 >> # This file is auto-generated. >> # User changes will be destroyed the next time authconfig is run. >> auth required /lib/security/$ISA/pam_env.so >> auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok >> auth sufficient /lib/security/$ISA/pam_ldap.so use_first_pass >> auth sufficient /lib/security/$ISA/pam_krb5.so use_first_pass >> auth required /lib/security/$ISA/pam_deny.so >> >> account required /lib/security/$ISA/pam_unix.so broken_shadow >> account [default=bad success=ok user_unknown=ignore] >> /lib/security/$ISA/pam_ldap.so >> account [default=bad success=ok user_unknown=ignore] >> /lib/security/$ISA/pam_krb5.so >> #account required /lib/security/$ISA/pam_deny.so >> >> password requisite /lib/security/$ISA/pam_cracklib.so retry=3 >> password sufficient /lib/security/$ISA/pam_unix.so nullok >> use_authtok md5 shadow >> password sufficient /lib/security/$ISA/pam_ldap.so use_authtok >> password sufficient /lib/security/$ISA/pam_krb5.so use_authtok >> password required /lib/security/$ISA/pam_deny.so >> >> session required /lib/security/$ISA/pam_limits.so >> session required /lib/security/$ISA/pam_unix.so >> session optional /lib/security/$ISA/pam_ldap.so >> session optional /lib/security/$ISA/pam_krb5.so >> >> >> My RH4 version is the same, with this difference: >> --- system-auth.RH3 2006-10-25 22:49:19.000000000 -0400 >> +++ system-auth.RH4 2006-10-25 22:42:05.000000000 -0400 >> @@ -8,6 +8,7 @@ >> auth required /lib/security/$ISA/pam_deny.so >> >> account required /lib/security/$ISA/pam_unix.so broken_shadow >> +account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 >> quiet >> account [default=bad success=ok user_unknown=ignore] >> /lib/security/$ISA/pam_ldap.so >> account [default=bad success=ok user_unknown=ignore] >> /lib/security/$ISA/pam_krb5.so >> #account required /lib/security/$ISA/pam_deny.so >> >> >> -----Original Message----- >>>From: George Holbert <gholbert(a)broadcom.com> >>>Sent: Mar 7, 2007 8:42 PM >>>To: MJD Shop Account <mjdshop(a)earthlink.net>, "General discussion list for >>>the Fedora Directory server project." <fedora-directory-users(a)redhat.com> >>>Subject: Re: [Fedora-directory-users] ldap too many connections from >>>clients? following ldap even for local accounts? >>> >>>> If a machine is disconnected from the network, a login attempt as >>>> 'root' user (with local passwd file entry and password) fails. >>>> ... >>>> I think I need to configure something such that the nsswitch.conf >>>> entry tells it to stop if it finds the 'files' entry and not proceed >>>> to the 'ldap' entry. I thought this would happen by default. >>> >>>At least for authentication, this behavior depends also on your PAM >>>config. >>> >>>You need to make sure that the auth and account stacks will succeed for >>>local accounts (e.g., root) without asking pam_ldap. >>>What's in your /etc/pam.d/system-auth files on your RHEL3 and RHEL4 >>>clients? >>> >>> >>>MJD Shop Account wrote: >>>> I'm having some odd ldap issues with connection or lack thereof to >>>> ldap server when nsswitch.conf and pam.d/system-auth are configured to >>>> used FDS ldap server. >>>> >>>> I'm running both RHEL3 and RHEL4 clients. My servers are RHEL4 update >>>> 4 and FDS 1.0.4. My /etc/ldap.conf is configured with two host >>>> names. I've noticed these issues: >>>> >>>> * If a machine is disconnected from the network, a login attempt >>>> as 'root' user (with local passwd file entry and password) >>>> fails. The system appears to accept the password, but sits for >>>> maybe a minute, then dumps you back to the login prompt. I've >>>> had to boot off rescue CD and shell in to remove 'ldap' from >>>> the /etc/nsswitch.conf file to get around this in some instances. >>>> >>>> My relevant /etc/ldap.conf entries are: >>>> passwd: files ldap >>>> shadow: files >>>> group: files ldap >>>> netgroup: files ldap >>>> >>>> * I noticed that a anhy randomly chosen client has a few >>>> connections to the ldap server that persist. The connections >>>> are tied to processes that also should have local entries only >>>> in the local /etc/passwd files. Here's an example: >>>> # netstat -a | grep ldap >>>> tcp 38 0 clienthostname:32771 serverhostname:ldap >>>> CLOSE_WAIT >>>> # fuser 32771/tcp >>>> here: 32771 >>>> 32771/tcp: 3729 >>>> # ps -ef | grep 3729 | grep -v grep >>>> ntp 3729 1 0 Feb23 ? 00:00:00 ntpd -u ntp:ntp >>>> -p /var/run/ntpd.pid -g >>>> # >>>> >>>> * I notice that doing a "netstat -a" on the server that most >>>> clients are using takes a long time. It spits out a bunch, >>>> then slows down when reporting the entries that are ESTABLISHED >>>> ldap connections: >>>> tcp 0 0 ldapserver:ldap ldapclient:35908 ESTABLISHED >>>> I see that some clients have very many connections, I would >>>> expect just one or two. Here's one client that had a whole >>>> bunch, most disappeared before I could capture this bash shell >>>> command output. This output is for jobs associated with ports >>>> connecting to ldap server: >>>> # for i in `netstat -a | grep ldap | cut -d: -f2 | cut -d" " >>>> -f1`; do for j in `(fuser $i/tcp | cut -b 23-26)`; do ps -ef | >>>> grep $j | grep -v grep; done; done >>>> xfs 2726 1 0 Feb20 ? 00:00:00 xfs -droppriv >>>> -daemon >>>> root 3138 3031 0 Feb20 ? 00:00:00 >>>> /usr/bin/gdm-binary bell-style none >>>> root 3418 3138 0 18:32 ? 00:00:02 /usr/X11R6/bin/X >>>> :0 -auth /var/gdm/:0.Xauth vt7 >>>> gdm 3430 3138 0 18:32 ? 00:00:00 >>>> /usr/bin/gdmgreeter >>>> root 2477 2617 0 18:22 ? 00:00:01 sshd: root@pts/0 >>>> root 2481 2477 0 18:22 pts/0 00:00:00 -tcsh >>>> >>>> I ran a similar command on a client computer where the user is >>>> running a lot of jobs, I got 53 lines of output. Basically >>>> every job is maintaining an ldap connection, I guess. >>>> >>>> * I think I need to configure something such that the >>>> nsswitch.conf entry tells it to stop if it finds the 'files' >>>> entry and not proceed to the 'ldap' entry. I thought this would >>>> happen by default. >>>> >>>> * I think the above problem is possibly leading to many more ldap >>>> connections than are necessary which in turn may be causing >>>> performance issues on the server, ALTHOUGH the cpu load and >>>> memory load does not appear inordinately heavy >>>> >>>> * I tried running nscd (for caching the info) once, it seemed to >>>> cause too many problems so I turned it off. I have tried >>>> something like implementing pam_ccache, I don't think it would >>>> help the too-many-connections, just the issue with no logins >>>> when off the net. >>>> >>>> * Here's my /etc/ldap.conf minus the usual comment lines, I'm >>>> doing anonymous binds. Maybe there's some keepalive flag that >>>> should be set or unset?: >>>> host server1 server2 >>>> base dc=example,dc=com >>>> ldap_version 3 >>>> scope sub >>>> bind_timelimit 10 >>>> pam_lookup_policy yes >>>> pam_password exop >>>> nss_base_passwd ou=People,dc=example,dc=com?one >>>> nss_base_group ou=Group,dc=example,dc=com?one >>>> nss_base_services ou=Services,dc=example,dc=com?one >>>> nss_base_aliases ou=Aliases,dc=example,dc=com?one >>>> nss_base_netgroup ou=Netgroup,dc=example,dc=com?one >>>> ssl start_tls >>>> tls_checkpeer yes >>>> tls_cacertfile /usr/share/ssl/certs/servercert.pem >>>> tls_ciphers TLSv1 >>>> pam_password md5 >>>> >>>> Any suggestions on what I might be doing wrong are greatly appreciated! >>>> >>>> -Marty >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> -- >>>> Fedora-directory-users mailing list >>>> Fedora-directory-users(a)redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>>> >>> >>> >>> >> >> >> > >

1 0

Re: [Fedora-directory-users] not enough file descriptors
by MJD Shop Account 17 Nov '15

17 Nov '15

I found that the user limits were by default 1024 and I could not set the nsslapd-maxdescriptors higher than that, so I upped the default limits and changed nsslapd-maxdescriptors to 2048. We'll see how that works out. Thanks Richard and George! -----Original Message----- >From: Richard Megginson <rmeggins(a)redhat.com> >Sent: Mar 2, 2007 5:55 PM >To: MJD Shop Account <mjdshop(a)earthlink.net>, "General discussion list for the Fedora Directory server project." <fedora-directory-users(a)redhat.com> >Cc: George Holbert <gholbert(a)broadcom.com> >Subject: Re: [Fedora-directory-users] not enough file descriptors > >MJD Shop Account wrote: >> ah! only 1024. What is considered a reasonable value? Is it setting this or picking it up from the defaults such as ulimits? >> >The server sets this itself. So you have to set the value yourself. > >See http://www.redhat.com/docs/manuals/dir-server/pdf/ds71cli.pdf - >search for nsslapd-conntablesize and nsslapd-maxdescriptors >> I assume I need to do this on all of the multi-masters and consumers to be the same, or do I? Does it propagate? I'm not sharing the config tree among different servers. >> >> -----Original Message----- >> >>> From: George Holbert <gholbert(a)broadcom.com> >>> Sent: Mar 2, 2007 5:16 PM >>> To: MJD Shop Account <mjdshop(a)earthlink.net>, "General discussion list for the Fedora Directory server project." <fedora-directory-users(a)redhat.com> >>> Subject: Re: [Fedora-directory-users] not enough file descriptors >>> >>> What is the value of the "nsslapd-maxdescriptors" attribute on cn=config? >>> >>> MJD Shop Account wrote: >>> >>>> I have a problem with running out of file descriptors. I get this repeating message periodically in the /opt/fedora-ds/slapd-<servername>/logs/errors file: >>>> [02/Mar/2007:13:25:45 -0500] - Not listening for new connections - too many fds open >>>> [02/Mar/2007:13:25:46 -0500] - Listening for new connections again >>>> [02/Mar/2007:13:25:47 -0500] - Not listening for new connections - too many fds open >>>> [02/Mar/2007:13:25:47 -0500] - Listening for new connections again >>>> ... >>>> >>>> When this happens, the users cannot log in for long periods and get angry. Imagine that. I do have this in a multi-master configuration with a second master, which is different hardware and does not show this error. >>>> >>>> I read the tuning page http://directory.fedora.redhat.com/wiki/Performance_Tuning#Linux, which recommends updating the filedescriptors limit like so: >>>> echo "64000" > /proc/sys/fs/file-max >>>> >>>> However mine is already well above that: >>>> # cat /proc/sys/fs/file-max >>>> 128456 >>>> >>>> How much higher should I be setting it? I am running RHEL 4 update 4, single Pentium III 1.4GHz processor, 1280MB of memory. >>>> >>>> I don't have any settinsg in sysctl.conf or /etc/security/limites for soft/hard limits, how do I tell what the defaults on soft/hard limits are? >>>> >>>> -- >>>> Fedora-directory-users mailing list >>>> Fedora-directory-users(a)redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>>> >>>> >>>> >>> >>> >> >> -- >> Fedora-directory-users mailing list >> Fedora-directory-users(a)redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>

1 0

ACIs caching issue
by Adrian Damian 16 Nov '15

16 Nov '15

Hello 389 Gurus, This is a very subtle issue that we are seeing on our LDAP server. Sometimes, the ACIs return different results for the same search executed from different clients (a Java client vs. a Python or the ldapsearch client). More specifically, the Java client does not get access to attributes that is supposed to see but the Python client does. What's even more strange is that after the Python client or ldapsearch client access, the Java client also starts working for a while and then stops again. The only difference that we've seen in these two cases in the LDAP logs is that when it doesn't work, the Java client makes the server skip the ACI that grants access with the message: "Found READ SKIP in cache". After running the other clients the ACI in question is evaluated and everything works for a while before going back into the bad state. Any ideas of how to fix this? Thank you, Adrian Server version: 389-Directory/1.2.11.15 B2014.219.179

2 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users November 2015