January 2019 - FreeIPA-users - Fedora mailing-lists

orphan certificate key Issue
by Uzor Ide 15 Jan '19

15 Jan '19

Hello All, I upgraded our ipa server and after the upgrade ipa won't start again. further investigation shows that components of ipa starts but pki-tomcatd(a)pki-tomcat.service appears to be where the issue lies. checking the logs suggested that issue lies in the certificate database. on checking the directory /etc/pki/pki-tomcat/alias with certutils [namead@ipasvr01 alias]$ sudo certutil -K -d . -f pwdfile.txt certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services" < 0> rsa 9bb20dbec9d8dd63e1db53b0662eaf37a1518bf9 ocspSigningCert cert-pki-ca < 1> rsa 49d9f7a5f5ab3ed93d4037676b1bf9e236b89d0f subsystemCert cert-pki-ca < 2> rsa df374a636d9a424aaefefc6367dcb868f82f536d Server-Cert cert-pki-ca *< 3> rsa 7cebd0bbadddd5e581c328a99982e0ef5172d61f (orphan)* < 4> rsa 52839be82200bb2a9ff2034629c53cd90a0575a8 auditSigningCert cert-pki-ca < 5> rsa c4a6d42c22a874a69231a2d7446bccfe9ce0cbaa caSigningCert cert-pki-ca Any help in the deleting the key would be appreciated. Thanks _Uz

3 7

Abstracted NTP server configuration
by Rob Crittenden 15 Jan '19

15 Jan '19

A PR to support multiple NTP servers was submitted in https://github.com/freeipa/freeipa/pull/2169 This spawned a design at https://www.freeipa.org/page/V4/NTP_Servers_Configuration We need to discuss the design. rob

5 15

ipa services continue to fail
by Andrew Meyer 14 Jan '19

14 Jan '19

