[Freeipa-users] Sync (some) users between IPA servers

[Matt .]

Hi,

I wonder, upfront to the maybe future of IPA trusts, is there a way to
sync some users between some IPA environments ?

I have 3 IPA systems,

- office (All services)
- production (DNS and serverauth only)
- customer auth, ldap only.

Between office and production I would like to have some synced users
so they can login on both environments (servers).

Would there be some way to accomplish this ?

Thanks,

Matt

-- 
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] Backend & UI plugin update for 4.4.x

[Steve Huston]

No, that should be all of the major changes; the puppet module that
installs things only puts the two plugin files in their respective
places.  The client part of the IPA module makes changes to have the
machine join the domain and whatnot, but those shouldn't affect the
webui.

I do modify the schema by adding some attribute types for Puppet,
namely puppetClass, parentNode, environment, puppetVar, and the object
class puppetClient.  That's basically right from one of the Puppet
webpages and also worked in the past - and is one of the things the
python plugin does, add the appropriate objectclass to host entries if
puppetVar is added to a host entry.

My steps to install:
* ipa-server-install --realm= --domain= --mkhomedir
--hostname= --no-host-dns
* ldapmodify -ZZ -h localhost -x -D 'cn=Directory Manager' -W
  < paste puppet schema changes>
  < paste DN entry for uid=hostadder,cn=sysaccounts,cn=etc... - a
service account used by puppet for adding hosts to IPA >
* login to web UI
* * Change home directory base, default shell, default SELinux user
* * Add SELinux user map for staff/sysadmin users
* * Add "user adder" permission/privilege/role for users who will be
able to create stageusers

That's about as far as I got before I realized some of the plugin
pieces weren't working, and then fixed the python plugin followed by
working on the UI plugin and finding this problem.  I'll go wipe and
reinstall the system again and walk through the steps, but test the UI
first and in between to see if I can find which of the steps might be
causing things to hiccup.

On Wed, Jan 25, 2017 at 1:42 PM, Pavel Vomacka  wrote:
> Hello Steve,
>
> I tried to reproduce what you described on the very same version of
> ipa-server and I was not successful. Actually I was not used your back-end
> plugin. I tried it with no plugin and then with your UI plugin and both
> worked correctly. Did you do any other changes somewhere in your
> installation?
>
> I will try it again also with your Python plugin and we'll see.
>
>
> On 01/24/2017 08:59 PM, Steve Huston wrote:
>>
>> And now I'm convinced this has nothing to do with my plugin and
>> instead is a bug somewhere in FreeIPA.
>>
>> I removed the entirety of the "astrocustom" plugin that I wrote,
>> restarted httpd, and force reloaded the page in chrome.  I clicked to
>> add a new user, gave the basic information, and clicked "add and
>> edit".  The bottom of the page shows the "Employee information" on the
>> left side bottom, and the manager drop-down is empty.  I entered '1'
>> in the "employee type" field and clicked save, and now "Employee
>> Information" is on the right side directly under "Contact settings",
>> and the manager drop-down is populated with the list of UIDs on the
>> system.
>>
>> When the UI is in the failed state, the "email address" field is also
>> blank, but when things switch to how they should be (after submitting
>> a change) it is populated with the email address in the record.  I
>> just tested by adding a telephone number to the record, and that also
>> made the contact information and employee information facets refresh
>> with the proper data.  Pressing shift-reload again makes all the
>> information disappear (including the telephone number I just entered).
>>
>> This is with ipa-server-4.4.0-14.el7_3.4
>>
>>
>> On Mon, Jan 23, 2017 at 1:55 PM, Steve Huston
>>  wrote:
>>>
>>> Just tested again, and this is still baffling:
>>>
>>> * Create a stage user with the right data, works fine, can be edited.
>>> * Enable that user, and now the two fields ('manager' and
>>> 'employeeType') appear to have bogus data in the UI, and I cannot save
>>> the page without changing them to something else.
>>> * Once that user is saved, the "Employee Information" facet moves to
>>> the right side of the page, and now shows not only the current data in
>>> the manager drop down but also the other choices (uids).  Change the
>>> value of manager and employeetype back to what they were previously
>>> and it saves.
>>> * An ldapsearch run when the user is first created (as the directory
>>> manager), and after having two edits (one to change the values to
>>> something else to let the webui save them, and one to change them back
>>> to what they should be and were the first time) produce completely
>>> identical results.
>>> * The output of "ipa user-show  --all --raw" is also identical at
>>> those same steps.
>>>
>>> So something, somewhere, is being saved in a way that prevents the
>>> webui from displaying them properly, that gets fixed when those values
>>> are manually changed via the webui.
>>>
>>> On Thu, Jan 19, 2017 at 2:44 PM, Steve Huston
>>>  wrote:

 Even more interesting...

 I tried to modify one of the records that was not displaying properly
 in the "active users" group, and sure enough the webui complained that
 the "Requested By" (relabeled "manager") 

