On 2017-10-12 11:38:57, Nico Williams wrote:
> On Thu, Oct 12, 2017 at 05:38:32PM +0200, Patrik Lundin wrote:
> > 
> > To summarize this tread: The --reset flag should currently not be used
> > in a production systems since ipropd-master is unable to parse the
> > resulting log file.
> 
> No, the master is perfectly able to to parse the new log.  The issue is
> that it's not enough to ensure that slaves get full props.
> 

A 7.4.0 ipropd-master chokes on the log when it is truncated with
--reset as I showed in my initial message to the list:
http://www.h5l.org/pipermail/heimdal-discuss/2017-October/000277.html:
===
If the slave log has a version number greater than 0 the master will
notice it is out of sync and attempt to update it only to fail in
send_diffs() because kadm5_log_get_version_fd() returns
HEIM_ERR_EOF (and this is documented behaviour for that function when
the log is truncated and LOG_VERSION_FIRST is supplied).
===

> > Since loading a database dump using "kadmin -l load <dumpfile>" does not
> > increment the iprop log version, this means that if you are migrating to
> > a new master which has no log you will need to do something like this:
> 
> kadmin load *does* truncate and reset the log, but it leaves it at
> version 0, which is what i think you meant.
> 

Ah, then it should cause the ipropd-master process to fail to send any
logs afterwards based on the above mentioned failure mode.

> > #1. Stop the current master.
> > #2. Dump the database on the current master.
> > #3. Load the database on the new master.
> > #4. Do some random modification of the database on the new master via
> >     kadmin -l in order to set the log version to at least 2.
> 
> Just version 1 will do, but yes.
> 

No, if you leave it at version 1 the slave will "get in sync with
version 1 by means of replaying log entries" which leaves it with an
empty database:
===
root@kdc-lab-master1:~# iprop-log last-version --no-lock
version: 1
===

===
root@kdc-lab-slave1:~# ls /var/lib/heimdal-kdc/
m-key

root@kdc-lab-slave1:~# /etc/init.d/heimdal-kdc start
Starting heimdal-kdc (via systemctl): heimdal-kdc.service.
===

The slave logs:
===
ipropd-slave[28181]: slave status change: getting credentials from 
keytab/database
ipropd-slave[28181]: slave status change: creating log file
ipropd-slave[28181]: slave status change: ipropd-slave started
ipropd-slave[28185]: slave status change: connecting to master: 
kdc-lab-master1.example.com
ipropd-slave[28185]: connection successful to master: 
kdc-lab-master1.labkrb.it.su.se[192.168.1.100]
ipropd-slave[28185]: ipropd-slave started at version: 0
ipropd-slave[28185]: slave status change: connected to master, waiting 
instructions
ipropd-slave[28185]: slave status change: up-to-date with version: 1 at 
2017-10-16T16:18:44
ipropd-slave[28185]: slave status change: up-to-date with version: 1 at 
2017-10-16T16:18:44
===

===
root@kdc-lab-slave1:~# ls /var/lib/heimdal-kdc/
heimdal.db  ipropd-slave-status  log  m-key

root@kdc-lab-slave1:~# kadmin -l list '*'
root@kdc-lab-slave1:~#
===

Only by going to version 2 and severing the log delta between the master
and the fresh slave version (0) will a complete dump be performed.

-- 
Patrik Lundin

Reply via email to