On 01/24/2017 12:36 PM, Harald Dunkel wrote:
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?
Yes it looks 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.
If I understand correctly the iterations of development I do not
understand why, at this point, you need to reconnect ipabak.
After you create ipabak replica, you take a snapshot of it (let
ipabak_0), then disconnect it from ipa1/ipa2.
Then you may start incremental dev of the script on the offline ipabak.
Before each test of the script, you just need to get ipabak to ipabak_0.
Am I missing something ?
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".
How do you know if the script is ready ? When it resolves all the
conflict entries ?
thanks
thierry
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
