Re: postmulti and vip with corosync/pacemaker
- 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.
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
>> 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:
> # Presumed VIP
> inet_interfaces = 192.0.2.1
> not being a local address. The solution for floating VIPs is:
> # IP addresses set in master.cf
> inet_interfaces = all
> 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
>> 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).