Bug#402804: openssh-client: Needs to conflict with old ssh-krb5; conffile ownership transfer failure
(CCing Sam for extra Kerberos wisdom; see down near the end)
(CCing debian-release because this just got into etch. Damnit)
On Tue, Dec 12, 2006 at 07:35:02PM -0500, Adam C Powell IV wrote:
> On Tue, 2006-12-12 at 13:10 -0800, Russ Allbery wrote:
> > Similarly, I don't understand this either. There is a Replaces that
> > should make dpkg accept this without any issues.
> >
> > Replaces: ssh (<< 1:3.8.1p1-9), openssh-client (<< 1:3.8.1p1-11), ssh-krb5 (<< 1:4.3p2-7)
> >
> > I didn't run into this problem in my upgrade testing, but maybe somehow I
> > did something on a different sequence than you did? But on a theoretical
> > level, I don't understand at all how this could be happening when the
> > Conflicts and Replaces are already in place.
>
> I just used dselect/apt and saw the problem in the log. Apt clearly
> tried to transfer ownership,
Actually, that's openssh's maintainer scripts.
> but dpkg gagged anyway. Unfortunately, I did dpkg --purge ssh-krb5;
> apt-get install openssh-client openssh-server (so I'd have a working
> ssh), and can no longer really test this...
>
> I know that dselect is somewhat deprecated (though I still prefer it
> over aptitude for its package layout and interactive dependency
> resolution), but apt/dpkg are not, and they are causing the problems
> here. Reassign to apt?
No, it's definitely not a bug in that layer.
A dpkg -D7777 log reveals:
D000040: does_replace new=openssh-server old=ssh-krb5 (1:4.3p2-7)
D000400: does_replace ... found old, version 1:4.3p2-7
D000040: does_replace ... no
D000040: does_replace new=ssh-krb5 old=openssh-server (1:4.3p2-7)
D000040: does_replace ... no
dpkg: error processing /var/cache/apt/archives/openssh-server_1%3a4.3p2-7_powerpc.deb (--unpack):
trying to overwrite `/etc/default/ssh', which is also in package ssh-krb5
The problem is that, because of the Conflicts, dpkg must unpack the new
ssh-krb5 first. Normally speaking this would be fine because unpacking
the new ssh-krb5 would mean dpkg forgot about the files it used to
contain, but this isn't the case for conffiles; those stay around at
least until the configure step. By the time dpkg gets to considering
openssh-client and openssh-server, the version in the Replaces isn't
satisfied.
I think the simplest option by far is to just drop the versioning on the
Replaces; since they're transitional packages, the versioning is only a
nicety anyway. I'll do this for the Replaces on both ssh and ssh-krb5,
although I don't entirely understand why I haven't been getting similar
reports about ssh as by all rights it should exhibit the same problem if
any of the conffiles were modified before the upgrade. I'll test this
out before upload.
> One more thing: Kerberos options seem unsupported in openssh-server.
> See attached. And this is after dpkg --purge ssh-krb5 so I don't think
> it's a leftover conffile.
[...]
> Setting up openssh-server (4.3p2-7) ...
> /etc/ssh/sshd_config line 65: Unsupported option KerberosTgtPassing
This was unsupported in the most recent version of ssh-krb5 too, so
that's OK.
> /etc/ssh/sshd_config: line 70: Bad configuration option: GSSAPIUseSessionCredCache
The options GSSUseSessionCCache/GSSAPIUseSessionCredCache (synonyms) and
GSSAPICleanupCreds (a synonym for GSSAPICleanupCredentials) were in
ssh-krb5 but aren't in current openssh. Russ, Sam, what should I do
about these? GSSAPICleanupCreds should presumably go back in as an
alias, and maybe get postinst migration. The credential caching options
appear to have been parsed in openssh-krb5 3.8.1p1-10 but not actually
handled in any way. Would it be OK to just add those as sUnsupported,
and add postinst code to comment them out?
Cheers,
--
Colin Watson [cjwatson@debian.org]
Reply to: