Re: [Freeipa-users] LDAP replication conflicts, but no apparent data damage

Yes, along with two name-conflicted "duplicates": [cid:image001.png@01D26664.649DC670] [id:image001.jpg@01D1C26F.0E28FA60] Daniel Alex Finkelstein| Lead Dev Ops Engineer dan.finkelst...@h5g.com | 212.604.3447 One World Trade Center,

[Freeipa-users] ldap_rename: Operations error (1)

I'm running FreeIPA 4.4.0 on CentOS 7.3 and I almost succeeded in renaming a duplicate, but then this happens: modifying rdn of entry "cn=ipaservers+nsuniqueid=9865b29e-c9a411e6-a937f721-75eb0f97,cn=hostgroups,cn=accounts,dc=test,dc=local" ldap_rename: Operations error (1) The commands were: $

[Freeipa-users] IPA 4.4.0: clcache_load_buffer_bulk error

Since upgrading to IPA 4.4.0 and CentOS-7.3, our master has been outputting the follow line repeatedly in its slapd error logs: [24/Dec/2016:08:11:36.684385818 +] clcache_load_buffer_bulk - changelog record with csn (585e436900150004) not found for DB_NEXT What does it mean and, if

Re: [Freeipa-users] Disabling Anonymous Binds (LDAP)

I'm on FreeIPA 4.x [id:image001.jpg@01D1C26F.0E28FA60] Daniel Alex Finkelstein| Lead Dev Ops Engineer dan.finkelst...@h5g.com | 212.604.3447 One World Trade Center, New York, NY 10007 www.high5games.com Play

[Freeipa-users] Disabling Anonymous Binds (LDAP)

I've seen some discussion in the (distant) past about disabling anonymous binds to the LDAP component of IPA, and I'm wondering if there's a preferred method to do it. Further, are there any known problems with disabling anonymous binds when using FreeIPA? The only modern documentation I can

Re: [Freeipa-users] FreeIPA 4.2.0 CentOS 7: DNS zone forwarding

There was a solution: explicitly disable DNSSEC in /etc/named.conf on all IPA masters/replicas and restart the named-pkcs11 service. After that, zone forwarding worked as expected. Thanks, Dan [cid:image001.jpg@01D1DEA7.77DC3540] Daniel Alex Finkelstein| Lead Dev

Re: [Freeipa-users] FreeIPA 4.2.0 CentOS 7: DNS zone forwarding

To give this a little more context, I've tried this: [root@ipa ~]# ipa dnsforwardzone-add example2.com. --forwarder=10.55.10.151 --forward-policy=only Server will check DNS forwarder(s). This may take some time, please wait ... ipa: WARNING: DNSSEC validation failed: record 'example2.com. SOA'

[Freeipa-users] FreeIPA 4.2.0 CentOS 7: DNS zone forwarding

Hi all, I'm trying to follow the directions (and cautions) from here: http://www.freeipa.org/page/V4/Forward_zones, but when I add a new zone (example2.com) and a forwarding address and set the zone to forward-only, no records are returned for hosts like, say, testhost.example2.com. The NS

Re: [Freeipa-users] CentOS 7 & FreeIPA 4.2: DNS resolution at the top-level domain/zone

Solution found (or, if not, a workaround): IPA replicas must be named in the root domain/zone and not in a subdomain, else DNS fails to serve records in the root domain. Once we changed our configuration to reflect this, DNS returned to normal. —Dan

Re: [Freeipa-users] CentOS 7 & FreeIPA 4.2: DNS resolution at the top-level domain/zone

Hi Petr, Top level means the root zone of the various DNS trees we serve. For example, h5g.com would be the root and dev.h5g.com, test.h5g.com, etc., would be the subdomains. Our subdomains query fine, but any hosts in the root domain no longer resolve. An example of an unresolvable name is

Re: [Freeipa-users] CentOS 6.8: uninstalling IPA client causes python error

Oh, I disabled that first. I turn on services and restrictions one-by-one after things are working, not before. —Dan [cid:image001.jpg@01D1CB7D.8BC9E530] Daniel Alex Finkelstein| Lead Dev Ops Engineer dan.finkelst...@h5g.com |

[Freeipa-users] CentOS 7 & FreeIPA 4.2: DNS resolution at the top-level domain/zone

We've recently set up a "clean" install of FreeIPA replete with replicas, but we just noticed an odd behavior in the DNS service: hosts in the top level domain (like ipa.example.com) do not resolve, whereas hosts in subdomains (like ipa.dev.example.com) do. I'm not sure what to look for in the

Re: [Freeipa-users] CentOS 6.8: uninstalling IPA client causes python error

Epilogue: While I couldn't solve the python error, I did manage to uninstall the ipa client and sssd components, then delete /var/lib/ipa-client (which was causing the ipa-client-install program to think that it was already registered). After reinstalling the ipa client and sssd components,

[Freeipa-users] CentOS 6.8: uninstalling IPA client causes python error

We're rebinding clients from IPA 3 to IPA 4 and two CentOS 6.8 servers are giving us grief. When we try to run the uninstall program via "ipa-client-install --uninstall", we get: [root@localhost ~]# ipa-client-install --uninstall -U -f Disabling client Kerberos and LDAP configurations

