Hank van Cleef wrote: >The esteemed Mark Sapiro has said: >> >> Did you change the archive from public to private? Do you have to enter >> the password each time (not normal) or only once (normal for a private >> archive)? >> >I used bin/arch to build the archives from the mbox file, all in the >private directory. Then manually ran nightly_htdig to get the data >bases built.
But was the archive 'private' or 'public' (admin Archiving options) before the problem started? >The scenario plays like this: > >On cold entry (no cookies in the browser) go to the archives page from >the main page. User validation screen pops up. Enter username and >password, and you get to the pipermail archives. You can now read those >all day without needing to revalidate. Good. >Now, set up an htdig search, which returns a few pages of hits. Click >on one of those hits, and the validation screen pops up again. >Validate, and the message is displayed. Go back and click on another >hit. The validation screen pops up again, and displays the page after >another validation. > >Trying to display the second page makes the I assume you mean the second page of hits. >htdig Archives Access Failure > >template page pop up. > >This happens with either a user or the admin password active. > >The error log message that accompanies this is: > >Jan 19 11:12:55 2007 (23983) htsearch for list: mercedes, cause: auth, >detail: -10- > >It seems clear to me that the htdig process is not able to find the validation >cookie. I don't think that is the issue. It seems to me that the htdig process finds the cookie the first time, but then removes it. This explains why you need to revalidate when you try to visit the message, and it explains why you get mmsearch.py's authorization error when you try to get the second page of hits. >If this were compiled code and not Python, I'd dbx the thing, >but don't know enough about Python to know how to use the debugging >resources. If there's some sort of crash and traceback message, I don't >know where to look for that either. There wouldn't be a traceback in this case. >For reference, the htdig (3.1.6) build was a default ./configure build. >It wouldn't compile with either the Solaris Studio 11 CC or g++ 4.1.1. >I loaded g++ 2.95.3 on another Solaris 9 machine, did a build there, NFS >mounted the source tree, and did a make install to get it on this >machine. The only additional step needed to get htdig to run its own >rundig was to copy libstdc++ into /usr/lib (a bug in the Solaris >Companion Disk g++ build). > >The default overrides in mm_cfg.py relative to archiving (you'll notice >that some are commented out----I copied this file from the old host >installation, and left the last guy's commented-out stuff in place) > ># HTDIG_MAILMAN_LINK = 'htdig-mailman' >HTDIG_RUNDIG_PATH = '/opt/www/htdig/bin/rundig' >HTDIG_HTSEARCH_PATH = '/opt/www/cgi-bin/htsearch' >USE_HTDIG = 1 > ># ARCHIVE_TO_MBOX = 1 > >GZIP_ARCHIVE_TXT_FILES = 0 It seems that htdig per se is working fine. It returns the hits. I think the problem is in mmsearch.py. It checks to be sure it is authorized for the private archive, and it is. It does the search and displays the results and somehow in this latter step the cookie is removed. -- Mark Sapiro <[EMAIL PROTECTED]> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan ------------------------------------------------------ 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/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
