Hi all When I open a local Zope instance's WebDAV source port using Cadaver, it works fine:: jean@blommie python $ cadaver dav:!> open blommie:13800 Looking up hostname... Connecting to server... connected. Connecting to server... connected. dav:/> ls Listing collection `/': (reconnecting...done) succeeded. Coll: Accounting 0 Apr 9 10:49 Coll: Catalog 0 Apr 10 07:49 [... etc ...] However, when I try to forward a remote instance's WebDAV source port via ssh, I get the following behaviour:: jean@blommie lib $ ssh -l jean -L 8888:remote.co.za:8800 remote.co.za jean@remote.co.za's password: Last login: Mon Apr 15 16:30:44 2002 from local.co.za [jean@diepdink jean]$ jean@blommie python $ cadaver dav:!> open localhost:8888 Looking up hostname... Connecting to server... connected. Connecting to server... connected. Connecting to server... connected. [... for ever ...] At the same time, I see this in the remote shell:: [jean@diepdink jean]$ channel 2: open failed: connect failed: Connection refused [... for ever ...] I tried this a while back too: http://lists.zope.org/pipermail/zope/2002-January/107871.html but there were no responses, and I haven't been able to figure out what's wrong in the meantime either .. -- Jean Jordaan Upfront Systems http://www.upfrontsystems.co.za
Hi all In case this helps: here's the output of TCPWatch for the unsuccessfully forwarded port. (Basically, it seems to show that the session stays connected for somewhere between 0.1 and 0.01 seconds.):: [00:00.000 - client 127.0.0.1:56914 forwarded to :8888] ==>OPTIONS / HTTP/1.1 ==>User-Agent: cadaver/0.17.0 neon/0.12.0-dev ==>Keep-Alive: ==>Connection: TE, Keep-Alive ==>TE: trailers ==>Content-Length: 0 ==>Host: localhost:8889 ==> [00:00.003 - server connected] [00:00.118 - server closed] [00:00.000 - client 127.0.0.1:56916 forwarded to :8888] ==>OPTIONS / HTTP/1.1 ==>User-Agent: cadaver/0.17.0 neon/0.12.0-dev ==>Keep-Alive: ==>Connection: TE, Keep-Alive ==>TE: trailers ==>Content-Length: 0 ==>Host: localhost:8889 ==> [00:00.003 - server connected] [00:00.028 - client closed] [... etc ...] This is what a successful connection to a local Zope looks like:: Forwarding :13801 -> :13800 [00:00.000 - client 127.0.0.1:58956 forwarded to :13800] ==>OPTIONS / HTTP/1.1 ==>User-Agent: cadaver/0.17.0 neon/0.12.0-dev ==>Keep-Alive: ==>Connection: TE, Keep-Alive ==>TE: trailers ==>Content-Length: 0 ==>Host: localhost:13801 ==> [00:00.003 - server connected] <==HTTP/1.1 200 OK <==Server: Zope/(Zope 2.4.3 (binary release, python 2.1, linux2-x86), python 2.1.1, linux2) ZServer/1.1b1 [... etc ...] -- Jean Jordaan Upfront Systems http://www.upfrontsystems.co.za
Hi, On Mon, Apr 15, 2002 at 05:44:37PM +0200, Jean Jordaan wrote:
When I open a local Zope instance's WebDAV source port using Cadaver, it works fine::
The infinite loop was due to a bug in old versions of cadaver: I suggest you upgrade to 0.19.1. ...
However, when I try to forward a remote instance's WebDAV source port via ssh, I get the following behaviour::
jean@blommie lib $ ssh -l jean -L 8888:remote.co.za:8800 remote.co.za jean@remote.co.za's password: Last login: Mon Apr 15 16:30:44 2002 from local.co.za [jean@diepdink jean]$ ... [jean@diepdink jean]$ channel 2: open failed: connect failed: Connection refused [... for ever ...]
AFAIK this simply means that the ssh process running on the remote machine couldn't connect to remote.co.za on port 8800: running $ telnet remote.co.za 8800 from the ssh session should give the same results? (if so, is the server running, etc etc) Regards, joe
Hi Joe
The infinite loop was due to a bug in old versions of cadaver: I suggest you upgrade to 0.19.1.
OK, I'll give that a shot. OK, now I don't get an infinite loop, I get this instead:: dav:!> open localhost:8888 Looking up hostname... Connecting to server... connected. Could not contact server: Could not read status line: connection was closed by server.
AFAIK this simply means that the ssh process running on the remote machine couldn't connect to remote.co.za on port 8800: running
$ telnet remote.co.za 8800
from the ssh session should give the same results? (if so, is the server running, etc etc)
The server is definately running. I'm forwarding :8888 on local to :8800 on remote:: jean@local lib $ ssh -L 8888:remote.co.za:8800 remote.co.za jean@remote.co.za's password: Last login: Mon Apr 15 16:31:03 2002 from local.co.za If I telnet to 8800 when logged in on remote, I connect successfully:: [jean@remote jean]$ telnet localhost 8800 Trying 127.0.0.1... Connected to localhost (127.0.0.1). Escape character is '^]'. But when I telnet to the forwarded port 8888 when logged in on local, I disconnect immediately:: jean@local lib $ telnet localhost 8888 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Connection closed by foreign host. I can't telnet from local to remote (telnet remote.co.za 8800): firewalled. Which is why I want to forward the port. I strongly get the feeling that I'm just not understanding ssh port forwarding well enough .. -- Jean Jordaan Upfront Systems http://www.upfrontsystems.co.za
On Tue, Apr 16, 2002 at 09:44:39AM +0200, Jean Jordaan wrote:
Hi Joe
The infinite loop was due to a bug in old versions of cadaver: I suggest you upgrade to 0.19.1.
OK, I'll give that a shot. OK, now I don't get an infinite loop, I get this instead::
dav:!> open localhost:8888 Looking up hostname... Connecting to server... connected. Could not contact server: Could not read status line: connection was closed by server.
Much better :) ...
If I telnet to 8800 when logged in on remote, I connect successfully::
[jean@remote jean]$ telnet localhost 8800 Trying 127.0.0.1... Connected to localhost (127.0.0.1). Escape character is '^]'.
Ah ha, then you really want to be using: ssh -L 8888:localhost:8800 remote.co.za you understand this after playing about with it a bit. e.g. -L 8888:www.openssh.org:80 would mean "listen for connections to port 8888 on the local side. tunnel these through the ssh session, and, from the remote side, connect them through to www.openssh.org port 80" BTW, you may have problems using tunnelled connections and WebDAV with the COPY and MOVE methods, if the server doesn't know it can be called "localhost". With Apache/mod_dav you'd need to add "ServerAlias localhost" to the virtual host in httpd.conf. I don't know if that's sufficient for Zope too. Regards, joe
Joe, you're an ainjel!!
Ah ha, then you really want to be using:
ssh -L 8888:localhost:8800 remote.co.za
dav:!> open localhost:8888 Looking up hostname... Connecting to server... connected. Connecting to server... connected. dav:/> ls Listing collection `/': (reconnecting...done) succeeded. Beautiful :)) At the moment I still feel that that ssh syntax is perfectly opaque, and that the manpage doesn't help .. I'll continue to strive for enlightenment. I also tried: ssh -L 8888:blommie:8800 remote.co.za (the name of the local machine is 'blommie') but this got me:: dav:!> open blommie:8888 Looking up hostname... Connecting to server... Could not connect to remote host. i.e. nothing doing on blommie; however 'localhost' connects (this was strange to me -- why would blommie be unknown, and not localhost?):: dav:!> open localhost:8888 Looking up hostname... Connecting to server... connected. Could not contact server: Could not read status line: connection was closed by server. but is immediately refused:: [jean@remote jean]$ channel 2: open failed: administratively prohibited: open failed -- Jean Jordaan Upfront Systems http://www.upfrontsystems.co.za
Hi there .. me again I'm trying to get 'sitecopy' working across the ssh tunnel, but I get a bunch of errors:: Downloading news.htm: [] failed: 500 Internal Server Error The files are created locally, but they all have a size of 0. It's a problem with authentication. When I 'get' a resource in the 'feko_usa' folder, I'm not prompted for authentication, and the 'get' fails. When I 'get' in the root, I am prompted and the 'get' succeeds. When I *now* 'get' the resource in the 'feko_usa' folder, it also succeeds, since I've had a chance to authenticate. Here's a transcript that illustrates the issue:: jean@blommie tmp $ cadaver dav:!> open localhost:8888 Looking up hostname... Connecting to server... connected. Connecting to server... connected. dav:/> cd feko_usa Connecting to server... connected. dav:/feko_usa/> get news.htm Enter local filename for `/feko_usa/news.htm': news.htm Downloading `/feko_usa/news.htm' to news.htm: (reconnecting...done) Progress: [=============================>] 100.0% of 3926 bytes failed: 500 Internal Server Error dav:/feko_usa/> get ../index_html Downloading `/index_html' to index_html: Progress: [=============================>] 100.0% of 2208 bytes Authentication required for Zope on server `localhost': Username: jean Password: Progress: [==============================] 225.5% of 1759 bytes succeeded. dav:/feko_usa/> get news.htm Enter local filename for `/feko_usa/news.htm': news.htm Downloading `/feko_usa/news.htm' to news.htm: Progress: [=============================>] 100.0% of 4468 bytes succeeded. dav:/feko_usa/> (I also notice a "225.5% of 1759 bytes succeeded" which can't be intentional.) So is it possible to force sitesync to authenticate as a specific user before attempting downloads, when connecting via WebDAV? And does anyone know why Zope would not trigger an authentication prompt in a subfolder? (This is Zope 2.4.3 on Linux, sitecopy 0.10.15 with bundled neon 0.11.0, and cadaver 0.19.1 with bundled neon 0.18.3) -- Jean Jordaan Upfront Systems http://www.upfrontsystems.co.za
Ensure that you use the latest Zope version (at least latest 2.4.X from the CVS). If the problem persists, use the WebDAVLogger product to get any additional debug information from the WebDAV protocol layer. -aj ----- Original Message ----- From: "Jean Jordaan" <jean@upfrontsystems.co.za> To: "Joe Orton" <joe@manyfish.co.uk> Cc: "Cadaver@Webdav. Org" <cadaver@webdav.org>; "Zope@Zope. Org" <zope@zope.org> Sent: Tuesday, April 16, 2002 06:40 Subject: [Zope] RE: [cadaver] Trouble forwarding Zope's WebDAV source port
Hi there .. me again
I'm trying to get 'sitecopy' working across the ssh tunnel, but I get a bunch of errors::
Downloading news.htm: [] failed: 500 Internal Server Error
The files are created locally, but they all have a size of 0. It's a problem with authentication. When I 'get' a resource in the 'feko_usa' folder, I'm not prompted for authentication, and the 'get' fails. When I 'get' in the root, I am prompted and the 'get' succeeds. When I *now* 'get' the resource in the 'feko_usa' folder, it also succeeds, since I've had a chance to authenticate.
Here's a transcript that illustrates the issue::
jean@blommie tmp $ cadaver dav:!> open localhost:8888 Looking up hostname... Connecting to server... connected. Connecting to server... connected. dav:/> cd feko_usa Connecting to server... connected. dav:/feko_usa/> get news.htm Enter local filename for `/feko_usa/news.htm': news.htm Downloading `/feko_usa/news.htm' to news.htm: (reconnecting...done) Progress: [=============================>] 100.0% of 3926 bytes failed: 500 Internal Server Error dav:/feko_usa/> get ../index_html Downloading `/index_html' to index_html: Progress: [=============================>] 100.0% of 2208 bytes Authentication required for Zope on server `localhost': Username: jean Password: Progress: [==============================] 225.5% of 1759 bytes succeeded. dav:/feko_usa/> get news.htm Enter local filename for `/feko_usa/news.htm': news.htm Downloading `/feko_usa/news.htm' to news.htm: Progress: [=============================>] 100.0% of 4468 bytes succeeded. dav:/feko_usa/>
(I also notice a "225.5% of 1759 bytes succeeded" which can't be intentional.)
So is it possible to force sitesync to authenticate as a specific user before attempting downloads, when connecting via WebDAV?
And does anyone know why Zope would not trigger an authentication prompt in a subfolder?
(This is Zope 2.4.3 on Linux, sitecopy 0.10.15 with bundled neon 0.11.0, and cadaver 0.19.1 with bundled neon 0.18.3)
-- Jean Jordaan Upfront Systems http://www.upfrontsystems.co.za
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Hi all
Ensure that you use the latest Zope version (at least latest 2.4.X from the CVS).
We'll try this when we can, but for now we have 2.4.3 deployed, and will have to work with it for a while until we can upgrade clients.
If the problem persists, use the WebDAVLogger product to get any additional debug information from the WebDAV protocol layer.
OK, I tried that, but unless I'm missing something, I'm afraid it doesn't help (see logs below). Is there anything I should look for? One thing I notice is that the local Zope answers the initial GET with a 401, while the tunneled Zope answers it with a 500 (see below). On a local Zope (which does prompt for authentication in 'feko_usa', as I would expect) nothing to do with authentication shows up in the WebDAV log at all, when I do this:: dav:/> open localhost:13800 Looking up hostname... Connecting to server... connected. Connecting to server... connected. dav:/> cd feko_usa Connecting to server... connected. dav:/feko_usa/> cat news.htm Displaying `/feko_usa/news.htm': Connecting to server... connected. Authentication required for Zope on server `localhost': Username: jean Password: (When I try that thru the ssh tunnel, the only difference is:: dav:!> open localhost:8888 Looking up hostname... Connecting to server... connected. Connecting to server... connected. [... snip ...] dav:/feko_usa/> cat news.htm Displaying `/feko_usa/news.htm': Connecting to server... connected. Failed: 500 Internal Server Error ). Here follow part of the logs of those actions. The WebDAV section is in response to 'cd feko_usa'. The section from Z2.log is the only trace of 'cat news.htm':: --------------------------------------------------------------------------- --- Response: Timediff: 0.1949 seconds HTTP/1.1 207 Multi-Status Server: Zope/(Zope 2.4.3 (binary release, python 2.1, linux2-x86), python 2.1.1, linux2) ZServer/1.1b1 Date: Tue, 16 Apr 2002 14:02:44 GMT Ms-Author-Via: DAV Content-Type: text/xml; charset="utf-8" Connection: close Date: Tue, 16 Apr 2002 14:02:44 GMT Content-Length: 640 <?xml version="1.0" encoding="utf-8"?> <d:multistatus xmlns:d="DAV:"> <d:response> <d:href>/feko_usa/</d:href> <d:propstat> <d:prop> <n:getcontentlength xmlns:n="DAV:"></n:getcontentlength> <n:getlastmodified xmlns:n="DAV:">Mon, 08 Oct 2001 10:37:37 GMT</n:getlastmodified> <n:displayname xmlns:n="DAV:">feko_usa</n:displayname> <n:resourcetype xmlns:n="DAV:"><n:collection/></n:resourcetype> </d:prop> <d:status>HTTP/1.1 200 OK</d:status> </d:propstat> <d:propstat> <d:prop> <n:executable xmlns:n="http://apache.org/dav/props/"/> </d:prop> <d:status>HTTP/1.1 404 Not Found</d:status> </d:propstat> </d:response> </d:multistatus> ==> var/Z2.log <== 127.0.0.1 - Anonymous [16/Apr/2002:16:02:44 +0200] "PROPFIND /feko_usa/ HTTP/1.1" 207 948 "" "cadaver/0.19.1 neon/0.18.3" 127.0.0.1 - Anonymous [16/Apr/2002:16:03:01 +0200] "GET /feko_usa/news.htm HTTP/1.1" 401 3543 "" "cadaver/0.19.1 neon/0.18.3" 127.0.0.1 - jean [16/Apr/2002:16:03:05 +0200] "GET /feko_usa/news.htm HTTP/1.1" 200 4233 "" "cadaver/0.19.1 neon/0.18.3" Here is the corresponding fragment of Z2.log on the remote machine:: 127.0.0.1 - Anonymous [16/Apr/2002:16:14:01 +0200] "PROPFIND /feko_usa/ HTTP/1.1" 207 948 "" "cadaver/0.19.1 neon/0.18.3" 127.0.0.1 - Anonymous [16/Apr/2002:16:14:21 +0200] "GET /feko_usa/news.htm HTTP/1.1" 500 4349 "" "cadaver/0.19.1 neon/0.18.3" I notice that on the local machine there are *two* requests for 'news.htm': the first one as Anonymous, which triggers the cadaver authentication prompt, and the next as 'jean', after authentication. In the forwarded case, the Zope server returns a 500 instead of a 401. It looks as though this might be the problem: if only Zope can tell cadaver '401', it should prompt. As it does from the root:: 127.0.0.1 - Anonymous [16/Apr/2002:16:25:34 +0200] "PROPFIND / HTTP/1.1" 207 931 "" "cadaver/0.19.1 neon/0.18.3" 127.0.0.1 - Anonymous [16/Apr/2002:16:25:38 +0200] "GET /index_html HTTP/1.1" 401 2659 "" "cadaver/0.19.1 neon/0.18.3" 127.0.0.1 - jean [16/Apr/2002:16:25:45 +0200] "GET /index_html HTTP/1.1" 200 1966 "" "cadaver/0.19.1 neon/0.18.3" I'll see whether the latest 2.4 also behaves like this when I have a chance. Thanks for all the help so far .. -- Jean Jordaan Upfront Systems http://www.upfrontsystems.co.za
Hi all I've found the problem! The subdirectory in question uses LoginManager for authentication. In the local site, its 'loginForm' method raises 'Unauthorized' (which uses Basic authentication); in the remote site, it raises 'LoginRequired' (which uses cookie-based authentication). Obviously neither cadaver nor sitecopy has any idea of cookies. I've changed 'loginForm' to use Basic authentication, and now all is well. Thanks for all the help .. I think I understand webdav and ssh a bit better now! -- Jean Jordaan Upfront Systems http://www.upfrontsystems.co.za
Hi there Has anyone else noticed any funnies when doing a WebDAV GET of a PDF? I'm using sitecopy to make a local copy of a site. When this file was reached:: Downloading feko_usa/pdf/Feko_ShortCourse_April2002.pdf: [] failed: Could not read response body: connection timed out. Zope stopped accepting connections. The above showed the following in z2.log:: Unhandled exception in thread: Traceback (most recent call last): File "/usr/local/zope/2-4-3_for_diepdink/ZServer/PubCore/ZServerPublisher.py", line 97, in __init__ File "/usr/local/zope/2-4-3_for_diepdink/ZServer/HTTPResponse.py", line 273, in _finish File "/usr/local/zope/2-4-3/lib/python/Products/WebDAVLogger/__init__.py", line 56, in mywrite File "/usr/local/zope/2-4-3/lib/python/Products/WebDAVLogger/__init__.py", line 32, in _log TypeError: expected string or buffer This happened twice .. but since the last Zope restart, sitecopy has also run successfully twice, so I can't make it reproducable:: Downloading feko_usa/pdf/Feko_ShortCourse_April2002.pdf: [.......................] done. (Zope 2.4.3 on Linux) -- Jean Jordaan Upfront Systems http://www.upfrontsystems.co.za
That is a problem of the WebDAV logger but not the WebDAV support. Remove the WebDAVLogger product as workaround. -aj ----- Original Message ----- From: "Jean Jordaan" <jean@upfrontsystems.co.za> To: "Zope@Zope. Org" <zope@zope.org> Sent: Wednesday, April 17, 2002 08:40 Subject: [Zope] Exception raised by WebDAV GET of a PDF file
Hi there
Has anyone else noticed any funnies when doing a WebDAV GET of a PDF?
I'm using sitecopy to make a local copy of a site. When this file was reached::
Downloading feko_usa/pdf/Feko_ShortCourse_April2002.pdf: [] failed: Could not read response body: connection timed out.
Zope stopped accepting connections. The above showed the following in z2.log::
Unhandled exception in thread: Traceback (most recent call last): File "/usr/local/zope/2-4-3_for_diepdink/ZServer/PubCore/ZServerPublisher.py", line 97, in __init__ File "/usr/local/zope/2-4-3_for_diepdink/ZServer/HTTPResponse.py", line 273, in _finish File "/usr/local/zope/2-4-3/lib/python/Products/WebDAVLogger/__init__.py", line 56, in mywrite File "/usr/local/zope/2-4-3/lib/python/Products/WebDAVLogger/__init__.py", line 32, in _log TypeError: expected string or buffer
This happened twice .. but since the last Zope restart, sitecopy has also run successfully twice, so I can't make it reproducable::
Downloading feko_usa/pdf/Feko_ShortCourse_April2002.pdf: [.......................] done.
(Zope 2.4.3 on Linux)
-- Jean Jordaan Upfront Systems http://www.upfrontsystems.co.za
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Hi Andreas
That is a problem of the WebDAV logger but not the WebDAV support. Remove the WebDAVLogger product as workaround.
Ah, thanks! That's why it started working again -- I had already removed WebDAVLogger, but it stayed resident until I restarted Zope. -- Jean Jordaan Upfront Systems http://www.upfrontsystems.co.za
A fix for the WebDAVLogger is in the CVS on cvs.zope.org/Packages/WebDAVLogger. -aj ----- Original Message ----- From: "Jean Jordaan" <jean@upfrontsystems.co.za> To: "Andreas Jung" <andreas@zope.com>; "Zope@Zope. Org" <zope@zope.org> Sent: Wednesday, April 17, 2002 09:14 Subject: RE: [Zope] Exception raised by WebDAV GET of a PDF file
Hi Andreas
That is a problem of the WebDAV logger but not the WebDAV support. Remove the WebDAVLogger product as workaround.
Ah, thanks! That's why it started working again -- I had already removed WebDAVLogger, but it stayed resident until I restarted Zope.
-- Jean Jordaan Upfront Systems http://www.upfrontsystems.co.za
For some time we have been using Zope onboth W2K and Redhat 7.2 without any mayor problems. We have been following the mailing list for a while now, but this is new to us. We just bought a brand new pre installed webserver (Dell PowerApp) running linux RH 7.0(?) After unpacking and installing Zope we tried to start Zope using ./start and got the following error: 2002-04-17T12:45:45 PANC (300) z2 startup exception Traceback (innermost last): File /usr/local/zope/2-5-0/z2.py line 556, in ? File /usr/local/zope/2-5-0/ZServer/HTTPServer.py, line 320 in __init__ File /usr/local/zope/2-5-0/ZServer/medusa/http_server.py, line 570 in __init__ File /usr/local/zope/2-5-0/ZServer/medusa/asyncore.py, line 306, in bind error: (998, 'Address already in use') Apparantly Zope is trying to access a port already assigned. Is there any workaround this? TIA, Roel
You probably need to modify the start file and change the port(s) that zope will use when starting. I believe there are three arguments that can be passed -w portnumber "ZServer", -W portnumber "WebDAV" and -f portnumber "ftp" . Adding these arguments will change the ports that zope uses. Here is what mine looks like
snip<
$INST_HOME/z2.py -w80 -W9001\ "$@" ----- Original Message ----- From: Roel Van den Bergh <roel@planetinterior.com> To: Zope@Zope. Org <zope@zope.org> Sent: Wednesday, April 17, 2002 6:32 AM Subject: [Zope] Problem Starting Zope PANIC (300)
For some time we have been using Zope onboth W2K and Redhat 7.2 without any mayor problems. We have been following the mailing list for a while now, but this is new to us.
We just bought a brand new pre installed webserver (Dell PowerApp) running linux RH 7.0(?) After unpacking and installing Zope we tried to start Zope using ./start and got the following error:
2002-04-17T12:45:45 PANC (300) z2 startup exception Traceback (innermost last): File /usr/local/zope/2-5-0/z2.py line 556, in ? File /usr/local/zope/2-5-0/ZServer/HTTPServer.py, line 320 in __init__ File /usr/local/zope/2-5-0/ZServer/medusa/http_server.py, line 570 in __init__ File /usr/local/zope/2-5-0/ZServer/medusa/asyncore.py, line 306, in bind error: (998, 'Address already in use')
Apparantly Zope is trying to access a port already assigned. Is there any workaround this?
TIA, Roel
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Problems solved, thanks for all the help Changed port to 8000 (./start -w8000) and everything seems to work fine Roel PS -w80 already taken by other applicition :-)
-----Oorspronkelijk bericht----- Van: zope-admin@zope.org [mailto:zope-admin@zope.org]Namens Todd Graham Verzonden: woensdag 17 april 2002 15:46 Aan: roel@planetinterior.com; Zope@Zope. Org Onderwerp: Re: [Zope] Problem Starting Zope PANIC (300)
You probably need to modify the start file and change the port(s) that zope will use when starting. I believe there are three arguments that can be passed -w portnumber "ZServer", -W portnumber "WebDAV" and -f portnumber "ftp" . Adding these arguments will change the ports that zope uses. Here is what mine looks like
snip<
$INST_HOME/z2.py -w80 -W9001\ "$@"
participants (6)
-
Andreas Jung -
Andreas Jung -
Jean Jordaan -
Joe Orton -
Roel Van den Bergh -
Todd Graham