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

[Marc Haber]

On Tue, Jan 25, 2005 at 10:19:27PM +0100,  Marc A. Lehmann  wrote:
> 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?

No, just being a mail admin since 1997.

> It's a verifiable fact that it caused data loss.

Fault of the remote SMTP side. Can you please provide logs where your
exim accepted the message and then discarded it without bouncing?

> 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.

See rfc2821 4.5.4.1.

> Also, it's possible that the retry time
> was longer due to additional reasons (network outage).

Tough luck. Shit happens.

> The fact is that exim didn'T accept the package although it was correctly
> configured.

Obviously, it was not.

> 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.

Well, at least I have read the SMTP more thoroughly than you. Please
notice that insulting people is not going to make those people honor
your requests faster.

Please feel free to refer to debian-devel or the tech ctte for the bug
severity. Make sure to include in your complaint that we already have
confirmed the issue and that we'll try to modify the package to ease
your pain with your non-standard configuration.

> 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.

So you have poor monitoring systems in place on a productive system
that hosts customer data and does run an unreleased developer version
of Debian GNU/Linux.

> > > Otherwise please acknowledge that this bug causes the problem to happen.
> > 
> > I already did that.
> 
> So why did you wrongly change the severity then?

The bug is a bug with normal severity.

> > > 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.

Well, you're not the only one using the Debian packages of exim4. We
need to support people using the package in the way it was intended.
Please do not ask us to break updates for other people just to make
your setup work.

> Maybe you confused this report with some other report?

No.

> > > 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!)

So you want the postinst to parse the config file, catering for
include and ifdef code? You are just suggesting to replicate a _big_
part of exim itself in the postinst.

> again was not required for upgrading the package, as you already said.

It might have been required for upgrading the package on older systems.

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

Wrong.

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

People upgrading from some ancient exim package with different
defaults need that chmod or they will suffer the same problem.

> > 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.

You can dpkg-statoverride the directory, which might be used as a hint
for the postinst.

> 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.

OK, suggest something better, and include a patch.

> 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.

The default configuration does not have a user/group mentioned, and
the user might want to change the configuration after running the
postinst.

Are you suggesting to check queue ownership in the init script just
before starting exim?

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835