Bug#292191: upgrade changes ownerhsip of /var/spool/exim4

[( Marc A. Lehmann )]

On Tue, Jan 25, 2005 at 08:45:05PM +0100, Marc Haber <mh+debian-packages@zugschlus.de> wrote:
> On Tue, Jan 25, 2005 at 08:38:55PM +0100,  Marc A. Lehmann  wrote:
> > > NACK
> > 
> > Reason? It's not your mail that has been lost, and the bug certainly
> > causes non-restorable data loss.
> 
> I does not. Any sensible sender will queue for multiple days.

Sorry, but are you dense? It's a verifiable fact that it caused data
loss. No matter how much you wish or wrongls claim it isn't doesn't make
it magically true.

> > Thanks that you know what we do. Unfortunately, logs didn't show anything
> > bad as exim4 started fine and the system didn't receive mail for some
> > time.
> 
> And you didn't think of testing your setup after upgrading your
> non-released development version of your Linux distribution?

I might have (at leats I did so in the past), but the person in question
did not. After all, this was a minor upgrade and it's not expected that
debian scripts break the setup that way, especially not without having any
reason to do so.

Also, I find your logic strangely flawed. Just because careful and
knowledgable monitoring might cause the priblem not to be severe this does
not, as you seem to assume, make the bug less problematic :(

> > This has not happened, presumably because within the 24 hours that this
> > happened, the other mail already stopped retrying.
> 
> The other mailes are broken.

Just because you claim so without _any_ reason doesn't make it true. I don't
think there is any authority (wether rfc or anything else) that requires
retry times of longer than 24 hours. Also, it's possible that the retry time
was longer due to additional reasons (network outage).

The fact is that exim didn'T accept the package although it was correctly
configured. That this might or might not be caused be a short retry time or
other problems (and a normal retry time) does have no effect on the problem.

That you claim it's a broken mailer on the other side only shows that you
have no good understanding of how SMTP in general and retries specifically
work, as your assumption of this being a mailer issue is broken.

> > If you think that losing mails is not serious data loss, speak up please.
> 
> A mailer being down for less than 48 hours should not cause data loss.

Why? See above on why I think your understanding is flawed.

In any case, it *did* cause data loss, and I only found out because a
customer complained *after* the problem had been fixed. It's likely that
other people won't notice the problem, and we will neither.

> > Otherwise please acknowledge that this bug causes the problem to happen.
> 
> I already did that.

So why did you wrongly change the severity then?

> > For me, yes, but for others probably not. This is a bug and it should be
> > fixed properly.
> 
> Please outline a possible fix that will allow upgrades from exim4
> 4.24-3 to a current version (both of them using a debconf-generated
> config without local changes) to function properly.

We didn't upgrade from 4.24, but from 4.43, and the problem is that it
wasn't a debconf-generated config but a custom one. I see no relation tot
he problem at hand.

Maybe you confused this report with some other report?

> > If users cannot edit the exim4 confgi file then it must go
> > out of /etc.
> 
> People can edit the exim4 config file. But they might be required to
> touch other parts of the system, for example telling the system that
> they explicitly want non-default file modes.

I did so, using chmod AND by editing the config file. Doing chmod to the
wrong user (afetr all, the corretc user is explicitly mentioned in the
config file for the package!) again was not required for upgrading the
package, as you already said.

So the debian package gratitiously and without technical reasons chmod
directories to a different user as given in the config file for the package.

If that isn't a bug then I don't know what a bug is.

I would have undertsood if I had upgraded from some ancient exim package
with different defaults.

> It is a bug that the exim4 packages currently do not have that
> possibility. They will have an interface to dpkg-statoverride in due
> time.

Well, dpkg-statoverride is not a solution (according to the docs) because
there is no way to dpkg-statoverride a whole hierarchy, after all I cannot
know the name of future spool files.

If this is handled by special magic inside the update scripts I'd say this is
a poor fix, as it is a subtle effect even if documented in some obscure
place.

Especially as it's not necessary to chmod the spool files *unless*
upgrading from an old package. And, if that is not possible (because of
some limitation in dpkg, who knows) then it would still be far preferable
to chmod to the user/group mentioned in the configuration. This would have
the benefit of not breaking existing configurations even when upgrading.

-- 
                The choice of a
      -----==-     _GNU_
      ----==-- _       generation     Marc Lehmann
      ---==---(_)__  __ ____  __      pcg@goof.com
      --==---/ / _ \/ // /\ \/ /      http://schmorp.de/
      -=====/_/_//_/\_,_/ /_/\_\      XX11-RIPE