postmulti fatal error with 3.0.0

[Andreas]

Hi,

i installed the new postfix-3.0.0 in my arch system, however by default (default main.cf) postmulti results in a fatal error for a reason (conflict) i don't understand:

# postmulti -l
postmulti: fatal: instance /etc/postfix, shlib_directory=/usr/lib/postfix conflicts with instance /etc/postfix, daemon_directory=/usr/lib/postfix

makedefs.out: http://pastebin.com/HhD0AZKQ

Only if i set shlib_directory=no all works as expected. I'm wondering if this is normal.

--Andreas

[Wietse Venema]

Andreas:

> Hi,
>
> i installed the new postfix-3.0.0 in my arch system, however by default

> (default main.cf <http://main.cf>) postmulti results in a fatal error

> for a reason (conflict) i don't understand:
>
> > # postmulti -l
> > postmulti: fatal: instance /etc/postfix,
> > shlib_directory=/usr/lib/postfix conflicts with instance /etc/postfix,
> > daemon_directory=/usr/lib/postfix

DO NOT set daemon_directory the same as shlib_directory.

Wietse

[Viktor Dukhovni]

On Tue, Feb 17, 2015 at 07:32:22PM -0500, Wietse Venema wrote:

> > > # postmulti -l
> > > postmulti: fatal: instance /etc/postfix,
> > > shlib_directory=/usr/lib/postfix conflicts with instance /etc/postfix,
> > > daemon_directory=/usr/lib/postfix
>
> DO NOT set daemon_directory the same as shlib_directory.

IIRC the main reason for the conflict detection in question is to
avoid use of the shared directories also as per-instance directories.

Use of the same pathname for two shared directories should also be
avoided (thus solving your immediate problem).

If we wanted to tolerate such use, something like the patch below
(untested) might make it possible:

diff --git a/src/postmulti/postmulti.c b/src/postmulti/postmulti.c
index 0d124ae..1d2292a 100644
--- a/src/postmulti/postmulti.c
+++ b/src/postmulti/postmulti.c
@@ -971,7 +971,9 @@ static void check_shared_dir_status(void)
sp->param_name, sp->param_value[0]);
if (strcmp(sp->param_name, VAR_META_DIR) == 0)
continue;
- register_claim(var_config_dir, sp->param_name, sp->param_value[0]);
+ /* Tolerate duplicate pathnames between the shared directories. */
+ if (IS_CLAIMED_BY(sp->param_value[0]) == 0)
+ register_claim(var_config_dir, sp->param_name, sp->param_value[0]);
}
}

This relies on the "claims" of the shared directories being registered
first, which is the case now, and is likely to remain so.

Since Linux systems seem to lack a /usr/libexec, you can use:

daemon_directory = /usr/lib/postfix
shlib_directory = /usr/lib/postfix/lib

This is something the distribution maintainers will have to figure
out. If you are a distribution maintainer, please DO NOT apply
the above patch unless it is first adopted upstream.

--
Viktor.

[Andreas]

Yes, this is what the error tells me, but is there any reason behind
this? In the documentation i couldn't find any hint, why this should be
a bad idea.

Also i did not set this explicitly, but shlib_directory by default will
be /usr/lib/postfix if compiled with shared=yes

On many systems (Debian, Arch, and probably more) daemon_directory is
/usr/lib/postfix as well, which will lead to a broken multi-instance
capability by default.

Hopefully i just missed some important point.

Andreas

