GNOME Bugzilla – Bug 124879
Mailing list subscription pages broken
Last modified: 2009-08-15 18:40:50 UTC
Bug in Mailman version 2.1b4 We're sorry, we hit a bug! If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! Traceback: Traceback (most recent call last):
+ Trace 40974
main()
process_form(mlist, doc, cgidata, language)
mlist.AddMember(userdesc, remote)
cookie = Pending.new(Pending.SUBSCRIPTION, userdesc)
db = _load()
return cPickle.load(fp)
Python information: Variable Value sys.version 2.2.1 (#1, Oct 5 2002, 11:19:44) [GCC 2.95.4 20020320 [FreeBSD]] sys.executable /usr/local/bin/python sys.prefix /usr/local sys.exec_prefix /usr/local sys.path /usr/local sys.platform freebsd4 Environment variables: Variable Value HTTP_ACCEPT */* CONTENT_TYPE application/x-www-form-urlencoded HTTP_REFERER https://lists.xcf.berkeley.edu/mailman/listinfo/gimp-announce SERVER_SOFTWARE Apache/1.3.27 (Unix) mod_ssl/2.8.11 OpenSSL/0.9.6g PYTHONPATH /usr/lists/mailman SCRIPT_FILENAME /usr/lists/mailman/cgi-bin/subscribe SERVER_ADMIN root@lists.XCF.Berkeley.EDU SCRIPT_NAME /mailman/subscribe SERVER_SIGNATURE Apache/1.3.27 Server at lists.XCF.Berkeley.EDU Port 443 REQUEST_METHOD POST HTTP_HOST lists.xcf.berkeley.edu PATH_INFO /gimp-announce HTTPS on SERVER_PROTOCOL HTTP/1.1 QUERY_STRING REQUEST_URI /mailman/subscribe/gimp-announce CONTENT_LENGTH 102 PATH_TRANSLATED /usr/local/www/data/gimp-announce HTTP_USER_AGENT Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/85.7 (KHTML, like Gecko) Safari/85.5 HTTP_CONNECTION close SERVER_NAME lists.XCF.Berkeley.EDU REMOTE_ADDR 24.69.138.38 REMOTE_PORT 5218 HTTP_ACCEPT_LANGUAGE en-us, ja;q=0.33, en;q=0.67 SERVER_ADDR 128.32.112.242 SERVER_PORT 443 GATEWAY_INTERFACE CGI/1.1 UNIQUE_ID P5CY3oAgcPIAAELI1fk DOCUMENT_ROOT /usr/local/www/data
I didn't see anything in this report about keywords. It seems the mailman subscription pages for all the mailing lists are down. I don't know who can fix this. Changing priority, summary and os apporopriately. Is this the first time this has been reported here? Dave.
There is bug #121086 already.
Bug #121086 is about the mailing list archives. This one is about the subscription pages. Note that the other subscription mechanism based on e-mails to the list request address (e.g. gimp-web-request@...) is also broken: a mail with the subject "help" will return the help text and some other options are also working (including "unsubscribe"), but a mail with the subject "subscribe" will be dropped. So it is not possible for anybody to subscribe to any of the GIMP lists. The proposed solution to bug #121086 (get more memory for the machine) may also help solving this bug, althoug it could also be a different problem. I suppose that only Yosh knows what to do.
The bug is intermittent, acourding to yosh. If you have problems, you can keep trying.
Personally I have tried over the past 6 weeks on 4 different occasions to subscribe to gimp-web, and have failed on all 4 occasions. So if it's intermittent, I've been extremely unlucky, I guess... Dave.
Same here. I tried several times (5 or 6, don't remember) both via the web and via e-mail during last week. None of these worked. I just tried again (twice) and it still did not work. So if the problem is intermittent, it is certainly serious enough to prevent most people from subscribing.
There's a new mailing list machine, but it needs to be setup. So these problems should be fixed soonish.
Hi, Since the mlailing lists are the primary way that gimp people communicate between themselves, and also one of our primary means of communicating with people outside the community, it would be nice to make this a high priority. How soon is soonish? Cheers, Dave.
*** Bug 127449 has been marked as a duplicate of this bug. ***
*** Bug 127659 has been marked as a duplicate of this bug. ***
Something needs to happen here. We are trying hard to attract new developers and don't even allow them to join the mailing lists. This is doing severe damage to the GIMP project and it needs to change.
I've decided to host the lists myself, so as soon as I get the current subscription list, it will be setup.
Does this mean that the host names and so on will change? If the list address changes, it would be nice to post a warning to all lists a few days in advance. Those who use mail filters based on the sending host would certainly appreciate it.
Following on from Raphael's comments, is this an intermediate solution, or long-term? If it's a medium to long-term thing, it might be better to look at the possibility of having the lists housed on a machine where a number of people havce access to fix problems. Perhaps lists.gnome.org would be prepared to house the lists? We would probably need to figure out how to migrate the archives and the existing user list, but that would give us a number of list admins straight away, as well as eventually having a number of gimp people help out with the adminning. The offer from yosh is very generous, but if we're talking about a server change, I would prefer to avoid putting all our eggs in one basket in terms of the list infrastructure. How does this sound? Cheers, Dave.
Hosting the GIMP related mailing lists on lists.gnome.org sounds good to me - especially from an administration point of view, see bolsh' comment above. Either that or we could host the lists on gimp.org when the server is replaced?
Hi, For lists.gimp.org we need - A machine, preferably fairly beefy with decent bandwidth - A spam filter (please please please) - A virtual hostname - An installation of mailman - A way to migrate the old user lists to the new list server - Ideally a way to move the archives from the old machine to the new machine - A couple of volunteers to do all that :) Q: Is there a way to rebuild the archives that haven't been built yet once we move? I'm not familiar with mailman at all. For lists.gnome.org, we'd need to send mail asking for the lists to be created, and then figure out how to migrate subscriber lists and archives. The machine, bandwidth and list admins are already there, although it'd be appreciated, probably if someone helped out with any migration work. Cheers, Dave.
I can help for the migration, although I currently do not have access to the old list of subscribers. It is also relatively easy to re-generate the list archives with Pipermail, but this of course requires access to the new machine in order to run the script by hand. So you can count me as a volunteer, except that I cannot do much without access to the old or new machines. Regarding spam filters, the best solution may be spamassassin (running as spamc + spamd before delivery to the list). It can be a bit of a memory hog and it can take a few seconds to start, but running it as a daemon (spamd) instead of a launching a separate process every time helps a lot. I have been using it since a while for my own mailbox as well as on a server that delivers mails to several thousand users. It is rather stable and has an excellent success rate (better than any other filter that I have tried).
By the way, the Mailman FAQ has an entry explaining how to use SpamAssassin with Mailman: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.023.htp And there is another one explaining how to import an existing list (in mbox format) into a new Mailman installation: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq05.001.htp For more information about Mailman: http://www.list.org/
Sorry to add even more spam, but I forgot to mention that lists.gnome.org uses MHonArc instead of Pipermail for its mail archives. Mailman has quite good support for MHonArc and other email archivers. If you want some links: http://www.oac.uci.edu/indiv/ehood/MHonArc/doc/faq/general.html#compare
OK - the immediate concern is to be able to have people subscribe to the list, and to have the old subscriber list migrated to a new machine. lists.gimp.org seems to be the favoured solution at the moment. Which machine will that be, and whose bandwidth will it be taking up? Do we have a candidate machine, or should we start looking for one? Cheers, Dave.
There is a machine ready. Yosh tells me he knows exactly what to do, however it is a matter of having a block of time to do it. He is the only one that can, mostly because the lists are currently on the XCF and it is not ok for random people to have administrative privledges. It would take as long to explain to someone what to do, as it would to just do it himself, so we really just have to wait until he has the time to do it. This sucks a lot, but it took a while for yosh to give up on the XCF entirely, find the machine, and plan the move. Finding the time is the last hurdle. I've talked to yosh recently. He is getting very frustrated by how much he is getting hassled to do this. So much so, that it is becoming demotivating. I am sure Yosh wants to fix this rather annoying problem as soon as he can, so lets just let it rest. The problem is solved, it is just a matter of time.
Hi Daniel, Are you mixing up the website and the mailing lists? I wasn't aware that there was a problem with the mailing list move, or that it depended on yosh... As I understand it, anyone who knows how to set up mailman and has root access to a machine to host the lists could do this job. I didn't realise that yosh was the only person who could do it. If we do get someone else to do it, all that would be required from xcf would be (in the first instance) the subscriber list, and eventually the list data (archives and the like) but that wouldn't be urgent. We could even (in the short term) ask old subscribers to re-subscribe to the new lists, in which case we wouldn't need any XCF intervention at all. If people are making a big deal of it, it's because the mailing lists are the lifeblood of the project, and we are getting numerous complaints from people who want to join them and can't. Plus, we have a major release coming up soon, and it would be a terrible shame to waste the momentum that will give us because of a lack of infrastructure. Cheers, Dave.
Dave, was it really so unclear that hosting it myself means that I would take care of the machine, bandwidth, and mailman setup? What else would it mean? It'll get setup as soon as I get the current subscriber list and forwarding from the old address enabled (since the hostname will change).
I guess that it was unclear to me that your comment that you would host the lists yourself was the final word. When I suggested lists.gnome.org, my intention was in part to reduce the amount of work that any one person would have to do. I think that this has shown that having a number of people who can (and may) do this type of job is essential. So yes, I was unclear that the new list machine was going to be your machine. All of the comments I made following that were made under the assumption that the list machine would not be someone's personal machine, and that the machine's identity was not yet known. In fact I said as much in my comment here on the 23rd. So - just to clear matters up - what is the current situation? Are we happy with yosh moving the lists to his computer, or should we keep looking for another solution? Cheers, Dave.
It's not "my" computer. It's a gimp.org machine. When have I ever implied anything otherwise when talking about hardware and bandwidth resources? Having to explain myself at every step means less time for doing the actual work. There is no reason lists.gimp.org can't have multiple list admins (which is a distinction from MTA admin, or dns admin)
Oh, and more people for certain admin things isn't necessarily a good thing, mainly because more people == more points for security failure.
A certain amount of redundancy is essential. If one person doesn't have time, there is a fallback. Personally I've noticed that 3 or 4 people is about optimal - there is always someone to do urgent stuff, the group is small enough to have everyone clued up, and also that when a task eeds doing that it doesn't go undone because people think someone else will do it. I didn't understand we were talking about a gimp.org machine. Your comment that you had decided to host the lists yourself was the source of my confusion. I agree that we've talked enough about this, though. Is there any part of the migration that you can delegate to someone else? Raphael offered to help, and seems to know what he's talking about apropos mailman. In any case, I would personally like to see 3 or 4 people have root for this machine, as well as grouping together functions like list admin, ftp admin, http admin and the like. Is this something that would be envisageable? Dave.
To add my 2 (euro)cents: yes, I am volunteering for some of the admin stuff if I can be of any help. But I don't want to force Yosh to let me do things that he would prefer to do himself, because if I were in his situation, I would also be careful before giving privileges to anyone. I think that I know what I am talking about, because I maintain a number of Linux and Solaris machines at work, in several networks. I am responsible for several web servers, firewalls/NAT boxes, ftp servers, a mail server, a DNS server, etc. So I assume that I would be able to provide some help in various areas: mail, web, ftp, rsync, etc. However, as anyone who administers more than a dozen machines should know, one has to be paranoid when it comes to access rights. Not only because some users could use their privileges to do things that they are not supposed to do, but also because one mistake from a root user could open a security hole that would be quickly exploited, or simply because a root user could do a lot of damage by accident (deleting some files, killing a vital service, etc.). If someone asks me for getting root access to one of my machines, I usually try to find another way to let that person do what they want (using "sudo" if there is no easier solution). I would expect Yosh or any other administrator to do the same, especially for a box that is directly connected to the Internet and is rather visible. So in summary, I am offering my help but I am not insisting on getting root access.
Setting the milestone on this bug to 1.3.x - even though it's not a bug in the program, I think it would be a waste to release something we expect lots of people to use without the mailing lists working. Cheers, Dave.
Tis happier now.
Woohoo! Thanks yosh. Could we still carry on with the idea of housing the lists on a machine where more people can access the administrative side of things? I guess now that the lists are working again (although not the archives, apparrently), it's not as urgent. Thanks again, Dave.
Thanks 2, Yosh! You can still count me as a volunteer if you need help, although it is probably less urgent now, as Dave said.
Changing all www.gimp.org bugs from gimp product to the gimp-web product, including old closed/fixed bugs, and reassigning.
re-resolving old bugs
Re-assigning all bug reports related to the mailing lists to the "mailing lists" component. Let's hope that we are done with all these Bugzilla changes....