Preliminary discussion: DB alias entries

[Sam Hartman]

Greg, if you do something like what you are talking about, I think Love's approach is the best: a separate key space for aliases.
I understand there will be multiple lookups but I think that's OK. 

However, I'd like to ask you to think about whether adding alias
support to db2 done this way makes any sense at all.  If you have a
major sponsor who really wants aliases in db2 manipulated through
kadm5, then by all means go forward.  What you are proposing is not
harmful; it just seems like something that very few people will find
useful and thus is likely to be an inefficient use of the consortium's
time.  Here's why I say that.

If you go back to _The Role of Kerberos in Modern Information
Systems_, you find that your target customers use Kerberos as part of
larger infrastructure.  Your customers typically are not manipulating
the kdb by hand, they are using tools to do that.  They want Kerberos
to play well with their existing other infrastructure--whether it is
infrastructure that maintains DNS, DHCP, user accounts, whatever.  In
each of the case studies examined in that paper, Kerberos was used
along side other systems.

So, if the problem you are trying to solve is better host name
canonicalization, requiring the admin to use kadmin to manipulate your
database seems like a poor approach.

I'd instead pick some way to make host aliases available to the KDC,
within the db2 backend, but independent of the existing KDB.
I might consider things like
* a second db2 database (Love's approach)
along with a tool to load this from a DNS zone file

* an sqllite database along with example scripts to load from a zone file

* Look the alias info (and alias info only) up in LDAP


My point though is that I think it makes sense to separate the alias
information from the other parts of the system, to focus on
infrastructure integration rather than on hand aliases, and to
understand that people will be adapting your solution to a lot of
different infrastructures.  Based on the feedback in the paper, I
suspect that concrete instantiations of a solution would be better
than a well designed plugin interface, although I'd certainly have
making this pluggable in the back of my head even though I doubt you
have time to pull that off for 1.7.