[Zope] Re: POST works with tcpwatch port,APOLOGIES
Irene Barg
ibarg@as.arizona.edu
Thu, 23 Aug 2001 07:26:22 -0700
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
----------------------------------------------------------------