Currently in my environment I have 6 servers 2 in my local office and 2 in each region in AWS. The AWS servers are all running CentOS 7.x with FreeIPA 4.5.x running on all 6. The AWS servers are all t2.medium w/ unlimited turned on. Occasionally we issues with all 6 where one of the processes for freeipa stops working completely. This could be the ipa.service or the named-pkcs11, or dirsrv(a)MYREALM.ORG. Sometimes it will be resource constraints, other times the whole system could come to a crawl for no reason whatsoever. Looking through the IPA logs doesn't always tell me what was going on. I usually have to restart the service or reboot the whole instance/machine to get it back to a working state. Also as of right now i'm seeing that dirsrv(a)MYREALM.NET will not start because a configured resource limit was exceeded. Here is the error i'm getting all of a sudden: ● dirsrv(a)EXAMPLE.NET.service - 389 Directory Server EXAMPLE.NET. Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: disabled) Active: failed (Result: resources) Jan 14 19:55:21 freeipa01.west.example.net systemd[1]: Failed to load environment files: No such file or directoryJan 14 19:55:21 freeipa01.west.example.net systemd[1]: dirsrv(a)EXAMPLE.NET.service failed to run 'start-pre' task: No such file or directoryJan 14 19:55:21 freeipa01.west.example.net systemd[1]: Failed to start 389 Directory Server EXAMPLE.NET..Jan 14 19:55:21 freeipa01.west.example.net systemd[1]: Unit dirsrv(a)EXAMPLE.NET.service entered failed state.Jan 14 19:55:21 freeipa01.west.example.net systemd[1]: dirsrv(a)EXAMPLE.NET.service failed.Jan 14 19:55:21 freeipa01.west.example.net systemd[1]: Starting 389 Directory Server EXAMPLE.NET....[andrew.meyer@freeipa01 ~]$ Here is a snippet from the logs:/var/log/dirsrv/slapd-EXAMPLE-NET/errors [14/Jan/2019:19:51:42.631413149 +0000] - NOTICE - ldbm_back_start - found 3880412k physical memory[14/Jan/2019:19:51:42.632553293 +0000] - NOTICE - ldbm_back_start - found 3273584k available[14/Jan/2019:19:51:42.633584210 +0000] - NOTICE - ldbm_back_start - cache autosizing: db cache: 97010k[14/Jan/2019:19:51:42.634560420 +0000] - NOTICE - ldbm_back_start - cache autosizing: userRoot entry cache (3 total): 131072k[14/Jan/2019:19:51:42.636236633 +0000] - NOTICE - ldbm_back_start - cache autosizing: userRoot dn cache (3 total): 65536k[14/Jan/2019:19:51:42.639592221 +0000] - NOTICE - ldbm_back_start - cache autosizing: ipaca entry cache (3 total): 131072k[14/Jan/2019:19:51:42.641296133 +0000] - NOTICE - ldbm_back_start - cache autosizing: ipaca dn cache (3 total): 65536k[14/Jan/2019:19:51:42.643594212 +0000] - NOTICE - ldbm_back_start - cache autosizing: changelog entry cache (3 total): 131072k[14/Jan/2019:19:51:42.645241367 +0000] - NOTICE - ldbm_back_start - cache autosizing: changelog dn cache (3 total): 65536k[14/Jan/2019:19:51:42.646916994 +0000] - NOTICE - ldbm_back_start - total cache size: 683450613 B;[14/Jan/2019:19:51:42.650449731 +0000] - NOTICE - dblayer_start - Detected Disorderly Shutdown last time Directory Server was running, recovering database.[14/Jan/2019:19:51:49.346656922 +0000] - ERR - schema-compat-plugin - scheduled schema-compat-plugin tree scan in about 5 seconds after the server startup![14/Jan/2019:19:51:49.544963162 +0000] - ERR - NSACLPlugin - acl_parse - The ACL target cn=groups,cn=compat,dc=example,dc=net does not exist[14/Jan/2019:19:51:49.564630973 +0000] - ERR - NSACLPlugin - acl_parse - The ACL target cn=computers,cn=compat,dc=example,dc=net does not exist[14/Jan/2019:19:51:49.584635724 +0000] - ERR - NSACLPlugin - acl_parse - The ACL target cn=ng,cn=compat,dc=example,dc=net does not exist[14/Jan/2019:19:51:49.604545604 +0000] - ERR - NSACLPlugin - acl_parse - The ACL target ou=sudoers,dc=example,dc=net does not exist[14/Jan/2019:19:51:49.624542861 +0000] - ERR - NSACLPlugin - acl_parse - The ACL target cn=users,cn=compat,dc=example,dc=net does not exist[14/Jan/2019:19:51:49.684538158 +0000] - ERR - NSACLPlugin - acl_parse - The ACL target cn=ad,cn=etc,dc=example,dc=net does not exist[14/Jan/2019:19:51:49.825646593 +0000] - ERR - NSACLPlugin - acl_parse - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=example,dc=net does not exist[14/Jan/2019:19:51:49.844539895 +0000] - ERR - NSACLPlugin - acl_parse - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=example,dc=net does not exist[14/Jan/2019:19:51:49.990796503 +0000] - ERR - NSACLPlugin - acl_parse - The ACL target cn=automember rebuild membership,cn=tasks,cn=config does not exist[14/Jan/2019:19:52:00.365183146 +0000] - NOTICE - NSMMReplicationPlugin - changelog program - _cl5ConstructRUV - Rebuilding the replication changelog RUV, this may take several minutes...[14/Jan/2019:19:52:00.445692209 +0000] - NOTICE - NSMMReplicationPlugin - changelog program - _cl5ConstructRUV - Rebuilding replication changelog RUV complete. Result 0 (Success)[14/Jan/2019:19:52:00.446842275 +0000] - NOTICE - NSMMReplicationPlugin - changelog program - _cl5ConstructRUV - Rebuilding the replication changelog RUV, this may take several minutes...[14/Jan/2019:19:52:00.513081196 +0000] - NOTICE - NSMMReplicationPlugin - changelog program - _cl5ConstructRUV - Rebuilding replication changelog RUV complete. Result 0 (Success)[14/Jan/2019:19:52:00.514432537 +0000] - NOTICE - NSMMReplicationPlugin - changelog program - _cl5ConstructRUV - Rebuilding the replication changelog RUV, this may take several minutes...[14/Jan/2019:19:52:00.515614720 +0000] - NOTICE - NSMMReplicationPlugin - changelog program - _cl5ConstructRUV - Rebuilding replication changelog RUV complete. Result 0 (Success)[14/Jan/2019:19:52:00.516689146 +0000] - NOTICE - NSMMReplicationPlugin - changelog program - _cl5ConstructRUV - Rebuilding the replication changelog RUV, this may take several minutes...[14/Jan/2019:19:52:00.517810761 +0000] - NOTICE - NSMMReplicationPlugin - changelog program - _cl5ConstructRUV - Rebuilding replication changelog RUV complete. Result 0 (Success)[14/Jan/2019:19:52:00.526034848 +0000] - WARN - NSMMReplicationPlugin - replica_check_for_data_reload - Disorderly shutdown for replica o=ipaca. Check if DB RUV needs to be updated[14/Jan/2019:19:52:00.584599421 +0000] - ERR - set_krb5_creds - Could not get initial credentials for principal [ldap/freeipa01.west.example.net(a)EXAMPLE.NET] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm)[14/Jan/2019:19:52:00.604610301 +0000] - WARN - NSMMReplicationPlugin - replica_check_for_data_reload - Disorderly shutdown for replica dc=example,dc=net. Check if DB RUV needs to be updated[14/Jan/2019:19:52:00.624573161 +0000] - ERR - set_krb5_creds - Could not get initial credentials for principal [ldap/freeipa01.west.example.net(a)EXAMPLE.NET] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm)[14/Jan/2019:19:52:00.644588420 +0000] - NOTICE - NSMMReplicationPlugin - Force update of database RUV (from CL RUV) -> 5c3cdd700000001b0000[14/Jan/2019:19:52:00.675318674 +0000] - INFO - slapd_daemon - slapd started. Listening on All Interfaces port 389 for LDAP requests[14/Jan/2019:19:52:00.684551689 +0000] - INFO - slapd_daemon - Listening on All Interfaces port 636 for LDAPS requests[14/Jan/2019:19:52:00.704669406 +0000] - INFO - slapd_daemon - Listening on /var/run/slapd-EXAMPLE-NET.socket for LDAPI requests[14/Jan/2019:19:52:00.752022024 +0000] - ERR - schema-compat-plugin - schema-compat-plugin tree scan will start in about 5 seconds![14/Jan/2019:19:52:04.456691971 +0000] - ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meTofreeipa03.east.example.net" (freeipa03:389) - Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) ()[14/Jan/2019:19:52:05.055410972 +0000] - ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meTofreeipa02.west.example.net" (freeipa02:389) - Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) ()[14/Jan/2019:19:52:06.180112049 +0000] - ERR - schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=example,dc=net[14/Jan/2019:19:52:06.225167327 +0000] - ERR - schema-compat-plugin - Finished plugin initialization.[14/Jan/2019:19:52:09.118232562 +0000] - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meTofreeipa02.west.example.net" (freeipa02:389): Replication bind with GSSAPI auth resumed[14/Jan/2019:19:52:09.417962320 +0000] - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meTofreeipa03.east.example.net" (freeipa03:389): Replication bind with GSSAPI auth resumed For the on premise freeipa servers I have upgraded the RAM/CPU to 4x4. However I wanted to reach out to the mailing list to find out what to do about the servers in AWS. Regards,