[Freeipa-users] free ipa hangs

[Aaron Collins]

Every day or so one of my masters hangs.  The processes is still running no 
errors in the logs, the tcp port is still listening but it’s not fulling 
requests.  This also hangs any machines querying from the host as the sssd 
timeout doesn’t seem to take affect during the tcp connection.  From looking 
through the archives and troubleshooting docs I’ve taken a stack trace, but I 
can’t make heads or tails of what it means.  I was hoping someone here could 
review it and tell me perhaps where I should be looking.
Stack Trace: 
https://dl.dropboxusercontent.com/u/13113270/stacktrace.1485223167.txt

Using FreeIPA 4.4
[root@ipa-dc1.core2]# rpm -qa |grep ipa-server
ipa-server-4.4.0-14.el7.centos.1.1.x86_64
ipa-server-common-4.4.0-14.el7.centos.1.1.noarch
[root@ipa-dc1.core2]# rpm -qa |grep 389-ds
389-ds-base-snmp-1.3.5.10-12.el7_3.x86_64
389-ds-base-debuginfo-1.3.5.10-12.el7_3.x86_64
389-ds-base-libs-1.3.5.10-12.el7_3.x86_64
389-ds-base-1.3.5.10-12.el7_3.x86_64
[root@ipa-dc1.core2]# uname -a
Linux ipa-dc1.core2.cloud.cheggnet.com 3.10.0-123.8.1.el7.x86_64 #1 SMP Mon Sep 
22 19:06:58 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

In addition I’ve also noticed I have ghost replicas {15,24,13} which I can’t 
seem to remove and a high number of changes not sure if this is normal.

