Menu
▾
▴
fetchmail-users
|
From: Matthias A. <mat...@gm...> - 2006-01-05 00:48:50
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, in the original 6.3.0 announcement, I mentioned that we're more careful about writing the .fetchids file. While this is true, the change introduced a minor incompatibility. This announcement attempts to avoid astonishment throught that change. Beginning with release 6.3.0, fetchmail needs not only need write access to the idfile ($HOME/.fetchids), but also to the directory holding this file. fetchmail 6.2.X and older versions got away if just the idfile had write permission. The reason is that fetchmail 6.3.0 and newer now writes the ids to a temporary file, to avoid truncation of the idfile if running short of diskspace; a truncated idfile might lead to many duplicate messages, which might, in turn, aggravate the "low space" situation. For end users running fetchmail with default idfile on their own account, nothing changes: they have write access to their home directory. For system-wide execution of the script as used by some distributions (for instance Debian), it is now important that the idfile is in a directory writable by fetchmail, else creation of the temporary file and renaming into place will fail. Debian for instance places the idfile under /var/mail, this will no longer work with 6.3.0. I still think the new behavior is a step ahead, towards a more reliable fetchmail. Please accept my apologies for missing this in the 6.3.0/6.3.1 materials I provided to Rob Funk and that we shipped with fetchmail 6.3.0. Happy fetchmailing, - -- Matthias Andree -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFDvF7dvmGDOQUufZURAiknAKCFQxw6GWYmrvh2TW/qASnSA2n66QCfVrR/ IY+E3PqfFeWJW560g5IPDmQ= =uILr -----END PGP SIGNATURE----- |
|
From: Nico G. <ni...@ng...> - 2006-01-05 15:24:30
|
Hallo Matthias, * Matthias Andree <mat...@gm...> [2006-01-05 14:47]: > in the original 6.3.0 announcement, I mentioned that we're more careful > about writing the .fetchids file. While this is true, the change > introduced a minor incompatibility. [...] sorry, hab gerade probleme das nachzuvollziehen, kannst du mir das nochmal auf deutsch erklären? gruß nico -- Nico Golde - JAB: ni...@ja... | GPG: 0x73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org Forget about that mouse with 3/4/5 buttons - gimme a keyboard with 103/104/105 keys! |
|
Re: [fetchmail-users] Re: [pkg-fetchmail-maint] fetchmail 6.3.0 contained incompatible idfile change
From: Matthias A. <mat...@gm...> - 2006-01-06 15:44:03
|
Nico Golde <ni...@ng...> writes: > Hallo Matthias, > > * Matthias Andree <mat...@gm...> [2006-01-05 14:47]: >> in the original 6.3.0 announcement, I mentioned that we're more careful >> about writing the .fetchids file. While this is true, the change >> introduced a minor incompatibility. > > [...] > sorry, hab gerade probleme das nachzuvollziehen, kannst du > mir das nochmal auf deutsch erklären? (he asked for a German explanation, so here goes) Seit 6.3.0 schreibt fetchmail sein $idfile nicht mehr direkt, was zur Trunkierung zum Beginn des Schreibens führt, sondern zunächst in eine temporäre Datei, die später per rename() das eigentliche idfile ersetzt. Früher konnte man - wie es Debian tut, einfach fetchmail eine ID-Datei geben, die den passenden Besitzer hat; das hat jedoch immer wieder dazu geführt, dass Leute viele Nachrichten mehrfach abholen mussten, wenn fetchmail gecrasht ist, die Partition für's idfile voll war oder die quota erschöpft etc. Wegen des rename() und dem Anlegen der temporären Datei ist nötig, dass fetchmail Schreibzugriff auf das Verzeichnis hat. Das Grundproblem ist, dass das Debian-Startskript fetchmails idfile nicht unterhalb /var/run/fetchmail (= ~fetchmail) anlegt, sondern in /var/mail, wo fetchmail m. E. (ich hab' kein Debian) nicht schreiben darf. Wenn Ihr das ändert, müsst Ihr im postinstall die Datei noch vom alten Ort an den neuen verschieben, sonst zürnen Euch Eure User :-) -- Matthias Andree |
|
From: Dembe <da...@de...> - 2006-01-06 13:27:50
|
Matthias Andree wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Beginning with release 6.3.0, fetchmail needs not only need write access >to the idfile ($HOME/.fetchids), but also to the directory holding this >file. fetchmail 6.2.X and older versions got away if just the idfile had >write permission. > We hadn't spotted this and so presumably our .fetchids file hasn't been updated. However, we've also not had any errors in the logs saying that fetchmail couldn't update the .fetchids file (our system is stable so we don't run fetchmail with any -v 's). Shouldn't this perhaps be put forward as a change for a next version so that if fetchmail doesn't have access to the .fetchids file, a warning error is logged (even if the debug options aren't being explicitly enabled)? Thanks, David |
|
From: Matthias A. <mat...@gm...> - 2006-01-06 15:40:23
|
Dembe <da...@de...> writes: > We hadn't spotted this and so presumably our .fetchids file hasn't been > updated. However, we've also not had any errors in the logs saying that > fetchmail couldn't update the .fetchids file (our system is stable so we > don't run fetchmail with any -v 's). Shouldn't this perhaps be put forward > as a change for a next version so that if fetchmail doesn't have access > to the .fetchids file, a warning error is logged (even if the debug > options aren't being explicitly enabled)? David, fetchmail should be doing exactly that, log and print on standard error messages like "Cannot open fetchids file ... for writing" or "Cannot rename fetchids file ... to ..." and the like. I've checked this, it works for me in 6.3.2-rc1. The problem only matters for system-wide installs that pass an UIDL file to fetchmail that is in a directory where the fetchmail user has no write permission. End-user installs and system-wide installs that leave the default --idfile are unaffected by the change, as these have write permission in their respective home directory. I issued the report since Debian is known to put the UID file in a directory that the fetchmail user cannot write, so they're going to fail when they upgrade. Note the error messages will appear localized when fetchmail is started with LANG or LC_MESSAGES environment variables set. HTH, -- Matthias Andree |
|
From: Simon B. <ba...@gm...> - 2006-01-05 01:01:28
|
Matthias Andree wrote: > Beginning with release 6.3.0, fetchmail needs not only need write access > to the idfile ($HOME/.fetchids), but also to the directory holding this > file. fetchmail 6.2.X and older versions got away if just the idfile had > write permission. > > The reason is that fetchmail 6.3.0 and newer now writes the ids to a > temporary file, to avoid truncation of the idfile if running short of > diskspace; a truncated idfile might lead to many duplicate messages, > which might, in turn, aggravate the "low space" situation. What about using one of the system-wide temporary directories instead? -- Best regards / Viele Grüße, ba...@Fr... Simon Barner ba...@gm... |
|
From: Matthias A. <mat...@gm...> - 2006-01-05 02:20:19
|
Simon Barner schrieb am 2006-01-05:
> Matthias Andree wrote:
> > Beginning with release 6.3.0, fetchmail needs not only need write access
> > to the idfile ($HOME/.fetchids), but also to the directory holding this
> > file. fetchmail 6.2.X and older versions got away if just the idfile had
> > write permission.
> >
> > The reason is that fetchmail 6.3.0 and newer now writes the ids to a
> > temporary file, to avoid truncation of the idfile if running short of
> > diskspace; a truncated idfile might lead to many duplicate messages,
> > which might, in turn, aggravate the "low space" situation.
>
> What about using one of the system-wide temporary directories instead?
The basic idea is: the UIDs are somewhat precious (and we have had
issues to that extent in the bug trackers). That's why I chose to write
a temporary file and atomically (i. e. rename(2)) replace the original
file. This guarantees that we'll always have the old UID file available
even if writing the new fails at some point. In unlucky situations,
6.2.5.X and older might end up with an empty ID file, would start
refetching and flooding /var/mail with dupes.
Rename(2) only works within the same device or perhaps mountpoint (some
file systems such as AFS and Coda even turn every directory into a
filesystem of its own). Besides that, I will not use directories with
public write access (/tmp, /var/tmp), these are minefields, and handling
subdirectories within them still doesn't guarantee we can rename without
truncating the output file.
Plus, creating backup files still requires write permission on the
directory...
Debian for instance uses a fetchmail user for the system wide fetchmail
daemon, home directory is /var/run/fetchmail, yet they use
/var/mail/.i-forgot-the-UIDL-name for their idfile. If they used
/var/run/fetchmail/.i-forgot-the-UIDL-name, everything would be fine. No
need for ${TMPDIR-/tmp}.
--
Matthias Andree
|
|
From: Simon B. <ba...@gm...> - 2006-01-05 02:39:12
|
Matthias Andree wrote:
> > What about using one of the system-wide temporary directories instead?
>
[ Nice explanation skipped -- thanks! ]
>
> Debian for instance uses a fetchmail user for the system wide fetchmail
> daemon, home directory is /var/run/fetchmail, yet they use
> /var/mail/.i-forgot-the-UIDL-name for their idfile. If they used
> /var/run/fetchmail/.i-forgot-the-UIDL-name, everything would be fine. No
> need for ${TMPDIR-/tmp}.
I thought about adding something similar to the FreeBSD port, but I thought
of having one fetchmail instance per user (if that is possible). OTOH, this
will not work if there are many users.
Do you think, a system-wide fetchmail is worth the trouble? (I know, you are
biased since you are the current maintainer ;-)
--
Best regards / Viele Grüße, ba...@Fr...
Simon Barner ba...@gm...
|
|
From: Rob M. <rob...@gm...> - 2006-01-06 18:57:22
|
On 05/01/06, Simon Barner <ba...@gm...> wrote:
>
> I thought about adding something similar to the FreeBSD port, but I thought
> of having one fetchmail instance per user (if that is possible). OTOH, this
> will not work if there are many users.
>
> Do you think, a system-wide fetchmail is worth the trouble? (I know, you are
> biased since you are the current maintainer ;-)
Personally, yes. With the caveat that it only works if you're not
making lots of changes. If things are relatively static then it works
well.
If nothing else it stops the users from deleting or messing up their
fetchmail config files themselves, and ensures you avoid hammering POP
servers with lots of simultaneous connections.
--
Please keep list traffic on the list.
Rob MacGregor
Whoever fights monsters should see to it that in the process he
doesn't become a monster. Friedrich Nietzsche
|
|
From: Matthias A. <mat...@gm...> - 2006-01-07 12:40:54
|
Simon Barner <ba...@gm...> writes: > Do you think, a system-wide fetchmail is worth the trouble? (I know, you are > biased since you are the current maintainer ;-) Well, the "trouble" is having a working local SMTP or LMTP package installed and adding an unprivileged fetchmail user and chrooting fetchmail along with the needed libraries (DNS!) and picking sensible defaults. The Debian init script is a good starting point, but needs minor touch-ups, for instance, the mentioned .fetchids placement. -- Matthias Andree |
|
From: Dembe <da...@de...> - 2006-01-05 12:11:05
|
Matthias Andree wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Beginning with release 6.3.0, fetchmail needs not only need write access >to the idfile ($HOME/.fetchids), but also to the directory holding this >file. fetchmail 6.2.X and older versions got away if just the idfile had >write permission. > We hadn't spotted this and so presumably our .fetchids file hasn't been updated. However, we've also not had any errors in the logs saying that fetchmail couldn't update the .fetchids file (our system is stable so we don't run fetchmail with any -v 's). However, shouldn't this perhaps be put forward as a change for a next version so that fetchmail doesn't have access to the .fetchids file a warning error is logged (even without the debug options being enabled)? Thanks, David |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X