RE: [Mailman-Users] Newlist from a webpage?
Bob, thats interesting... but lets modify this a bit to make it more multi-user...
the virtual domains's "controlpanel" writes to a (hidden) file (in the root of each virtual domain) the necessary info for the newlist routine, after checking that the list doesnt exist yet...
Then, every couple minutes (say every 5... but that *could* be too long if you have a large number of virtual domains on the box - but being a cron job, thats configurable on a box by box basis) the cron job wakes up, as root, and processes through the list of domains on the box, looking for new trigger files.
When found it processes the newlist (capturing any error that might occur), and either updates the /etc/aliases and the virtual domains redirection, or barfs back a message to the intended list owner indicating they were >< that close to getting a list with that name...
Lets complicate things a little more - and add rmlist processing as well - that way complete control is within the virtual domain owner's hands... and I dont have to deal with as many support requests ;-)
This should be pretty simple this way... it's not instantaneous - but it should serve most people well enough, and since it's all driven from inside the virtual domains's diskspace, the possibilty of multiple people thrashing the same file is minimized. (currently) I'm not worried about wasting cycles - my server rarely breaks 5% CPU usage - and I already have another job that runs at 5 minute intervals that I can tack this on to the end of...
I've got a site design/build to complete by the end of the year, so I'll look at this sometime in the new year.
-----Original Message----- From: Bob Puff@NLE [mailto:bob@nleaudio.com] Sent: Saturday, December 23, 2000 10:31 PM To: scott-brown@home.com Subject: Re: [Mailman-Users] Newlist from a webpage?
Hi Scott,
I have another idea for you. Something I think was done at the old ISP I used to use.
Have your cgi script build some sort of shell script to do what you need. Stuff it in some directory. Now set up a cron job that runs every hour (or more often if you want) that checks to see if this script is present, and if so, run it with root priveleges. Then delete it after it is done.
Yes, it does waste some processor time, but you can do just about anything. Been thinking about implementing that in my system.
Please keep me posted on your progress.
Bob
Scott Brown wrote:
Know whats really funny here Bob?
People want the ability. People discuss it. A few of us
it, write a little code, run into roadblocks... and in the end, nothing useful gets done and the thread dies off.
I dont want this to happen this time.
Personally - I've looked through the source to newlist -
there really - and what is there *could* be turned into a CGI - once I figure out the PHP CGI wrapper that Barry (et al) used - but I ran into a roadblock where the security of my server's config (all user CGI's are SUEXEC'd) makes it impossible for newlist to complete successfully (see my other thread about newlist dying with an error trying to unlink a lock file).
So - I think I'm going to have to do what someone else suggested - and create an email address to which the required info gets
even fiddle with there's not much posted, intercept it
via a "wrapper" like functionality, and then process things as the mail user.
The next stage (updating the /etc/aliases and virtual domain tables files), requries root priv on my box, so I'm still trying to figure out how to do that one.
-----Original Message----- From: Bob Puff@NLE [mailto:bob@nleaudio.com] Sent: Friday, December 22, 2000 1:31 PM To: scott-brown@home.com Subject: Re: [Mailman-Users] Newlist from a webpage?
Hi Scott,
I've been following your thread. Let me know if you come up with a cgi (or other) script - I'm trying to do the same thing here - let users create mailing lists.
Bob
Mailman-Users maillist - Mailman-Users@python.org http://www.python.org/mailman/listinfo/mailman-users
Essentially the problem here is just to pass a piece of information from a program with no privileges running as nobody to a program with the ability to update the aliases file and run newlist. The 15-minute solution is to use what's there already (sendmail and perl) to send the information through the mail system via cgi. Since the message never leaves the machine, it's just like using a file semaphore; a POST calls the MTA, which then leaves the information in a file, which then gets picked up by the MTA and passed to a little script that makes the necessary updates.
You can go further by having a watched file; when the file changes a program (probably a perl or python script) wakes up and reads the contents of the file, then makes the necessary changes. Or you can use cron to sit there and call a script like you've described below that watches a file and makes the changes if they're there.
My personal choice would be the one I suggested first because it's easiest, yields instantaneous changes and is effectively exactly the same as if I wrote a real program that called an ioctl to watch a file for a semaphore. This way inetd takes the place of the watcher, waking up the MTA and having it call the script that calls newlist and updates aliases.
On another note, I have verified that hostway.com does indeed offer mailman as part of their virtual hosting service. Given that I've spent many hours trying to get virtual mailmen to work in a way that would satisfy me, I'd love to know how they're implementing it. Better yet, I wish someone would shoot me.
Dave Klingler
the virtual domains's "controlpanel" writes to a (hidden) file (in the root of each virtual domain) the necessary info for the newlist routine, after checking that the list doesnt exist yet...
Then, every couple minutes (say every 5... but that *could* be too long if you have a large number of virtual domains on the box - but being a cron job, thats configurable on a box by box basis) the cron job wakes up, as root, and processes through the list of domains on the box, looking for new trigger files.
When found it processes the newlist (capturing any error that might occur), and either updates the /etc/aliases and the virtual domains redirection, or barfs back a message to the intended list owner indicating they were >< that close to getting a list with that name...
Lets complicate things a little more - and add rmlist processing as well - that way complete control is within the virtual domain owner's hands... and I dont have to deal with as many support requests ;-)
This should be pretty simple this way... it's not instantaneous - but it should serve most people well enough, and since it's all driven from inside the virtual domains's diskspace, the possibilty of multiple people thrashing the same file is minimized. (currently) I'm not worried about wasting cycles - my server rarely breaks 5% CPU usage - and I already have another job that runs at 5 minute intervals that I can tack this on to the end of...
I've got a site design/build to complete by the end of the year, so I'll look at this sometime in the new year.
-----Original Message----- From: Bob Puff@NLE [mailto:bob@nleaudio.com] Sent: Saturday, December 23, 2000 10:31 PM To: scott-brown@home.com Subject: Re: [Mailman-Users] Newlist from a webpage?
Hi Scott,
I have another idea for you. Something I think was done at the old ISP I used to use.
Have your cgi script build some sort of shell script to do what you need. Stuff it in some directory. Now set up a cron job that runs every hour (or more often if you want) that checks to see if this script is present, and if so, run it with root priveleges. Then delete it after it is done.
Yes, it does waste some processor time, but you can do just about anything. Been thinking about implementing that in my system.
Please keep me posted on your progress.
Bob
Scott Brown wrote:
Know whats really funny here Bob?
People want the ability. People discuss it. A few of us
it, write a little code, run into roadblocks... and in the end, nothing useful gets done and the thread dies off.
I dont want this to happen this time.
Personally - I've looked through the source to newlist -
there really - and what is there *could* be turned into a CGI - once I figure out the PHP CGI wrapper that Barry (et al) used - but I ran into a roadblock where the security of my server's config (all user CGI's are SUEXEC'd) makes it impossible for newlist to complete successfully (see my other thread about newlist dying with an error trying to unlink a lock file).
So - I think I'm going to have to do what someone else suggested - and create an email address to which the required info gets
even fiddle with there's not much posted, intercept it
via a "wrapper" like functionality, and then process things as the mail user.
The next stage (updating the /etc/aliases and virtual domain tables files), requries root priv on my box, so I'm still trying to figure out how to do that one.
-----Original Message----- From: Bob Puff@NLE [mailto:bob@nleaudio.com] Sent: Friday, December 22, 2000 1:31 PM To: scott-brown@home.com Subject: Re: [Mailman-Users] Newlist from a webpage?
Hi Scott,
I've been following your thread. Let me know if you come up with a cgi (or other) script - I'm trying to do the same thing here - let users create mailing lists.
Bob
Mailman-Users maillist - Mailman-Users@python.org http://www.python.org/mailman/listinfo/mailman-users
Mailman-Users maillist - Mailman-Users@python.org http://www.python.org/mailman/listinfo/mailman-users
Hi Dave,
Essentially the problem here is just to pass a piece of information from a program with no privileges running as nobody to a program with the ability to update the aliases file and run newlist. The 15-minute solution is to use what's there already (sendmail and perl) to send the information through the mail system via cgi.
Thats only a "15-minute solution" if you're versant in sendmail and perl. I can hack away at a perl script until it works (generally with a few trips to the man pages ;-), but sendmail... well, I know how to update the necessary files for new virt domains, and I can restart it when it's confused... but past that.... ;-)
Since the message never leaves the machine, it's just like using a file semaphore; a POST calls the MTA, which then leaves the information in a file, which then gets picked up by the MTA and passed to a little script that makes the necessary updates.
A definite bonus...
You can go further by having a watched file; when the file changes a program (probably a perl or python script) wakes up and reads the contents of the file, then makes the necessary changes. Or you can use cron to sit there and call a script like you've described below that watches a file and makes the changes if they're there.
Thats only because I feel confident in creating that process... I _LIKE_ your suggestion, but I dont know if I could implement it. I do know I could implement what I discussed.
My personal choice would be the one I suggested first because it's easiest, yields instantaneous changes and is effectively exactly the same as if I wrote a real program that called an ioctl to watch a file for a semaphore.
This way inetd takes the place of the watcher, waking up the MTA and having it call the script that calls newlist and updates aliases.
It's the hand-off from sendmail to the perl program that has me scratching my head right now. Obviously, it would need to be done in the way that Mailman does it now - but I've not fully disected the WRAPPER program as of yet... My background is in mainframe business application programming - so I dont have a lot of experience with OO code ...
Of course, once the sendmail part is happy and functioning, it should be a simple job to parse out the required fields, run newlist, update the domain info, update /etc/aliases and the virt domain user file, and then send off a confirmation message...
On another note, I have verified that hostway.com does indeed offer mailman as part of their virtual hosting service. Given that I've spent many hours trying to get virtual mailmen to work in a way that would satisfy me, I'd love to know how they're implementing it.
Well, it would seem there's as many ways as there are people looking at the problem.
Better yet, I wish someone would shoot me.
Thats not the answer. Chocolate is the answer. Chocolate, cold pizza and a beer or two works wonders for me when I'm running into a deadline ;-)
Scott.
Happy holidays, everybody. I wrote:
Essentially the problem here is just to pass a piece of information from a program with no privileges running as nobody to a program with the ability to update the aliases file and run newlist. The 15-minute solution is to use what's there already (sendmail and perl) to send the information through the mail system via cgi.
Still grasping his sanity, Scott Brown wrote:
Thats only a "15-minute solution" if you're versant in sendmail and perl. I can hack away at a perl script until it works (generally with a few trips to the man pages ;-), but sendmail... well, I know how to update the necessary files for new virt domains, and I can restart it when it's confused... but past that.... ;-)
Whups! My apologies. I'm not that great with sendmail either, but I know how to do a few things with it related to CGI apps.
For sending mail, I usually use metasend, since it's easy to use. I chose it once because it does MIME and I needed MIME, so keep in mind that there might be easier ways to do it. For what we're talking about, I'd be happy with sendmail because you can just pipe it a bunch of text and send it on its way very easily. But most any MTA will take a command line and zing mail off for you.
Here's a piece of perl from a CGI mail gateway that I stole from an O'Reilly CGI book long ago and modified. It assumes you've built an array named MAIL containing your FROM and TO addresses and the message you want to send. You could just as easily call sendmail with a command line, too.
sub send_mail { # Get a sendmail process ready... open (SENDMAIL, "| $sendmail");
# ...and send it a mail header... print SENDMAIL <<Mail_Header; From: $MAIL{'from} <$MAIL{'email'}> To: $MAIL{'to'} Reply-To: $MAIL{'email'} Subject: $MAIL{'subject'} X-Mailer: $gateway X-Remote-Host: $ENV{'REMOTE_ADDR'} Mail_Header
# I threw in a cc line just so you'd know you could cc each newlist request # to someone, maybe the sysadmin or the company mail person. if ($MAIL{'cc'}) { print SENDMAIL "Cc: ", $MAIL{'cc'}, "\n"; }
# And now we throw in the message, maybe just the names of the list and # the email and password for the list admin. print SENDMAIL "\n", $MAIL{'message'}, "\n";
# Go home, drink a beer, contemplate life, pass out on the sofa. close (SENDMAIL);
Here's another way of doing it with metasend and a JPEG file, which of course isn't what you want but I'm pasting and you can get the gist of it *lazy grin*:
system(qq/metasend -b -z -e base64 -f $preview -F PrintForge -m IMAGE\/JPEG -s "PrintForge Preview" -S 1000000 -t $options{'previewmailto'} /);
The truth is I don't remember what metasend's various options are, but I think you could skip most of what I pasted because you're just sending text. But if you always wanted to send yourself a picture, now you can.
Since the message never leaves the machine, it's just like using a file semaphore; a POST calls the MTA, which then leaves the information in a file, which then gets picked up by the MTA and passed to a little script that makes the necessary updates. [snip] It's the hand-off from sendmail to the perl program that has me scratching my head right now. Obviously, it would need to be done in the way that Mailman does it now - but I've not fully disected the WRAPPER program as of yet... My background is in mainframe business application programming - so I dont have a lot of experience with OO code ...
OHHHHHHHH!!!! Good grief, I'm so bamboozled by wrapper and its minions right now that I wouldn't dare use it either. I just meant call the program in the same way that mailman calls wrapper:
newlist: "|/home/mailman/myprogramdir/mylistprog"
That just pipes the incoming mail to your list program. I've been using wrapper (and you can try this at home) with
su mail mail/wrapper mailcmd test < help_test
where "test" is the name of a list and "help_test" is a piece of mail I cc'd to myself with the word "help" in the subject field. Unfortunately, although this works fine I still get "operating system error" in my mail logs, AND my gid is set fine AND I can't figure it out. *^#$@#$(!!!
So you can see how that wrapper call works with stdin and argv, and how a call like I've written above should work just as well.
Of course, once the sendmail part is happy and functioning, it should be a simple job to parse out the required fields, run newlist, update the domain info, update /etc/aliases and the virt domain user file, and then send off a confirmation message...
Thar ya go. Don't forget to parse it for metacharacters, just in case some smarmy customer puts a shell command in for the name of the new list.
Well, it would seem there's as many ways as there are people looking at the problem.
Better yet, I wish someone would shoot me.
Thats not the answer. Chocolate is the answer. Chocolate, cold pizza and a beer or two works wonders for me when I'm running into a deadline ;-)
*sniff* I was a human being, once! If only those things could help me! No, only bullet could help me now...
I discovered last night, while implementing another "this has to work!" solution (a separate installation of apache, an idea which I'd actually started to like because I can do all kinds of cool security and backup things that way), that apache neatly bypasses my chroot and zooms up the directory tree, skipping my mailman installation in the process. So many people have told me that's impossible! Bla ha! Bla ha ha ha ha ha ha! Bla ha haha...how do they do that???!!! Must look at the Apache code.
I then fell back on another forehead-slappin' solution (two separate mailman installations, with the cgi version using links to the other's data directories). That's when I realized that all this time I've been using wrapper to find out when things were working, but I seem to have another problem when mailman runs in a virtual machine. It could be just that I've tried so many solutions that I'm skipping some installation step, so I'm going to try from scratch today.
I'm really happy with my virtual machines, happy enough that I've put myself through the living hell of hard-coded directory names in Mailman in an attempt to keep them. I can have separate email names on separate machines this way, and the MTA's never have to meet. Python looks pretty easy, actually. Maybe I'll modify Mailman to have a single configuration file where all the directory names are kept...
Dave Klingler
On Dec 24, Dave Klingler wrote:
sub send_mail { # Get a sendmail process ready... open (SENDMAIL, "| $sendmail");
Make sure that $sendmail not only includes the correct path to sendmail but also the correct flags, -t being the important one here (read reciepinet addresses from headers)
$sendmail = "/usr/sbin/sendmail -oem -t";
Dan
Dan Busarow 949 443 4172 Dana Point Communications, Inc. dan@dpcsys.com Dana Point, California 83 09 EF 59 E0 11 89 B4 8D 09 DB FD E1 DD 0C 82
On Dec 24, Dave Klingler wrote:
sub send_mail { # Get a sendmail process ready... open (SENDMAIL, "| $sendmail");
Make sure that $sendmail not only includes the correct path to sendmail but also the correct flags, -t being the important one here (read reciepinet addresses from headers)
$sendmail = "/usr/sbin/sendmail -oem -t";
Yes, although interestingly enough, iirc the docs say that the -t option is only for privileged users. In practice I've never had a problem with it. I always wondered about that.
Dave Klingler
"DK" == Dave Klingler <davek@mail.commercedata.com> writes:
DK> Essentially the problem here is just to pass a piece of
DK> information from a program with no privileges running as
DK> nobody to a program with the ability to update the aliases
DK> file and run newlist.As more MTAs gain the ability to "magically" recognize new mailing lists, the hurdles to a ttw (through the web) newlist decrease. There are recipes for Exim and Postfix -- scan the archives, and btw, Wieste sent me an email with some better ideas than I'd posted before, but haven't tried yet. Writing a CGI shouldn't be too hard, except that Mailman's current CGI generating scripts are in serious need of rewriting.
For other, non-automagic MTAs, I envision a simple pluggable framework for sticking in your own post-list-creation scripts. That way you could add some setuid thingy that e.g. runs newaliases and HUPs your MTA.
One issue is: who gets to create and delete new lists? Probably only those with the site password.
-Barry
participants (4)
-
barry＠digicool.com -
Dan Busarow -
Dave Klingler -
Scott Brown