Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 2 subscribers
  • Views 7003 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

PureMessage for UNIX: HistorianDB questions

WolfgangK

We're preparing the update to PMX 6.4 (currently at 6.3.3). We do have multiple MTAs running PMX as well as a Centralized Server Manager running the quarantine database.

If I understood correctly, a Redis database is used for the new Delay Queue feature. And Redis only must exist once for the environment to actually make sense.

 

But while the quarantine DB isn't necessary for the frontends to filter spam properly, Redis would have an impact to my understanding. So Redis cluster it is... Is there an recommended way? Is such an setup even supported? Or am I following the wrong path?



This thread was automatically locked due to age.
  • 0

    Hi Wolfgang,

     

    The redis db is its own db that should (ideally) be separate from the CSM/Spam DB.  Normally in a multi edge scenario you would have (edge severs) (1 csm) and (1 redis) server.   the edge servers report spam and gather config to/from the csm and only the edge servers report to the redis db. 

     

    at a very high level the feature works like this:

    The redis server is used to collect MTA information that the edge servers report to it.  This in turn allows you to create additional logic in your policy.siv file that gives the edge server the ability to query the DB for more information about the MTA .. for example, has ip this ip ever connected to me? has it relayed mail before? if so how much and was it legitimate or spam. 

     

    Under the hood it allows the labs team to create additional detection rules that specifically target snowshoe spam.

     

    I would recommend that you install the redis DB and configure the /opt/pmx6/etc/delay.conf on the edge servers to point to its ip.. leave it set to collect.  This will accept mta information from the edge servers but not enable the delay feature.  (the feature must remain in collect for a minimum of 10.5 days before you can enable it).  The longer its set to collect, the better the feature will work.  So if it takes a month or two to poc and get rolling, your all ready to go from the start

     

    the documentation can be found here: https://community.sophos.com/kb/en-us/127126 

  • 0 in reply to Red_Warrior

    Thanks for the clarification.

    The thing is, when the central redis DB dies, the edge servers may have a problem, as far as I understood. So I was thinking to install the redis with high availability. But I'm not sure this actually works with the setup routines and versions provided by Sophos via the installer script. Is there a way recommended by Sophos?

    Or is this exaggerated and the availability of redis doesn't have a significant impact to the availability of the delay feature?

  • 0 in reply to WolfgangK

    In regard to automatic fail-over.. pmx would not understand a fall over.. It would just use what ever is in your /opt/pmx/etc/delay.conf file.. 

     

    but if you really wanted to:

    create a new delay.conf for puppet (or similar)

    append the new ip address.

    push it out

    restart the pmx delay services as pmx6 user

     

     

     

    in theory that should work fine.

  • 0 in reply to Red_Warrior

    This would be a manual failover. Not exactly what we need. We have users served via our mail gateways from US West Coast to Australia. There's exactly not a single minute the whole year, we don't receive mails. But this system is managed by a single team in Germany (me) and as I really enjoy my sleep at night we need something more stable than a single point of failure. Luckily Redis can be clustered by itself - even behind a LoadBalancer with TCP session termination for even faster failover.

    I only wanted to know, if there are specific version dependencies towards Redis from PMX and/or if there are already best practices/recommended ways/experiences in setting up an environment without single point of failure.

  • 0 in reply to WolfgangK

    Not as far as i am aware the get/put queries are quite simple.. as long as the request is served and the schema is the same you shouldnt have any issues replicating , dumping or rebuilding from scratch any db.

    I have not specifically tested it but i dont see why it would not work with any recent version.. pmx does not care, its just a db to it

Unfiltered HTML