Loading ...
Sorry, an error occurred while loading the content.

Re: postmulti and vip with corosync/pacemaker

Expand Messages
  • Viktor Dukhovni
    ... 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
    Message 1 of 3 , Jan 18, 2013
    • 0 Attachment
      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).

      --
      Viktor.
    • Olivier Brousselle
      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
      Message 2 of 3 , Jan 28, 2013
      • 0 Attachment
        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).
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.