1 0

Peer certificate cannot be authenticated with given CA certificates
by Petr Benas 14 Jan '19

14 Jan '19

Hello, we have an issue with resubmitting several certificates. We suspect the reason might be the encoding mismatch between the certificate and the CA certificate. Our environment was upgraded during the years from some 3.x version to current 4.5.4. So the very first CA certificate was encoded in PRINTABLESTRING. Issuer: organizationName = PRINTABLESTRING:EXAMPLE.COM commonName = PRINTABLESTRING:Certificate Authority Validity Not Before: Dec 1 14:14:37 2014 GMT Not After : Dec 1 14:14:37 2034 GMT Subject: organizationName = PRINTABLESTRING:EXAMPLE.COM commonName = PRINTABLESTRING:Certificate Authority When we renew-ed (due to SHA1) we got to PRINTABLESTRING X UTF8STRING and after we renewed again, so now we have: Issuer: organizationName = UTF8STRING:EXAMPLE.COM commonName = UTF8STRING:Certificate Authority Validity Not Before: Oct 9 07:34:24 2017 GMT Not After : Oct 9 07:34:24 2037 GMT Subject: organizationName = UTF8STRING:EXAMPLE.COM commonName = UTF8STRING:Certificate Authority And most certificated were renewed fine. However, recently we noticed that several certificated can't be resubmitted, all of them seem to be like this: Issuer: organizationName = PRINTABLESTRING:EXAMPLE.COM commonName = PRINTABLESTRING:Certificate Authority Validity Not Before: Nov 24 12:17:12 2016 GMT Not After : Nov 14 12:17:12 2018 GMT Subject: organizationName = UTF8STRING:EXAMPLE.COM commonName = UTF8STRING:ipa07.example.com The error when resubmitting is: Peer certificate cannot be authenticated with given CA certificates. The tcpdump from 8443 says Unknown CA. Is the assumption that the encoding mismatch is blocking the submitting certificate correct? One of the certificate which we also can't renew is the 'IPA RA' (/var/lib/ipa/ra-agent.pem) What we tried: Add all versions of CA certificate to /etc/pki/pki-tomcat/alias trust store (also add them one-by-one) Setting date back before the expiration. Advises from: https://rcritten.wordpress.com/2017/09/20/peer-certificate-cannot-be-authen… Deleting the related CSR from o=ipaca, supposing that newly generated csr will be fine. Any suggestions what else we could try? Thanks Petr

