>>>>> "Greg" == Greg Stark <[EMAIL PROTECTED]> writes:
Greg> That would be clean, but it's not practical, in this case
Greg> I'm talking about kerberos and /etc/krb.conf and
Greg> /etc/krb.realms. These files are standardized upstream and
Greg> we can't start moving them around.
I can't remember what /etc/krb.realms is...
However, AFAIK, the only conflict in files will be between MIT and
Heimdal implementations of Kerberos...
Greg> In this case it's not likely to be important because I don't
Greg> believe many people used the 0.99 kerberos
Greg> libraries. However a similar problem is likely to crop up
Greg> shortly between heimdal and kerberos4kth.
I don't think so - Heimdal uses:
/etc/krb5.conf /etc/krb5.keytab
Where the first file is config info that could be stored in DNS
instead. The second file contains the private keys for this host, and
must be kept secret.
I would be surprised if the krb5.conf is compatible with MIT's
implementation of Kerberos, however, I think the keytab file should be
OK. Don't take my word for it though...
Greg> But pretty much any library that has configuration files is
Greg> likely to keep the same filenames across multiple
Greg> versions. It would be confusing for the user to have custom
Greg> filenames just for debian that's different from the names
Greg> used for configuration files from the upstream version.
Greg> I guess one option is to have a /etc/libfoo.conf.1 and then
Greg> link /etc/libfoo.conf to it in the postinst. Then it points
Greg> to the most recently installed configuration.
I have already noticed this problem with certain packages - I think it
has dhcp and dhcp-beta. I installed dhcp, which automatically removed
(but didn't purge) dhcp-beta. At a latter date, I purged dhcp-beta. To
my surprise, dhcp-beta stopped working. Why? Because the postrm
routine deleted the /var/dhcp directory.
While it looks like the postrm routine has now been hacked not to
delete the directory if any files exist, I don't really like this
solution, and think it clearly highlights some of the problems with
shared configuration files.
Ideally, I don't think the postrm script should delete any files,
everything should be managed by dpkg, but I don't think this is going
to happen any time in the near future.
>>>>> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes:
Manoj> In that case, onse should serously consider if
Manoj> sumultaneous installation is very useful, since the
Manoj> packages seem to be drop in replacements. If it is indeed
Manoj> desirable to have more than one version installed
Manoj> simultaneously, your solution below seems a decent
Manoj> workaround.
Personally (and I realize others do disagree), my feeling is:
- Kerberos 4 is obsolete and should not be used anymore. MIT no longer
support it. There is only one mainstream application that still
requires Kerberos 4: AFS. It could be argued that AFS is now obsolete,
but AFAIK, no up-to-date open source implementation of DCE/DFS exists
:-(. Eventually, I have been told, Arla (open source AFS) will
support Kerberos 5.
- MIT and Heimdal are mostly[1] drop in replacements, and it would be
OK if they conflicted.
Manoj> Yes. And one can look into alternatives, espescially
Manoj> for heimedahl and MIT kerberos, rather than trying to have
Manoj> both packages ahve the same conf file.
For /etc/krb5.conf, DNS could be used, for at least some situations.
Footnote:
[1] programs need to be compiled specifically for MIT or
Heimdal. Arrgh! It would be nice if something like SASL could be used
to "insulate" programs from having to directly interface with the
Kerberos libraries, but this may require making major changes to the
code.
Still, I think this would be worth the effort... With SASL support,
the program will work with any authentication method, not just
Kerberos. eg, you could write a SASL module that does ssh like RSA
based authentication. No re-compilation required. Not everybody likes
Kerberos, and this would be the best way to satisfy everyone.
SASL support in Debian would mean we could support both
implementations of Kerberos 5, and just use a different SASL module
for each one.
However, now the subject has changed considerable from what is in the
subject line...
--
Brian May <[EMAIL PROTECTED]>
