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

postmulti and vip with corosync/pacemaker

Expand Messages
  • Olivier Brousselle
    Hello, I m trying to install failover multi instances of postfix on a 2 machines Centos 6, with postfix 2.6, corosync and pacemaker and use of virtual IP. No
    Message 1 of 3 , Jan 18, 2013
      Hello,

      I'm trying to install failover multi instances of postfix on a 2
      machines Centos 6, with postfix 2.6, corosync and pacemaker and use of
      virtual IP.
      No SElinux enable.

      Each instance use a virtual IP, and each virtual IP comes from
      pacemaker. So only one machine have vip.
      In my configuration, 192.168.1.100 is the virtual ip for the instance
      postfix-mta (vip-mta.mydomain.fr).
      and the result of postconf :

      ############## /etc/postfix/main.cf
      alias_database =
      alias_maps =
      config_directory = /etc/postfix
      inet_interfaces = loopback-only
      inet_protocols = ipv4
      local_recipient_maps =
      local_transport = error:5.1.1 Mailbox unavailable
      master_service_disable = inet
      multi_instance_directories = /etc/postfix-mta
      multi_instance_enable = yes
      multi_instance_wrapper = ${command_directory}/postmulti -p --
      mydestination =
      mydomain = mydomain.fr
      myhostname = vm-test-postmulti.mydomain.fr
      mynetworks = 127.0.0.1
      myorigin = $mydomain
      relayhost = [smtp.mydomain.fr]
      transport_maps = hash:/etc/postfix/transport

      ############## /etc/postfix-mta/main.cf
      alias_database = hash:/etc/aliases
      alias_maps = hash:/etc/aliases
      authorized_submit_users =
      config_directory = /etc/postfix-mta
      data_directory = /var/lib/postfix-mta
      debug_peer_level = 2
      default_destination_concurrency_limit = 20
      default_destination_recipient_limit = 200
      inet_interfaces = 192.168.1.100
      inet_protocols = ipv4
      master_service_disable =
      multi_instance_enable = no
      multi_instance_group = mta
      multi_instance_name = postfix-mta
      mydestination = $myhostname, localhost.$mydomain, localhost
      mydomain = mydomain.fr
      myhostname = vip-mta.mydomain.fr
      mynetworks = 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24,
      192.168.4.0/24, 192.168.5.0/24
      mynetworks_style = host
      queue_directory = /var/spool/postfix-mta
      smtpd_banner = $myhostname - Serveur MTA
      smtpd_client_restrictions = check_client_access
      hash:/etc/postfix-mta/client_access
      transport_maps = hash:/etc/postfix-mta/transportList,
      ldap:/etc/postfix-mta/ldap-transport-1.cf,
      ldap:/etc/postfix-mta/ldap-transport-2.cf
      unknown_local_recipient_reject_code = 450
      virtual_alias_maps = hash:/etc/postfix-mta/virtual,
      ldap:/etc/postfix-mta/ldap-reecriture-listes.cf


      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.

      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 normal because the vip is not up, but my instance postfix-mta is
      disabled.

      Is there a way to configure all my instances with virtual ip, and when
      starting postfix just start primary instance without failed message ?
      The other instances will be started with pacemaker after starting vip on
      one machine.

      Thanks in advance...

      --
      Olivier Brousselle
      Rectorat de Rouen - DSI - Equipe Infrastructures
    • 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 2 of 3 , Jan 18, 2013
        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 3 of 3 , Jan 28, 2013
          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.