Thanks, Paul, have a beer on me...........it's nice to know that I'm not just some street corner crank, but that the situation really IS stupid, SO unfortunate. Features are nice, front ends are nice, blart and bonkus death rays are soooooooooooooo hot....butbutbutbut, you development elvenfolk didja never think that a major element of the adaption of your cathedral of code is system management and upgrade?????...that if it's too much of a Chaley Foxtrot in that respect, no one will want to dance with you?????

A lot of this freeware just stuns me. One application like Mailman is bad enough, but add in Apache and python and manymanyfiles and you just have to have a combinatorial explosion of phase-of-the-moon gotchas when you try to upgrade....<just get the new tarball and untar/drop it on top the production version> Uh-huh, and when smoke comes out the side, /then/ what?
We usta have a super-geek who would whump up these magical application suites that knocked the socks of the management, gottahaveit!!!, and then throw it over the wall to me to maintain and upgrade without any documentation. Now you have 3000 people using and loving it and wanting it up every second (a college runs 25x8x357) and along comes a honking security exposure. Should I defecate or go blind???
The magic word is PRODUCTION. Honestly, without Perfect Knowledge (TMk) how could you?
I mean, the only halfway air tight, non-omniscient, production-tolerable way to do it is to have two machines that leapfrog each other.....
Sheesh. Stop Making New Function And Make/use A GNU Packaging Setup That Allows SysAdmins to Upgrade, Patch, Backout (whatta concept!) and GNU APPS 'MARKET SHARE' WILL GO UP BY 50%, 200%, who knows? You will be so proud of yourself!


sorry. So much promise. Gorgeous babe of an application, but /so/ high maintenance and maybe a dose of the c*&p

[EMAIL PROTECTED] wrote:

Stewart -

<pulling up a barstool>

I feel your pain. With all due respect to the helpful comments posted by
Mr. Turnbull and Mr. Dennis, I find Mailman very awkward indeed. You make
reference to the idea of building on a test host and pushing the install
over to a production box - and how involved something like that is. Myself, I've been in the test stages of a migration of a mailman install
(2.0.x to 2.1.x) from one box to another for many weeks. The sorta, kinda
migration info in the Mailman faq is far from adequate. The bestiary of
python, binaries and config files that Mailman is (and *then* you add in
apache and a decent MTA) makes migration distressingly difficult. Though I
was painstakingly carefull to install Mailman properly on the new box
(yes, the INSTALL doc is ridiculously lengthly: tweak, dink, edit, hack,
kludge) and move everything over (lists, archives, data directory), my
first attempt failed completely. My second attempt mostly worked but,
finally, was unusable due to the fact that the admindb functions would
*occasionally* return 500 errors to my list owner's browsers. yeah. great.
I posted request for help to this list but the silence was deafening.
Although I do notice that the people on this list are generally pretty
helpful, it's my impression that the development team is Very busy (well,
smart people usually are) and can't pay as much attention to streamlining
Mailman as some of us would prefer.


But I'm SO in agreement with your point about the single binary (or few
binaries). And how that really is in keeping with the unix tradition. If
the kind of functionality apache or sendmail provide (yeah postfix does it
with a veritable smurf attack of binaries but what an elegant and
maintainable smurf attack!) can be packaged in the condensed manner that
they are (single binary) it's just frustrating that Mailman is so, um,
distributed ;-). Especially when the heavy lifting is really done by the
MTA and web server....

On the other hand, the price is right... And as far as I can tell, if you
install Mailman carefull and tatoo the 0s and 1s to the drive (forget
about moving it anywhere, ever) it does seem to work well. And finally, it
does seem to me to be the best thing out there (I haven't done an
exhaustive survey) for letting users manage their own lists. Because god
knows we all probably don't have the time for that....

Best,
--------------------------
Paul Ellis
Unix Systems Administrator
Cybertrust Corporation
[EMAIL PROTECTED]
703/480-8605


On Fri, 29 Oct 2004, Stewart Dean wrote:


<scraping sound of soapbox being pulled up>

I really, /really/ appreciate applications that build into a single binary or a very few files, that can be built on a (different) build and test host, then copied over to the production when everything is thrashed out and ripe...you know, like Pine and UoW IMAP.
I like it because:
= it keeps the production host clean,
= updates are MUCH more manageable,
= you don't have a compiler on the production host to give hackers a way to build nasty things on your production machines,
= You know when you remove/replace the single/very few files, you've got everything cleaned out/replaced.
= there's prolly other things that don't come to mind right now.


I have just gotten to page three of INSTALL and it seems like This Will Not Be The Case With Mailman. Tell me it isn't so.

-- ==== Stewart Dean, Unix System Admin, Henderson Computer Resources Center of Bard College, Annandale-on-Hudson, New York 12504 [EMAIL PROTECTED] voice: 845-758-7475, fax: 845-758-7035

------------------------------------------------------
Mailman-Users mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/

Reply via email to