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
