[Freeipa-users] FreeIPA 4.4 / Winsync issues.
I have installed a new replica in our IPA domain and configured it to do a winsync with Windows 2012R2. It creates the agreement but then after a while it dies. It appears something isn't configured just right. The Windows client is using the passync user on my side, and i'm creating the sync using a windows account that has the appopriate permissions. This is what I see after about 10 minutes of the sync running from the server side. [22/Feb/2017:23:43:33.103632587 +] agmt="cn= meTolas01-050-005.axi.mtech.int" (las01-050-005:389) - Can't locate CSN 58ae22550018 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized. [22/Feb/2017:23:43:33.105866800 +] NSMMReplicationPlugin - changelog program - agmt="cn=meTolas01-050-005.axi.mtech.int" (las01-050-005:389): CSN 58ae22550018 not found, we aren't as up to date, or we purged [22/Feb/2017:23:43:33.107971862 +] NSMMReplicationPlugin - windows sync - agmt="cn=meTolas01-050-005.axi.mtech.int" (las01-050-005:389): Data required to update replica has been purged. The replica must be reinitialized. [22/Feb/2017:23:43:33.109455154 +] NSMMReplicationPlugin - windows sync - agmt="cn=meTolas01-050-005.axi.mtech.int" (las01-050-005:389): Incremental update failed and requires administrator action On the Windows Side, we show either DSA is unwilling to perform, or Insufficient access. We are using the passsync user that was created during the sync. 02/21/17 15:25:20: PassSync service initialized 02/21/17 15:25:20: PassSync service running 02/21/17 15:25:20: dataFilename is C:\Windows\System32\passhook.dat 02/21/17 15:25:20: 1 new entries loaded from data file 02/21/17 15:25:20: Cleared contents of data file 02/21/17 15:25:20: Password list has 1 entries 02/21/17 15:25:20: Ldap bind error in Connect 53: DSA is unwilling to perform 02/21/17 15:25:20: Attempting to sync password for jeremiah.pedersen 02/21/17 15:25:20: Searching for (uid=jeremiah.pedersen) 02/21/17 15:25:20: Password match, no modify performed: jeremiah.pedersen 02/21/17 15:25:20: Removing password change from list 02/21/17 15:25:20: Password list is empty. Waiting for passhook event 02/21/17 17:19:42: Received passhook event. Attempting sync 02/21/17 17:19:42: 1 new entries loaded from data file 02/21/17 17:19:42: Cleared contents of data file 02/21/17 17:19:42: Password list has 1 entries 02/21/17 17:19:42: Ldap bind error in Connect 53: DSA is unwilling to perform 02/21/17 17:19:42: Attempting to sync password for jeremiah 02/21/17 17:19:42: Searching for (uid=jeremiah) 02/21/17 17:19:42: Password match, no modify performed: jeremiah 02/21/17 17:19:42: Removing password change from list 02/21/17 17:19:42: Password list is empty. Waiting for passhook event 02/22/17 05:05:15: Received passhook event. Attempting sync 02/22/17 05:05:15: 1 new entries loaded from data file 02/22/17 05:05:15: Cleared contents of data file 02/22/17 05:05:15: Password list has 1 entries 02/22/17 05:05:15: Ldap bind error in Connect 53: DSA is unwilling to perform 02/22/17 05:05:15: Attempting to sync password for ray 02/22/17 05:05:15: Searching for (uid=ray) 02/22/17 05:05:15: Ldap error in ModifyPassword 50: Insufficient access 02/22/17 05:05:15: Modify password failed for remote entry: uid=ray,cn=users,cn=accounts,dc=lxi,dc=mtech,dc=int 02/22/17 05:05:15: Deferring password change for ray 02/22/17 05:05:15: Backing off for 2000ms 02/22/17 05:05:17: Backoff time expired. Attempting sync 02/22/17 05:05:17: Password list has 1 entries 02/22/17 05:05:17: Ldap bind error in Connect 53: DSA is unwilling to perform 02/22/17 05:05:17: Attempting to sync password for ray 02/22/17 05:05:17: Searching for (uid=ray) 02/22/17 05:05:17: Ldap error in ModifyPassword 50: Insufficient access 02/22/17 05:05:17: Modify password failed for remote entry: uid=ray,cn=users,cn=accounts,dc=lxi,dc=mtech,dc=int 02/22/17 05:05:17: Deferring password change for ray 02/22/17 05:05:17: Backing off for 4000ms 02/22/17 05:05:21: Backoff time expired. Attempting sync 02/22/17 05:05:21: Password list has 1 entries 02/22/17 05:05:21: Ldap bind error in Connect 53: DSA is unwilling to perform 02/22/17 05:05:21: Attempting to sync password for ray 02/22/17 05:05:21: Searching for (uid=ray) 02/22/17 05:05:21: Ldap error in ModifyPassword 50: Insufficient access 02/22/17 05:05:21: Modify password failed for remote entry: uid=ray,cn=users,cn=accounts,dc=lxi,dc=mtech,dc=int 02/22/17 05:05:21: Deferring password change for ray 02/22/17 05:05:21: Backing off for 8000ms 02/22/17 05:05:29: Backoff time expired. Attempting sync 02/22/17 05:05:29: Password list has 1 entries 02/22/17 05:05:29: Ldap bind error in Connect 53: DSA is unwilling to perform Any help would greatly be appreciated. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA upgrade from ipa-server-4.2.0-15.0.1.el7.centos.18 to ipa-server-4.2.0-15.0.1.el7.centos.19 (went sideways)
Ludwig, Thanks for that, for some reason I had to re-create the /var/lock/ dirsrv/slapd-RSINC-LOCAL/server directory tree, it did not exist. Once I re-created it now the server starts. Should it have disappeared like that? On Fri, Sep 23, 2016 at 12:18 AM, Ludwig Krispenz wrote: > can you check if you have > /var/lock/dirsrv/slapd-RSINC-LOCAL > > if the server user has permissions to write into this directory and its > subdirs or if any pid file still exists in /var/lock/dirsrv/slapd-RSINC- > LOCAL/server > > > On 09/23/2016 07:29 AM, Devin Acosta wrote: > > > Tonight, > > I noticed there was like 30 packages to be applied on my IPA server. I did > the normal 'yum update' process and it completed. I then rebooted the box > for the new kernel to take affect and then that is when IPA stopped working > completely. > > When I try to start the dirsrv@RSINC-LOCAL.service, it throws up with: > > [23/Sep/2016:05:19:38 +] - SSL alert: Configured NSS Ciphers > [23/Sep/2016:05:19:38 +] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: > TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: > TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: > TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: > TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: TLS_RSA_WITH_AES_256_GCM_SHA384: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: > enabled > [23/Sep/2016:05:19:38 +] - SSL alert: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: > enabled >
[Freeipa-users] FreeIPA upgrade from ipa-server-4.2.0-15.0.1.el7.centos.18 to ipa-server-4.2.0-15.0.1.el7.centos.19 (went sideways)
Tonight, I noticed there was like 30 packages to be applied on my IPA server. I did the normal 'yum update' process and it completed. I then rebooted the box for the new kernel to take affect and then that is when IPA stopped working completely. When I try to start the dirsrv@RSINC-LOCAL.service, it throws up with: [23/Sep/2016:05:19:38 +] - SSL alert: Configured NSS Ciphers [23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_RSA_WITH_AES_256_GCM_SHA384: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled [23/Sep/2016:05:19:38 +] - SSL alert: TLS_RSA_WITH_SEED_CBC_SHA: enabled [23/Sep/2016:05:19:38 +] SSL Initialization - Configured SSL version range: min: TLS1.0, max: TLS1.2 [23/Sep/2016:05:19:38 +] - Shutting down due to possible conflicts with other slapd processes *I am not sure what to do about the error "Shutting down due to possible conflicts with other slapd processes"??* The dirserv won't start, and therefore IPA won't start either. Is there some way to do some cleanup or to have it repair the issue? Any help is greatly appreciated!!! Devin. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] FreeIPA / CentOS 7.2 / Issues on Startup
My first primary FreeIPA Master server has gone belly up. When I try to start the server it shows this message in the "error' log. However the other issue i have is when I try to start the server using "ipactl start" it times out after 300 seconds, how do I get past this issue? [17/Aug/2016:22:44:57 +] SSL Initialization - Configured SSL version range: min: TLS1.0, max: TLS1.2 [17/Aug/2016:22:44:57 +] - 389-Directory/1.3.4.0 B2016.215.1556 starting up [17/Aug/2016:22:44:57 +] - WARNING: changelog: entry cache size 2097152B is less than db size 28016640B; We recommend to increase the entry cache size nsslapd-cachememsize. [17/Aug/2016:22:44:57 +] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. Any help is greatly needed!! -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] FreeIPA / Change SSL Certificate for Web Server
I have just installed a newly created FreeIPA server running CentOS 7.2. I have a (wildcard) SSL Certificate that I want to use for the FreeIPA Web Management GUI. I tried to follow the directions listed here at the URL of https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP however when I run those steps I get the error message: ipa-server-certinstall -w -d star.linuxstack.cloud.key star.linuxstack.cloud.crt Directory Manager password: Enter private key unlock password: org.fedorahosted.certmonger.duplicate: Certificate at same location is already used by request with nickname "20160722021526". Any ideas? It seems like I need to somehow just get the one installed by default replaced. I don't see any information on how to just replace it? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA (Add Replica fails on GSSAPI)
When i tried to create the replica from another server, it fails giving me this? [root@ipa02-aws ~]# ipa-replica-prepare ipa03-aws.rsinc.local --ip-address 10.40.x.x Directory Manager (existing master) password: If you installed IPA with your own certificates using PKCS#12 files you must provide PKCS#12 files for any replicas you create as well. The replica must be created on the primary IPA server. On Thu, Jul 14, 2016 at 8:22 AM, Petr Vobornik wrote: > On 07/14/2016 07:18 AM, Bjarne Blichfeldt wrote: > > Well, I just had the same problem, but in my case I also tried to > install a ca: > > > > “ipa-replica-install --setup-ca …..” > > > > Without “--set-up” the installation succeeded. > > > > Regards, > > > > Bjarne > > > > The error below is not related to CA. > > It tries to check that new replica's ldap service principal was replica > to master server. The principal is not replicated there and after 60 > attemps it fails. > > What is your replication topology? Could it be that other replicas are > keeping this master busy? > > Does installation against other replica work? > > Could you provide dirsrv error log of the master from the time of > installation? > > > > > > > *From:*Devin Acosta [mailto:linuxguru...@gmail.com] > > *Sent:* 12. juli 2016 21:35 > > *To:* freeipa-users@redhat.com > > *Subject:* [Freeipa-users] FreeIPA (Add Replica fails on GSSAPI) > > > > I am trying to add a 4th replica to my FreeIPA installation. I am > running the > > latest CentOS 7.2 (full updates) and i have tried multiple times and > fails every > > time in same location. When it fails I remove the replication agreements > and try > > again and keeps failing in same location. > > > > [root@ipa03-aws centos]# ipa-replica-install > replica-info-ipa03-aws.rsinc.local.gpg > > > > WARNING: conflicting time&date synchronization service 'chronyd' will > > > > be disabled in favor of ntpd > > > > Directory Manager (existing master) password: > > > > Run connection check to master > > > > Check connection from replica to remote master 'ipa01-aws.rsinc.local': > > > > Directory Service: Unsecure port (389): OK > > > > Directory Service: Secure port (636): OK > > > > Kerberos KDC: TCP (88): OK > > > > Kerberos Kpasswd: TCP (464): OK > > > > HTTP Server: Unsecure port (80): OK > > > > HTTP Server: Secure port (443): OK > > > > The following list of ports use UDP protocol and would need to be > > > > checked manually: > > > > Kerberos KDC: UDP (88): SKIPPED > > > > Kerberos Kpasswd: UDP (464): SKIPPED > > > > Connection from replica to master is OK. > > > > Start listening on required ports for remote master check > > > > Get credentials to log in to remote master > > > > admin@RSINC.LOCAL <mailto:admin@RSINC.LOCAL> password: > > > > Check SSH connection to remote master > > > > Execute check on remote master > > > > Check connection from master to remote replica 'ipa03-aws.rsinc.local': > > > > Directory Service: Unsecure port (389): OK > > > > Directory Service: Secure port (636): OK > > > > Kerberos KDC: TCP (88): OK > > > > Kerberos KDC: UDP (88): OK > > > > Kerberos Kpasswd: TCP (464): OK > > > > Kerberos Kpasswd: UDP (464): OK > > > > HTTP Server: Unsecure port (80): OK > > > > HTTP Server: Secure port (443): OK > > > > Connection from master to replica is OK. > > > > Connection check OK > > > > Configuring NTP daemon (ntpd) > > > >[1/4]: stopping ntpd > > > >[2/4]: writing configuration > > > >[3/4]: configuring ntpd to start on boot > > > >[4/4]: starting ntpd > > > > Done configuring NTP daemon (ntpd). > > > > Configuring directory server (dirsrv). Estimated time: 1 minute > > > >[1/38]: creating directory server user > > > >[2/38]: creating directory server instance > > > >[3/38]: adding default schema > > > >[4/38]: enabling memberof plugin > > > >[5/38]: enabling winsync plugin > > > >[6/38]: configuring replication version plugin > > > >[7/38]: enabling IPA enrollment plugin > > > >[8/38]: enabling ldapi > > > >[9/38]: configuring uniqueness plugin > > > >[10/38]: conf
Re: [Freeipa-users] Replication Agreement issues noticed with repl-monitor.pl
ipa01-jap was a host that is no more, is there a simple way to clear these replication agreements to clean it up? On Thu, Jul 14, 2016 at 7:14 AM, Petr Vobornik wrote: > On 07/14/2016 12:57 PM, Martin Kosek wrote: > > On 07/13/2016 04:24 AM, Devin Acosta wrote: > >> > >> I was trying to create another Replica but then noticed it was > constantly having > >> issues trying to finish the joining of the replication. I then ran the > command: > >> repl-monitor.pl <http://repl-monitor.pl>, It appears i have several > replicaid's > >> and they seem to be having issues, wondering if this is adding to my > issue. > >> > >> Anyone know how I can resolve this issue and clean up the replication??? > >> > >> See attached Screenshot. > > > > I wonder if cleaning RUVs help: > > > > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/trouble-replica.html#trouble-repl-cleanruv > > > > dangling RUVs > > 1. "Can't acquire busy replica" > seems OK if it disappears after a while. > > 2. "1 Unable to acquire replicaLDAP error: Can't contact LDAP" > Probably worth investigating if ipa01- > i2x.rsinc.local:389 and ipa01- > jap.rsinc.local:389 still exist. If not then there is probably a > dangling replication agreement for o=ipaca suffix. > > -- > Petr Vobornik > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Replication Agreement issues noticed with repl-monitor.pl
I was trying to create another Replica but then noticed it was constantly having issues trying to finish the joining of the replication. I then ran the command: repl-monitor.pl, It appears i have several replicaid's and they seem to be having issues, wondering if this is adding to my issue. Anyone know how I can resolve this issue and clean up the replication??? See attached Screenshot. replication-issue.pdf Description: Adobe PDF document -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] ipa-replica-install fails at [6/8]: enable GSSAPI for replication
;t acquire busy replica: start: 0: end: 0 2016-05-09T02:45:35Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/idm1-dev.rsinc.local@RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local@RSINC.LOCAL) 2016-05-09T02:45:35Z DEBUG Unable to find entry for (krbprincipalname=ldap/idm1-dev.rsinc.local@RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-05-09T02:45:35Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-05-09T02:45:36Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-05-09T02:45:37Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-05-09T02:45:37Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/idm1-dev.rsinc.local@RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local@RSINC.LOCAL) 2016-05-09T02:45:37Z DEBUG Unable to find entry for (krbprincipalname=ldap/idm1-dev.rsinc.local@RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-05-09T02:45:37Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-05-09T02:45:38Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-05-09T02:45:39Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-05-09T02:45:39Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/idm1-dev.rsinc.local@RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local@RSINC.LOCAL) 2016-05-09T02:45:39Z DEBUG Unable to find entry for (krbprincipalname=ldap/idm1-dev.rsinc.local@RSINC.LOCAL) on ipa01-aws.rsinc.local:636 2016-05-09T02:45:39Z INFO Setting agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config schedule to 2358-2359 0 to force synch 2016-05-09T02:45:40Z INFO Deleting schedule 2358-2359 0 from agreement cn=meToipa01-aws.rsinc.local,cn=replica,cn=dc\=rsinc\,dc\=local,cn=mapping tree,cn=config 2016-05-09T02:45:41Z INFO Replication Update in progress: FALSE: status: 1 Can't acquire busy replica: start: 0: end: 0 2016-05-09T02:45:41Z INFO Getting ldap service principals for conversion: (krbprincipalname=ldap/idm1-dev.rsinc.local@RSINC.LOCAL) and (krbprincipalname=ldap/ipa01-aws.rsinc.local@RSINC.LOCAL) Thanks. Devin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] nsds5ReplConflict / Replication issue!
I did try to resync idm1-i2x from ipa01-aws, probably was a bad idea..
Is there any way to basically have it resync and get a fresh copy from
the other nodes that are ok?
Well it initially started when I noticed errors in the logs about having
a conflict on a record. So i was trying to get that record cleaned up. I
then though oh maybe I should just have it reload everything from
another server, and i wonder if now that's why the box is just giving
strange results.
i had ipa1-i2x.rsinc.local reload from ipa01-aws.rsinc.local, you can
see the output of the commands below about replication status. I can
still log into ipa1-i2x.rsinc.local,
[dacosta@ipa1-i2x ~]$ ipa-replica-manage -v list ipa02-aws.rsinc.local
ipa: WARNING: session memcached servers not running
ipa01-aws.rsinc.local: replica
last init status: None
last init ended: 1970-01-01 00:00:00+00:00
last update status: 0 Replica acquired successfully: Incremental update
started
last update ended: 1970-01-01 00:00:00+00:00
[dacosta@ipa1-i2x ~]$ ipa-replica-manage -v list ipa01-aws.rsinc.local
ipa: WARNING: session memcached servers not running
ipa02-aws.rsinc.local: replica
last init status: None
last init ended: 1970-01-01 00:00:00+00:00
last update status: 0 Replica acquired successfully: Incremental update
succeeded
last update ended: 2016-05-06 19:47:26+00:00
ipa1-i2x.rsinc.local: replica
last init status: 0 Total update succeeded
last init ended: 2016-05-06 18:46:29+00:00
last update status: 0 Replica acquired successfully: Incremental update
succeeded
last update ended: 2016-05-06 19:46:59+00:00
[dacosta@ipa1-i2x ~]$ ipa-replica-manage -v list ipa1-i2x.rsinc.local
ipa: WARNING: session memcached servers not running
ipa01-aws.rsinc.local: replica
last init status: None
last init ended: 1970-01-01 00:00:00+00:00
last update status: 1 Can't acquire busy replica
last update ended: 1970-01-01 00:00:00+00:00
I do have these errors on (idm1-i2x) in the errors:
[06/May/2016:18:48:46 +] NSMMReplicationPlugin - ruv_compare_ruv:
RUV [changelog max RUV] does not contain element [{replica 4
ldap://ipa01-aws.rsinc.local:389} 56e2f9e70004
572ce68100020004] which is present in RUV [database RUV]
[06/May/2016:18:48:46 +] NSMMReplicationPlugin -
replica_check_for_data_reload: Warning: for replica dc=rsinc,dc=local
there were some differences between the changelog max RUV and the
database RUV. If there are obsolete elements in the database RUV, you
should remove them using the CLEANALLRUV task. If they are not
obsolete, you should check their status to see why there are no changes
from those servers in the changelog.
[06/May/2016:18:48:46 +] NSMMReplicationPlugin - ruv_compare_ruv:
RUV [changelog max RUV] does not contain element [{replica 91
ldap://ipa1-i2x.rsinc.local:389} 56f02d3b005b
56f02d67005b] which is present in RUV [database RUV]
[06/May/2016:18:48:46 +] NSMMReplicationPlugin -
replica_check_for_data_reload: Warning: for replica o=ipaca there were
some differences between the changelog max RUV and the database RUV. If
there are obsolete elements in the database RUV, you should remove them
using the CLEANALLRUV task. If they are not obsolete, you should check
their status to see why there are no changes from those servers in the
changelog.
[06/May/2016:18:48:46 +] set_krb5_creds - Could not get initial
credentials for principal [ldap/ipa1-i2x.rsinc.local@RSINC.LOCAL] in
keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error (see
e-text))
[06/May/2016:18:48:46 +] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error
-2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified
GSS failure. Minor code may provide more information (No Kerberos
credentials available)) errno 0 (Success)
[06/May/2016:18:48:46 +] slapi_ldap_bind - Error: could not perform
interactive bind for id [] authentication mechanism [GSSAPI]: error -2
(Local error)
[06/May/2016:18:48:46 +] NSMMReplicationPlugin -
agmt="cn=meToipa01-aws.rsinc.local" (ipa01-aws:389): Replication bind
with GSSAPI auth failed: LDAP error -2 (Local error) (SASL(-1): generic
failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide
more information (No Kerberos credentials available))
[06/May/2016:18:48:46 +] - slapd started. Listening on All
Interfaces port 389 for LDAP requests
[06/May/2016:18:48:46 +] - Listening on All Interfaces port 636 for
LDAPS requests
[06/May/2016:18:48:46 +] - Listening on
/var/run/slapd-RSINC-LOCAL.socket for LDAPI requests
[06/May/2016:18:48:50 +] NSMMReplicationPlugin -
agmt="cn=meToipa01-aws.rsinc.local" (ipa01-aws:389): Replication bind
with GSSAPI auth resumed
[06/May/2016:18:49:18 +] - Retry count exceeded in delete
[06/May/2016:18:49:18 +] DSRetroclPlugin - delete_changerecord:
could not delete change record 436145 (rc: 51)
Thanks
[Freeipa-users] nsds5ReplConflict / Replication issue!
I am running the latest FreeIPA on CentOS 7.2. I noticed I had a “nsds5ReplConflict” with an item, i tried to follow the webpage to rename and delete but that failed. I then tried to have ipa1-i2x reload from ipa01-aws instance, now now it seems to have gone maybe worse? can you please advise how to get back to a healthy system. I initially added a system account as recommended so i could have say like Jira/Confluence do User searches against IDM. [dacosta@ipa1-i2x ~]$ ldapsearch -x -D "cn=directory manager" -w ‘password' -b "dc=rsinc,dc=local" "nsds5ReplConflict=*" \* nsds5ReplConflict # extended LDIF # # LDAPv3 # base with scope subtree # filter: nsds5ReplConflict=* # requesting: * nsds5ReplConflict # # 7ad08581-059911e6-b55c83a4-93228cdf + ldapsearch, sysaccounts, etc, rsinc.loc al dn: nsuniqueid=7ad08581-059911e6-b55c83a4-93228cdf+uid=ldapsearch,cn=sysaccoun ts,cn=etc,dc=rsinc,dc=local userPassword:: e1NTSEF9M3krdTh5TkdYV= = uid: ldapsearch objectClass: account objectClass: simplesecurityobject objectClass: top nsds5ReplConflict: namingConflict uid=ldapsearch,cn=sysaccounts,cn=etc,dc=rsin c,dc=local # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [dacosta@ipa1-i2x ~]$ ./ipa_check_consistency -H "ipa1-i2x.local ipa01-aws.rsinc.local" -d RSINC.LOCAL Directory Manager password: FreeIPA servers: ipa1-i2x ipa01-aws STATE === Active Users ERROR 33 FAIL Stage Users ERROR 0 FAIL Preserved Users ERROR 0 FAIL User Groups ERROR 7 FAIL Hosts ERROR 82 FAIL Host Groups ERROR 1 FAIL HBAC Rules ERROR 2 FAIL SUDO Rules ERROR 4 FAIL DNS Zones ERROR 14 FAIL LDAP Conflicts ERROR YES FAIL Anonymous BIND ERROR on FAIL Replication Status ipa02-aws 0 ipa1-i2x 0 === [dacosta@ipa1-i2x ~]$ ipa-replica-manage list ipa: WARNING: session memcached servers not running ipa02-aws.rsinc.local: master ipa01-aws.rsinc.local: master ipa1-i2x.rsinc.local: master Devin Acosta Linux Certified Engineer e: de...@linuxguru.co -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Inplace upgrade
Barry, Yes you should be able to just do a: "yum update ipa-server" and you should be good to go. -- Devin Acosta, RHCE, LFCE Linux Certified Engineer e: de...@linuxguru.co On May 3, 2016 at 9:10:04 PM, barry...@gmail.com (barry...@gmail.com) wrote: Hi : How to in place upgrade ipa-server-3.0.0-26.el6_4.4.x86_64 to ipa-server-3.0.0-37.el6.x86_64 This is minor version upgrade , can it just type update command? Regards Barry -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA 4.2.0 / Replica / Join Issue
Rob, Yeah i forgot to attach the file when I initially sent. I also attached the output from all the nodes. I guess what i realized is that my agreements are a little different than i originally thought. What is also strange is on a few hosts that initially did enroll from AWS, when I look at the host via the GUI the host shows: Kerberos Key Present, Host Provisioned One-Time-Password Not Present Host Certificate, No Valid Certificate So the few that enrolled, they don't show having any Host certificates but they show Kerberos Key present and Host provisioned. Is there a problem with the way I provisioned the Replicas? I'm just using subdomains for human clarification but they all use the same Kerberos domain, etc. [root@ipa02-ore ~]# ipa-replica-manage list -v `hostname` Directory Manager password: ipa01-ore.prod.cloud.myinc.local: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2016-03-03 20:39:30+00:00 [root@ipa01-ore ~]# ipa-replica-manage list -v `hostname` ipa02-ore.prod.cloud.myinc.local: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2016-03-03 20:41:20+00:00 rspsna-ipa01.prod.i2x.myinc.local: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2016-03-03 20:41:29+00:00 [root@rspsna-ipa01 ~]# ipa-replica-manage list -v `hostname` ipa01-ore.prod.cloud.myinc.local: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2016-03-03 20:43:35+00:00 rspsna-ipa02.prod.i2x.myinc.local: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2016-03-03 20:43:35+00:00 [root@rspsna-ipa02 ~]# ipa-replica-manage list -v `hostname` rspsna-ipa01.prod.i2x.myinc.local: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2016-03-03 20:44:14+00:00 See attached file for the initial fail. Thanks very much for your help. Devin Acosta arch 3 2016 1:34 PM, "Rob Crittenden" wrote: > de...@pabstatencio.com wrote: > >> I am running the latest patched CentOS 7.2, with FreeIPA 4.2.0, and I >> the Master node in the Data Center, then i created 3 replica's, one in >> the DC for High Availability, and then 2 Replica's in the AWS Cloud. I'm >> having major issues with the Replica's in the AWS Cloud. I am trying to >> have it so it auto-discovers the servers automatically so the failover >> is dynamic. I created the replica's as well to have a Certificate >> Authority. When I attempt to join a virtual machine in AWS to the domain >> it fails half way thru the process. I have attached a full debug of my >> ipa-client-install, hoping someone can assist me. I know prior to >> joining the 2 replicas in AWS I had absolutely no issues with joining >> servers in the DC to IDM. I built all my replica's from the Master >> server (rspsna-ipa01), so rspsna-ipa02, ipa01-ore, ipa02-ore were built >> from rspsna-ipa01. >> >> The main part that seems to fail during the (client) join is: > > The important bits are needed. This part of the log is just trying to > clean things up (so failures are expected and ok). We'd really need to > see a full ipaclient-install.log. > >> When I look at the slapd error log on one of the replica's i see this: >> >> [02/Mar/2016:23:40:09 +] - Listening on All Interfaces port 636 for >> LDAPS requests >> [02/Mar/2016:23:40:09 +] - Listening on >> /var/run/slapd-MYINC-LOCAL.socket for LDAPI requests >> [02/Mar/2016:23:40:09 +] slapd_ldap_sasl_interactive_bind - Error: >> could not perform interactive bind for id [] mech [GSSAPI]: LDAP error >> -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified >> GSS failure. Minor code may provide more information (No Kerberos >> credentials available)) errno 0 (Success) >> [02/Mar/2016:23:40:09 +] slapi_ldap_bind - Error: could not perform >> interactive bind for id [] authentication mechanism [GSSAPI]: error -2 >> (Local error) >> [02/Mar/2016:23:40:09 +] NSMMReplicationPlugin - >> agmt="cn=meTorspsna-ipa01.prod.i2x.myinc.local" (rspsna-ipa01:389): >> Repl
[Freeipa-users] FreeIPA 4.2.0 / Replica / Join Issue
bind with GSSAPI auth resumed [02/Mar/2016:23:40:12 +] NSMMReplicationPlugin - agmt="cn=meTorspsna-ipa01.prod.i2x.myinc.local" (rspsna-ipa01:389): Replication bind with GSSAPI auth resumed [03/Mar/2016:00:07:00 +] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [03/Mar/2016:00:07:00 +] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [03/Mar/2016:00:07:00 +] NSMMReplicationPlugin - agmt="cn=meToipa02-ore.prod.cloud.myinc.local" (ipa02-ore:389): Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) () [03/Mar/2016:00:07:03 +] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [03/Mar/2016:00:07:03 +] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [03/Mar/2016:00:07:09 +] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [03/Mar/2016:00:07:09 +] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [03/Mar/2016:00:07:21 +] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [03/Mar/2016:00:07:21 +] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) [03/Mar/2016:00:07:45 +] NSMMReplicationPlugin - agmt="cn=meToipa02-ore.prod.cloud.myinc.local" (ipa02-ore:389): Replication bind with GSSAPI auth resumed [03/Mar/2016:01:26:53 +] NSMMReplicationPlugin - replication keep alive entry already exists [03/Mar/2016:03:24:06 +] NSMMReplicationPlugin - replication keep alive entry already exists [03/Mar/2016:05:17:30 +] NSMMReplicationPlugin - replication keep alive entry already exists [03/Mar/2016:07:08:29 +] NSMMReplicationPlugin - replication keep alive entry already exists [03/Mar/2016:08:59:51 +] NSMMReplicationPlugin - replication keep alive entry already exists [03/Mar/2016:10:42:48 +] NSMMReplicationPlugin - replication keep alive entry already exists [03/Mar/2016:12:35:51 +] NSMMReplicationPlugin - replication keep alive entry already exists [03/Mar/2016:14:28:20 +] NSMMReplicationPlugin - replication keep alive entry already exists [03/Mar/2016:16:24:12 +] NSMMReplicationPlugin - replication keep alive entry already exists [03/Mar/2016:18:09:51 +] NSMMReplicationPlugin - replication keep alive entry already exists [03/Mar/2016:19:47:07 +] NSMMReplicationPlugin - replication keep alive entry already exists Thanks much. Devin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] FreeIPA 4.2.0 / CentOS 7.2 / DNS Strangeness (Sub-domains)
I am noticing a very strange issue with FreeIPA, I installed FreeIPA on a fresh Virtual Machine called (idm.servers.lnx.ninja) and registered the Kerberos domain as LNX.NINJA. Everything installs just fine without any issues, and even when I log into FreeIPA and go to the DNS Manager i see that it created a few zones as I would have expected (ie: Reverse zone for 10.10.10.x, lnx.ninja zone, and servers.lnx.ninja zone. What I notice is that if I try to do a DNS query for any record on the (lnx.ninja) zone it fails even though there are records there, and if I query any records inside the servers.lnx.ninja zone they work just fine. What I can't understand is why are my DNS queries dying on the (lnx.ninja) zone. So for my test I created 2 (A) records one inside (lnx.ninja) and one inside (servers.lnx.ninja). What would cause any DNS queries to lnx.ninja to not succeed? I have duplicated this issue multiple times with several other VM's using different domains and they have have same issue. Any advise is appreciated! [root@idm ~]# dig @localhost blah.lnx.ninja ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.1 <<>> @localhost blah.lnx.ninja ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 50913 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;blah.lnx.ninja. IN A ;; Query time: 1 msec ;; SERVER: ::1#53(::1) ;; WHEN: Wed Jan 06 05:30:15 UTC 2016 ;; MSG SIZE rcvd: 43 [root@idm ~]# dig @localhost blah.servers.lnx.ninja ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.1 <<>> @localhost blah.servers.lnx.ninja ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64481 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;blah.servers.lnx.ninja. IN A ;; ANSWER SECTION: blah.servers.lnx.ninja. 86400 IN A 10.10.10.1 ;; AUTHORITY SECTION: servers.lnx.ninja. 86400 IN NS idm.servers.lnx.ninja. ;; ADDITIONAL SECTION: idm.servers.lnx.ninja. 1200 IN A 10.10.10.10 ;; Query time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Wed Jan 06 05:30:32 UTC 2016 ;; MSG SIZE rcvd: 101 Thanks Much. Devin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
