Hi Thierry, On 01/23/17 17:45, thierry bordaz wrote: > > > On 01/23/2017 05:09 PM, Harald Dunkel wrote: >> >> I created a full replica (including CA) in an LXC container today >> ("ipabak"). The idea is to take a snapshot of the whole container, >> run ipabak without network connection, and then create and verify >> a shell script to fix the disconnected replica. On problems I can >> roll ipabak back to the snapshot. Maybe it needs some iterations to >> create a working script. > > Do you want to run ipabak against ipa1 or ipa2 server ?
ipabak is a replica of ipa1: # ipa-replica-manage -v list ipabak.vs.example.de Directory Manager password: ipa1.example.de: replica last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2017-01-24 10:13:13+00:00 # ipa-csreplica-manage -v list ipabak.vs.example.de Directory Manager password: ipa1.example.de last init status: None last init ended: 1970-01-01 00:00:00+00:00 last update status: Error (0) Replica acquired successfully: Incremental update succeeded last update ended: 2017-01-24 10:14:01+00:00 ipa1 is the first master. ipabak was setup using # ssh r...@ipa1.example.de ipa-replica-prepare ipabak.vs.example.de # scp -p r...@ipa1.example.de:/var/lib/ipa/replica-info-ipabak.vs.example.de.gpg /var/lib/ipa/ # ipa-replica-install /var/lib/ipa/replica-info-ipabak.vs.example.de.gpg --setup-ca Do you think this is OK? BTW, freeipa doesn't provide DNS in my net. >> >> When the script appears to be fine I can revert the ipabak container >> to the most recent snapshot again, connect it to the network to sync >> it with ipa1 and then run the script with multisite replication >> enabled. >> >> Do you think this could work? > > It should work if you run ipabak against ipa1 or ipa2. But then how to > prevent that ipa1/ipa2 get more conflicts with the iterations of tests ? > ipabak is not supposed to be connected to ipa1 again, if it has been modified by the script in development. It has to be reverted back to the snapshot first. From ipa1's point of view, ipabak just goes offline for some time, but it never comes back modified. The development iterations are not cumulative, except for the script. In each cycle I add code to the script, revert the dis- connected ipabak back to the snapshot, and test the whole script. The snapshot is not overwritten. The snapshot of a LXC container is just an exact copy of its root directory, taken while the container was off. To revert a LXC container back to its snapshot, I have to turn it off, replace its root directory by a copy of the snapshot, and turn it on again. To create a new snapshot I revert ipabak to the current snapshot, connect it to the network, sync it with ipa1, disconnect it and copy the containers root directory to the new snapshot directory. The old snapshot has to be removed then. When the script appears to be ready I have to revert and sync ipabak again as above, but instead of disconnecting it from the network I have to stop all ipa servers in parallel to take a snapshot of each. (All ipa servers are LXC containers.) Next start the ipa servers again and run the script on ipabak, now connected with ipa1. This should make the changes "official". Did I miss something here? 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