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

[( Marc A. Lehmann )]

> > Sorry, but are you dense?
>=20
> No, just being a mail admin since 1997.

What does that prove? I am mail admin for our institute since 1994. Does
that prove I am right? I'd hope the decision wether sth. is right or
wrong should be based on relatable facts, not on "mine is longer"-style
arguments.

> > It's a verifiable fact that it caused data loss.
>=20
> Fault of the remote SMTP side.=20

Why? You assume that data loss will not occur because one side will not be
reachable for a short (whatever that means) amount of time. This, however,
is not realitym and most likely not what happened in my case, although
sdome badly configured mailer might have had a too-short retry time.

> Can you please provide logs where your exim accepted the message and
> then discarded it without bouncing?

Why should my exim have done that, it had no reason to... Therefore, I
cannot provide logs for this event, as it didn't happen.

It returned a temporary failure, as it should. The mail was lost, because
the sender side did not retry long enough.

> > 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.
>=20
> See rfc2821 4.5.4.1.

Well, if you read that section, you will see that you are wrong and the
rfc mandates no such long retry times :(

In any case, the fact that exim4 was down for say, 24 hours, does not mean
that the full retry time was just 24 hours.

As I (already) explained, I can imagine that the mail that was lost was
probably lost because there was an additional outage on the sending side, or
maybe in between.

As an experienced mail admin (which you seem to be with lots of years of
experience) you should be aware that retry time is measured in relation to
the complete downtime, not just the downtime of one part of the link.

In fact, most of the mail went through nicely, but I cannot understand why
you dispute the fact that mail has been lost, and can be lost regardless
of wether the downtime is just a few minutes or a week.

> > Also, it's possible that the retry time
> > was longer due to additional reasons (network outage).
>=20
> Tough luck. Shit happens.

Well, I full agree. However, I completely don't understand why you are
incapable of simply acknowledging the bug (possibly silently) instead
of resorting to misinformation or ridicoulous arguments. Mail was lost
because of that, despite your serious efforts of brainwashing.

> > The fact is that exim didn'T accept the package although it was correct=
ly
> > configured.
>=20
> Obviously, it was not.

I was talking about the config file. But if you will, indeed, the upgrade
scripts have broken the configuration then.

> > work, as your assumption of this being a mailer issue is broken.
>=20
> Well, at least I have read the SMTP more thoroughly than you.

Possibly, but that doesn't mean you understood it, as rfc2821, which you
probably mean with "the SMTP", doesn't require the rules your seem to read
out of it.

Please also note that rfc's are not law. Things cna be bugs regardless of
wether rfc require them or disallow them. Although, of course, deviating
=66rom rfcs is a sin unless there are good and well-understood reasons for
that :)

> Please notice that insulting people

I can see you feel insulted, otherwise, why would you resort to the style
of argument you are resorting to now (i.e. "deceiving").

*Iff* I was insulting, then please accept my apologies. I honestly tried
to report a bug, and correct your misunderstandings regarding the way smtp
retry works, and the mechanism through which we lost mail. If there was an
insult in there, I am deeply and *honestly* sorry. It would help if you
could tell me what you found insulting, so I can learn from that and avoid
the phrases In future correspondence.

Let me assure you that I wasn't trying to be insulting. I *was* trying to
correct your misunderstandings, though.

> is not going to make those people honor your requests faster.

Which request? I reported a bug. If you don't want to fix it, or want to fix
it, or want to fix it today, or want to fix it later, is completely your own
decision (and maybe others).

I did not request a fix at all. I did point out that there is a bug
inside the upgrade scripts that can cause serious data loss (and usually
doesn't).

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

I do not understand why you are arguing about that ridiculous severity leve=
l.
I am not arguign about that at all. I was arguign because reportbug told me
that serious data loss would warrant this sevrity level, and your response
was, in summary "no, because there was no data loss".

That was quite strange, because *we did lose data because of that*, no
matter how hard you want to make others believe that this isn't the case.

As long as you do dispute that data has been lost, or this is a bug in the
remote side, I will try to correct you. If you really insist on knowing
better, then it's your problem, as I did invest time and effort into
reporting the issue and explaining it as much as I can do (and will do so
in the future).

If certainly did not request a fix, or a timely fix, or a critical
severity.

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

Sorry, but that is just too lame to even consider arguing about. Yes,
there is no bug, yes, no data was lost, yes, yours is longert than mine
(by -3 years or so). If that makes you sleep at night, so be it.

> > > I already did that.
> >=20
> > So why did you wrongly change the severity then?
>=20
> The bug is a bug with normal severity.

Not according to reportbug. Feel free to reassigng his bug to reportbug
then.

> > 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 t=
ot
> > he problem at hand.
>=20
> 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.

I have no idea what that means. Modifying the config file manually is not
intended use of the package? Is that what you want to tell me? In that
case it's certainly better to move the exim4 config file out of /etc,
don't you think so?

> Please do not ask us to break updates for other people just to make
> your setup work.

You are childish - I never asked you to break updates for people. Not
chmodding the directories for 4.43->4.43 updates, or chmodding them
correctly would have both worked in my case, and certainly in the
4.24->4.43 case.

Also, I am not asking for a fix - I am alerting you of a possible severe
problem caused by the update scripts.

> > Maybe you confused this report with some other report?
>=20
> No.

That's bad...

> > 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!)
>=20
> 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.

I don't want anything. I am *suggesting* that this would be the right fix. I
don't know how difficult it is - supposedly one can coax exim into providing
this info, thus not relying on duplicating exim, but I haven't tried it and
so cannot say for certain.

> > again was not required for upgrading the package, as you already said.
>=20
> It might have been required for upgrading the package on older systems.

It's not required in this case.

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

Why? Just claiming "wrong" or "the mta is broken" or "the setup is broken"
is not going to sound very believable given your record of misquoting or
misunderstanding.

Nothing would have been broken when upgrading in my config and any other
similar config (regarding versions). Fact? Or do you want to dispute that,
too?

> > I would have undertsood if I had upgraded from some ancient exim package
> > with different defaults.
>=20
> People upgrading from some ancient exim package with different
> defaults need that chmod or they will suffer the same problem.

Actually, no. If they have the same config, they won't. Only if they follow
the debian standard config they will.

However, just a few lines above you claimed that there was a reason to
do this even in my config, but your only argument relates to a config
completely unlike mine.

> > If this is handled by special magic inside the update scripts I'd say t=
his is
> > a poor fix, as it is a subtle effect even if documented in some obscure
> > place.
>=20
> OK, suggest something better, and include a patch.

I did suggest something better, you even commented on it, saying it's
technically difficult to implement.

> > 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 preferab=
le
> > to chmod to the user/group mentioned in the configuration.
>=20
> The default configuration does not have a user/group mentioned, and
> the user might want to change the configuration after running the
> postinst.
>=20
> Are you suggesting to check queue ownership in the init script just
> before starting exim?

No, but that would certainly help a lot. In any case, you are confusing
issues. If the user changes the uid/gid of exim's spool files manually then
he cna be expected to do so for the spool directory, too.

You are equating this with the debian upgrade script, which does that
without asking or alerting the user, which is quite a different thing,
because even experienced users cannot avoid it, much less inexperienced
ones which are probably not aware of debian silently breakign their setup.

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