2 2

Ldap authentication
by Alex Severov 13 Jan '19

13 Jan '19

Hello. I have ipa with ad integration. I want to install nextcloud with ldap authentication. I used this document https://www.freeipa.org/page/Owncloud_Authentication_against_FreeIPA I changed ldap tree to compat. But I can't login in nextcloud with ad user password! Wat's wrong? -- Alex Severov

1 0

FreeIPA for the maximally paranoid and overworked?
by K. M. Peterson 13 Jan '19

13 Jan '19

Hi all, This is a newbie question with respect to FreeIPA, and I haven't seen this elsewhere, so I thought I'd ask. I've just cleaned up an issue with trying to implement a new replica on our domain, and I've realized that there are a couple of areas I don't understand that are causing more stress than I need at this point, for I am maximally paranoid and overworked, and I need some advice on how not to make that worse when implementing FreeIPA. I've been reading this list on and off for most of the last year, and what's struck me is how complicated this project is, especially of course areas where I personally have less expertise (e.g., LDAP, Kerberos). Implementing and managing this is just one of my jobs, and our IdM becomes more critical as time goes on, so I need to understand a few things. Question 1: As I just had, for the first time, to manually modify LDAP to remove data, I'd like to understand how taking that approach can backfire. In other words, it's clear this isn't habitually a good idea, because mistakes will replicate, for example. But, where are the real danger points: for example, I've seen stories of having to recover a server in an environment where the time was intentionally set back to allow an operation on an expired cert. As with a database update that triggers other (unexpected) changes, are there LDAP operations that can't practically be "un-done"? I know that deleting records is permanent (obvious), but are there gotchas like changing a particular object fires some large number of events that there's no way to revert? Or, in colloquial terms, are there places that are really, really bad to try to outwit the management interfaces? I'm not talking everyday updates, but instances where we get stuck (as I was yesterday and today)? Question 2: How to stay safe. Our installation on a small network as a pair of masters replicating with each other, CA and DNS installed on both. They are VMs allocated on separate physical hosts. Before updates, I snapshot both for recovery purposes. I update one at a time, now, and ensure that they're functional before doing the other one (I know that schema changes will propagate before service is applied elsewhere, but I can't do anything else about that). I haven't had to deal with the question of how to make sure my (self-signed) CA certificate doesn't expire, but I know when it will and am leaving myself ample time to understand that. I'm about to start pushing out this functionality to multiple geos, again at small-ish scale, and I'm reading the topology references to be sure I understand what I'm doing. But: what am I missing? I get the impression that trying to (conventionally) "back up" data isn't useful. I've tried to design the network to make it as simple as possible to meet our needs. Does anyone else have anything to add in the sense of "best practices", or to echo my first question "there be dragons <here>"? I've learned a lot from this list, and I'd also like to add a thank you to everyone here who have helped with that! I do see this getting better and better, and it's appreciated.

3 4

Web UI login/certificate issues, IPA 4.5.4
by dbischof＠hrz.uni-kassel.de 12 Jan '19

12 Jan '19