Am 2/18/2015 um 01:32 schrieb Wietse Venema:
> Andreas:
>> Hi,
>>
>> i installed the new postfix-3.0.0 in my arch system, however by default
>> (default main.cf <http://main.cf>) postmulti results in a fatal error
>> for a reason (conflict) i don't understand:
>>

>>> # postmulti -l
>>> postmulti: fatal: instance /etc/postfix,
>>> shlib_directory=/usr/lib/postfix conflicts with instance /etc/postfix,
>>> daemon_directory=/usr/lib/postfix
> DO NOT set daemon_directory the same as shlib_directory.
>

> Wietse

[Viktor Dukhovni]

On Wed, Feb 18, 2015 at 02:11:34AM +0100, Andreas wrote:

> On many systems (Debian, Arch, and probably more) daemon_directory is
> /usr/lib/postfix as well, which will lead to a broken multi-instance
> capability by default.

Note that on BSD systems daemon_directory is /usr/libexec, and
Linux FHS 3.0 (will it ever be out of beta?) appears slated to
introduce /usr/libexec (and Redhat seems to already be using it):

http://www.linuxbase.org/betaspecs/fhs/fhs/ch04s07.html

I'd like to encourage distributions to start using /usr/libexec/postfix
rather than /usr/lib/postfix for daemon_directory, and then use
/usr/lib/postfix for the shared libraries.

--
Viktor.

[Andreas]

Dear Viktor,

sorry, i got your mail quite delayed...

i can confirm this patch working, thank you!

> IIRC the main reason for the conflict detection in question is to
> avoid use of the shared directories also as per-instance directories.

Which is a very good idea and prevents many configuration errors.

> Use of the same pathname for two shared directories should also be
> avoided (thus solving your immediate problem).

It solves my problem, but i cannot see a technical reason why they
cannot have the same shared directories.

> Since Linux systems seem to lack a /usr/libexec, you can use:
>
> daemon_directory = /usr/lib/postfix
> shlib_directory = /usr/lib/postfix/lib
>
> This is something the distribution maintainers will have to figure
> out. If you are a distribution maintainer, please DO NOT apply
> the above patch unless it is first adopted upstream.

Since, as you said, some distributions lack /usr/libexec, wouldn't it be
a better idea to leave it up to the package/distribution maintainers to
separate shared objects from shared executables?

Andreas

[Wietse Venema]

Andreas:

> Since, as you said, some distributions lack /usr/libexec, wouldn't
> it be a better idea to leave it up to the package/distribution
> maintainers to separate shared objects from shared executables?

That is not how Postfix works. With Postfix, things are forbidden
unless explicitly permitted. Sharing directories is no exception.
I encourage Linux maintainers to take advantage of the 20+ years
old idea to separate library files from program files.

Wietse

[Viktor Dukhovni]

On Wed, Feb 18, 2015 at 11:16:19AM +0100, Andreas wrote:

> > This is something the distribution maintainers will have to figure
> > out. If you are a distribution maintainer, please DO NOT apply
> > the above patch unless it is first adopted upstream.
>

> Since, as you said, some distributions lack /usr/libexec, wouldn't it be
> a better idea to leave it up to the package/distribution maintainers to
> separate shared objects from shared executables?

As Redhat and others have discovered, on multi-arch systems multiple
executables of various ABIs can be deployed in a single directory,
but object libraries need to be segregated by ABI.

This extends to "off-path" executabes that are only executed by
other programs, but are not intended to be used directly by users.
This is what /usr/libexec is for, and it is starting to be used
in Linux systems.

The upstream Postfix release defaults to

daemon_directory = /usr/libexec/postfix

on all but one system type (GNU0 Debian whatever that is),
and even that one should probably be changed to /usr/libexec.

With 3.0.0 Linux distributions should start using the upstream
default. This does mean that users should remove explicit legacy
default settings of daemon_directory from their main.cf files.

Distribution package upgrades will need to update or drop obsolete
daemon_directory settings from all installed Postfix instances.

--
Viktor.

[Wietse Venema]

Viktor Dukhovni:

> The upstream Postfix release defaults to
>
> daemon_directory = /usr/libexec/postfix
>
> on all but one system type (GNU0 Debian whatever that is),
> and even that one should probably be changed to /usr/libexec.

Postfix should have its own libexec subdirectory. Unlike commands
that are named postfoo and postbar because they share storage with
other commands, no such attempt is made with programs that are meant
to be installed in a Postfix-only directory.

Wietse

[Andreas]

Am 2/18/2015 um 18:39 schrieb Viktor Dukhovni:
> With 3.0.0 Linux distributions should start using the upstream
> default. This does mean that users should remove explicit legacy
> default settings of daemon_directory from their main.cf files.
> Distribution package upgrades will need to update or drop obsolete
> daemon_directory settings from all installed Postfix instances.

Is this a suggestion or restriction? If it is a suggestion, then both
ways should be possible.

But as i understood Witse correctly, having postfix executables and libs
share a directory is explicitly forbidden (and forcing every linux
distribution out there to follow an FHS *draft*). Accepted (maybe
mention in docs). Then you should at least be consistent and enforce
this restriction in the master process as well.

[li...@rhsoft.net]

FHS draft or not - look when the last update of FHS was
it also don't contain /run present on 99% of recent linux setups

[Wietse Venema]

Andreas:
> Am 2/18/2015 um 18:39 schrieb Viktor Dukhovni:
> > With 3.0.0 Linux distributions should start using the upstream
> > default. This does mean that users should remove explicit legacy
> > default settings of daemon_directory from their main.cf files.
> > Distribution package upgrades will need to update or drop obsolete
> > daemon_directory settings from all installed Postfix instances.
> Is this a suggestion or restriction? If it is a suggestion, then both
> ways should be possible.
>
> But as i understood Witse correctly, having postfix executables and libs
> share a directory is explicitly forbidden (and forcing every linux

That is subject to revision (I prefer to play safe and permit only
stuff that has a reason to be permitted). I just did not expect
that one would actually want to mix programs and object libraries.

Postfix is a cross-platform program. That is one reason to have
configurable pathnames, because every platform seems to have things
in different places.

Wietse