Installing Mailman To Use HTTPS On CentOS 5.1

March 30th, 2008 by Dave · 3 Comments

In starting up my new Python web-app project that I’ve blogged a bit about, I realized that I needed to setup a mailing list or two in order to keep the few people working on it all on the same page. Besides just having a list for development discussions among a distributed group of people, it is very handy to have SVN send out e-mail notices to everyone about commits. I could have used something like Majordomo or ezmim, but I like the features of Mailman – primarily the ability for users to subscribe, unsubscribe, etc. via a web page as well as through e-mail. I could have also just used an alias in the MTA config, but that doesn’t allow new developers to sign up on their own.

The following documents my notes along the way to installing and configuring Mailman on a CentOS 5.1 box such that its web pages are accessible only through https. It is important to note that I’m talking about an installation from scratch here. If you’re upgrading a previous installation from either an older mailman, or an older version of CentOS, then the following is NOT for you.

  1. As I had hoped, the CentOS base repo provides an RPM for the latest release of Mailman which, according to the GNU webpage for Mailman is version 2.1.9. You can install this as:
    $ sudo yum install mailman-2.1.9-2

    If you read the description of this package, you’ll see that it installs a special install instructions file into /usr/share/doc/mailman-2.1.9/INSTALL.REDHAT. You might want to read this yourself, but basically, it leads you through the following steps if you’re running your MTA (i.e. mailserver) on the same host as your web (httpd) server. You should note that the RedHat RPM does NOT install Mailman such that its configuration pages are accessible only through HTTPS. The following instructions include extra steps to make sure that this is true.

  2. Edit the newly installed file /etc/httpd/conf.d/mailman.conf to customize it for your host. In particular, edit the last line and replace the http://www.example.com with your own site’s hostname after an https:// prefix. It should end up looking something like this:
    RedirectMatch ^/mailman[/]*$ https://davmp.kimanddave.com/mailman/listinfo
  3. You’ll need to insert two RewriteRule lines in your httpd config files to redirect all non-https requests for Mailman features to the https site. And if you don’t have any rewrite features setup elsewhere, you’ll need a couple of other lines. You can find out the most about this process by reading the Apache docs for the RewriteEngine here. But, since I’ve already got a virtual host file that represents the config I want to have Mailman show up as a part of, I simply added lines like the following:
    <virtualhost _default_:80>
       ...
       RewriteEngine        on
       RewriteCond          %{HTTPS} !=on
       RewriteRule          ^/mailman/(.*) https://davmp.kimanddave.com/mailman/$1 [L,R]
       RewriteRule          ^/pipermail/(.*) https://davmp.kimanddave.com/pipermail/$1 [L,R]
    </virtualhost>
    
    <virtualhost *:443>
       ...
       Include "conf.d/mailman.conf.include"
    </virtualhost>

    And then renamed /etc/httpd/conf.d/mailman.conf to /etc/httpd/conf.d/mailman.conf.include. These settings prevent Apache from allowing these URLs to work for any other virtual hosts.

  4. Test your configuration changes by running
    $ apachectl -t

    This will print out <code>Ok</code> if everything is syntactically correct. Once you’ve fixed any issues, go ahead and restart the webserver via a command of:

    $ sudo /sbin/service httpd restart
  5. Create your site password for mailman by running
    $ sudo /usr/lib/mailman/bin/mmsitepass

    Contrary to the RedHat instructions, you do not need to type a password on the command line as you will be prompted for it. Clearly it is safer to type it at the prompt.

    Running this command sets the site password in to /etc/mailman/adm.pw so you do need to run it as sudo — don’t forget that the first password prompt will be for your sudo request if you haven’t run anything else sudo in a while. 🙂 This password will be accepted anywhere an individual user or mailman administrator password would be accepted, so make sure you’ll remember this in case you need to reset other passwords in your Mailman installation.

  6. (OPTIONAL) Setup the site-wide “list creator” role password by doing
    $ sudo /usr/lib/mailman/bin/mmsitepass -c

    This password can be given to those whom you want to have the ability to create and delete mailing lists through the web but without the risk of letting them change the mailman config itself.

  7. Edit /etc/mailman/mm_cfg.py. There is code in here to try and autodetect your domain names, but it’s probably safest to make it explicit. To do that, start with the line from socket import * and comment out (prepend with an #) all lines down to the one that sets the DEFAULT_MAIL_HOST variable. Then insert two lines to set up your explicit values. You should end up with something like this:
    #from socket import *
    #try:
    #    fqdn = getfqdn()
    #except:
    #    fqdn = 'mm_cfg_has_unknown_host_domains'
    #
    #DEFAULT_URL_HOST   = fqdn
    #DEFAULT_EMAIL_HOST = fqdn
    DEFAULT_URL_HOST   = "davmp.kimanddave.com"
    DEFAULT_EMAIL_HOST = "kimanddave.com"
  8. Ensure that Mailman renders its own URLs with the https scheme by appending the following line to the /etc/mailman/mm_cfg.py file.
    DEFAULT_URL_PATTERN = 'https://%s/mailman/'
  9. (ASIDE) If you had previous mailing lists configured, this is where you’d update Mailman’s files to use this new info by running
    $ sudo /usr/lib/mailman/bin/update

    but we can skip that since we’re a new install.

  10. Create the “site-wide” mailing list, also known as the one that Mailman password reminders come from. Usually this is called mailman but you can use any value you want as long as you set MAILMAN_SITE_LIST to the same value in /etc/mailman/mm_cfg.py. Let’s use this default and set this up by running
    $ sudo /usr/lib/mailman/bin/newlist mailman

    and then follow the prompts. Note that this MUST be done prior to starting up the Mailman daemon.

    Also note that this command will output a list of mail aliases after you answer a few prompts. Copy and paste these lines into your MTA’s aliases configuration. The simplest way to do that is to edit /etc/aliases (because most MTA’s respect the contents of that file) and append these lines to the end, then, after saving that file, run the newaliases command.

  11. It is now time to start the Mailman daemon! Do this with a command like:
    $ sudo /sbin/service mailman start

    Its important to note that the RedHat packagers do not ship RPMs that enable services as part of the installation, so you’ll need to enable the service as well if you want mailman to work after a reboot. You can do this with a command like:

    $ sudo /sbin/chkconfig --level 345 mailman on
  12. Add yourself to your new mailman mailing list. Do this by visiting your host’s mailman list info page at https://your.host.name/mailman, click the Mailman link at the bottom left, and use the resulting form to subscribe your e-mail address.
  13. If you want your mailing lists to be completely public, you’re done. You do NOT need to follow the remaining steps!
  14. If you want to limit who can access your mailing list web pages, then I recommend editing the /etc/httpd/conf.d/mailman.conf.include configuration file to put in lines to require authentication. Something like this would be a very basic authentication requirement, though you could also use LDAP, MySQL, etc. databases but setting those up are a whole separate topic.
    AuthType Basic
    AuthName "mysite"
    AuthUserFile /etc/httpd/auth/passwords
    AuthGroupFile /etc/httpd/auth/groups
    Require group mailman

    Of course, you’ll need to read up on using authentication files with Apache here.

→ 3 CommentsTags: IT/Network · Uncategorized

Ubuntu Install Frustration

March 21st, 2008 by Dave · 2 Comments

So, it didn’t take me long to try and install Ubuntu 7.10 to a new virtual machine and get a little annoyed.  I absolutely hate the fact that you can’t download a DVD of Ubuntu and instead are forced to download different CD ISOs for every possible combination of what you might want to install.   If I want to install a server, Ubuntu won’t let me install the i386 build on an amd64 class cpu.  Why not?!?  32bit software works fine on a 64bit cpu, right?  Likewise, if I have a problem installing a desktop edition via the GUI installer, I have to download a new ISO to install via a text mode installer.   Etc.

Why is it so hard to let me get a DVD that includes all the necessary packages for both i386/amd64, both text mode and GUI mode installers, etc.   What is Canonical thinking???

→ 2 CommentsTags: IT/Network

Ubuntu 7.10 FTW

March 21st, 2008 by Dave · No Comments

So, more than two weeks ago, I asked what linux distribution you would choose to host a Python web-app. The response has been overwhelmingly … nothing. I guess no one reads this blog who does any Python development, or perhaps just no one reads this blog? Nevertheless, I’ve made a decision of what I’ll be trying: Ubuntu.

The first reason I settled on Ubuntu is that it is clear lots of Python development happens on Ubuntu. Exhibit A to support this is my own experiences of the past week. I just got back from PyCon 2008 in Chicago where my employer had a vendor booth where I, and my co-workers, were handing out Python distribution CD’s for Windows and RHEL. More than half the people we tried to give a CD to replied that the CD would be a coaster for them as they didn’t run either of those OSes. Approximately half of *those* people said they run Ubuntu (and the other half said Mac OSX.) This mass of Python users on Ubuntu should make it easy to find help online for any problems I run into.

Another reason is that my use of Distrowatch’s search capability shows that Ubuntu is one of the only major distributions that includes Python 2.5.1 in a fully released version. Fedora 8 and OpenSUSE 10.3 also do, but not a single person I ran into at PyCon said they used OpenSUSE, and only a few use (or worked for) Fedora. And while I have experience with a RedHat environment like Fedora, I have absolutely none with OpenSUSE. However, I have probably as much experience running Ubuntu as a result of my day job as I do with using Fedora, so at best Ubuntu and Fedora are tied on this point.

The last reason is that the Ubuntu Server installation claims to provide an installation option that automatically configures a LAMP (Linux, Apache, MySQL, and PHP) stack. Ubuntu claims this saves a significant amount of configuration work that would otherwise be needed to tie this stack together. I have no idea how much it really helps, nor how easy it will be to replace the PHP part with Python, but perhaps it will help somewhat.

→ No CommentsTags: Development · IT/Network

VMware Server 2.0 Thoughts

March 11th, 2008 by Dave · 2 Comments

Like many other developers, I end up using virtual machines quite a bit to test features of the software I’m working on across a number of different OSes (and also for a myriad of other reasons.) Given my experiences so far, I prefer to use VMware’s free Server and Player products due to the portability of the guest VM. Anyway, because of this, I thought it was time to try out the free beta of VMware Server 2.0. Here is a summary of some of my experiences.

  • The first thing you should know, even before you install, is that VMware has dropped the server console desktop application in favor of a web browser plugin that enables something similar. While a great idea, since it means you could access or administer your VMs from a remote machine without having to locate and install the server console software, the implementation so far leaves a little bit to be desired. For me, the biggest problem was that the browser plugin was not yet available for either Firefox or Safari on OS X so I could not connect to the console from my notebook. So I was reduced to accessing the console from the machine I was running the server on anyway (an Ubuntu 7.10 install btw.) In which case, there isn’t a large benefit to having access via a web browser.In fact, the requirement to use a browser is a detriment because Firefox prevents a user from running multiple sessions simultaneously. This means that I have to always remember to shutdown Firefox before I go home in case I’ll need to access the VMware Server configuration via a VNC session from home. Yes, I could remotely shutdown Firefox from my VNC session but then I can’t see whether any of the tabs contain critical information I’ll need when I get back to the office. And yes, I could install / setup VNC so I connect to the :0 display and thus see the machine console from home, but that isn’t the default on any Linux distribution I’ve come across so you always have to remember to set it up. It was just much easier when I could invoke the ‘vmware’ command and start up a new server console as many times as I wanted.
  • If installing on Ubuntu 7.10, you MUST turn off IPv6 before installing. (This might be necessary on other host OSes as well.) You can find instructions on how to do this for Ubuntu 7.10 here. This needs to be done as the web app console is actually a couple apps that communicate amongst themselves and they have trouble if IPv6 is enabled. Note that you have to do this prior to installation as the install process will silently fail if these apps can’t connect to each other during installation. I’ve turned up no help instructions that say how you can recover an install after the fact.
  • One of the new things I love about the new console is that the summary information for a running VM now includes the IP address of the VM’s network interface. This is a godsend for direct remote connection as it no longer means you have to login just to get the ip address to do an ssh, rdesktop, or vncviewer connection to the VM. Whoever thought up the idea of providing that bit of information is my hero!
  • The web browser plugin is still pretty unstable. I can’t go more than an hour or so of interaction time with it (that means 5 or 10 mins at a time spread out over one or more work days) before it segfaults the browser. Unfortunately, I get no useful error messages that I can forward to VMware so I’m not sure how to help them get over this hurdle. As a result of frustration with this browser plugin, I installed the old 1.0.4 server console app (yes, you can download it individually and install it) but it refuses to connect with the VMware server instance no matter what I try (localhost, remotehost with machine’s IP and with or without an explicit specification of the port, remotehost but use a server name of localhost, etc.) I’ve given up on getting that combination to work after not finding any assistance on the VMware server beta forums.

Because of that last bullet, I’ve uninstalled Server 2.0 beta and gone back to Server 1.0.4 for now. Perhaps when the next build comes out, I’ll give it another try.

→ 2 CommentsTags: Development · IT/Network