Hi, my IPA system consists of 2 masters with their own self-signed CAs, one of them being the certificate renewal master (ipa1). The system has been running for years and has been migrated from an IPA 3 system. Since a while, the Web UI logins on ipa1 don't work anymore ("Login failed due to an unknown reason."). Web UI logins on the other server (ipa2) work and everything else is working fine, too, ipactl status reports all services running. On login attempt: --- httpd log [...] [:error] [pid 15551] [remote 141.51.X.X:0] mod_wsgi (pid=15551): Exception occurred processing WSGI script '/usr/share/ipa/wsgi.py'. [...] [:error] [pid 15551] [remote 141.51.X.X:0] CalledProcessError: Command '/usr/bin/kinit -n -c /var/run/ipa/ccaches/armor_15551 -X X509_anchors=FILE:/var/kerberos/krb5kdc/kdc.crt -X X509_anchors=FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem' returned non-zero exit status 1 --- --- krb5kdc.log [...] Dec 20 16:06:54 ipa1.example.com krb5kdc[15517](info): AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 141.51.X.Y: NEEDED_PREAUTH: WELLKNOWN/ANONYMOUS(a)EXAMPLE.COM for krbtgt/EXAMPLE.COM(a)EXAMPLE.COM, Additional pre-authentication required Dec 20 16:06:54 ipa1.example.com krb5kdc[15517](info): closing down fd 11 Dec 20 16:06:54 ipa1.example.com krb5kdc[15518](info): AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 141.51.X.Y: KDC_RETURN_PADATA: WELLKNOWN/ANONYMOUS(a)EXAMPLE.COM for krbtgt/EXAMPLE.COM(a)EXAMPLE.COM, Failed to verify own certificate (depth 0): certificate has expired Dec 20 16:06:54 ipa1.example.com krb5kdc[15518](info): closing down fd 11 --- --- ipa-checkcerts.py IPA version 4.5.4-10.el7.centos.3 Check CA status Check tracking Check NSS trust Check dates Checking certificates in CS.cfg Comparing certificates to requests in LDAP Checking RA certificate Checking authorities Checking host keytab Validating certificates Checking renewal master End-to-end cert API test Checking permissions and ownership Failures: Unable to find request for serial 268304391 Unable to find request for serial 268304394 Unable to find request for serial 268304393 Unable to find request for serial 268304392 Subject O=EXAMPLE.COM,CN=ipa2.example.com and template subject CN=ipa1.example.com,O=EXAMPLE.COM do not match for serial 57 --- --- ipa pkinit-status --all ----------------- 2 servers matched ----------------- Server name: ipa2.example.com PKINIT status: enabled Server name: ipa1.example.com PKINIT status: enabled ---------------------------- Number of entries returned 2 ---------------------------- To my understanding, proper certificate exchange between my two servers ceased working at some point. How do i track this down and fix it? Mit freundlichen Gruessen/With best regards, --Daniel.

2 14

kinit: Password incorrect while getting initial credentials
by nandha kumar 12 Jan '19

12 Jan '19

