[1477] in Kerberos_V5_Development
Re: proposal: db support in aname_to_localname going away
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Fri Aug 2 10:17:13 1996
To: Sam Hartman <hartmans@MIT.EDU>
Cc: krbdev@MIT.EDU
From: Ken Raeburn <raeburn@cygnus.com>
Date: 02 Aug 1996 10:16:24 -0400
In-Reply-To: Sam Hartman's message of Thu, 1 Aug 1996 14:09:09 -0400
Another problem: NetBSD uses db to access passwd info (if the hashed
file exists). A *different* db. If a program uses the krb5 db,
getpwnam won't work, nor anything else that accesses a native-db file.
OTOH, Marc had also suggested looking at using the btree
implementation to make an rcache from. I understand from Ted that the
btree code may not be well tested so far, but aside from that, is
there any good argument against trying to do so? It would mean that
random servers would need at least some of the db support.
I'm not too concerned about the aname_to_localname support per se, but
pulling the db support there may just put off the problem for a little
while, without actually removing it or fixing it.
Another possible solution is to merge db into libkrb5.so, but maintain
a simple set of patches (a bunch of #defines, really) which rename all
the exported names to keep them under the krb5_* part of the
namespace. I know Marc doesn't want to maintain even that much of a
difference from the distribution version, but I think it's a minor bit
of work and makes our code friendlier in terms of namespace intrusion.
Of course, we're already losing on the reserved-name space. Here's a
list I threw together:
asn1*
daemon (??)
decode_krb5_*
dump_profile*
encode_krb5_*
gmt_mktime
initialize_*_error_table
*_keyproc
krb5_*
mcc_head
profile_*
And I think this was just the krb5 library.
