« Eating our own dogfood | Main | small world... »
January 07, 2005
some more alias migration fun
For a couple of reasons(speeding up migration time, testing out some enhanced spam control facilities for mailing lists), we migrated another alias from the master alias file to Sympa. The process was similar to what was done the other day, though this was a "simple" alias, rather than an Admin Alias. The procedure is now down to about six minutes (a couple of which were spent tracking down the appropriate crontab entries to run by hand).
For some extra background, here are some of the different kinds of things we have lurking in our master alias file:
- simple aliases - this is just as it sounds, a run-of-the-mill everyday sendmail alias. alias: address
- Administrative aliases - these are the kinds of aliases you create here. At present, when you fill out that form, it actually sends an e-mail to our Network ID office, who then create the alias largely by hand - they enter the names into a text file on our list-server system, and run a script which puts the text file into place, and creates an entry in the master alias file pointing to the file looking a bit like this:
foobar-annc-list: :include:/fs1/mail/lib/foobar-annc-list
There may also be some additional aliases which go with these, which have a similar function to majordomo's owner aliases. Admin aliases are good for situations where you want a departmental alias, but don't want to tie it to a specific user via a Personal Alias They don't have the moderation capabilities of a Majordomo list, and they can only be modified by the Network ID office or Postmaster.
- Majordomo lists - These are the lists that you create here. Similar to admin aliases, submitting that form sends an e-mail to the network ID people, who create the subscriber files and run the script to create the pertinent entries in the master alias file. This creates the list itself (which uses program delivery to call the majordomo process), request, and owner aliases. In general Majordomo lists are pretty flexible, but difficult to manage (since changes to list configuration have to either be done via e-mail or by pestering the Majordomo administrator to do it for you) They've also proven somewhat unwieldy due to changes in the primary e-mail address we use here - mailing lists using a subscriber-post-only policy get really confused by Webmail users whose primary e-mail address has changed. This was made worse by the workaround we attempted to deal with @po.cwru.edu/@cwru.edu addresses a while back.
- archive aliases - some internal aliases wanted archiving capabilities - we accomplished this by setting up program delivery to deliver the message to a file.
Note that Personal Aliases aren't part of this. When they were initially deployed, they were stored in the Master Alias file, but those have now been migrated to LDAP.
We eventually plan to migrate most of the aliases listed above to Sympa, though that's probably going to be a somewhat long and drawn out process. I suspect that admin aliases may actually be the hardest, since ownership of the aliases isn't as strongly defined as majordomo lists (most admin aliases are actually "owned" by our Network ID people).
Posted by sdh7 at January 7, 2005 01:57 PM
Trackback Pings
TrackBack URL for this entry:
http://blog.case.edu/sdh7/mt-tb.cgi/104
Comments
I wonder how accurate some of those majordomo list owner entries are...
Posted by: jms18 at January 7, 2005 04:30 PM