[Freeipa-users] be_pam_handler_callback Backend returned: (3, 4, <NULL>) [Internal Error (System error)]

[Harald Dunkel]

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 root at ipa1.example.de ipa-replica-prepare ipabak.vs.example.de
# scp -p root at 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