[Freeipa-users] Third Party Certificate
Hello! I have been using FreeIPA for a while in our network with 6 replicas and it's been working great. I seem to have made a wee mistake though and I'd appreciate some help. I did this: https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP on one server because I had a new cert for our internal domain and I thought it might be nice to use the same cert for all our internal web services. It worked fine but now when I'm on that server I get SEC_ERROR_UNTRUSTED_ISSUER when I run ipa commands. Is there any way I can roll this back, or make it work as is? Thanks! -Ian -- 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] Third Party Certificate
YES! Thank you so much. On 08/02/2016 08:19 AM, Florence Blanc-Renaud wrote: > On 08/02/2016 03:17 PM, Ian Harding wrote: >> Hello! >> >> I have been using FreeIPA for a while in our network with 6 replicas and >> it's been working great. I seem to have made a wee mistake though and >> I'd appreciate some help. >> >> I did this: >> >> https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP >> >> on one server because I had a new cert for our internal domain and I >> thought it might be nice to use the same cert for all our internal web >> services. >> >> It worked fine but now when I'm on that server I get >> SEC_ERROR_UNTRUSTED_ISSUER when I run ipa commands. Is there any way I >> can roll this back, or make it work as is? >> >> Thanks! >> >> -Ian >> > Hi Ian, > > if the certificate that you installed was issued by a CA not known by > IPA (let's call him the issuer), then you need to add this issuer cert > first using: > ipa-cacert-manage install -n nickname -t C,, > kinit admin > ipa-certupdate > > You can check that the issuer cert is properly installed in > /etc/httpd/alias and /etc/ipa/nssdb with: > certutil -L -d /etc/httpd/alias > certutil -L -d /etc/ipa/nssdb > where it should appear with C,, flags > > Hope this helps, > Flo. > -- Ian Harding IT Director Brown Paper Tickets 1-800-838-3006 ext 7186 http://www.brownpapertickets.com -- 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] Deleted Replica Problems
I deleted a replica that had a corrupted ldap database and it caused some problems. I'm now getting the dreaded [root@edinburghnfs ianh]# ipa-replica-manage connect freeipa-sea.bpt.rocks Connection unsuccessful: freeipa-sea.bpt.rocks is an IPA Server, but it might be unknown, foreign or previously deleted one. I had to go around and remove old replication agreements from the other replicas, but then they could connect again. This one, and another, I am not able to do that with. They were initially created with freeipa-sea as their master. I assume I run ipa-server-install --uninstall on edinburghnis, then reinstall to fix? There's always an error about having to "Manually remove" the ldap database. What's the best way to do that? Thanks! - Ian -- 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] Third Party Certificate
On 08/02/2016 08:19 AM, Florence Blanc-Renaud wrote: > On 08/02/2016 03:17 PM, Ian Harding wrote: >> Hello! >> >> I have been using FreeIPA for a while in our network with 6 replicas and >> it's been working great. I seem to have made a wee mistake though and >> I'd appreciate some help. >> >> I did this: >> >> https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP >> >> on one server because I had a new cert for our internal domain and I >> thought it might be nice to use the same cert for all our internal web >> services. >> >> It worked fine but now when I'm on that server I get >> SEC_ERROR_UNTRUSTED_ISSUER when I run ipa commands. Is there any way I >> can roll this back, or make it work as is? >> >> Thanks! >> >> -Ian >> > Hi Ian, > > if the certificate that you installed was issued by a CA not known by > IPA (let's call him the issuer), then you need to add this issuer cert > first using: > ipa-cacert-manage install -n nickname -t C,, > kinit admin > ipa-certupdate > > You can check that the issuer cert is properly installed in > /etc/httpd/alias and /etc/ipa/nssdb with: > certutil -L -d /etc/httpd/alias > certutil -L -d /etc/ipa/nssdb > where it should appear with C,, flags > > Hope this helps, > Flo. > I seem to have created a problem here. First some background. freeipa-sea.bpt.rocks suffered ldap database corruption on a messy reboot. I tried to delete it from the freeipa ecosystem but did a poor job, then rebuilt it with the same name and IP address. Replication issues ensued. I chose this inopportune time to install the ssl certificate as described above. I have spent today deleting old replication agreements and reestablishing them which seems to have worked on most of the replicas. However I see this now on most of them [root@bpt-nyc1-nfs ianh]# ipa-csreplica-manage list Directory Manager password: seattlenfs.bpt.rocks: master bpt-nyc1-nfs.bpt.rocks: master freeipa-sea.bpt.rocks: CA not configured bellevuenfs.bpt.rocks: master freeipa-dal.bpt.rocks: master edinburghnfs.bpt.rocks: master fremontnis.bpt.rocks: master Is this related to the original deletion or the subsequent addition of the certificate? I installed the replicas with their own CA. I have added the certificate root to the replicas as mentioned above. Thanks! -- 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] clean-ruv
I've followed the procedure in this thread:
https://www.redhat.com/archives/freeipa-users/2016-May/msg00043.html
and found my list of RUV that don't have an existing replica id.
I've tried to remove them like so:
[root@seattlenfs ianh]# ldapmodify -D "cn=directory manager" -W -a
Enter LDAP Password:
dn: cn=clean 97, cn=cleanallruv, cn=tasks, cn=config
objectclass: top
objectclass: extensibleObject
replica-base-dn: dc=bpt,dc=rocks
replica-id: 97
replica-force-cleaning: yes
cn: clean 97
adding new entry "cn=clean 97, cn=cleanallruv, cn=tasks, cn=config"
[root@seattlenfs ianh]# ipa-replica-manage list-clean-ruv
CLEANALLRUV tasks
RID 9: Waiting to process all the updates from the deleted replica...
RID 96: Successfully cleaned rid(96).
RID 97: Successfully cleaned rid(97).
No abort CLEANALLRUV tasks running
and yet, they are still there...
[root@seattlenfs ianh]# ldapsearch -ZZ -h seattlenfs.bpt.rocks -D
"cn=Directory Manager" -W -b "o=ipaca"
"(&(objectclass=nstombstone)(nsUniqueId=---))"
| grep "nsds50ruv\|nsDS5ReplicaId"
Enter LDAP Password:
nsDS5ReplicaId: 81
nsds50ruv: {replicageneration} 55c8f3ae0060
nsds50ruv: {replica 81 ldap://seattlenfs.bpt.rocks:389}
568ac4310051 5
nsds50ruv: {replica 1065 ldap://freeipa-sea.bpt.rocks:389}
57b103d40429000
nsds50ruv: {replica 1070 ldap://bellevuenfs.bpt.rocks:389}
57a4f270042e000
nsds50ruv: {replica 1075 ldap://bpt-nyc1-nfs.bpt.rocks:389}
57a47865043300
nsds50ruv: {replica 1080 ldap://bellevuenfs.bpt.rocks:389}
57a417670438000
nsds50ruv: {replica 1085 ldap://fremontnis.bpt.rocks:389}
57a403e6043d
nsds50ruv: {replica 1090 ldap://freeipa-dal.bpt.rocks:389}
57a2dd350442000
nsds50ruv: {replica 1095 ldap://freeipa-sea.bpt.rocks:389}
579a963c0447000
nsds50ruv: {replica 96 ldap://freeipa-sea.bpt.rocks:389}
55c8f3bd0060
nsds50ruv: {replica 86 ldap://fremontnis.bpt.rocks:389}
5685b24e0056 5
nsds50ruv: {replica 91 ldap://seattlenis.bpt.rocks:389}
567ad6180001005b 5
nsds50ruv: {replica 97 ldap://freeipa-dal.bpt.rocks:389}
55c8f3ce0061
nsds50ruv: {replica 76 ldap://bellevuenis.bpt.rocks:389}
56f385eb0007004c
nsds50ruv: {replica 71 ldap://bellevuenfs.bpt.rocks:389}
570485690047
nsds50ruv: {replica 66 ldap://bpt-nyc1-nfs.bpt.rocks:389}
5733e594000a0042
nsds50ruv: {replica 61 ldap://edinburghnfs.bpt.rocks:389}
57442125003d
nsds50ruv: {replica 1195 ldap://edinburghnfs.bpt.rocks:389}
57a4239004ab00
What have I done wrong?
The problem I am trying to solve is that seattlenfs.bpt.rocks sends
updates to all its children, but their changes don't come back because
of these errors:
[23/Aug/2016:00:02:16 -0700] attrlist_replace - attr_replace
(nsslapd-referral,
ldap://seattlenfs.bpt.rocks:389/dc%3Dbpt%2Cdc%3Drocks) failed.
in effect, the replication agreements are one-way.
Any ideas?
- Ian
--
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] clean-ruv
Ah. I see. I mixed those up but I see that those would have to be
consistent.
However, I have been trying to beat some invalid RUV to death for a long
time and I can't seem to kill them.
For example, bellevuenfs has 9 and 16 which are invalid:
[ianh@seattlenfs ~]$ ldapsearch -ZZ -h seattlenfs.bpt.rocks -D
"cn=Directory Manager" -W -b "dc=bpt,dc=rocks"
"(&(objectclass=nstombstone)(nsUniqueId=---))"
| grep "nsds50ruv\|nsDS5ReplicaId"
Enter LDAP Password:
nsDS5ReplicaId: 7
nsds50ruv: {replicageneration} 55c8f3640004
nsds50ruv: {replica 7 ldap://seattlenfs.bpt.rocks:389}
568ac3cc0007 57
nsds50ruv: {replica 20 ldap://freeipa-sea.bpt.rocks:389}
57b1037700020014
nsds50ruv: {replica 18 ldap://bpt-nyc1-nfs.bpt.rocks:389}
57a4780100010012
nsds50ruv: {replica 15 ldap://fremontnis.bpt.rocks:389}
57a40386000f 5
nsds50ruv: {replica 14 ldap://freeipa-dal.bpt.rocks:389}
57a2dccd000e
nsds50ruv: {replica 17 ldap://edinburghnfs.bpt.rocks:389}
57a422f90011
nsds50ruv: {replica 19 ldap://bellevuenfs.bpt.rocks:389}
57a4f20d00060013
nsds50ruv: {replica 16 ldap://bellevuenfs.bpt.rocks:389}
57a417060010
nsds50ruv: {replica 9 ldap://bellevuenfs.bpt.rocks:389}
570484ee0009 5
So I try to kill them like so:
[ianh@seattlenfs ~]$ ipa-replica-manage clean-ruv 9 --force --cleanup
ipa: WARNING: session memcached servers not running
Clean the Replication Update Vector for bellevuenfs.bpt.rocks:389
Cleaning the wrong replica ID will cause that server to no
longer replicate so it may miss updates while the process
is running. It would need to be re-initialized to maintain
consistency. Be very careful.
Background task created to clean replication data. This may take a while.
This may be safely interrupted with Ctrl+C
^C[ianh@seattlenfs ~]$ ipa-replica-manage clean-ruv 16 --force --cleanup
ipa: WARNING: session memcached servers not running
Clean the Replication Update Vector for bellevuenfs.bpt.rocks:389
Cleaning the wrong replica ID will cause that server to no
longer replicate so it may miss updates while the process
is running. It would need to be re-initialized to maintain
consistency. Be very careful.
Background task created to clean replication data. This may take a while.
This may be safely interrupted with Ctrl+C
^C[ianh@seattlenfs ~]$ ipa-replica-manage list-clean-ruv
ipa: WARNING: session memcached servers not running
CLEANALLRUV tasks
RID 16: Waiting to process all the updates from the deleted replica...
RID 9: Waiting to process all the updates from the deleted replica...
No abort CLEANALLRUV tasks running
[ianh@seattlenfs ~]$ ipa-replica-manage list-clean-ruv
ipa: WARNING: session memcached servers not running
CLEANALLRUV tasks
RID 16: Waiting to process all the updates from the deleted replica...
RID 9: Waiting to process all the updates from the deleted replica...
and it never finishes.
seattlenfs is the first master, that's the only place I should have to
run this command, right?
I'm about to burn everything down and ipa-server-install --uninstall but
I've done that before a couple times and that seems to be what got me
into this mess...
Thank you for your help.
On 08/23/2016 01:37 AM, Ludwig Krispenz wrote:
> looks like you are searching the nstombstone below "o=ipaca", but you
> are cleaning ruvs in "dc=bpt,dc=rocks",
>
> your attrlist_replace error refers to the bpt,rocks backend, so you
> should search the tombstone entry ther, then determine which replicaIDs
> to remove.
>
> Ludwig
>
> On 08/23/2016 09:20 AM, Ian Harding wrote:
>> I've followed the procedure in this thread:
>>
>> https://www.redhat.com/archives/freeipa-users/2016-May/msg00043.html
>>
>> and found my list of RUV that don't have an existing replica id.
>>
>> I've tried to remove them like so:
>>
>> [root@seattlenfs ianh]# ldapmodify -D "cn=directory manager" -W -a
>> Enter LDAP Password:
>> dn: cn=clean 97, cn=cleanallruv, cn=tasks, cn=config
>> objectclass: top
>> objectclass: extensibleObject
>> replica-base-dn: dc=bpt,dc=rocks
>> replica-id: 97
>> replica-force-cleaning: yes
>> cn: clean 97
>>
>> adding new entry "cn=clean 97, cn=cleanallruv, cn=tasks, cn=config"
>>
>> [root@seattlenfs ianh]# ipa-replica-manage list-clean-ruv
>> CLEANALLRUV tasks
>> RID 9: Waiting to process all the updates from the deleted replica...
>> RID 96: Successfully cleaned rid(96).
>> RID 97: Successfully cleaned rid(97).
>>
>> No abort CLEANALLRUV tasks running
>>
>>
>> and yet, they are still there...
>>
>> [root@seattlenfs ianh]# ldapsearch -ZZ -h seattlenfs.bpt.rocks -D
>> "cn=Directory Manager" -W -b &quo
Re: [Freeipa-users] clean-ruv
On 08/23/2016 03:14 AM, Ludwig Krispenz wrote:
>
> On 08/23/2016 11:52 AM, Ian Harding wrote:
>> Ah. I see. I mixed those up but I see that those would have to be
>> consistent.
>>
>> However, I have been trying to beat some invalid RUV to death for a long
>> time and I can't seem to kill them.
>>
>> For example, bellevuenfs has 9 and 16 which are invalid:
>>
>> [ianh@seattlenfs ~]$ ldapsearch -ZZ -h seattlenfs.bpt.rocks -D
>> "cn=Directory Manager" -W -b "dc=bpt,dc=rocks"
>> "(&(objectclass=nstombstone)(nsUniqueId=---))"
>>
>> | grep "nsds50ruv\|nsDS5ReplicaId"
>> Enter LDAP Password:
>> nsDS5ReplicaId: 7
>> nsds50ruv: {replicageneration} 55c8f3640004
>> nsds50ruv: {replica 7 ldap://seattlenfs.bpt.rocks:389}
>> 568ac3cc0007 57
>> nsds50ruv: {replica 20 ldap://freeipa-sea.bpt.rocks:389}
>> 57b1037700020014
>> nsds50ruv: {replica 18 ldap://bpt-nyc1-nfs.bpt.rocks:389}
>> 57a4780100010012
>> nsds50ruv: {replica 15 ldap://fremontnis.bpt.rocks:389}
>> 57a40386000f 5
>> nsds50ruv: {replica 14 ldap://freeipa-dal.bpt.rocks:389}
>> 57a2dccd000e
>> nsds50ruv: {replica 17 ldap://edinburghnfs.bpt.rocks:389}
>> 57a422f90011
>> nsds50ruv: {replica 19 ldap://bellevuenfs.bpt.rocks:389}
>> 57a4f20d00060013
>> nsds50ruv: {replica 16 ldap://bellevuenfs.bpt.rocks:389}
>> 57a417060010
>> nsds50ruv: {replica 9 ldap://bellevuenfs.bpt.rocks:389}
>> 570484ee0009 5
>>
>>
>> So I try to kill them like so:
>> [ianh@seattlenfs ~]$ ipa-replica-manage clean-ruv 9 --force --cleanup
>> ipa: WARNING: session memcached servers not running
>> Clean the Replication Update Vector for bellevuenfs.bpt.rocks:389
>>
>> Cleaning the wrong replica ID will cause that server to no
>> longer replicate so it may miss updates while the process
>> is running. It would need to be re-initialized to maintain
>> consistency. Be very careful.
>> Background task created to clean replication data. This may take a while.
>> This may be safely interrupted with Ctrl+C
>> ^C[ianh@seattlenfs ~]$ ipa-replica-manage clean-ruv 16 --force --cleanup
>> ipa: WARNING: session memcached servers not running
>> Clean the Replication Update Vector for bellevuenfs.bpt.rocks:389
>>
>> Cleaning the wrong replica ID will cause that server to no
>> longer replicate so it may miss updates while the process
>> is running. It would need to be re-initialized to maintain
>> consistency. Be very careful.
>> Background task created to clean replication data. This may take a while.
>> This may be safely interrupted with Ctrl+C
>> ^C[ianh@seattlenfs ~]$ ipa-replica-manage list-clean-ruv
>> ipa: WARNING: session memcached servers not running
>> CLEANALLRUV tasks
>> RID 16: Waiting to process all the updates from the deleted replica...
>> RID 9: Waiting to process all the updates from the deleted replica...
>>
>> No abort CLEANALLRUV tasks running
>> [ianh@seattlenfs ~]$ ipa-replica-manage list-clean-ruv
>> ipa: WARNING: session memcached servers not running
>> CLEANALLRUV tasks
>> RID 16: Waiting to process all the updates from the deleted replica...
>> RID 9: Waiting to process all the updates from the deleted replica...
>>
>> and it never finishes.
>>
>> seattlenfs is the first master, that's the only place I should have to
>> run this command, right?
> right, you need to run it only on one master, but this ease of use can
> become the problem.
> The cleanallruv task is propagated to all servers in the topology and it
> does this based on the replication agreements it finds.
> A frequent cause of failure is that replication agreements still exist
> pointing to no longer existing servers. It is a bit tedious, but could
> you run the following search on ALL
> of your current replicas (as directory manager):
>
> ldapsearch .. -b "cn=config" "objectclass=nsds5replicationagreement"
> nsds5replicahost
>
> if you find any agreement where nsds5replicahost is a host no longer
> existing or working, delete these agreements.
I have 7 FreeIPA servers, all of which have been in existence in some
form or another since I started. It used to work great. I've broken it
now but the hostnames and ip addresses all still exist. I've
uninstalled and reinstalled them a few times which I think is the source
of my troubles so I tried to straighten out the RUVs and probably messed
that up pretty good
Anyway, now what I THINK I have i
Re: [Freeipa-users] clean-ruv
On 08/24/2016 04:43 AM, Ludwig Krispenz wrote:
>
> On 08/24/2016 01:08 AM, Ian Harding wrote:
>>
>> On 08/23/2016 03:14 AM, Ludwig Krispenz wrote:
>>> On 08/23/2016 11:52 AM, Ian Harding wrote:
>>>> Ah. I see. I mixed those up but I see that those would have to be
>>>> consistent.
>>>>
>>>> However, I have been trying to beat some invalid RUV to death for a
>>>> long
>>>> time and I can't seem to kill them.
>>>>
>>>> For example, bellevuenfs has 9 and 16 which are invalid:
>>>>
>>>> [ianh@seattlenfs ~]$ ldapsearch -ZZ -h seattlenfs.bpt.rocks -D
>>>> "cn=Directory Manager" -W -b "dc=bpt,dc=rocks"
>>>> "(&(objectclass=nstombstone)(nsUniqueId=---))"
>>>>
>>>>
>>>> | grep "nsds50ruv\|nsDS5ReplicaId"
>>>> Enter LDAP Password:
>>>> nsDS5ReplicaId: 7
>>>> nsds50ruv: {replicageneration} 55c8f3640004
>>>> nsds50ruv: {replica 7 ldap://seattlenfs.bpt.rocks:389}
>>>> 568ac3cc0007 57
>>>> nsds50ruv: {replica 20 ldap://freeipa-sea.bpt.rocks:389}
>>>> 57b1037700020014
>>>> nsds50ruv: {replica 18 ldap://bpt-nyc1-nfs.bpt.rocks:389}
>>>> 57a4780100010012
>>>> nsds50ruv: {replica 15 ldap://fremontnis.bpt.rocks:389}
>>>> 57a40386000f 5
>>>> nsds50ruv: {replica 14 ldap://freeipa-dal.bpt.rocks:389}
>>>> 57a2dccd000e
>>>> nsds50ruv: {replica 17 ldap://edinburghnfs.bpt.rocks:389}
>>>> 57a422f90011
>>>> nsds50ruv: {replica 19 ldap://bellevuenfs.bpt.rocks:389}
>>>> 57a4f20d00060013
>>>> nsds50ruv: {replica 16 ldap://bellevuenfs.bpt.rocks:389}
>>>> 57a417060010
>>>> nsds50ruv: {replica 9 ldap://bellevuenfs.bpt.rocks:389}
>>>> 570484ee0009 5
>>>>
>>>>
>>>> So I try to kill them like so:
>>>> [ianh@seattlenfs ~]$ ipa-replica-manage clean-ruv 9 --force --cleanup
>>>> ipa: WARNING: session memcached servers not running
>>>> Clean the Replication Update Vector for bellevuenfs.bpt.rocks:389
>>>>
>>>> Cleaning the wrong replica ID will cause that server to no
>>>> longer replicate so it may miss updates while the process
>>>> is running. It would need to be re-initialized to maintain
>>>> consistency. Be very careful.
>>>> Background task created to clean replication data. This may take a
>>>> while.
>>>> This may be safely interrupted with Ctrl+C
>>>> ^C[ianh@seattlenfs ~]$ ipa-replica-manage clean-ruv 16 --force
>>>> --cleanup
>>>> ipa: WARNING: session memcached servers not running
>>>> Clean the Replication Update Vector for bellevuenfs.bpt.rocks:389
>>>>
>>>> Cleaning the wrong replica ID will cause that server to no
>>>> longer replicate so it may miss updates while the process
>>>> is running. It would need to be re-initialized to maintain
>>>> consistency. Be very careful.
>>>> Background task created to clean replication data. This may take a
>>>> while.
>>>> This may be safely interrupted with Ctrl+C
>>>> ^C[ianh@seattlenfs ~]$ ipa-replica-manage list-clean-ruv
>>>> ipa: WARNING: session memcached servers not running
>>>> CLEANALLRUV tasks
>>>> RID 16: Waiting to process all the updates from the deleted replica...
>>>> RID 9: Waiting to process all the updates from the deleted replica...
>>>>
>>>> No abort CLEANALLRUV tasks running
>>>> [ianh@seattlenfs ~]$ ipa-replica-manage list-clean-ruv
>>>> ipa: WARNING: session memcached servers not running
>>>> CLEANALLRUV tasks
>>>> RID 16: Waiting to process all the updates from the deleted replica...
>>>> RID 9: Waiting to process all the updates from the deleted replica...
>>>>
>>>> and it never finishes.
>>>>
>>>> seattlenfs is the first master, that's the only place I should have to
>>>> run this command, right?
>>> right, you need to run it only on one master, but this ease of use can
>>> become the problem.
>>> The cleanallruv task is propagated to all servers in the topology and it
>>> does this based on the replication agreements it finds.
>>> A frequent cause of failure is that replication agreements still exist
>>
[Freeipa-users] Cleaning Up an Unholy Mess
I tried to simply uninstall and reinstall freeipa-dal and this happened. It only had a replication agreement with freeipa-sea [root@freeipa-dal ianh]# ipa-server-install --uninstall This is a NON REVERSIBLE operation and will delete all data and configuration! Are you sure you want to continue with the uninstall procedure? [no]: yes Shutting down all IPA services Removing IPA client configuration Unconfiguring ntpd Configuring certmonger to stop tracking system certificates for KRA Configuring certmonger to stop tracking system certificates for CA Unconfiguring CA Unconfiguring named Unconfiguring ipa-dnskeysyncd Unconfiguring web server Unconfiguring krb5kdc Unconfiguring kadmin Unconfiguring directory server Unconfiguring ipa_memcached Unconfiguring ipa-otpd [root@freeipa-dal ianh]# ipa-server-install --uninstall This is a NON REVERSIBLE operation and will delete all data and configuration! Are you sure you want to continue with the uninstall procedure? [no]: yes WARNING: Failed to connect to Directory Server to find information about replication agreements. Uninstallation will continue despite the possible existing replication agreements. Shutting down all IPA services Removing IPA client configuration Configuring certmonger to stop tracking system certificates for KRA Configuring certmonger to stop tracking system certificates for CA [root@freeipa-dal ianh]# ipa-replica-install --setup-ca --setup-dns --no-forwarders /var/lib/ipa/replica-info-freeipa-dal.bpt.rocks.gpg Directory Manager (existing master) password: The host freeipa-dal.bpt.rocks already exists on the master server. You should remove it before proceeding: % ipa host-del freeipa-dal.bpt.rocks [root@freeipa-dal ianh]# So I tried to delete it again with --force [root@freeipa-sea ianh]# ipa-replica-manage --force del freeipa-dal.bpt.rocks Directory Manager password: 'freeipa-sea.bpt.rocks' has no replication agreement for 'freeipa-dal.bpt.rocks' [root@freeipa-sea ianh]# Can't delete it from the master server either [root@seattlenfs ianh]# ipa host-del freeipa-dal.bpt.rocks ipa: ERROR: invalid 'hostname': An IPA master host cannot be deleted or disabled Now what? I'm running out of things that work. -- Ian Harding IT Director Brown Paper Tickets 1-800-838-3006 ext 7186 http://www.brownpapertickets.com -- 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] Cleaning Up an Unholy Mess
On 08/24/2016 06:33 PM, Rob Crittenden wrote: > Ian Harding wrote: >> I tried to simply uninstall and reinstall freeipa-dal and this happened. >> >> It only had a replication agreement with freeipa-sea >> >> [root@freeipa-dal ianh]# ipa-server-install --uninstall >> >> This is a NON REVERSIBLE operation and will delete all data and >> configuration! >> >> Are you sure you want to continue with the uninstall procedure? [no]: yes >> Shutting down all IPA services >> Removing IPA client configuration >> Unconfiguring ntpd >> Configuring certmonger to stop tracking system certificates for KRA >> Configuring certmonger to stop tracking system certificates for CA >> Unconfiguring CA >> Unconfiguring named >> Unconfiguring ipa-dnskeysyncd >> Unconfiguring web server >> Unconfiguring krb5kdc >> Unconfiguring kadmin >> Unconfiguring directory server >> Unconfiguring ipa_memcached >> Unconfiguring ipa-otpd >> [root@freeipa-dal ianh]# ipa-server-install --uninstall >> >> This is a NON REVERSIBLE operation and will delete all data and >> configuration! >> >> Are you sure you want to continue with the uninstall procedure? [no]: yes >> >> WARNING: Failed to connect to Directory Server to find information about >> replication agreements. Uninstallation will continue despite the possible >> existing replication agreements. >> Shutting down all IPA services >> Removing IPA client configuration >> Configuring certmonger to stop tracking system certificates for KRA >> Configuring certmonger to stop tracking system certificates for CA >> [root@freeipa-dal ianh]# ipa-replica-install --setup-ca --setup-dns >> --no-forwarders /var/lib/ipa/replica-info-freeipa-dal.bpt.rocks.gpg >> Directory Manager (existing master) password: >> >> The host freeipa-dal.bpt.rocks already exists on the master server. >> You should remove it before proceeding: >> % ipa host-del freeipa-dal.bpt.rocks >> [root@freeipa-dal ianh]# >> >> So I tried to delete it again with --force >> >> [root@freeipa-sea ianh]# ipa-replica-manage --force del >> freeipa-dal.bpt.rocks >> Directory Manager password: >> >> 'freeipa-sea.bpt.rocks' has no replication agreement for >> 'freeipa-dal.bpt.rocks' >> [root@freeipa-sea ianh]# >> >> Can't delete it from the master server either >> >> [root@seattlenfs ianh]# ipa host-del freeipa-dal.bpt.rocks >> ipa: ERROR: invalid 'hostname': An IPA master host cannot be deleted or >> disabled >> >> >> Now what? I'm running out of things that work. > > Not sure what version of IPA you have but try: > > # ipa-replica-manage --force --cleanup delete freeipa-dal.bpt.rocks > > If this had a CA on it then you'll want to ensure that any replication > agreements it had have been removed as well. > > rob > It turns out I'm not smart enough to untangle this mess. Is there any way to kind of start over? I managed to delete and recreate a couple replicas but the problems (obsolete ruv as far as I can tell) carry on with the new replicas. They won't even replicate back to the master they were created from. Basically, is there a way to do a fresh install of FreeIPA server, and do a dump/restore of data from my existing messed up install? Thanks! -- Ian Harding IT Director Brown Paper Tickets 1-800-838-3006 ext 7186 http://www.brownpapertickets.com -- 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] Cleaning Up an Unholy Mess
On 08/25/2016 10:41 AM, Rob Crittenden wrote: > Ian Harding wrote: >> >> >> On 08/24/2016 06:33 PM, Rob Crittenden wrote: >>> Ian Harding wrote: >>>> I tried to simply uninstall and reinstall freeipa-dal and this >>>> happened. >>>> >>>> It only had a replication agreement with freeipa-sea >>>> >>>> [root@freeipa-dal ianh]# ipa-server-install --uninstall >>>> >>>> This is a NON REVERSIBLE operation and will delete all data and >>>> configuration! >>>> >>>> Are you sure you want to continue with the uninstall procedure? >>>> [no]: yes >>>> Shutting down all IPA services >>>> Removing IPA client configuration >>>> Unconfiguring ntpd >>>> Configuring certmonger to stop tracking system certificates for KRA >>>> Configuring certmonger to stop tracking system certificates for CA >>>> Unconfiguring CA >>>> Unconfiguring named >>>> Unconfiguring ipa-dnskeysyncd >>>> Unconfiguring web server >>>> Unconfiguring krb5kdc >>>> Unconfiguring kadmin >>>> Unconfiguring directory server >>>> Unconfiguring ipa_memcached >>>> Unconfiguring ipa-otpd >>>> [root@freeipa-dal ianh]# ipa-server-install --uninstall >>>> >>>> This is a NON REVERSIBLE operation and will delete all data and >>>> configuration! >>>> >>>> Are you sure you want to continue with the uninstall procedure? >>>> [no]: yes >>>> >>>> WARNING: Failed to connect to Directory Server to find information >>>> about >>>> replication agreements. Uninstallation will continue despite the >>>> possible >>>> existing replication agreements. >>>> Shutting down all IPA services >>>> Removing IPA client configuration >>>> Configuring certmonger to stop tracking system certificates for KRA >>>> Configuring certmonger to stop tracking system certificates for CA >>>> [root@freeipa-dal ianh]# ipa-replica-install --setup-ca --setup-dns >>>> --no-forwarders /var/lib/ipa/replica-info-freeipa-dal.bpt.rocks.gpg >>>> Directory Manager (existing master) password: >>>> >>>> The host freeipa-dal.bpt.rocks already exists on the master server. >>>> You should remove it before proceeding: >>>> % ipa host-del freeipa-dal.bpt.rocks >>>> [root@freeipa-dal ianh]# >>>> >>>> So I tried to delete it again with --force >>>> >>>> [root@freeipa-sea ianh]# ipa-replica-manage --force del >>>> freeipa-dal.bpt.rocks >>>> Directory Manager password: >>>> >>>> 'freeipa-sea.bpt.rocks' has no replication agreement for >>>> 'freeipa-dal.bpt.rocks' >>>> [root@freeipa-sea ianh]# >>>> >>>> Can't delete it from the master server either >>>> >>>> [root@seattlenfs ianh]# ipa host-del freeipa-dal.bpt.rocks >>>> ipa: ERROR: invalid 'hostname': An IPA master host cannot be deleted or >>>> disabled >>>> >>>> >>>> Now what? I'm running out of things that work. >>> >>> Not sure what version of IPA you have but try: >>> >>> # ipa-replica-manage --force --cleanup delete freeipa-dal.bpt.rocks >>> >>> If this had a CA on it then you'll want to ensure that any replication >>> agreements it had have been removed as well. >>> >>> rob >>> >> >> It turns out I'm not smart enough to untangle this mess. >> >> Is there any way to kind of start over? I managed to delete and >> recreate a couple replicas but the problems (obsolete ruv as far as I >> can tell) carry on with the new replicas. They won't even replicate >> back to the master they were created from. > > Once you have the right version of 389-ds then then cleanruv tasks work > a lot better. What version are you running now? 1.3.4.0. It's handcuffed to my CentOS 7 so I don't want to update it outside the CentOS ecosystem. What's the downside of upgrading it from source or an RPM for a different flavor of RedHat derived Linux? I'm a one-man band but I'd be interested in hearing a pitch from someone who is super smart on this stuff for a working consulting gig and maybe ongoing support. Who would I talk to at RedHat about coming in from the cold for full on corporate support? Thanks! > >> Basically, is there a way to do a fresh install of FreeIPA server, and >> do a dump/restore of data from my existing messed up install? > > Not really, no. You can migrate IPA to IPA but only users and groups and > you lose private groups for existing users (they become regular POSIX > groups). > > rob > -- Ian Harding IT Director Brown Paper Tickets 1-800-838-3006 ext 7186 http://www.brownpapertickets.com -- 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] Cleaning Up an Unholy Mess
On 08/25/2016 03:10 PM, Mark Reynolds wrote: > > > On 08/25/2016 02:04 PM, Ian Harding wrote: >> >> On 08/25/2016 10:41 AM, Rob Crittenden wrote: >>> Ian Harding wrote: >>>> >>>> On 08/24/2016 06:33 PM, Rob Crittenden wrote: >>>>> Ian Harding wrote: >>>>>> I tried to simply uninstall and reinstall freeipa-dal and this >>>>>> happened. >>>>>> >>>>>> It only had a replication agreement with freeipa-sea >>>>>> >>>>>> [root@freeipa-dal ianh]# ipa-server-install --uninstall >>>>>> >>>>>> This is a NON REVERSIBLE operation and will delete all data and >>>>>> configuration! >>>>>> >>>>>> Are you sure you want to continue with the uninstall procedure? >>>>>> [no]: yes >>>>>> Shutting down all IPA services >>>>>> Removing IPA client configuration >>>>>> Unconfiguring ntpd >>>>>> Configuring certmonger to stop tracking system certificates for KRA >>>>>> Configuring certmonger to stop tracking system certificates for CA >>>>>> Unconfiguring CA >>>>>> Unconfiguring named >>>>>> Unconfiguring ipa-dnskeysyncd >>>>>> Unconfiguring web server >>>>>> Unconfiguring krb5kdc >>>>>> Unconfiguring kadmin >>>>>> Unconfiguring directory server >>>>>> Unconfiguring ipa_memcached >>>>>> Unconfiguring ipa-otpd >>>>>> [root@freeipa-dal ianh]# ipa-server-install --uninstall >>>>>> >>>>>> This is a NON REVERSIBLE operation and will delete all data and >>>>>> configuration! >>>>>> >>>>>> Are you sure you want to continue with the uninstall procedure? >>>>>> [no]: yes >>>>>> >>>>>> WARNING: Failed to connect to Directory Server to find information >>>>>> about >>>>>> replication agreements. Uninstallation will continue despite the >>>>>> possible >>>>>> existing replication agreements. >>>>>> Shutting down all IPA services >>>>>> Removing IPA client configuration >>>>>> Configuring certmonger to stop tracking system certificates for KRA >>>>>> Configuring certmonger to stop tracking system certificates for CA >>>>>> [root@freeipa-dal ianh]# ipa-replica-install --setup-ca --setup-dns >>>>>> --no-forwarders /var/lib/ipa/replica-info-freeipa-dal.bpt.rocks.gpg >>>>>> Directory Manager (existing master) password: >>>>>> >>>>>> The host freeipa-dal.bpt.rocks already exists on the master server. >>>>>> You should remove it before proceeding: >>>>>> % ipa host-del freeipa-dal.bpt.rocks >>>>>> [root@freeipa-dal ianh]# >>>>>> >>>>>> So I tried to delete it again with --force >>>>>> >>>>>> [root@freeipa-sea ianh]# ipa-replica-manage --force del >>>>>> freeipa-dal.bpt.rocks >>>>>> Directory Manager password: >>>>>> >>>>>> 'freeipa-sea.bpt.rocks' has no replication agreement for >>>>>> 'freeipa-dal.bpt.rocks' >>>>>> [root@freeipa-sea ianh]# >>>>>> >>>>>> Can't delete it from the master server either >>>>>> >>>>>> [root@seattlenfs ianh]# ipa host-del freeipa-dal.bpt.rocks >>>>>> ipa: ERROR: invalid 'hostname': An IPA master host cannot be deleted or >>>>>> disabled >>>>>> >>>>>> >>>>>> Now what? I'm running out of things that work. >>>>> Not sure what version of IPA you have but try: >>>>> >>>>> # ipa-replica-manage --force --cleanup delete freeipa-dal.bpt.rocks >>>>> >>>>> If this had a CA on it then you'll want to ensure that any replication >>>>> agreements it had have been removed as well. >>>>> >>>>> rob >>>>> >>>> It turns out I'm not smart enough to untangle this mess. >>>> >>>> Is there any way to kind of start over? I managed to delete and >>>> recreate a couple replicas but the problems (obsolet
[Freeipa-users] Me Again
c=rocks does not exist [20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=bpt,dc=rocks does not exist [20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=bpt,dc=rocks does not exist Any clues what that's about? The high numbered RUV are for CA RUV I assume. Those other machines are still installed but IPA services turned off so people can't authenticate to them because replication was not working. If there was some way I could go down to one machine (freeipa-sea) and get it all cleaned up, no ghost RUV, everything quiet in the logs, and start over creating replicas, I would love to do that. Seems like someone smarter than me could stop the server, back up the ldif files and edit them to make all the cruft go away. Is that possible? I've started a conversation with RedHat about getting on board with the official bits and support but I want to know if it's possible/cost effective to do what I describe, along with, I assume, migrating to the official versions of Spacewalk and FreeIPA. Thanks! Ian -- Ian Harding IT Director Brown Paper Tickets 1-800-838-3006 ext 7186 http://www.brownpapertickets.com -- 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] Replication issues (was Me Again)
On 09/21/2016 11:43 AM, Rob Crittenden wrote: > Ian Harding wrote: >> I used to have a lot of replicas, but like a house of cards, it all came >> crashing down. >> >> I was down to two, that seemed to be replicating, but last few days I've >> noticed that they haven't always been. >> >> freeipa-sea.bpt.rocks is where we do all our admin. >> seattlenfs.bpt.rocks is also up and running and can be used for >> authentication. >> >> When I noticed that logins were failing after password changes I did >> >> ipa-replica-manage re-initialize --from=freeipa-sea.bpt.rocks > > Note that this is the hammer approach. Diagnosing the underlying issues > would probably be best. > > What is the output of: > > $ rpm -q 389-ds-base freeipa-server > > (or ipa-server depending on distro). > > That will give us the info needed to suggest what else to look for. > > rob > Hammer sounds pretty good. # rpm -q 389-ds-base ipa-server 389-ds-base-1.3.4.0-33.el7_2.x86_64 ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64 >> >> on seattlenfs.bpt.rocks and replication appeared to be working again. >> >> Well it happened again, and this time I peeked at the dirsrv errors log >> and saw some scary things having to do with the CA. >> >> [19/Sep/2016:02:55:50 -0700] 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 0 (Success) >> [19/Sep/2016:02:55:50 -0700] slapi_ldap_bind - Error: could not perform >> interactive bind for id [] authentication mechanism [GSSAPI]: error -1 >> (Can't contact LDAP server) >> [19/Sep/2016:02:55:50 -0700] NSMMReplicationPlugin - >> agmt="cn=meTofreeipa-sea.bpt.rocks" (freeipa-sea:389): Replication bind >> with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) () >> [19/Sep/2016:02:56:04 -0700] NSMMReplicationPlugin - >> agmt="cn=meTofreeipa-sea.bpt.rocks" (freeipa-sea:389): Replication bind >> with GSSAPI auth resumed >> [20/Sep/2016:10:18:25 -0700] NSMMReplicationPlugin - >> multimaster_be_state_change: replica dc=bpt,dc=rocks is going offline; >> disabling replication >> [20/Sep/2016:10:18:26 -0700] - WARNING: Import is running with >> nsslapd-db-private-import-mem on; No other process is allowed to access >> the database >> [20/Sep/2016:10:18:29 -0700] - import userRoot: Workers finished; >> cleaning up... >> [20/Sep/2016:10:18:29 -0700] - import userRoot: Workers cleaned up. >> [20/Sep/2016:10:18:29 -0700] - import userRoot: Indexing complete. >> Post-processing... >> [20/Sep/2016:10:18:29 -0700] - import userRoot: Generating >> numsubordinates (this may take several minutes to complete)... >> [20/Sep/2016:10:18:29 -0700] - import userRoot: Generating >> numSubordinates complete. >> [20/Sep/2016:10:18:29 -0700] - import userRoot: Gathering ancestorid >> non-leaf IDs... >> [20/Sep/2016:10:18:29 -0700] - import userRoot: Finished gathering >> ancestorid non-leaf IDs. >> [20/Sep/2016:10:18:29 -0700] - import userRoot: Creating ancestorid >> index (new idl)... >> [20/Sep/2016:10:18:29 -0700] - import userRoot: Created ancestorid index >> (new idl). >> [20/Sep/2016:10:18:29 -0700] - import userRoot: Flushing caches... >> [20/Sep/2016:10:18:29 -0700] - import userRoot: Closing files... >> [20/Sep/2016:10:18:29 -0700] - import userRoot: Import complete. >> Processed 1324 entries in 3 seconds. (441.33 entries/sec) >> [20/Sep/2016:10:18:29 -0700] NSMMReplicationPlugin - >> multimaster_be_state_change: replica dc=bpt,dc=rocks is coming online; >> enabling replication >> [20/Sep/2016:10:18:29 -0700] NSMMReplicationPlugin - replica_reload_ruv: >> Warning: new data for replica dc=bpt,dc=rocks does not match the data in >> the changelog. >> Recreating the changelog file. This could affect replication with >> replica's consumers in which case the consumers should be reinitialized. >> [20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target >> cn=groups,cn=compat,dc=bpt,dc=rocks does not exist >> [20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target >> cn=computers,cn=compat,dc=bpt,dc=rocks does not exist >> [20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target >> cn=ng,cn=compat,dc=bpt,dc=rocks does not exist >> [20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target >> ou=sudoers,dc=bpt,dc=rocks does not exist >> [20/Sep/2016:10:18:29 -0700] NSACLPlugin - The ACL target >> cn=users,cn=compat,dc=bpt,dc=rocks does not exist >> [20/Se
[Freeipa-users] Different Database Generation ID
I have this error in the log of my FreeIPA server freeipa-sea.bpt.rocks: [11/Oct/2016:09:04:39 -0700] NSMMReplicationPlugin - agmt="cn=masterAgreement1-seattlenfs.bpt.rocks-pki-tomcat" (seattlenfs:389): The remote replica has a different database generation ID than the local database. You may have to reinitialize the remote replica, or the local replica. So I did this: ipa-replica-manage re-initialize --from freeipa-sea.bpt.rocks on seattlenfs But the error continues. I think I know why. freeipa-sea had a meltdown and I had to rebuild it, and established it as a replica of seattlenfs. Unfortunately, I think seattlenfs was a replica of the original freeipa-sea. It seems like a bad idea to reinitialize themselves from each other, and in fact it's warned against here: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Troubleshooting_Replication_Related_Problems.html "... Also, M2 should not initialize M1 back. " But in looking at my bash history I have indeed done that as well. Is there any way out of this mess? These two servers actually DO replicate, most of the time. They stop for no reason and restarting the ipa services on freeipa-sea does get them started again. -- Ian Harding IT Director Brown Paper Tickets 1-800-838-3006 ext 7186 http://www.brownpapertickets.com -- 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] Topology -> IPA Servers
I have finally had some luck expunging the remnants of long removed IPA servers now that I have upgraded to FreeIPA 4.4. However, when I look at the IPA Servers list under Topology, I now have three records like so: Server name Min domain level Max domain level Managed suffixes freeipa-dal.bpt.rocks freeipa-sea.bpt.rocks 0 1 domain, ca seattlenfs.bpt.rocks 0 0 domain Showing 1 to 3 of 3 entries. And an error dialog pops up which says "freeipa-dal.bpt.rocks: server not found" which is true, it's long dead. [root@freeipa-sea ianh]# ipa-replica-manage del --force --cleanup freeipa-dal.bpt.rocks Cleaning a master is irreversible. This should not normally be require, so use cautiously. Continue to clean master? [no]: yes [root@freeipa-sea ianh]# ipa host-find freeipa-dal.bpt.rocks --all --- 0 hosts matched --- Number of entries returned 0 [root@freeipa-sea ianh]# ipa-replica-manage list seattlenfs.bpt.rocks: master freeipa-dal.bpt.rocks: master freeipa-sea.bpt.rocks: master [root@freeipa-sea ianh]# ipa-replica-manage list-ruv Directory Manager password: Replica Update Vectors: seattlenfs.bpt.rocks:389: 21 freeipa-sea.bpt.rocks:389: 20 Certificate Server Replica Update Vectors: freeipa-sea.bpt.rocks:389: 1065 Any ideas how to make that ghost finally go away? I'm trying to change the domain level of freeipa-sea.bpt.rocks, but when I do I get "Domain Level cannot be raised to 1, server freeipa-dal.bpt.rocks does not support it." Thanks! -- Ian Harding IT Director Brown Paper Tickets 1-800-838-3006 ext 7186 http://www.brownpapertickets.com -- 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] IPA to IPA migration
On 01/05/2017 07:17 AM, Rob Crittenden wrote: > Timothy Geier wrote: >> This is something I’ve looked at lately and a manual proof of concept I >> just did (using ideas from >> https://www.freeipa.org/page/Howto/Migration#Migrating_from_other_FreeIPA_to_FreeIPA) >> makes it seem theoretically possible (though it looks like, barring the >> migration of the kerberos master key, all enrolled hosts would need to >> use ipa-getkeytab to get a replacement keytab from the new server and >> copy it to /etc/krb5.keytab so that sssd will work properly..the >> alternative is re-enrollment. All other keytabs in use by other >> applications would have to be similarly replaced). > > Why migrate at all? It is possible to get a FreeIPA installation so boogered up that it's just not salvageable. I'm pretty close to that right now. The replication model is really great but it replicates all my mistakes. Maybe I'm just not smart enough, but I suspect others have wished they could just throw in the towel and start over. I would if it were relatively easy, that is, if I could export and reimport users (ideally with passwords), hosts, groups, hbac rules, etc. I woudln't even mind having to re-enroll them. -- Ian Harding IT Director Brown Paper Tickets 1-800-838-3006 ext 7186 http://www.brownpapertickets.com -- 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] DB locks and Clean RUV
I just updated my FreeIPA server and now the LDAP instance crashes daily at 9:15 PM. I have a lot of these in my logs : Mar 14 08:40:20 freeipa-sea ns-slapd: [14/Mar/2017:08:40:20.781100512 -0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 9): Replica is not cleaned yet (agmt="cn=meTobellevuenfs.bpt.rocks" (bellevuenfs:389)) Mar 14 08:40:20 freeipa-sea ns-slapd: [14/Mar/2017:08:40:20.781560066 -0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 9): Replicas have not been cleaned yet, retrying in 14400 seconds Mar 14 08:40:20 freeipa-sea ns-slapd: [14/Mar/2017:08:40:20.837043110 -0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 16): Replica is not cleaned yet (agmt="cn=meTobellevuenfs.bpt.rocks" (bellevuenfs:389)) Mar 14 08:40:20 freeipa-sea ns-slapd: [14/Mar/2017:08:40:20.837354975 -0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 16): Replicas have not been cleaned yet, retrying in 14400 seconds Mar 14 08:40:28 freeipa-sea ns-slapd: [14/Mar/2017:08:40:28.214216609 -0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 7): Replica is not cleaned yet (agmt="cn=meTobellevuenfs.bpt.rocks" (bellevuenfs:389)) Mar 14 08:40:28 freeipa-sea ns-slapd: [14/Mar/2017:08:40:28.214609007 -0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 7): Replicas have not been cleaned yet, retrying in 14400 seconds Mar 14 08:40:28 freeipa-sea ns-slapd: [14/Mar/2017:08:40:28.286618494 -0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 14): Replica is not cleaned yet (agmt="cn=meTobellevuenfs.bpt.rocks" (bellevuenfs:389)) Mar 14 08:40:28 freeipa-sea ns-slapd: [14/Mar/2017:08:40:28.287040274 -0700] NSMMReplicationPlugin - CleanAllRUV Task (rid 14): Replicas have not been cleaned yet, retrying in 14400 seconds But there are apparently not any tasks running: [root@freeipa-sea log]# ipa-replica-manage list-clean-ruv Directory Manager password: No CLEANALLRUV tasks running No abort CLEANALLRUV tasks running The crash happens after: Mar 13 21:18:13 freeipa-sea ns-slapd: [13/Mar/2017:21:18:13.702716206 -0700] NSMMReplicationPlugin - changelog program - _cl5PurgeRID: Ran out of db locks getting the next entry. Reduce the batch value and restart. Mar 13 21:18:15 freeipa-sea ns-slapd: [13/Mar/2017:21:18:15.303117842 -0700] NSMMReplicationPlugin - changelog program - _cl5PurgeRID: Ran out of db locks getting the next entry. Reduce the batch value and restart. Mar 13 21:18:16 freeipa-sea ns-slapd: [13/Mar/2017:21:18:16.628504719 -0700] NSMMReplicationPlugin - changelog program - _cl5PurgeRID: Ran out of db locks getting the next entry. Reduce the batch value and restart. Mar 13 21:18:17 freeipa-sea ns-slapd: [13/Mar/2017:21:18:17.954354140 -0700] NSMMReplicationPlugin - changelog program - _cl5PurgeRID: Ran out of db locks getting the next entry. Reduce the batch value and restart. Mar 13 21:18:19 freeipa-sea ns-slapd: [13/Mar/2017:21:18:19.284145453 -0700] NSMMReplicationPlugin - changelog program - _cl5PurgeRID: Ran out of db locks getting the next entry. Reduce the batch value and restart. Is there any way to get rid of the cleanallruv tasks that the system thinks are not running? Thanks! - Ian -- Ian Harding IT Director Brown Paper Tickets 1-800-838-3006 ext 7186 http://www.brownpapertickets.com -- 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] Manual Cleanup
I've made some progress. But I have one zombie replication agreement to
kill, I just don't know the syntax.
freeipa-dal.bpt.rocks does not exist. I want all references to it to go
away.
How would I do that with ldapmodify?
Thanks!
[root@freeipa-sea slapd-BPT-ROCKS]# ldapsearch -D "cn=directory
manager" -w ... -b "o=ipaca"
"(&(objectclass=nstombstone)(nsUniqueId=---))"
nscpentrywsi
# extended LDIF
#
# LDAPv3
# base with scope subtree
# filter:
(&(objectclass=nstombstone)(nsUniqueId=---))
# requesting: nscpentrywsi
#
# replica, o\3Dipaca, mapping tree, config
dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
nscpentrywsi: cn: replica
nscpentrywsi: createTimestamp: 20160814234939Z
nscpentrywsi: creatorsName: cn=directory manager
nscpentrywsi: modifiersName: cn=Multimaster Replication
Plugin,cn=plugins,cn=c
onfig
nscpentrywsi: modifyTimestamp: 20170316181544Z
nscpentrywsi: nsDS5Flags: 1
nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager
cloneAgreement1-freei
pa-sea.bpt.rocks-pki-tomcat,ou=csusers,cn=config
nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager
masterAgreement1-free
ipa-dal.bpt.rocks-pki-tomcat,ou=csusers,cn=config
nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager
masterAgreement1-seat
tlenfs.bpt.rocks-pki-tomcat,ou=csusers,cn=config
nscpentrywsi: nsDS5ReplicaId: 1065
nscpentrywsi: nsDS5ReplicaName: b21a1f1e-627911e6-93e6ef4b-69dcc2d1
nscpentrywsi: nsDS5ReplicaRoot: o=ipaca
nscpentrywsi: nsDS5ReplicaType: 3
nscpentrywsi: nsState::
KQQAAABO1spYKg
==
nscpentrywsi: nsds5replicabinddngroup: cn=replication
managers,cn=sysaccounts,
cn=etc,dc=bpt,dc=rocks
nscpentrywsi: nsds5replicabinddngroupcheckinterval: 60
nscpentrywsi: objectClass: top
nscpentrywsi: objectClass: nsDS5Replica
nscpentrywsi: objectClass: extensibleobject
nscpentrywsi: numSubordinates: 2
nscpentrywsi: nsds50ruv: {replicageneration} 57c291d90429
nscpentrywsi: nsds50ruv: {replica 1065 ldap://freeipa-sea.bpt.rocks:389}
57f84
0bf0429 58cad6670429
nscpentrywsi: nsds50ruv: {replica 1290 ldap://seattlenfs.bpt.rocks:389}
nscpentrywsi: nsds50ruv: {replica 1295 ldap://freeipa-dal.bpt.rocks:389}
nscpentrywsi: nsds5agmtmaxcsn:
o=ipaca;cloneAgreement1-freeipa-sea.bpt.rocks-p
ki-tomcat;seattlenfs.bpt.rocks;389;unavailable
nscpentrywsi: nsds5agmtmaxcsn:
o=ipaca;masterAgreement1-seattlenfs.bpt.rocks-p
ki-tomcat;seattlenfs.bpt.rocks;389;unavailable
nscpentrywsi: nsruvReplicaLastModified: {replica 1065
ldap://freeipa-sea.bpt.r
ocks:389} 58cad63d
nscpentrywsi: nsruvReplicaLastModified: {replica 1290
ldap://seattlenfs.bpt.ro
cks:389}
nscpentrywsi: nsruvReplicaLastModified: {replica 1295
ldap://freeipa-dal.bpt.r
ocks:389}
nscpentrywsi: nsds5ReplicaChangeCount: 15993
nscpentrywsi: nsds5replicareapactive: 0
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
[root@freeipa-sea slapd-BPT-ROCKS]# ipa-csreplica-manage del
freeipa-dal.bpt.rocks --forceDirectory Manager password:
'freeipa-sea.bpt.rocks' has no replication agreement for
'freeipa-dal.bpt.rocks'
[root@freeipa-sea slapd-BPT-ROCKS]# ipa-replica-manage list
seattlenfs.bpt.rocks: master
freeipa-dal.bpt.rocks: master
freeipa-sea.bpt.rocks: master
[root@freeipa-sea slapd-BPT-ROCKS]# ipa-replica-manage list
freeipa-sea.bpt.rocks
seattlenfs.bpt.rocks: replica
[root@freeipa-sea slapd-BPT-ROCKS]# ipa-csreplica-manage list
Directory Manager password:
seattlenfs.bpt.rocks: master
freeipa-dal.bpt.rocks: CA not configured
freeipa-sea.bpt.rocks: master
--
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] Manual Cleanup
On 03/17/2017 12:25 AM, Standa Laznicka wrote: > Hello Ian, > > You could do: > `ipa-replica-manage del freeipa-dal.bpt.rocks --force --cleanup` > I have done this, it warns me that I should be careful, I say yes, and it returns almost immediately. The master still shows up [root@freeipa-sea ianh]# ipa-replica-manage del freeipa-dal.bpt.rocks --force --cleanup Cleaning a master is irreversible. This should not normally be require, so use cautiously. Continue to clean master? [no]: yes > Then you may need to check again for the master with `ipa-replica-manage > list`. If it's not there anymore, check whether some RUVs are still in > place with `ipa-replica-manage list-ruv`. > > The last command should get you RUVs on both CA and domain suffixes if > you're using FreeIPA >= 4.3.2 (hope I got the .z number right). If you > see that there's some RUVs left for the wrong host, try calling > `ipa-replica-manage clean-ruv ` which should remove the RUV (no > matter the suffix - CA or domain - just give it the number and it should > work given FreeIPA >= 4.3.2 is used). > There aren't any dangling RUV that I can see but the 'master' record is still there. [root@freeipa-sea ianh]# ipa-replica-manage list seattlenfs.bpt.rocks: master freeipa-dal.bpt.rocks: master freeipa-sea.bpt.rocks: master [root@freeipa-sea ianh]# ipa-replica-manage list freeipa-sea.bpt.rocks seattlenfs.bpt.rocks: replica [root@freeipa-sea ianh]# ipa-replica-manage list seattlenfs.bpt.rocks freeipa-sea.bpt.rocks: replica [root@freeipa-sea ianh]# ipa-replica-manage list-ruv Directory Manager password: Replica Update Vectors: freeipa-sea.bpt.rocks:389: 20 seattlenfs.bpt.rocks:389: 21 Certificate Server Replica Update Vectors: freeipa-sea.bpt.rocks:389: 1065 seattlenfs.bpt.rocks:389: 1290 Thanks for your help, but I think I need some ldapdelete magic. Does this mean anything to you? I manually removed every reference to freeipa-dal from dse.ldif and started the directory server I still see this: [root@freeipa-sea ianh]# ldapsearch -D "cn=directory manager" -W -b cn=config | grep freeipa-dal Enter LDAP Password: nsslapd-referral: ldap://freeipa-dal.bpt.rocks:389/o%3Dipaca I have to think it is stored somewhere else when the server is offline in a database file and gets inserted into the DSE at startup? I found a mess of references to freeipa-dal in this section. Is there a way to make it go away? [root@freeipa-sea ianh]# ldapsearch -D 'cn=Directory Manager' -W -b 'cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks' | grep freeipa-dalEnter LDAP Password: # freeipa-dal.bpt.rocks + f0b9918f-6a5011e6-a4bad0d8-a4feaa1b, masters, ipa, et dn: cn=freeipa-dal.bpt.rocks+nsuniqueid=f0b9918f-6a5011e6-a4bad0d8-a4feaa1b,cn cn: freeipa-dal.bpt.rocks # CA + 5148cf38-6a5111e6-a4bad0d8-a4feaa1b, freeipa-dal.bpt.rocks + f0b9918f-6a dn: cn=CA+nsuniqueid=5148cf38-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.ro # KDC + 5148cf40-6a5111e6-a4bad0d8-a4feaa1b, freeipa-dal.bpt.rocks + f0b9918f-6 dn: cn=KDC+nsuniqueid=5148cf40-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.r # KPASSWD + 5148cf41-6a5111e6-a4bad0d8-a4feaa1b, freeipa-dal.bpt.rocks + f0b991 dn: cn=KPASSWD+nsuniqueid=5148cf41-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.b # MEMCACHE + 5148cf42-6a5111e6-a4bad0d8-a4feaa1b, freeipa-dal.bpt.rocks + f0b99 dn: cn=MEMCACHE+nsuniqueid=5148cf42-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal. # HTTP + 5148cf45-6a5111e6-a4bad0d8-a4feaa1b, freeipa-dal.bpt.rocks + f0b9918f- dn: cn=HTTP+nsuniqueid=5148cf45-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt. # OTPD + 5148cf46-6a5111e6-a4bad0d8-a4feaa1b, freeipa-dal.bpt.rocks + f0b9918f- dn: cn=OTPD+nsuniqueid=5148cf46-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt. # DNS + 9cfb790e-6a5111e6-a4bad0d8-a4feaa1b, freeipa-dal.bpt.rocks + f0b9918f-6 dn: cn=DNS+nsuniqueid=9cfb790e-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.r # DNSKeySync + 9cfb791b-6a5111e6-a4bad0d8-a4feaa1b, freeipa-dal.bpt.rocks + f0b [root@freeipa-sea ianh]# > HTH, > Standa > > On 03/16/2017 07:14 PM, Ian Harding wrote: >> I've made some progress. But I have one zombie replication agreement to >> kill, I just don't know the syntax. >> >> freeipa-dal.bpt.rocks does not exist. I want all references to it to go >> away. >> >> How would I do that with ldapmodify? >> >> Thanks! >> >> >> [root@freeipa-sea slapd-BPT-ROCKS]# ldapsearch -D "cn=directory >> manager" -w ... -b "o=ipaca" >> "(&(objectclass=nstombstone)(nsUniqueId=---))" >> >> nscpentrywsi >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: >> (&(objectclass=nstombstone)(nsUniqueId=--fff
[Freeipa-users] Funny Looking Records
I have some funny looking records left over from a deleted replica. I think this is why I see it in the list of servers and can't delete the server. ldapsearch -D 'cn=Directory Manager' -W -b 'cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks' dn ## These records have the name of the deleted server in them ## dn: cn=freeipa-dal.bpt.rocks+nsuniqueid=f0b9918f-6a5011e6-a4bad0d8-a4feaa1b,cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks dn: cn=CA+nsuniqueid=5148cf38-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.rocks+nsuniqueid=f0b9918f-6a5011e6-a4bad0d8-a4feaa1b,cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks dn: cn=KDC+nsuniqueid=5148cf40-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.rocks+nsuniqueid=f0b9918f-6a5011e6-a4bad0d8-a4feaa1b,cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks dn: cn=KPASSWD+nsuniqueid=5148cf41-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.rocks+nsuniqueid=f0b9918f-6a5011e6-a4bad0d8-a4feaa1b,cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks dn: cn=MEMCACHE+nsuniqueid=5148cf42-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.rocks+nsuniqueid=f0b9918f-6a5011e6-a4bad0d8-a4feaa1b,cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks dn: cn=HTTP+nsuniqueid=5148cf45-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.rocks+nsuniqueid=f0b9918f-6a5011e6-a4bad0d8-a4feaa1b,cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks dn: cn=OTPD+nsuniqueid=5148cf46-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.rocks+nsuniqueid=f0b9918f-6a5011e6-a4bad0d8-a4feaa1b,cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks dn: cn=DNS+nsuniqueid=9cfb790e-6a5111e6-a4bad0d8-a4feaa1b,cn=freeipa-dal.bpt.rocks+nsuniqueid=f0b9918f-6a5011e6-a4bad0d8-a4feaa1b,cn=masters,cn=ipa,cn=etc,dc=bpt,dc=rocks How can I make them go away? -- Ian Harding IT Director Brown Paper Tickets 1-800-838-3006 ext 7186 http://www.brownpapertickets.com -- 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 server-del
Is there any way this can be made to work? This server does not exist in real life or seemingly in FreeIPA, but a ghost of it does. ianh@vm-ian-laptop:~$ ipa server-find freeipa-dal.bpt.rocks 1 IPA server matched Server name: freeipa-dal.bpt.rocks Min domain level: 0 Max domain level: 0 Number of entries returned 1 ianh@vm-ian-laptop:~$ ipa server-del freeipa-dal.bpt.rocks Removing freeipa-dal.bpt.rocks from replication topology, please wait... ipa: ERROR: freeipa-dal.bpt.rocks: server not found ianh@vm-ian-laptop:~$ ipa server-del freeipa-dal.bpt.rocks --force Removing freeipa-dal.bpt.rocks from replication topology, please wait... ipa: ERROR: freeipa-dal.bpt.rocks: server not found ianh@vm-ian-laptop:~$ ipa server-del freeipa-dal.bpt.rocks --force --continue Removing freeipa-dal.bpt.rocks from replication topology, please wait... ipa: WARNING: Forcing removal of freeipa-dal.bpt.rocks - Deleted IPA server "" - Failed to remove: freeipa-dal.bpt.rocks ianh@vm-ian-laptop:~$ - Ian -- 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