[Freeipa-users] CentOS 7, FreeIPA 4.2: slapd crashes soon after launch

Our FreeIPA master was working fine for about a day and then, apropos of nothing, the LDAP component started to crash with nary an error message. Obviously, with it down we can log into the WebUI nor can we query the status of the components or retrieve data. In

[Freeipa-users] FreeIPA 4.2, CentOS 7: WebUI login "Decrypt integrity check failed" after restore

We restored data (just the data) from an ipa-backup on a newly-installed and configured host and with an LDAP browser we can see the data; however, the DNS data doesn't appear to be available over port 53 (selinux & firewall deactivated) and we can't login as any of the preserved users. In the

Re: [Freeipa-users] FreeIPA 4.2.0: An error has occurred (IPA Error 4301: CertificateOperationError)

And, from the 'ipactl -d --ignore-service-failures restart' we get this: ipa: DEBUG: stderr= ipa: DEBUG: wait_for_open_ports: localhost [8080, 8443] timeout 300 ipa: DEBUG: Waiting until the CA is running ipa: DEBUG: Starting external process ipa: DEBUG: args='/usr/bin/wget' '-S' '-O' '-'

Re: [Freeipa-users] FreeIPA 4.2.0: An error has occurred (IPA Error 4301: CertificateOperationError)

That’s exactly right, and we got the files and links back to serviceable order. Now we're (merely) facing issues with our restored certificate store, which the pki-tomcatd process is not happy with. All IPA services start normally except for tomcat, which spits out SSL errors (and we're pretty

Re: [Freeipa-users] FreeIPA 4.2.0: An error has occurred (IPA Error 4301: CertificateOperationError)

An update: The journalctl command has some really interesting output: Jun 10 11:16:23 ipa.example.com pkidaemon[25032]: WARNING: Symbolic link '/var/lib/pki/pki-tomcat/alias' does NOT exist! Jun 10 11:16:23 ipa.example.com pkidaemon[25032]: INFO: Attempting to create

[Freeipa-users] FreeIPA 4.2.0: An error has occurred (IPA Error 4301: CertificateOperationError)

I have a promoted CA master/FreeIPA 4.2.0 instance on CentOS 7 that emits this error in the httpd logs whenever the WebUI tries to see the certificates page: [Wed Jun 08 16:56:27.052106 2016] [:error] [pid 2863] ipa: ERROR: ipaserver.plugins.dogtag.ra.find(): Unable to communicate with CMS

Re: [Freeipa-users] Replica without CA: implications?

If, after identifying the dangling RUVs and attempting to clean them, you see this: [root@ipa-replica ~]# ipa-replica-manage clean-ruv 104 Clean the Replication Update Vector for ipa.example.com:389 Cleaning the wrong replica ID will cause that server to no longer replicate so it may miss

Re: [Freeipa-users] FreeIPA 4.2.0 on CentOS 7.2 as replica of FreeIPA 3.0.0 on CentOS 6.8; cannot install CA components as replica, cannot promote to master

By the way, I want to mention the conncheck: if I don't skip it, it tries to ssh into the master IPA instance as 'admin@', rather than the user (root), and fails. All other parts of the connectivity check work, however. Why does it try to access the master as a Kerberos principal instead of the

Re: [Freeipa-users] FreeIPA 4.2.0 on CentOS 7.2 as replica of FreeIPA 3.0.0 on CentOS 6.8; cannot install CA components as replica, cannot promote to master

Swing and a miss: when setting up the replicas, we always use the —setup-ca and end the command with the replica gpg file, but it's the —setup-ca that fails as per the earlier messages. If we proceed without —setup-ca, it's fine. I'll try it without skipping the connection check, but I don't

Re: [Freeipa-users] FreeIPA 4.2.0 on CentOS 7.2 as replica of FreeIPA 3.0.0 on CentOS 6.8; cannot install CA components as replica, cannot promote to master

Hi Rob, There's a few logs in there, I'm not sure which is most informative. Here are some sections from what I think are relevant logs: /var/log/pki/pki-tomcat/localhost.log: Jun 01, 2016 12:16:34 PM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet

Re: [Freeipa-users] FreeIPA 4.2.0 on CentOS 7.2 as replica of FreeIPA 3.0.0 on CentOS 6.8; cannot install CA components as replica, cannot promote to master

Hi Sebastian, Unfortunately, that doesn't seem to be it and reinstalling the replica with —setup-ca failed again with the same errors. I've included relevant sections of the logs. /var/log/ipareplica-install.log: 016-06-02T10:43:16Z DEBUG Starting external process 2016-06-02T10:43:16Z DEBUG

[Freeipa-users] FreeIPA 4.2.0 on CentOS 7.2 as replica of FreeIPA 3.0.0 on CentOS 6.8; cannot install CA components as replica, cannot promote to master

Hi folks, As the subject suggests, we're converting from FreeIPA 3.0.0 on CentOS 6 to 4.2.0 on CentOS 7. The way we're doing it is to create FreeIPA replicas in CentOS 7 and then hope to promote one of them to the CA master. I'm running into two problems: The first is that when we create a