Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: Temporary dir for mailpost (Russ Allbery)
2. Re: Circular dependencies between libinnhist and libstorage
(Russ Allbery)
3. Re: Temporary dir for mailpost (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Wed, 15 Apr 2015 14:56:19 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Temporary dir for mailpost
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> Regarding this ticket:
> https://inn.eyrie.org/trac/ticket/81
> "mailpost tries to store its message ID database in INN's pathtmp, but
> since it's usually running as the mail system (often daemon) rather than
> as news, this fails."
> What should we do?
This is a hard problem, since there's no generally good directory for this
sort of thing and we can't automatically create one since we don't know
what user mailpost will actually run as. I don't think there's a good
alternative to just requiring some manual configuration when mailpost is
set up.
It might make sense to put the database and the temporary files all in the
same place. The advantage of using /var/run is that those files will
often be wiped automatically on reboot. It would be nice to keep that.
But there's no guarantee that /var/run will be writable, and putting them
in /tmp is a bad idea since they're very predictable filenames. It may be
necessary to just live with putting them in a persistent directory.
I think it would make sense to have a directory explicitly configured for
mailpost, and to put the database and the temporary files there, and to
document that this directory has to be created and set to be writable by
the user that mailpost runs as. And if we're going to do that, it might
be simplest to just make -b mandatory, although that's not a
backward-compatible change. But it's hard to see how to do this safely in
a backward-compatible way.
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 2
Date: Wed, 15 Apr 2015 15:04:00 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Circular dependencies between libinnhist and libstorage
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> I recently tried to build INN 2.6.0 on an Ubuntu VM (12.04.1 LTS)
> provided by the GCC C Farm, and found out that the build fails
> because of the "$(LIBHIST) $(LIBSTORAGE)" order.
The root of this mess is that storage/expire.c calls libhist functions,
but libhist wants to call IsToken, TextToToken, and TokenToText, which are
in libstorage.
This is just broken -- libraries with circular dependencies are always a
bug and need to be fixed. The dependency on libhist in libstorage is
probably hardest to break, since expiration is based on history and it
really needs the full history functionality. IsToken, TextToToken, and
TokenToText are small, standalone functions with no futher dependencies.
The best solution is probably to just move those three functions to
libinn, at which point libhist will no longer have any dependency on
libstorage. That's kind of unfortunate, since the exact format of storage
tokens is properly the domain of libstorage, but meh, that's a very
theoretical problem and this is a very concrete one.
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 3
Date: Thu, 16 Apr 2015 12:00:39 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Temporary dir for mailpost
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Russ,
>> "mailpost tries to store its message ID database in INN's pathtmp,
>> but since it's usually running as the mail system (often daemon)
>> rather than as news, this fails."
>
> I don't think there's a good alternative to just requiring some
> manual configuration when mailpost is set up.
>
> I think it would make sense to have a directory explicitly configured
> for mailpost, and to put the database and the temporary files there,
> and to document that this directory has to be created and set to be
> writable by the user that mailpost runs as. And if we're going to do
> that, it might be simplest to just make -b mandatory, although that's
> not a backward-compatible change. But it's hard to see how to do
> this safely in a backward-compatible way.
Thanks for your suggestions.
We may:
- put the database and the temporary files in the same directory
(configurable with -b)
- in case -b is not given, mailpost checks whether INN's pathtmp is
writable and if that's not the case, it dies with an error
- in case -b is given, mailpost checks whether the explicitly configured
directory is writable and if that's not the case, it dies with an error
Wouldn't that do the trick instead of making -b mandatory?
Hmm... Couldn't we also just create and use the ~/.mailpost directory
by default instead of INN's pathtmp? (or ~/.inn-mailpost or
~/.inn/mailpost that could be useful if we ever wish to store files for
other programs ?)
--
Julien ?LIE
? ? Et on appelle comment ce genre de logis ?
? HLM? Habitations Latines M?lang?es? ? (Ast?rix)
------------------------------
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
End of inn-workers Digest, Vol 71, Issue 2
******************************************
