Help build the new GNHLUG Internet server

[Bruce Dawson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I should point out that time is of the essence. The drop-dead date for
the new server is early March, so between now and then, we have to:

1. Get a distro loaded onto the new server.
2. Get all existing data and programs from the old server to the new server.
3. Test and hope nothing breaks.
4. Deploy.

Each of those steps has to take, at maximum, a few days.

This is being done with volunteer worker(s) with unspecified available time.

I don't think it is advisable to switch to a new mailing list manager at
this point in time - maybe later, but not now. (To add a new mailing
list manager, we would have to add a step 2.5 - Migrate existing data to
new application).

This is the appropriate forum to discuss the pros and cons of mailman vs
majordomo2. This is *not* the appropriate forum to discuss which one
GNHLUG should be using - that discussion belongs in gnhlug-sysadmin.

Sorry for the terse and direct nature of this message, but "I'm busy"
with other things at the moment. I just want to get/set things straight
before we dive into another mis-understood flame war for which we have
little mental bandwidth.

- --Bruce

Steven W. Orr wrote:
> On Friday, Feb 10th 2006 at 10:02 -0500, quoth Jeff Kinz:
> 
> =>On Fri, Feb 10, 2006 at 09:36:03AM -0500, Steven W. Orr wrote:
> =>> May I strongly urge you to not use Mailman and to instead consider 
> =>> Majordomo2 (see: http://www.mj2.org) 
> =>> 
> =>Steve, could you give up some more info about why Majordomo2 is a better 
> =>maillist manager?
> =>
> =>Are there certain features we would want to use, or is it efficient in
> =>terms of machine resources, or more secure, or more spamproof?
> 
> On Friday, Feb 10th 2006 at 10:29 -0500, quoth Bill McGonigle:
> 
> =>On Feb 10, 2006, at 09:36, Steven W. Orr wrote:
> =>
> =>> It is a better mailinglist manager.
> =>
> =>Fill in here the ways mailman is insufficient for our use or things that
> =>Majordomo would let us do that we can't.
> =>
> =>> It suffers from not getting enough use
> =>> compared to what Mailman was able to achieve with Red Hat having been the
> =>> promoter.
> =>
> =>I remember when Mailman was new and we all jumped at the chance to get away
> =>from majordomo.  That's why Redhat included it.  I was just debugging a
> =>Majordomo setup for a client last week and bemoaned that they weren't on
> =>mailman, which I've found much easier to setup and customize.  For their setup
> =>Majordomo didn't offer any benefits, but maybe they exist for other
> =>requirements.
> =>
> =>> I use it here on syslang for the dozen odd lists I run. My
> =>> biggest list is about 800 people and it works really well.
> =>
> =>FYI, mailman scales to about 10K per list.  After that 'python pickles' get in
> =>the way and it falls apart.  I've done some research lately for a client with
> =>a 120K customer mailing list and the solution seems to be to use the mysql
> =>backend to avoid python pickles.   You can also chain 'umbrella lists' but
> =>that's somewhat of a hack.  Mailman 3 is also listed as a solution but that
> =>appears to be vapor, currently aimed at being a Zope personality.  My
> =>goodness.
> 
> Good questions. Also very hard to answer. Picking list software is very 
> hard because to do it correctly you have to become somewhat expert in all 
> of the candidates.
> 
> If the goal is to build a new server with the least amount of work then by 
> all means, you should stick with what you know. If you'd like to learn a 
> few tricks then you might want to consider this.
> 
> The entire structure of mj2 configuration is object oriented. The specific 
> configuration of a list is simply an instantiation of characteristics that 
> are inherited. There is a GLOBAL conf as well as a highly flexible DEFAULT 
> conf. Yes, it's called Majordomo with a 2 at the end but it is not related 
> to the old Majordomo which has not seen any development in well over a 
> decade. It does have a good web interface built in and it is very secure 
> as most lists are. The number of parameters that are available for 
> tweaking by the sysadmin is extremely rich. Very fine controls for things 
> like bounce management, spam control, moderation, digests, headers, 
> footers, and I could go on for hours.
> 
> Here's an example that some might find sexy:
> 
> The goal (for me) is to end up with a list that does not allow 
> attachments. That way people are guaranteed to not get a virus in the 
> mail.
> 
> configshow frambors config_defaults <<ENDAAQ
> plaintext
> rfc2369
> ENDAAQ
> 
> What is plaintext you ask? The snip below defines the attachment_filters 
> value for the DEFAULT:plaintext instance.
> 
> configset DEFAULT:plaintext attachment_filters <<ENDAAC
> text/plain | allow
> /./ | discard
> text/html | format
> text/enriched | format
> ENDAAC
> 
> configset frambors attachment_rules <<ENDAAL
> text/plain | require
> ENDAAL
> 
> configset frambors comments <<ENDAAO
> The plaintext template defines attachment_filters (which transform
> messages)
> and attachment_rules (which determine whether messages should be sent,
> forwarded to the list-owner for consultation, or rejected).
> 
> The attachment_filters in this template are as follows:
> 
>         text/plain | allow
>         /./ | discard
>         text/html | format
>         text/enriched | format
> 
> ...which, in order, mean:
> 
> 1) If there is a plaintext part, pass it through as-is.
> 2) Take all parts and discard them.  Discards only happen if there are
>    no other parts, so a message that contains only text/html or
> text/enriched
>    will not be discarded by this part.  (Neither will any sort of
> non-text
>    part that is the only part; that will be handled by the
> attachment_rules.
> 3) If there's an HTML part, render it to plain text.
> 4) Similarly with an enriched text part.
> 
> Then the attachment_rules are applied:
> 
>         text/plain | require
> 
> That is, if a message doesn't have a text/plain section (either by
> starting out
> with one, or by having HTML or enriched text rendered to plaintext),
> kick the
> message out for consultation.
> 
> ENDAAO
> 
> So just by adding the plaintext attr to the config_defaults configuration 
> setting, it is done.
> 
> :-)
> _______________________________________________
> gnhlug-discuss mailing list
> gnhlug-discuss at mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD7MQQ/TBScWXa5IgRAirOAJ0S/wH4kDEIBdn/avQOyC5MgpJFGACfQ+ck
tPFHXyW5rqsd5PlTyTqtbnk=
=dpoC
-----END PGP SIGNATURE-----