Can't admin pending messages
I think it was working and quit. I upgraded to Mailman 2.1 and I can't admin pending messages. It shows the pending messages with the choices - but if I select to approve, reject, or discard - nothing happens after I click submit. The same messages are still there and still pending.
What am I doing wrong?
At 19:44 29/01/2003, Marc Perkel wrote:
I think it was working and quit. I upgraded to Mailman 2.1 and I can't admin pending messages. It shows the pending messages with the choices - but if I select to approve, reject, or discard - nothing happens after I click submit. The same messages are still there and still pending.
What am I doing wrong?
Anything showing in Mailman error (or other) logs?
Are your ermissions OK. Did you run $bin/check_perms -f after upgrading?
Richard Barrett wrote:
At 19:44 29/01/2003, Marc Perkel wrote:
I think it was working and quit. I upgraded to Mailman 2.1 and I can't admin pending messages. It shows the pending messages with the choices - but if I select to approve, reject, or discard - nothing happens after I click submit. The same messages are still there and still pending.
What am I doing wrong?
Anything showing in Mailman error (or other) logs?
Are your ermissions OK. Did you run $bin/check_perms -f after upgrading?
Yep - reran check_perms and everything fine. Everything is in the right group - has the right permissions. Even rebooted the server. Nothing showing in the logs. And - I'm pretty sure it was working right after the upgrade and it quit for some reason. I have a second server with a nearly identical install and it works. I even changed the permissions on the hold files to 777 and no difference. If I manually delete the files it does make them go away.
I'm stumped.
29-Jan-03 at 13:19, Marc Perkel (marc@perkel.com) wrote :
Richard Barrett wrote:
At 19:44 29/01/2003, Marc Perkel wrote:
I think it was working and quit. I upgraded to Mailman 2.1 and I can't admin pending messages. It shows the pending messages with the choices - but if I select to approve, reject, or discard - nothing happens after I click submit. The same messages are still there and still pending.
What am I doing wrong?
Anything showing in Mailman error (or other) logs?
Are your ermissions OK. Did you run $bin/check_perms -f after upgrading?
Yep - reran check_perms and everything fine. Everything is in the right group - has the right permissions. Even rebooted the server. Nothing showing in the logs. And - I'm pretty sure it was working right after the upgrade and it quit for some reason. I have a second server with a nearly identical install and it works. I even changed the permissions on the hold files to 777 and no difference. If I manually delete the files it does make them go away.
I'm stumped.
Are your qrunner processes running and all the regular things like that? How about your locks directory?
Sometimes I do this: stop mailman... go into the locks directory, delete all listname-* files, start mailman.
This usually helps.
-- |-Simon White, Internet Services Manager, Certified Check Point CCSA. |-MTDS Internet, Security, Anti-Virus, Linux and Hosting Solutions. |-MTDS 14, rue du 16 novembre, Agdal, Rabat, Morocco. |-MTDS tel +212.3.767.4861 - fax +212.3.767.4863
Are you allowing cookies in this browser? What happens if you enter the admindb via a different browser?
On Wed, 2003-01-29 at 16:19, Marc Perkel wrote:
Richard Barrett wrote:
At 19:44 29/01/2003, Marc Perkel wrote:
I think it was working and quit. I upgraded to Mailman 2.1 and I can't admin pending messages. It shows the pending messages with the choices - but if I select to approve, reject, or discard - nothing happens after I click submit. The same messages are still there and still pending.
What am I doing wrong?
Anything showing in Mailman error (or other) logs?
Are your ermissions OK. Did you run $bin/check_perms -f after upgrading?
Yep - reran check_perms and everything fine. Everything is in the right group - has the right permissions. Even rebooted the server. Nothing showing in the logs. And - I'm pretty sure it was working right after the upgrade and it quit for some reason. I have a second server with a nearly identical install and it works. I even changed the permissions on the hold files to 777 and no difference. If I manually delete the files it does make them go away.
I'm stumped.
Mailman-Users mailing list Mailman-Users@python.org 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/
This message was sent to: jonc@nc.rr.com Unsubscribe or change your options at http://mail.python.org/mailman/options/mailman-users/jonc%40nc.rr.com
Hi,
Last month there was a thread about a problem that I am now having. Was a solution, or at least a cause, found?
The problem, as stated by the original poster, is "It shows the pending messages with the choices - but if I select to approve, reject, or discard - nothing happens after I click submit. The same messages are still there and still pending."
To clarify, this occurs in all parts of the admindb interface that are normally used. No approve/reject/discard/etc options have any effect. I just end up at the admindb page as though it was a daydream that I had used the buttons. There are no messages in any logs, there is no explanation or acknowledgment in the web interface.
I have tried most regular things like stopping and starting daemons, clearing out temp junk (not that there was any), etc. Of course, there are posts pending. But, to complicate matters, the affected machine was physically relocated on the weekend and had its hard drives moved into a new chassis (with a new motherboard, etc) due to a long-standing hardware fault that we wanted to eliminate. And various other software was upgraded. On top of that, it has new IP addresses and its domain has changed. BUT this has not cause weird bugs in other software and most of changes were made in stages with no observed malfunctions along the way. All I can think is that the last time Mailman admindb was known to work was late last week, before these changes, and now it doesn't work. The version was 2.1b3 but in the face of this new problem, I upgraded to 2.1 proper. The upgrade seems to have made no observable difference (improvement) in behaviour. Anyway, it sounds like the same problem that someone else had, even if my circumstances obscure this. OS is Solaris on UltraSPARC with Python 2.2.1. I will cheerfully upgrade this to Python 2.2.2 along with Python-dependent packages, in the near future.
But, as for Mailman...
Let me point you to a posting from the archives from Vivek Khera:
If you redirect a POST using mod_redirect, you lose the data. The workaround is to capture the POST data from the original request, convert it to a GET and redirect to that. But then if you're sending the first request in the clear, what exactly do you gain by redirecting to SSL after all the info just went by cleartext?
You need to fix it up so that the page is submitted *directly* to the SSL secured URL.
Since you moved thing around a bit, you may be using a simple redirect to point Mailman admindb calls back to the address they used to use. During the redirect the POST information is lost. The admindb cgi receives no information. It looks like it's ignoring you.
HtH - Jon Carnes
On Tue, 2003-02-04 at 04:11, James Devenish wrote:
Hi,
Last month there was a thread about a problem that I am now having. Was a solution, or at least a cause, found?
The problem, as stated by the original poster, is "It shows the pending messages with the choices - but if I select to approve, reject, or discard - nothing happens after I click submit. The same messages are still there and still pending."
To clarify, this occurs in all parts of the admindb interface that are normally used. No approve/reject/discard/etc options have any effect. I just end up at the admindb page as though it was a daydream that I had used the buttons. There are no messages in any logs, there is no explanation or acknowledgment in the web interface.
I have tried most regular things like stopping and starting daemons, clearing out temp junk (not that there was any), etc. Of course, there are posts pending. But, to complicate matters, the affected machine was physically relocated on the weekend and had its hard drives moved into a new chassis (with a new motherboard, etc) due to a long-standing hardware fault that we wanted to eliminate. And various other software was upgraded. On top of that, it has new IP addresses and its domain has changed. BUT this has not cause weird bugs in other software and most of changes were made in stages with no observed malfunctions along the way. All I can think is that the last time Mailman admindb was known to work was late last week, before these changes, and now it doesn't work. The version was 2.1b3 but in the face of this new problem, I upgraded to 2.1 proper. The upgrade seems to have made no observable difference (improvement) in behaviour. Anyway, it sounds like the same problem that someone else had, even if my circumstances obscure this. OS is Solaris on UltraSPARC with Python 2.2.1. I will cheerfully upgrade this to Python 2.2.2 along with Python-dependent packages, in the near future.
But, as for Mailman...
Mailman-Users mailing list Mailman-Users@python.org 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/
This message was sent to: jonc@nc.rr.com Unsubscribe or change your options at http://mail.python.org/mailman/options/mailman-users/jonc%40nc.rr.com
In message 1044370687.2294.4.camel@Anns1.nc.rr.com on Tue, Feb 04, 2003 at 09:58:02AM -0500, Jon Carnes wrote:
If you redirect a POST using mod_redirect, you lose
Yes, that is what appears to be happening. It seems that the admindb web forms (and e-mail to list admins) point to the (old) address. The other admin forms, such as 'admin' use relative URLs and work fine. So for some reason, parts of the lists think they are at the old address (even though I had updated the mm_cfg.py during the move). I had a look at the list's (in fact all lists') config.pck files and I can see the old addresses sitting there. The variable is web_page_url. However, I am yet to find mention of this anywhere in the Mailman admin interface (so I don't know how to change it). So I have three problems:
- old web address has been stored in config.pck and therefore overlooked in our move, since we only changed mm_cfg.py
- admindb behaves differently to admin
- can't find a way to change web_page_url on a list-by-list using the web admin interface, even though the config_list, move_list, withlist scripts will possibly do this right (looking into it now).
In message 20030205004651.GA20271@gulag.guild.uwa.edu.au on Wed, Feb 05, 2003 at 08:46:52AM +0800, James Devenish wrote:
config_list, move_list, withlist scripts will
Hmm, http://mailman.sourceforge.net/site.html doesn't seem to match my Mailman 2.1 installation. Nevertheless, the important part for me was its config_list example, which did work for me. Although it said:
attribute "web_page_url" changed Non-standard property restored: web_page_url
Why "non-standard"?? And is there a way to make a list go and use the default pattern from mm_cfg.py?
Look at ~mailman/bin/fix_url.py.
HtH - Jon Carnes
On Tue, 2003-02-04 at 19:46, James Devenish wrote:
In message 1044370687.2294.4.camel@Anns1.nc.rr.com on Tue, Feb 04, 2003 at 09:58:02AM -0500, Jon Carnes wrote:
If you redirect a POST using mod_redirect, you lose
Yes, that is what appears to be happening. It seems that the admindb web forms (and e-mail to list admins) point to the (old) address. The other admin forms, such as 'admin' use relative URLs and work fine. So for some reason, parts of the lists think they are at the old address (even though I had updated the mm_cfg.py during the move). I had a look at the list's (in fact all lists') config.pck files and I can see the old addresses sitting there. The variable is web_page_url. However, I am yet to find mention of this anywhere in the Mailman admin interface (so I don't know how to change it). So I have three problems:
- old web address has been stored in config.pck and therefore overlooked in our move, since we only changed mm_cfg.py
- admindb behaves differently to admin
- can't find a way to change web_page_url on a list-by-list using the web admin interface, even though the config_list, move_list, withlist scripts will possibly do this right (looking into it now).
Mailman-Users mailing list Mailman-Users@python.org 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/
This message was sent to: jonc@nc.rr.com Unsubscribe or change your options at http://mail.python.org/mailman/options/mailman-users/jonc%40nc.rr.com
In message 1044414569.1639.30.camel@Anns1.nc.rr.com on Tue, Feb 04, 2003 at 10:09:25PM -0500, Jon Carnes wrote:
Look at ~mailman/bin/fix_url.py.
Yes, I was going to mention that but the notes at the top of the file said "This script is intended to be run as a bin/withlist script, i.e. bin/withlist -l -r fix_url listname [options]". I wasn't clear on when I would be prompted for an address. Because I had multiple lists to move over, I didn't want to do this interactively and so I used config_list, since an explicit example was given on the Mailman website. Thanks anyway.
In message 20030205032238.GA23779@gulag.guild.uwa.edu.au on Wed, Feb 05, 2003 at 11:22:38AM +0800, James Devenish wrote:
In message 1044414569.1639.30.camel@Anns1.nc.rr.com on Tue, Feb 04, 2003 at 10:09:25PM -0500, Jon Carnes wrote:
Look at ~mailman/bin/fix_url.py. [...] I wasn't clear on when I would be prompted for an address.
Whoops, I now see that the description is on the """ line, above the synopsis sentence. But the code makes it look like it sets the list's web address to be the same as the default, and the list then uses that stored value rather than the default. So I would people generally have to consider doing fix_url when doing a site-wide web address change?
General questions (almost rhetorical, since Mailman seems to be working for me for the time being):
- is this behaviour generally true of the way mm_cfg.py is used by Mailman?
- should Mailman users expect other hidden variables to require updating in a migration? (Though, given everything we changed in our system, it does seem to be the only problem.)
The reason I ask if that this extra migration step is something that we were not exposed to during installation or regular maintenance, and which I have failed to intuitively find in the various "lister server admin" docs.
Well we've entered the philosophical realm here...
I agree 100% with you. The Unix way is to give the power to the user and "let them shoot their foot off" if that's what they want (or at least what they tell the system they want to do).
Barry moved the URL section out of the config_list dump/input and out of the Web-admin so that folks couldn't change it easily. We had a lot of users screwing around with the value and then breaking their ability to get back to the Web-admin. This is mega-bad for folks who are simply running a hosting service.
By that logic I can see removing it from the Web-admin, but IMO it should have been left in the config_list dump. So, if I can easily hack the config_list command to include changing the url then I'll do that, and put it where other folks can get to it.
That way you can use a tool you are more comfortable with and which is already documented to do the job. Yeah - Open Source!
Jon Carnes
On Tue, 2003-02-04 at 23:25, James Devenish wrote:
In message 20030205032238.GA23779@gulag.guild.uwa.edu.au on Wed, Feb 05, 2003 at 11:22:38AM +0800, James Devenish wrote:
In message 1044414569.1639.30.camel@Anns1.nc.rr.com on Tue, Feb 04, 2003 at 10:09:25PM -0500, Jon Carnes wrote:
Look at ~mailman/bin/fix_url.py. [...] I wasn't clear on when I would be prompted for an address.
Whoops, I now see that the description is on the """ line, above the synopsis sentence. But the code makes it look like it sets the list's web address to be the same as the default, and the list then uses that stored value rather than the default. So I would people generally have to consider doing fix_url when doing a site-wide web address change?
General questions (almost rhetorical, since Mailman seems to be working for me for the time being):
- is this behaviour generally true of the way mm_cfg.py is used by Mailman?
- should Mailman users expect other hidden variables to require updating in a migration? (Though, given everything we changed in our system, it does seem to be the only problem.)
The reason I ask if that this extra migration step is something that we were not exposed to during installation or regular maintenance, and which I have failed to intuitively find in the various "lister server admin" docs.
Mailman-Users mailing list Mailman-Users@python.org 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/
This message was sent to: jonc@nc.rr.com Unsubscribe or change your options at http://mail.python.org/mailman/options/mailman-users/jonc%40nc.rr.com
participants (5)
-
James Devenish -
Jon Carnes -
Marc Perkel -
Richard Barrett -
Simon White