Hi Team, I am running redhat 7.5 with freeipa 4.5 . I have established AD one way sync using password. I am able to ssh the ipa client and ipa server with windows administrator account , But when I try to login with normal AD user I am receiving the error " kinit: Password incorrect while getting initial credentials" ipa --version VERSION: 4.5.4, API_VERSION: 2.228 KRB5_TRACE=/dev/stdout kinit -V nandha.kumaravel(a)apxxx.xxx [28904] 1546967107.58765: Resolving unique ccache of type KEYRING Using new cache: persistent:0:krb_ccache_nLG0yqq [28904] 1546967107.58777: Response was not from master KDC [28904] 1546967107.58778: Received error from KDC: -1765328359/Additional pre-authentication required [28904] 1546967107.58781: Processing preauth types: 16, 15, 19, 2 [28904] 1546967107.58782: Selected etype info: etype aes256-cts, salt "APRIM.XXX nandha.kumaravel", params "" [28904] 1546967107.58783: PKINIT client has no configured identity; giving up [28904] 1546967107.58784: PKINIT client has no configured identity; giving up [28904] 1546967107.58785: Preauth module pkinit (16) (real) returned: 22/Invalid argument [28904] 1546967107.58786: PKINIT client has no configured identity; giving up [28904] 1546967107.58787: Preauth module pkinit (14) (real) returned: 22/Invalid argument Password for nandha.kumaravel(a)aprim.xxx: [28904] 1546967125.768563: AS key obtained for encrypted timestamp: aes256-cts/675E [28904] 1546967125.768565: Encrypted timestamp (for 1546967099.435765): plain 301AA011180F32303139303130383137303435395AA105020306A635, encrypted D03014021DFD2120B8EC876B6A6568CEC53DFFE6AB5003028B81A18173717C2C14259C5002A41900A974FF0E2F372EECB9E7F4836AE0DD43 [28904] 1546967125.768566: Preauth module encrypted_timestamp (2) (real) returned: 0/Success [28904] 1546967125.768567: Produced preauth for next request: 2 [ [28904] 1546967125.768577: Response was not from master KDC [28904] 1546967125.768578: Received error from KDC: -1765328360/Preauthentication failed [28904] 1546967125.768580: Preauth tryagain input types: 16, 14, 19, 2 [28904] 1546967125.768581: Retrying AS request with master KDC [28904] 1546967125.768582: Getting initial credentials for nandha.kumaravel(a)aprim.xxx [28904] 1546967125.768584: Sending request (182 bytes) to aprim.xxx (master) kinit: Password incorrect while getting initial credentials

3 4

Re: Testing requested - certificate checking tool
by SOLER SANGUESA Miguel 11 Jan '19

11 Jan '19

Hello, I have run the tool on an environment where I've installed my own certificate for HTTPS (following this tutorial: https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP), and it complains when find the root certificate of my certificate: # python2 ipa-checkcerts.py ipa: INFO: IPA version 4.6.4-10.el7 IPA version 4.6.4-10.el7 ipa: INFO: Check CA status Check CA status ipa: INFO: Check tracking Check tracking ipa: INFO: Check NSS trust Check NSS trust Traceback (most recent call last): File "ipa-checkcerts.py", line 931, in <module> sys.exit(c.run()) File "ipa-checkcerts.py", line 190, in run self.check_trust() File "ipa-checkcerts.py", line 439, in check_trust expected = expected_trust[nickname] KeyError: 'ICC-root' Is this normal? Because I have tried to add a RHEL 6 client and I get the error: " Successfully retrieved CA cert Subject: CN=Certificate Authority,O=IPA.TESTAD.LOCAL Issuer: CN=Certificate Authority,O=IPA.TESTAD.LOCAL Valid From: Mon Jan 30 10:52:18 2017 UTC Valid Until: Fri Jan 30 10:52:18 2037 UTC Joining realm failed: libcurl failed to execute the HTTP POST transaction. Peer certificate cannot be authenticated with known CA certificates" Thanks & Regards.

3 9

dirsrv replicas crashing with FD errors
by xcorvis＠gmail.com 10 Jan '19

10 Jan '19

I recently reinstalled a couple of our freeipa replicas and they're both falling over with the same error. They run for a few minutes - as little as one, or up to an hour, and then fall over with thousands of errors like this: > ERR - accept_and_configure - PR_Accept() failed, Netscape Portable Runtime error -5971 (Process open FD table is full.) Eventually we get some db errors and dirsrv crashes (which presumably is related to the FD table being full). I'm unable to determine why the table is filling. While they're up, the 2 failing replicas work fine (web, ldap) and seem to have all the appropriate info. The server they're being replicated from is fine, no notable errors, but it only has about 180 servers hitting it. There's another replica with no clients that works fine, no issues. These two servers used to work fine before I reinstalled the replicas (I have not changed the OS). It's a pretty small directory and we've got a couple thousand servers hitting the two failing replicas. They were recently updated from ipa-server 4.4 to 4.6, and used to work fine, the errors started after I rebuilt them. (BTW, I'm not the person who built the originals.) The logs are not very giving me much in the way of clues. File handles are set in /etc/sysconfig/dirsrv to 32k, which should be more than enough, it was previously set to 16k. It hasn't gotten any busier than it used to be, so I don't feel like the file handle issue is simply due to being sized wrong. Debug logging generated a lot of output but nothing I could clearly identify as being an issue. I'm at a loss. What should I be checking? Versions: CentOS Linux release 7.6.1810 (Core) ipa-common-4.6.4-10.el7.centos.noarch ipa-server-4.6.4-10.el7.centos.x86_64 ipa-client-4.6.4-10.el7.centos.x86_64 python2-ipalib-4.6.4-10.el7.centos.noarch ipa-client-common-4.6.4-10.el7.centos.noarch python2-ipaserver-4.6.4-10.el7.centos.noarch ipa-server-common-4.6.4-10.el7.centos.noarch sssd-ipa-1.16.2-13.el7.x86_64 389-ds-base-libs-1.3.8.4-18.el7_6.x86_64 389-ds-base-1.3.8.4-18.el7_6.x86_64 Thanks, --Adam

1 1

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users January 2019