[root@ipa-dc1.core2]#  ldapsearch -xLLL -H 
ldap://localhost  -D "cn=directory manager"  -b dc=randomnet,dc=com  
'(&(nsuniqueid=---)(objectclass=nstombstone))' 
nscpentrywsi
dn: cn=replica,cn=dc\3Drandomnet\2Cdc\3Dcom,cn=mapping tree,cn=config
nscpentrywsi: dn: cn=replica,cn=dc\3Drandomnet\2Cdc\3Dcom,cn=mapping 
tree,cn=config
nscpentrywsi: cn: replica
nscpentrywsi: createTimestamp: 20170113010933Z
nscpentrywsi: creatorsName: cn=Directory Manager
nscpentrywsi: modifiersName: cn=Multimaster Replication 
Plugin,cn=plugins,cn=config
nscpentrywsi: modifyTimestamp: 20170124195814Z
nscpentrywsi: nsDS5Flags: 1
nscpentrywsi: nsDS5ReplicaBindDN: cn=replication manager,cn=config
nscpentrywsi: nsDS5ReplicaBindDN: …
nscpentrywsi: nsDS5ReplicaId: 28
nscpentrywsi: nsDS5ReplicaName: f135c48c-d92c11e6-ba4cb212-9904938c
nscpentrywsi: nsDS5ReplicaRoot: dc=randomnet,dc=com
nscpentrywsi: nsDS5ReplicaType: 3
nscpentrywsi: nsState:: HADLsYdYAAEAuwAKAA
==
nscpentrywsi: nsds5ReplicaLegacyConsumer: off
nscpentrywsi: nsds5replicabinddngroup: cn=replication 
managers,cn=sysaccounts,cn=etc,dc=randomnet,dc=com
nscpentrywsi: nsds5replicabinddngroupcheckinterval: 60
nscpentrywsi: objectClass: nsds5replica
nscpentrywsi: objectClass: top
nscpentrywsi: objectClass: extensibleobject
nscpentrywsi: numSubordinates: 3
nscpentrywsi: nsds50ruv: {replicageneration} 564e51c4
nscpentrywsi: nsds50ruv: {replica 28 
ldap://ipa-dc1.core2.cloud.RANDOMNET.COM:389} 58782993001c 
5887b2780018001c
nscpentrywsi: nsds50ruv: {replica 17 ldap://ipa.RANDOMNET.COM:389} 
57ec1b370011 5887b2c6000c0011
nscpentrywsi: nsds50ruv: {replica 22 
ldap://ipa-dc03.core2.cloud.RANDOMNET.COM:389} 5818c9ac00010016 
58877a2600010016
nscpentrywsi: nsds50ruv: {replica 9 
ldap://ipa-dc2.core2.cloud.RANDOMNET.COM:389} 56c576370009 
58878ffe00060009
nscpentrywsi: nsds50ruv: {replica 27 
ldap://ipa-dc02.corp1.cloud.RANDOMNET.COM:389} 58774771001b 
5877d75c0009001b
nscpentrywsi: nsds50ruv: {replica 29 
ldap://ipa-dc01.test3.cloud.RANDOMNET.COM:389} 5878372a001d 
588795e20001001d
nscpentrywsi: nsds50ruv: {replica 30 
ldap://ipa-dc02.test3.cloud.RANDOMNET.COM:389} 58783e2d001e 
588799c50003001e
nscpentrywsi: nsds50ruv: {replica 15} 5875c4330002000f 587836f20009000f
nscpentrywsi: nsds50ruv: {replica 24} 5877d80800050018 58781d6a00050018
nscpentrywsi: nsds50ruv: {replica 13} 581802c7000d 581802c7000d
nscpentrywsi: nsds5agmtmaxcsn: 
dc=randomnet,dc=com;ipa-dc1.core2.cloud.randomnet.com-to-ipa-dc03.core2.cloud.RANDOMNET.COM;ipa-dc03.core2.cloud.RANDOMNET.COM;389;22;588778510002001c
nscpentrywsi: nsds5agmtmaxcsn: 
dc=randomnet,dc=com;ipa-dc1.core2.cloud.randomnet.com-to-ipa-dc2.core2.cloud.RANDOMNET.COM;ipa-dc2.core2.cloud.RANDOMNET.COM;389;9;588778510002001c
nscpentrywsi: nsds5agmtmaxcsn: 
dc=randomnet,dc=com;ipa-dc1.core2.cloud.randomnet.com-to-ipa.RANDOMNET.COM;ipa.RANDOMNET.COM;389;17;588778510002001c
nscpentrywsi: nsruvReplicaLastModified: {replica 28 
ldap://ipa-dc1.core2.cloud.RANDOMNET.COM:389} 5887b1bc
nscpentrywsi: nsruvReplicaLastModified: {replica 17 
ldap://ipa.RANDOMNET.COM:389} 5887b20d
nscpentrywsi: nsruvReplicaLastModified: {replica 22 
ldap://ipa-dc03.core2.cloud.RANDOMNET.COM:389} 5887796c
nscpentrywsi: nsruvReplicaLastModified: {replica 9 
ldap://ipa-dc2.core2.cloud.RANDOMNET.COM:389} 58878f46
nscpentrywsi: nsruvReplicaLastModified: {replica 27 
ldap://ipa-dc02.corp1.cloud.RANDOMNET.COM:389} 

Re: [Freeipa-users] Backend & UI plugin update for 4.4.x

[Pavel Vomacka]

Hello Steve,

I tried to reproduce what you described on the very same version of 
ipa-server and I was not successful. Actually I was not used your 
back-end plugin. I tried it with no plugin and then with your UI plugin 
and both worked correctly. Did you do any other changes somewhere in 
your installation?


I will try it again also with your Python plugin and we'll see.

On 01/24/2017 08:59 PM, Steve Huston wrote:

And now I'm convinced this has nothing to do with my plugin and
instead is a bug somewhere in FreeIPA.

I removed the entirety of the "astrocustom" plugin that I wrote,
restarted httpd, and force reloaded the page in chrome.  I clicked to
add a new user, gave the basic information, and clicked "add and
edit".  The bottom of the page shows the "Employee information" on the
left side bottom, and the manager drop-down is empty.  I entered '1'
in the "employee type" field and clicked save, and now "Employee
Information" is on the right side directly under "Contact settings",
and the manager drop-down is populated with the list of UIDs on the
system.

When the UI is in the failed state, the "email address" field is also
blank, but when things switch to how they should be (after submitting
a change) it is populated with the email address in the record.  I
just tested by adding a telephone number to the record, and that also
made the contact information and employee information facets refresh
with the proper data.  Pressing shift-reload again makes all the
information disappear (including the telephone number I just entered).

This is with ipa-server-4.4.0-14.el7_3.4


On Mon, Jan 23, 2017 at 1:55 PM, Steve Huston
 wrote:

Just tested again, and this is still baffling:

* Create a stage user with the right data, works fine, can be edited.
* Enable that user, and now the two fields ('manager' and
'employeeType') appear to have bogus data in the UI, and I cannot save
the page without changing them to something else.
* Once that user is saved, the "Employee Information" facet moves to
the right side of the page, and now shows not only the current data in
the manager drop down but also the other choices (uids).  Change the
value of manager and employeetype back to what they were previously
and it saves.
* An ldapsearch run when the user is first created (as the directory
manager), and after having two edits (one to change the values to
something else to let the webui save them, and one to change them back
to what they should be and were the first time) produce completely
identical results.
* The output of "ipa user-show  --all --raw" is also identical at
those same steps.

So something, somewhere, is being saved in a way that prevents the
webui from displaying them properly, that gets fixed when those values
are manually changed via the webui.

On Thu, Jan 19, 2017 at 2:44 PM, Steve Huston
 wrote:

Even more interesting...

I tried to modify one of the records that was not displaying properly
in the "active users" group, and sure enough the webui complained that
the "Requested By" (relabeled "manager") field was not filled in since
it was blank.  It also, however, complained that the "User tier"
(relabeled "employeetype") was incorrect, even though it showed the
label associated with the value 1.  I clicked the search drop-down for
manager, typed in my own uid, and even though everything had been
blank in the drop down before now my uid showed up.  I clicked on it,
and my uid was now in the manager field.  I then clicked the drop down
for employeetype, and chose one of the other options.  I was now able
to save the changes to the record.

Upon reloading the page, the "Employee Information" facet now shoed up
on the right side bottom, instead of the left side bottom where it was
appearing.  I was also now able to change the drop-down fields for
manager and employeetype to another value, and save them, and they
worked fine even filling in all the data that should have been there.
This almost seemed like the data being returned by the server was
flawed somehow, and confusing the webui, but once it was forced to
have the right data and re-saved it worked fine subsequently.

I looked at the output of "ipa user-show  --all --raw" both
before and after making such changes on a user, and can detect no
difference between them.

On Thu, Jan 19, 2017 at 1:14 PM, Alexander Bokovoy  wrote:

On to, 19 tammi 2017, Steve Huston wrote:

On Thu, Jan 19, 2017 at 11:16 AM, Alexander Bokovoy 
wrote:

In short, FreeIPA 4.2 -> 4.4 change was by splitting server and client
side plugins into different paths (ipaserver/plugins and
ipaclient/plugins instead of being common in ipalib/plugins). The client
code was also changed to always read metadata about API from the server
side. This means the client can adopt to any server version that
supports API metadata.


Right, and I think that the most of the plugin I had belongs

Re: [Freeipa-users] Keycloak + FreeIPA New password expiry

[Georgijs Radovs]

Thank you very much, Brian!





Georgijs Radovs
Junior Sysadmin


On Wed, Jan 25, 2017 at 7:13 PM, Brian Candler  wrote:

> On 25/01/2017 13:48, Georgijs Radovs wrote:
>
> Is it possible to configure FreeIPA server so it does not mark new
> passwords, set by Keycloak's LDAP bind user, expired?
>
> Yes, you need to configure the privileged LDAP bind user in
> passSyncManagersDNs:
>
> dn: cn=ipa_pwd_extop,cn=plugins,cn=config
> passSyncManagersDNs: uid=
>
> Note that this setting does not replicate - it needs to be applied to all
> replicas by hand.
>
> See:
> https://access.redhat.com/documentation/en-US/Red_Hat_
> Enterprise_Linux/7/html/Windows_Integration_Guide/
> pass-sync.html#password-sync
>

-- 
 
-- 
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] Keycloak + FreeIPA New password expiry

[Brian Candler]

On 25/01/2017 13:48, Georgijs Radovs wrote:
Is it possible to configure FreeIPA server so it does not mark new 
passwords, set by Keycloak's LDAP bind user, expired?


Yes, you need to configure the privileged LDAP bind user in 
passSyncManagersDNs:


dn: cn=ipa_pwd_extop,cn=plugins,cn=config
passSyncManagersDNs: uid=

Note that this setting does not replicate - it needs to be applied to 
all replicas by hand.


See:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/pass-sync.html#password-sync
-- 
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] Reinstalling IPA-Server

[Matthew Carter]

As I was configuring my network with a government STIG package, I ended 
up hosing up the network by following the STIGs directions and not 
thinking it through. Currently users can log in, but NFS mounts won't 
happen with krb5i encryption as they are being denied by the server who 
is my NFS host. I really like things nice and neat, so after fumbling 
around in my inexperienced haze, I feel now is the time to reload. I 
would like to keep my users home dirs intact, as I sure they would as well.



I'm assuming that the process is as follows and would like any pointers 
or tips from those in the know.



1. remove clients from Domain using ipa-client-automount --uninstall and 
then ipa-client-install --uninstall.


2. On the server, ipa-client-automount --uninstall and then yum remove ipa-*


Are there anything else that should be completed before a reinstallation?


I'm guessing I'll have to set up users again, but the data they have on 
the clients should be fine if I keep the same usernames, right?


Is there anyway of keeping the users passwords from the old installation 
and moving them to the new? I'm trying to avoid as much grumbling as 
possible.



Thanks!


Matt

--
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] Error: CA certificate is not tracked by certmonger

[Jeff Goddard]

I've accidentally removed tracking of my CA certificate and don't know how
to re-add it. Can someone assist? Using the command:pki ca-cert-find
results in the error:PKIException: Not Found


Thanks,

Jeff


--
-- 
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] How to clean out(reset) FreeIPA,

[Martin Basti]

On 24.01.2017 11:54, Tony Brian Albers wrote:

Hi guys,

Is there a way to expunge everything except admin account from IPA?

We have a supercomputer test installation here that needs it, and a
reset is preferable over a complete reinstall.

TIA

Tony


You can try ipa-backup and ipa-restore, ipa-backup with only admin and 
call IPA restore only as a cleanup


I'm not sure but ipa-backup --data should be enough, if you don't need 
to restore services just content of LDAP DB


Martin

--
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] How to clean out(reset) FreeIPA,

[Tony Brian Albers]

Hi guys,

Is there a way to expunge everything except admin account from IPA?

We have a supercomputer test installation here that needs it, and a 
reset is preferable over a complete reinstall.

TIA

Tony
-- 
Best regards,

Tony Albers
Systems administrator, IT-development
Royal Danish Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark.
Tel: +45 2566 2383 / +45 8946 2316

-- 
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 CA issues

[Gendy Tartovsky]

 Hi,

I'm having a PKI-tomcat issue that started after upgrade.
My configuration has 4 servers with CA, where servers 2, 3 and 4 are
replicated from the first one.
At first it didn't cause much trouble since all the issue came down to
pki-tomcat getting to start about 2 minutes.
But it seems that problem is progressed a lot and is causing issues in
multiple parts of the system.

After upgrading FreeIPA from 4.1 to 4.2  ipactl would not on the first node
start without the --ignore-service-failures.

 I found that in the menu Authentication-->Certificates
 I have multiple certificates for same hosts in some cases there were up to
30 duplicates per host and it is unclear what is generating them.

Next issue is that if I try to add a new replica with ipa-replica-prepare
utility
I get an error: "Failed to generate certificate"

And the last problem I found is that I am unable to restore a backup.
The ipa-restore utility is able to unpack the backup but once I try to
start FreeIPA on a new node
the pki-tomcat fails to start. And I see this message in debug:

ipa: DEBUG: Waiting for CA to start...
ipa: DEBUG: Starting external process
ipa: DEBUG: args='/usr/bin/wget' '-S' '-O' '-' '--timeout=30'
'--no-check-certificate' 'https://:8443/ca/admin/ca/getStatus'
ipa: DEBUG: Process finished, return code=8


In the /var/log/dirsrv/slapd-XXX/errors I see a lot of these
 NSMMReplicationPlugin - process_postop: Failed to apply update
(57c3cc550002000d) error (-1).  Aborting replication
session(conn=272420 op=6)

 but I'm not sure if it is directly related to the problem.

 In /var/log/pki/pki-tomcat/ca/debug I see a lot of these messages:
Can't create master connection in LdapBoundConnFactory::getConn! Could not
connect to LDAP server host bos-admin1.hq.datarobot.com port 636 Error
netscape.ldap.LDAPException: IO Error creating JSS SSL Socket

My guess was that the CA certificate got expired, so I tried to run
'ipa-cacert-manage renew'
but it failed with this message:

Resubmitting certmonger request '20151222031110' timed out, please check
the request manually


Don't really know what else to try right now.
-- 
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] Keycloak + FreeIPA New password expiry

[Georgijs Radovs]

Hello everyone!

Is it possible to configure FreeIPA server so it does not mark new 
passwords, set by Keycloak's LDAP bind user, expired?


Basically, so the user accounts synced from FreeIPA to Keycloak, could 
reset their passwords from Keycloak.


Here is my current setup:

FreeIPA server 4.4 as LDAP identity store

Keycloak server 2.1.0 as SAML identity provider

Keycloak has "User Federation" set up to sync user accounts from FreeIPA 
server.


Everything is working well, except for password reset.

For example, when a user account synced from FreeIPA, logs in to 
Keycloak server and resets his password at Keycloak server's user 
account portal, Keycloak bind user resets FreeIPA user account's 
password, but, as the password is set by bind user and not FreeIPA user, 
the password is set to be expired.


So, for password to be valid, FreeIPA user should go to FreeIPA server 
and reset his password once more.


Can you, please, suggest how to resolve this issue?


--


--
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] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]

[Ludwig]

On 01/25/2017 12:44 PM, Harald Dunkel wrote:

Hi Thierry,

On 01/24/17 17:56, thierry bordaz wrote:


On 01/24/2017 04:18 PM, Harald Dunkel wrote:

Would you suggest to disconnect ipabak from the network and ipa1,
cleanup the mess as far as possible, and then connect ipabak
to the network again to rely upon the regular replica synchroni-
zation?

Yes, as soon as ipaback is in sync with ipa1 and you took a snapshot of 
ipaback, I think you can disconnect ipaback and run your script on it 
(iterating with the snapshot).


My concern is that I will run into new conflicts on connecting
the modified ipaback back with ipa1?
conflict entries are only created if you do the same operation in 
parallel on different replicas. Once existing they behave like normal 
entries (only with special dns), eg if you delete it on one replica the 
delete will be replicated to the other replicas - either immediately if 
they are connected or later when they will be connected again.


I think what Thierry is suggesting is, that if you make mistakes in your 
cleanup these mistakes would also be replicated immediately if every 
replcia is connected, so disconnecting allows you to do a backup and 
then try the cleanup and when successful connect agai and have the 
cleanup operations replicated.



Regards
Harri



--
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] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]

[Harald Dunkel]

Hi Thierry,

On 01/24/17 17:56, thierry bordaz wrote:
> 
> 
> On 01/24/2017 04:18 PM, Harald Dunkel wrote:
>>
>> Would you suggest to disconnect ipabak from the network and ipa1,
>> cleanup the mess as far as possible, and then connect ipabak
>> to the network again to rely upon the regular replica synchroni-
>> zation?
> 
> Yes, as soon as ipaback is in sync with ipa1 and you took a snapshot of 
> ipaback, I think you can disconnect ipaback and run your script on it 
> (iterating with the snapshot).
> 

My concern is that I will run into new conflicts on connecting
the modified ipaback back with ipa1?


Regards
Harri

-- 
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