PLEASE ACCEPT MY APOLOGIES FOR FLOODING THIS ALREADY BUSY SITE WITH UNNECESSARY POSTS. I left tcpwatch running last night, and tested my Update page from two different machines using different Internet Service providers (one was AOL) and they both were able to POST updates via the tcpwatch 8086 port as well as the ZServer 8080 port. I really don't know what's going on with my out of state users, maybe operator error, but it doesn't appear to be a Zope problem. Sorry....:-( Irene Barg wrote:
Hello,
Zope Version: Zope 2.3.3 (binary release, python 1.5.2, linux2-x86) Python Version: 1.5.2 (#10, Dec 6 1999, 12:16:27) [GCC 2.7.2.3] System Platform: linux2
This is a follow-up on an earlier post "IE problems with Zope Solaris binary", but please read on.
I have a family database that users can browse with no problem. Created a role called 'dbupdate', then disabled all 'Acquire permissions settings' for the Update folder, then enabled the following for the 'dbupdate' role:
Access contents information Open/Close Database Connection(s) Query Vocabulary Search ZCatalog Use Database Methods Use Factories Use mailhost services View View History View management screens
Created 2-3 users in the Update folder and gave them 'dbupdate' roles. These users can login to the Update folder, GET a family record, edit it, but when it comes time to 'Submit' their updates (which does a POST), they get a message that simply says, "The Page cannot be displayed. The page you are looking for is currently unavailable. The Web site might be experienceing technical difficulties, or you may need to adjust your browser."
Now, this particular Zope site was originally on a Solaris system, and I had posted this same problem under the subject "IE Problems with Zope Solaris binary." However, moving the Zope site to a Linux box appeared to fix things. At least I cannot re-create the problem in this building. The problem only shows up when users outside (literally out of state) who come in from their Internet Service providers like AOL. Dieter Maurer and Tino Wildenhain had suggested I use 'tcpwatch' to debug this problem. On the Solaris installation, this didn't work because the ZServer simply dumped core, died, and tcpwatch die along with it. However, on the Linux setup, I started tcpwatch:
python tcpwatch.py 8086 jesse.as.arizona.edu 8080
I ask one of my out of State users to try an Update using the 8086 address and behold, she can do Updates and the POST doesn't fail! What may be a clue here, is that if you look at the Z2.log, it shows her coming in on the 'jesse' address. I guess this is because tcpwatch is acting as a proxy. Now the million dollar question is:
Was the success coming via the tcpwatch port a fluke? Or, could it be related to the permissions I gave the 'dbupdate' role? Or, could it be something related to 'file system' permissions in the /usr/local/zope tree?
/usr/local/var looks like this: jesse:/usr/local/zope> ls -l var total 7568 -rw------- 1 nobody barg 574368 Aug 22 09:02 Data.fs -rw-r--r-- 1 nobody barg 75448 Jan 22 2001 Data.fs.in -rw-r--r-- 1 nobody barg 160858 Aug 9 14:51 Data.fs.index -rw-r--r-- 1 nobody barg 5 Aug 20 12:29 Data.fs.lock -rw-r--r-- 1 nobody barg 26176 Aug 22 09:02 Data.fs.tmp -rw-r--r-- 1 nobody barg 854346 Aug 22 13:44 Z2.log -rw-r--r-- 1 nobody barg 9 Aug 20 12:29 Z2.pid -rw-r--r-- 1 nobody barg 725 Aug 20 12:29 Zope.log -rw-r--r-- 1 nobody barg 4 Aug 20 12:29 pcgi.pid srwxrwxrwx 1 root root 0 Aug 20 12:29 pcgi.soc= -rw-r--r-- 1 nobody barg 4 Aug 20 12:29 zProcessManager.pid
And in the top level of the Zope tree:
jesse:/usr/local/zope> ls -l total 132 drwxrwxr-x 2 barg barg 4096 Aug 9 10:49 Extensions/ -rw-r--r-- 1 barg barg 3479 Mar 9 1999 LICENSE.txt -rw-r--r-- 1 barg barg 987 Apr 29 1999 README.txt drwxrwxr-x 4 barg barg 4096 Aug 9 09:41 ZServer/ -rwxr-xr-x 1 barg barg 483 Aug 9 09:41 Zope.cgi* drwxrwxr-x 2 barg barg 4096 Jun 20 12:34 bin/ drwxrwxr-x 3 barg barg 4096 Jun 20 12:34 doc/ drwxrwxr-x 2 barg barg 4096 Aug 19 18:15 import/ drwxrwxr-x 2 barg barg 4096 Aug 9 09:41 inst/ -rwxr-xr-x 1 barg barg 225 Jul 23 1999 install* drwxrwxr-x 4 barg barg 4096 Jun 20 12:34 lib/ drwxrwxr-x 7 barg barg 4096 Aug 9 09:41 pcgi/ -rwx--x--x 1 barg barg 194 Aug 20 12:29 start* -rwx--x--x 1 barg barg 166 Aug 9 15:04 start.debug* -rwx--x--x 1 barg barg 54 Aug 9 09:41 stop* drwxrwxr-x 2 barg barg 4096 Aug 9 09:41 utilities/ drwxrwxr-x 2 nobody barg 4096 Aug 20 12:29 var/ -rw-r--r-- 1 barg barg 25418 Mar 8 14:41 z2.py -rw-r--r-- 1 barg barg 15777 Aug 9 09:41 z2.pyc -rw-r--r-- 1 barg barg 9546 Dec 7 2000 zpasswd.py -rw-r--r-- 1 barg barg 6424 Aug 9 09:41 zpasswd.pyc
I apologize for this long post, but, this is REALLY bugging me. Thank you, -- irene ---------------------------------------------------------------- Irene Barg Email: ibarg@as.arizona.edu Steward Observatory Phone: 520-621-2602 933 N. Cherry Ave. University of Arizona FAX: 520-621-1891 Tucson, AZ 85721 http://nickel.as.arizona.edu/~barg ----------------------------------------------------------------
-- ---------------------------------------------------------------- Irene Barg Email: ibarg@as.arizona.edu Steward Observatory Phone: 520-621-2602 933 N. Cherry Ave. University of Arizona FAX: 520-621-1891 Tucson, AZ 85721 http://nickel.as.arizona.edu/~barg ----------------------------------------------------------------