Problems with kprop and incremental propagation
Matej Zagiba
I have two problems with kprop/kpropd. At out site we are using (tying to use) two KDCs both version are 1.8.3 (1.8.3-dfsg-2 from debian repositories). One of them is production server with over 85k proncipals, second shoud be slave server.
I followed install manualhttp://web.mit.edu/kerberos/krb5-1.8/krb5-1.8.3/doc/krb5-install.html#Install%20the%20Slave%20KDCs.
Exact configuration details areat the end of post.
First problem with kprop is, it=s not recognize defaut realm:
root@kdc1:~# /usr/sbin/kprop -f /var/lib/krb5kdc/slave_datatrans kdc2.my.domain
/usr/sbin/kprop: Cannot resolve network address for KDC in requested realm while getting initial ticket
if I force realm with -r option, everything goes as expected:
root@kdc1:~# time /usr/sbin/kdb5_util dump /var/lib/krb5kdc/slave_datatrans
real 0m11.119s
user 0m10.685s
sys 0m0.404s
root@kdc1:~# /usr/sbin/kprop.orig -r KRB.MY.DOMAIN -f /var/lib/krb5kdc/slave_datatrans kdc2.my.domain
Database propagation to kdc2.my.domain: SUCCEEDED
While in usual cron synchronization it is not a big deal, in incremental propagation it means that full resync never
succeed. I wrote a little wrapper aroun kprobe, so full resync now works, but I wonder, if there is anything wrong in my configuration, or if it is bug.
Second problem is that kpropd allways asks for full resync. In kadmin logs it looks like this:
=== start of kpropd on slave ===
Nov 10 10:43:34 kdc1 kadmind[9394](Notice): Request: iprop_get_updates_1, UPDATE_BUSY; Incoming SerialNo=0; Outgoing SerialNo=N/A, success, client=kiprop/kdc2.my...@KRB.MY.DOMAIN,service=kiprop/kdc1.my...@KRB.MY.DOMAIN, addr=kdc2_ip
Nov 10 10:43:38 kdc1 kadmind[9394](Notice): Request: iprop_get_updates_1, UPDATE_BUSY; Incoming SerialNo=0; Outgoing SerialNo=N/A, success, client=kiprop/kdc2.my...@KRB.MY.DOMAIN,service=kiprop/kdc1.my...@KRB.MY.DOMAIN, addr=kdc2_ip
Nov 10 10:43:46 kdc1 kadmind[9394](Notice): Request: iprop_get_updates_1, UPDATE_FULL_RESYNC_NEEDED; Incoming SerialNo=0; Outgoing SerialNo=N/A, success, client=kiprop/kdc2.my...@KRB.MY.DOMAIN,service=kiprop/kdc1.my...@KRB.MY.DOMAIN, addr=kdc2_ip
Nov 10 10:43:46 kdc1 kadmind[9394](Notice): Request: iprop_full_resync_1, spawned resync process 14944, client=kiprop/kdc2.my...@KRB.MY.DOMAIN, service=kiprop/kdc1.my...@KRB.MY.DOMAIN, addr=kdc2_ip
Nov 10 10:44:51 kdc1 kadmind[9394](Notice): Request: iprop_get_updates_1, UPDATE_NIL; Incoming SerialNo=208; Outgoing SerialNo=N/A, success, client=kiprop/kdc2.my...@KRB.MY.DOMAIN,service=kiprop/kdc1.my...@KRB.MY.DOMAIN, addr=kdc2_ip
Nov 10 10:45:21 kdc1 kadmind[9394](Notice): Request: iprop_get_updates_1, UPDATE_OK; Incoming SerialNo=208; Outgoing SerialNo=209, success, client=kiprop/kdc2.my...@KRB.MY.DOMAIN,service=kiprop/kdc1.my...@KRB.MY.DOMAIN, addr=kdc2_ip
Nov 10 10:45:51 kdc1 kadmind[9394](Notice): Request: iprop_get_updates_1, UPDATE_FULL_RESYNC_NEEDED; Incoming SerialNo=0; Outgoing SerialNo=N/A, success, client=kiprop/kdc2.my...@KRB.MY.DOMAIN,service=kiprop/kdc1.my...@KRB.MY.DOMAIN, addr=kdc2_ip
Nov 10 10:45:51 kdc1 kadmind[9394](Notice): Request: iprop_full_resync_1, spawned resync process 14968, client=kiprop/kdc2.my...@KRB.MY.DOMAIN, service=kiprop/kdc1.my...@KRB.MY.DOMAIN, addr=kdc2_ip
Nov 10 10:46:57 kdc1 kadmind[9394](Notice): Request: iprop_get_updates_1, UPDATE_NIL; Incoming SerialNo=210; Outgoing SerialNo=N/A, success, client=kiprop/kdc2.my...@KRB.MY.DOMAIN,service=kiprop/kdc1.my...@KRB.MY.DOMAIN, addr=kdc2_ip
Nov 10 10:47:27 kdc1 kadmind[9394](Notice): Request: iprop_get_updates_1, UPDATE_NIL; Incoming SerialNo=210; Outgoing SerialNo=N/A, success, client=kiprop/kdc2.my...@KRB.MY.DOMAIN,service=kiprop/kdc1.my...@KRB.MY.DOMAIN, addr=kdc2_ip
Nov 10 10:47:57 kdc1 kadmind[9394](Notice): Request: iprop_get_updates_1, UPDATE_NIL; Incoming SerialNo=210; Outgoing SerialNo=N/A, success, client=kiprop/kdc2.my...@KRB.MY.DOMAIN,service=kiprop/kdc1.my...@KRB.MY.DOMAIN, addr=kdc2_ip
Nov 10 10:48:27 kdc1 kadmind[9394](Notice): Request: iprop_get_updates_1, UPDATE_NIL; Incoming SerialNo=210; Outgoing SerialNo=N/A, success, client=kiprop/kdc2.my...@KRB.MY.DOMAIN,service=kiprop/kdc1.my...@KRB.MY.DOMAIN, addr=kdc2_ip
Nov 10 10:48:57 kdc1 kadmind[9394](Notice): Request: iprop_get_updates_1, UPDATE_BUSY; Incoming SerialNo=210; Outgoing SerialNo=N/A, success, client=kiprop/kdc2.my...@KRB.MY.DOMAIN,service=kiprop/kdc1.my...@KRB.MY.DOMAIN, addr=kdc2_ip
Nov 10 10:49:01 kdc1 kadmind[9394](Notice): Request: iprop_get_updates_1, UPDATE_BUSY; Incoming SerialNo=210; Outgoing SerialNo=N/A, success, client=kiprop/kdc2.my...@KRB.MY.DOMAIN,service=kiprop/kdc1.my...@KRB.MY.DOMAIN, addr=kdc2_ip
Nov 10 10:49:09 kdc1 kadmind[9394](Notice): Request: iprop_get_updates_1, UPDATE_OK; Incoming SerialNo=210; Outgoing SerialNo=212, success, client=kiprop/kdc2.my...@KRB.MY.DOMAIN,service=kiprop/kdc1.my...@KRB.MY.DOMAIN, addr=kdc2_ip
Nov 10 10:49:39 kdc1 kadmind[9394](Notice): Request: iprop_get_updates_1, UPDATE_FULL_RESYNC_NEEDED; Incoming SerialNo=0; Outgoing SerialNo=N/A, success, client=kiprop/kdc2.my...@KRB.MY.DOMAIN,service=kiprop/kdc1.my...@KRB.MY.DOMAIN, addr=kdc2_ip
Nov 10 10:49:39 kdc1 kadmind[9394](Notice): Request: iprop_full_resync_1, spawned resync process 15002, client=kiprop/kdc2.my...@KRB.MY.DOMAIN, service=kiprop/kdc1.my...@KRB.MY.DOMAIN, addr=kdc2_ip
Nov 10 10:50:45 kdc1 kadmind[9394](Notice): Request: iprop_get_updates_1, UPDATE_OK; Incoming SerialNo=213; Outgoing SerialNo=214, success, client=kiprop/kdc2.my...@KRB.MY.DOMAIN,service=kiprop/kdc1.my...@KRB.MY.DOMAIN, addr=kdc2_ip
Please help me solve this problem, because this way incrementall propagation has no meaning, and conventional use of kprop take too long.
thanks
Matej Zagiba
configuration:
/etc/krb5.conf (both master and slave):
[libdefaults]
default_realm = KRB.MY.DOMAIN
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
[realms]
KRB.MY.DOMAIN = {
kdc = kdc1.my.domain
kdc = kdc2.my.domain
admin_server = kdc1.my.domain
iprop_enable = true
iprop_master_ulogsize = 2048
iprop_slave_poll = 30
iprop_port = 755
}
[domain_realm]
.my.domain. = KRB.MY.DOMAIN
my.domain. = KRB.MY.DOMAIN
[logging]
kdc = FILE:/var/log/kdc5.log
admin_server = FILE:/var/log/kadm5.log
default = FILE:/var/log/krb5.log
Matej Zagiba
according to strace kprop is reading /etc/krb5.conf
setting default_realm as global parameter did not help.
The other two settings (iprop_master_ulogsize = 2048, iprop_slave_poll = 30) shoud not have negative impact,
according to documentation, default values are 1500 entries in log and 2 minutes poll intervall.
I commented out those settings, restarted but no change. kproplog on master returns cca 550 entries,
starting from 1, so it not the problem of too short logfile. What isstrange is this log sequence:
Nov 10 10:49:09 kdc1 kadmind[9394](Notice): Request: iprop_get_updates_1, UPDATE_OK; Incoming SerialNo=210; Outgoing SerialNo=212, success, client=kiprop/kdc2.my...@KRB.MY.DOMAIN,service=kiprop/kdc1.my...@KRB.MY.DOMAIN, addr=kdc2_ip
Nov 10 10:49:39 kdc1 kadmind[9394](Notice): Request: iprop_get_updates_1, UPDATE_FULL_RESYNC_NEEDED; Incoming SerialNo=0; Outgoing SerialNo=N/A, success, client=kiprop/kdc2.my...@KRB.MY.DOMAIN,service=kiprop/kdc1.my...@KRB.MY.DOMAIN, addr=kdc2_ip
Nov 10 10:49:39 kdc1 kadmind[9394](Notice): Request: iprop_full_resync_1, spawned resync process 15002, client=kiprop/kdc2.my...@KRB.MY.DOMAIN, service=kiprop/kdc1.my...@KRB.MY.DOMAIN, addr=kdc2_ip
Nov 10 10:50:45 kdc1 kadmind[9394](Notice): Request: iprop_get_updates_1, UPDATE_OK; Incoming SerialNo=213; Outgoing SerialNo=214, success, client=kiprop/kdc2.my...@KRB.MY.DOMAIN,service=kiprop/kdc1.my...@KRB.MY.DOMAIN, addr=kdc2_ip
In master's kadmin logs, there are UPDATE_OK entries folowed by full_resync. After full_resync, slave's kproplog lookslike this:
root@kdc2:~# kproplog
Kerberos update log (/var/lib/krb5kdc/principal.ulog)
Update log dump :
Log version # : 1
Log state : Stable
Entry block size : 2048
Number of entries : 0
First serial # : None
Last serial # : 548
First time stamp : None
Last time stamp : Thu Nov 11 01:00:40 2010
But after UPDATE_OK event,it change to this:
root@kdc2:~# kproplog
Kerberos update log (/var/lib/krb5kdc/principal.ulog)
Update log dump :
Log version # : 1
Log state : Stable
Entry block size : 2048
Number of entries : 0
Last serial # : None
Last time stamp : None
So it's no wonder, next try triggers full resync.
Any ideas?
Matej
On 11/10/2010 11:48 PM, Jeremy Hunt wrote:
> Hi Matej,
>
> Try setting default_realm = KRB.MY.DOMAIN as a global parameter at the top of your krb5.conf file. That should fix problem one.
>
> Secondly, you only need iprop_enable and iprop_port to get the incremental propagation going.
>
> Your other two settings are nice to have tuning parameters. Until you get incremental proagation working you don't really know what they should be set to. I am guessing they are set too low and the propagation mechanism is spinning out trying to catch up.
>
> How incremental propagation works is that it compares the log files on all servers and propagates updates as it can while it can keep the two logs in a synchronised state. You appear to have your log size set too low and so I suspect you are truncating your driver file which sets the flag for full propagation. I am surprised you say that full propagation takes too long, but if so then it probably attempts a full propagation while it is busy. Because it is busy it fails the full propagation and throws away the replica's updates. Then it tries again next cycle. I bet it can do a full propagation in a quiet period.
>
> All of my iprop settings are in my kdc.conf file, but obviously your incremental propagation is attempting to work, so I learned something.
>
> Apart from that your configuration appears okay.
>
> After changing your configuration files, restart all you kerberos daemons.
>
> If kprop is still not picking up your domain, run strace or truss on it and see if it is reading the correct file.
>
> I hope that helps,
>
> Jeremy
>
> On 10/11/2010 9:04 PM, Matej Zagiba wrote:
>> [safeTgram (safetgram-in) receive status: NOT encrypted, NOT signed.]
>> ________________________________________________
>> Kerberos mailing list Kerb...@mit.edu
>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>
>
>
> --
>
> "The whole modern world has divided itself into Conservatives and Progressives. The business of Progressives is to go on making mistakes. The business of the Conservatives is to prevent the mistakes from being corrected." -- G. K. Chesterton
>
Jeremy Hunt
Jeremy Hunt
Hi Matej,
Hmm!
Try explicitly setting:
kdc1.my.domain = MY.DOMAIN
kdc2.my.domain = MY.DOMAIN
in the domain_realms section to fix the domain issue.
On the other issue, you did restart the daemons on both kdc systems after changing the config didn't you? And you did change the config on both servers didn't you?
The kproplog output is misleading after a full resync, I think that is a red herring. After it's first successful incremental update it reports the last matching log stamp. You want to get at least one incremental update to see that, because then you see both sides reporting the same or differing time stamps.
I don't see why you think the log entries are strange, what do you see that you think merits consideration? Don't worry, you might be seeing something that I am not, just tell me what you think is strange. If you point it out I may agree, but at the moment it looks fine to me.
When you have quiet periods does incremental propagation work? It should, and if it doesn't, then it is possible there are issues other than configuration issues. In a quiet period try getting a tcpdump of the traffic on both servers, make sure that there are not network or firewall issues blocking the dialogs.
Is it true that you now have the the poll interval as 2 minutes and you have 550 entries in the logs? How long does a full resync take?
You don't have kprop running as a process or out of inetd.conf on the root server (master) do you?
Regards,
Jeremy
On 11/11/2010 11:33 AM, Matej Zagiba wrote:
> [safeTgram (safetgram-in) receive status: NOT encrypted, NOT signed.]
>
>
> Thanks for reply,
>
> according to strace kprop is reading /etc/krb5.conf
> setting default_realm as global parameter did not help.
>
> The other two settings (iprop_master_ulogsize = 2048, iprop_slave_poll = 30) shoud not have negative impact,
> according to documentation, default values are 1500 entries in log and 2 minutes poll intervall.
>
> I commented out those settings, restarted but no change. kproplog on master returns cca 550 entries,
> starting from 1, so it not the problem of too short logfile. What isstrange is this log sequence:
>
> Nov 10 10:49:09 kdc1 kadmind[9394](Notice): Request: iprop_get_updates_1, UPDATE_OK; Incoming SerialNo=210; Outgoing SerialNo=212, success, client=kiprop/kdc2.my...@KRB.MY.DOMAIN,service=kiprop/kdc1.my...@KRB.MY.DOMAIN, addr=kdc2_ip
> Nov 10 10:49:39 kdc1 kadmind[9394](Notice): Request: iprop_get_updates_1, UPDATE_FULL_RESYNC_NEEDED; Incoming SerialNo=0; Outgoing SerialNo=N/A, success, client=kiprop/kdc2.my...@KRB.MY.DOMAIN,service=kiprop/kdc1.my...@KRB.MY.DOMAIN, addr=kdc2_ip
> Nov 10 10:49:39 kdc1 kadmind[9394](Notice): Request: iprop_full_resync_1, spawned resync process 15002, client=kiprop/kdc2.my...@KRB.MY.DOMAIN, service=kiprop/kdc1.my...@KRB.MY.DOMAIN, addr=kdc2_ip
> Nov 10 10:50:45 kdc1 kadmind[9394](Notice): Request: iprop_get_updates_1, UPDATE_OK; Incoming SerialNo=213; Outgoing SerialNo=214, success, client=kiprop/kdc2.my...@KRB.MY.DOMAIN,service=kiprop/kdc1.my...@KRB.MY.DOMAIN, addr=kdc2_ip
>
Matej Zagiba
thanx for shoving me right direction.
First problem was solved by removing last dot in lines
my.domain. = KRB.MY.REALM
.my.domain. = KRB.MY.REALM
in [domain_realm] section. It's strange, I clearly remember to read some advise to put the final dot there.
Second problem is some kind of bug, I run
strace kpropd -S -d
when I expected inckemental propagation to happen, and at the end of output, I saw this:
open("/etc/krb5kdc/principal", O_RDONLY) = -1 ENOENT (No such file or directory)
Well, that's definetly strange, because in /etc/krb5conf/kdc.conf contains this:
[kdcdefaults]
kdc_ports = 88,750
kdc_tcp_ports = 88,750
[realms]
KRB.MY.REALM = {
database_name = /var/lib/krb5kdc/principal
admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
acl_file = /etc/krb5kdc/kadm5.acl
key_stash_file = /etc/krb5kdc/stash
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = des3-hmac-sha1
supported_enctypes = des3-hmac-sha1:normal arcfour-hmac:normal des-cbc-crc:normal aes256-cts:normal aes128-cts:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3
default_principal_flags = +preauth
}
From strace I can see, that kpropd is looking at correct file - /var/lib/krb5kdc/principal.ulog when it checks for serial:
stat("/var/lib/krb5kdc/principal.ulog", {st_mode=S_IFREG|0600, st_size=40, ...}) = 0
open("/var/lib/krb5kdc/principal.ulog", O_RDWR) = 3
when it comes to applying changes, it uses /etc/krb5kdc/principal. It fails, and kdb5_util invoked for full resync uses correct database.
My workaround for now is to make symlinks of database files (principal, principal.ok, principal.kadm5.lock) to /etc/krb5kdc
With this, it works, but I wonder, if it's just my misconfiguration, or kprop/kpropd have serious bug using standard kerberos configuration files.
Matej
Jeremy Hunt
Aaah! Final dot in domainname is "nisplus"ese. I have been supporting nisplus for too long, I missed that. Perhaps you have too. My config has the client machines explicitly named, but in my environment with static machines I can do that, I presume yours has many machines dropping in and out.
Older versions of kerberos had database_name in a specific subsection for the kdc name in the realms section. So you should have it in the kdc1.my.domain and kdc2.my.domain subsections of the realms section, not the KRB.MY.REALM subsection. Alternatively you can define it in the KRB.MY.REALM subsection of the realms section of your kdc.conf file. In the latter case the location of the kdc.conf file is defined in the kdc section of your krb5.conf file.
What you are seeing is a default location set up in your kerberos build. That can be changed too if you want to rebuild kerberos.
But you seem to have solved your problems, document your findings for your successors, ... or you in a couple of years time :).
Regards,
Jeremy
Greg Hudson
1. kprop uses krb5_sname_to_principal() to determine its client
principal, and does not understand the referral realm. So it does not
work without a -r parameter unless the profile's domain_realm section
can map the local hostname. You worked around this by correcting your
existing domain_realm section in your profile.
A reasonable, if not perfect, fix here is to do what kpropd does in a
similiar piece of code: substitute the default realm for the referral
realm when using the result of krb5_sname_to_principal() as a client
principal.
2. kpropd, when processing incremental updates, modifies the KDB using
ulog_replay(), but does not initialize its context to use the KDC
profile, so it uses only settings from krb5.conf to find the KDB. You
worked around this with symlinks. An alternative workaround would be to
put the KDB configuration into krb5.conf instead of kdc.conf. (In the
past, it used to be required to put KDB configuration into krb5.conf.
That odd requirement was relaxed somewhere around krb5 1.5 for most
programs which run on the KDC, but a few have escaped the net, including
kpropd.)
I will open issues for both bugs and try to get them fixed for 1.9.
Thanks for your investigative work.
Matej Zagiba
thank You for help, I was reading the source code, but I got lost :-)
Anyway, I noticed kpropd has an -F switch to specify path to database, but it's used only in
full replication when passing arguments to kbd_util. It would be nice to use this argument
to override config files in incremental propagation as well.
I suppose not too many people uses incremental propagation, it relatively new feature,
but I must say after getting it work, it's perfect solution.
thanx for all the help
Matej Zagiba
Jeremy Hunt
I don't know that your conclusions are necessarily true. I would say the only bug is that the location of the principal database (and therefore the location of kdc.conf) is not settable in krb5.conf. My point is that if you can override the kdc location in krb5.conf then you can put the correct subsection in the realms section of the kdc.conf and everything will work. Of course, if Matej had been able to set the location of his principal database in the krb5.conf file, then everything would work as he defined it from that file without reference to a kdc.conf file.
I administer a more static domain than Matej, but I suspect that is irrelevant. I built my version of kerberos to use /krb5 as the containing directory for everything and configured incremental propagation entirely in kdc.conf. I needed none of the workarounds Matej did, my incremental propagation works seamlessly.
To put this in perspective my realm is used correctly and so is Matej's now he has correctly defined his domain in the domain_realm section of krb5.conf. The location of my principal database is /krb5/var/krb5kdc, this is not a typical location.
I put the directives as defined in the documentation in the subsection for my domain in the realms section of the kdc.conf file, and put the kdc.conf file in the same directory as the principal database. I built my kerberos by configuring with " --prefix=/krb5 --exec-prefix=/krb5" which set @LOCALSTATEDIR+/krb5/var in the Makefile, this defines the location of my principal database as /krb5/var/krb5kdc.
For what it is worth here is a sanitised version of my configuration, which works as advertised with no principal pathnames defined:
/krb5/etc/krb5.conf
--------------------------
[libdefaults]
# irrelevant, except possibly this
default_realm = MYREALM.COM
[appdefaults]
# irrelevant
[realms]
# only relevant in it defines where propagation is from and to
MYREALM.COM = {
kdc = kdc1
kdc = kdc2
admin_server = kdc1
# I am not advertising my password port here
kpasswd_server = kdc1:myPasswdPort
}
[domain_realm]
# The lines for my kdc systems probably set the realm correctly. this is satisfactory if you can do it this way.
# Matej's setting is more general, more elegant and entirely satisfactory,
# remember his settings were initially wrong and this was one of the causes of his problems
kdc1 = MYREALM.COM
kdc2 = MYREALM.COM
sys1 = MYREALM.COM
sys2 = MYREALM.COM
sys3 = MYREALM.COM
# etcetera
[logging]
# irrelevant
/krb5/var/krb5kdc/kdc.conf
-------------------------------------
[kdcdefaults]
# irrelevant
[realms]
MYREALM.COM= {
# Left out irrelevant stuff in this email like principal flags and enctypes, ports, files used, etcetera
# From my build, the location of kdc.conf is known
# The realm is referred to in this subsection.
# Incremental propagation is defined in the simplest way
# the principal database is found and the correct realm is used
iprop_enable = true
iprop_port = 2107
}
[logging]
# irrelevant
On 16/11/2010 11:14 AM, Greg Hudson wrote:
> [safeTgram (safetgram-in) receive status: NOT encrypted, NOT signed.]
>
>
> I can confirm two bugs that you have encountered and worked around:
>
> 1. kprop uses krb5_sname_to_principal() to determine its client
> principal, and does not understand the referral realm. So it does not
> work without a -r parameter unless the profile's domain_realm section
> can map the local hostname. You worked around this by correcting your
> existing domain_realm section in your profile.
> A reasonable, if not perfect, fix here is to do what kpropd does in a
> similiar piece of code: substitute the default realm for the referral
> realm when using the result of krb5_sname_to_principal() as a client
> principal.
>
> 2. kpropd, when processing incremental updates, modifies the KDB using
> ulog_replay(), but does not initialize its context to use the KDC
> profile, so it uses only settings from krb5.conf to find the KDB. You
> worked around this with symlinks. An alternative workaround would be to
> put the KDB configuration into krb5.conf instead of kdc.conf. (In the
> past, it used to be required to put KDB configuration into krb5.conf.
> That odd requirement was relaxed somewhere around krb5 1.5 for most
> programs which run on the KDC, but a few have escaped the net, including
> kpropd.)
>
> I will open issues for both bugs and try to get them fixed for 1.9.
> Thanks for your investigative work.
>
>
Matej Zagiba
if You configure/make/install kerberos with --prefix=/krb5, then default place for kdc configuration and database file is
/krb5/var/krb5kdc/ - so Your file paths are all default ones. Hence You don't need any workarounds.
On debian however, the policy is to place configuration files under /etc and database files under /var/lib/krb5kdc.
This requires explicit configuration in kdc.conf file (or krb5.conf, but that is non-intuitive) which is ignored
by kpropd when calling ulog_replay. In manual page only kdc.conf is mentioned as configuration file and -F option to
set principal database is documented, but none of it works with ulog_reply().
Jeremy Hunt
You are right, we agree.
Because my kdc is in the default location everything is found, including the kdc.conf which is in the same location as the kdc. This means having a kdc location directive in the kdc.conf file is a circular reference.
As I said in the my last email, the real bug/improvement is for the kdc location to be defined in the krb5.conf file. You are correct in that this definition should be referred to by all kerberos daemons and be a default or command line value otherwise.
If this was the case then debian packages could include the location of the kdc in the krb5.conf file and it would not need to be intuitive.
Regards,
Jeremy
Matej Zagiba
well, problem is not location of kdc.conf, kpropd can find kdc.conf just fine.
Problem is, when principal database is in non-standart location. Actually, kprpod reads and uses settings from kdc.conf
when it does check for last serial and timestamp, but does not use this values when calling ulog_replay().
And as Greg pointed out, putting database_name = /var/lib/krb5kdc/principal directive (or whole kdc configuration)
to realms section in krb5.conf solves the problem too.
Anyway, this shoud not be hard to fix, so I will look forward to 1.9 release (and may be debian will port the patch to 1.8.3)