Thanks for the reply,
So, I can just use postmulti to create instances and then detach them
with postmulti -i instance -e deport.
And finally modify init script to start instances with postfix -c
/directory/of/instance instead of postmulti -i instance -p start.
Greetings
--
Olivier
Le 18/01/2013 20:23, Viktor Dukhovni a écrit :
On Fri, Jan 18, 2013 at 09:57:37AM +0100, Olivier Brousselle wrote:
Each instance is marked as disable, there is a script to activate
instances (postmulti -i postfix-mta -e enable ; postmulti -i
postfix-mta -e start) for using with pacemaker.
That is:
# Turn it on for postmulti start
postmulti -i postfix-mta -e enable
# Start it.
postmulti -i postfix-mta -p start
Another option is to never explicitly enable such instances, and
start them via "postfix -c /etc/postfix-mta start", (only when the
host is primary for the VIP). This way when the machine boots normal
system Postfix start does not enable the VIP instance, instead
you have separate start/stop code for that managed by the cluster
state.
The problem is when i use postfix start. The default instance start
without any problem, but postfix reports "fatal: parameter
inet_interfaces: no local interface found for 192.168.1.100", and
the init script is marked as failed...
This is because "postconf" is unable to process the instance settings
due to:
main.cf:
# Presumed VIP
inet_interfaces = 192.0.2.1
not being a local address. The solution for floating VIPs is:
main.cf:
# IP addresses set in master.cf
inet_interfaces = all
master.cf:
192.0.2.1:smtp inet n - n - - smtpd
...
This way:
- The instance is still able to drain its queue if storage is
not shared via SAN (and unavailable when a slave).
- The postconf command does not fail when parsing the instance
parameters.
Is there a way to configure all my instances with virtual ip, and
when starting postfix just start primary instance without failed
message ?
To avoid running "postfix check" on disabled instances, don't list
them as slaves in the default Postfix configuration. You can remove
them from the default instance list after you set them up, or just
manage them without "postmulti".
The "postmulti" command is designed for static multi-instance
configurations, where more than one Postfix instance starts via a
boiler-plate system start-script that need not be aware of instances.
Your dynamic cluster setup may be better off with "ships in the night"
instances, built by hand, and started explicitly via postfix(1) rather
than postmulti(1).
