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

memcached questions

Expand Messages
  • Jon A.
    Since memcache use is relatively new, I ve found fewer examples of implementation. I ve read the postfix man and doc pages, and searched the mailing list and
    Message 1 of 3 , Jan 20, 2013
    • 0 Attachment
      Since memcache use is relatively new, I've found fewer examples of implementation.  I've read the postfix man and doc pages, and searched the mailing list and looked at others configurations on the web to compile this email -- partially to answer some questions/correct my mistakes, and partially because it may be helpful for somebody else to see what I've found.

      It appears that memcache may only be used for dynamic content (write) for
      - postscreen whitelist cache 
      - address verification cache 
      - TLS session key cache 

      For read only tables, there are many others that populate during startup but don't change.  Haven't found an extensive list of these, but my assumption most tables would work.  Could I suggest a doc addition that lists the approved list, or states all except X will work?

      My assumption is that a second box started that uses the read-only table will change the content in some manner to match it's own configuration if pointed to the same location.  Unfortunately I haven't been able to test this, so I'm curious what the behavior will be.  My thoughts are either we'd either end up with merged memcache entries from new & old configurations across a single box postfix restart, or a combination of entries from two server instances that use the same memcache instance.  If old values aren't flushed on a "start", should a recommendation to restart memcache to clear old values be included?  [Again, apologies on not testing all this, I will once I can set up a test bed]

      To play it safe, it seems wise to include the key_format option to isolate the tables from the initial table implementation... this prevents issues should I wish to start using memcache for an additional maps.  The most popular instance I've seen thus far is for postscreen, so I've used:

      Postscreen.cf:
      key_format = postscreen:%s
      backup = proxy:btree:/var/lib/postfix/postscreen_cache

      On the read-write tables, i have a question with cleanup and perhaps a potential enhancement request to the "last cleaned" memcache data:
      The note 1 on the memcache_table man page indicates automatic cache cleaning should be disabled but for one host.  Other than the hit on memcached to have more than one doing the cleanup, is there any harm in letting other hosts do the cleanup?

      I use svn checked out trees for my mailserver configuration on otherwise identically configured boxes and with no include file ability that would allow me to symlink local specifics in, or a "make" configuration scenario, I can't see how I'd shut it off for just one box with my static config.  As this would be the only parameter I've found to date that would require me to maintain different configurations, perhaps the "responsible" cleaner could write it's ID (for the case of multiple processes being on the same host, the hostname isn't sufficient) to the table and others not start if the "cleanup role" was already active and owned by another server instance?

      Alternatively, but not appealing to me, perhaps I start a postfix instance for localhost only on the memcached box just for cleanup?  How are others dealing with this?

      Next:
      Is there any benefit other than perhaps performance for TLS session keys to be in memcache?  I'd think that this data couldn't be shared as each host would have to have its own values.  As such, if I did want to store this, the key_format should have a machine-unique name.

      TLS.cf:
      key_format = machine1TLS:%s
      backup = proxy:btree:/var/lib/postfix/TLS_cache

      Also, when using backup, it's really important to be sure to remember to add the backup value to proxy_write_maps and proxy_read_maps in main.cf.  It's documented but I have seen many miss this, and I did at first too.

      proxy_write_maps = $smtp_sasl_auth_cache_name $lmtp_sasl_auth_cache_name $address_verify_map $postscreen_cache_map proxy:btree:/var/lib/postfix/postscreen_cache

      Thanks for any input/feedback on this somewhat theoretical email.

    • Wietse Venema
      ... You can use a Postfix memcache table for all Postfix tables (read-only or read-write) except where Postfix documentation says otherwise (primarily, you
      Message 2 of 3 , Jan 20, 2013
      • 0 Attachment
        Jon A.:
        > Since memcache use is relatively new, I've found fewer examples of
        > implementation. I've read the postfix man and doc pages, and searched the
        > mailing list and looked at others configurations on the web to compile this
        > email -- partially to answer some questions/correct my mistakes, and
        > partially because it may be helpful for somebody else to see what I've
        > found.
        >
        > It appears that memcache may only be used for dynamic content (write) for
        > - postscreen whitelist cache
        > - address verification cache
        > - TLS session key cache

        You can use a Postfix memcache table for all Postfix tables (read-only
        or read-write) except where Postfix documentation says otherwise
        (primarily, you can't use it for security-sensitive information).

        A Postfix memcache table implements a volatile cache. If you configure
        it with a "backup" database, then all information in the cache is
        a copy of information in the backup database.

        And of course you can't use memcached in read-write mode when the
        backup database is read-only. That would violate cache consistency.

        Wietse
      • Viktor Dukhovni
        ... I would not use memcache for TLS session state. This is pointless unless your servers are behind a load balancer, and also unnecessary if the sending
        Message 3 of 3 , Jan 20, 2013
        • 0 Attachment
          On Sun, Jan 20, 2013 at 05:17:19PM -0500, Jon A. wrote:

          > It appears that memcache may only be used for dynamic content (write) for
          >
          > - postscreen whitelist cache
          > - address verification cache
          > - TLS session key cache

          I would not use memcache for TLS session state. This is pointless
          unless your servers are behind a load balancer, and also unnecessary
          if the sending system uses the Postfix SMTP client's algorithm to
          distinguish between multiple MTAs sharing a common TCP service
          endpoint (perhaps by now Postfix is not the only MTA able to do this).

          Regardless you need to hide the memcache TCP endpoint behind a
          firewall to prevent unauthorized access by anything other than
          the intended Postfix processes.

          Better yet, use a proxy that does mutual authentication and
          uses unix-domain sockets on both ends (and an authenticated
          TCP stream in the middle).

          --
          Viktor.
        Your message has been successfully submitted and would be delivered to recipients shortly.