We have Plone/Zope and Apache all running. I thought that we had it right until I tried to access the the zope 'manage' area from my home. Our configuration is: Debian : testing (sarge) Zope : 2.6.2 ZopeCMF : 1.3.2 Plone : 1.0.5 Here is what I see from my home location. http://OurSite.com/plone looks just fine http://OurSite.com/manage does not show the Control Panel, but looks like most of the other stuff is there.
From the location where we have the install, http://OurSite.com:9673/manage shows the Control Panel
My question is why can't I see the Control Panel (I can't restart Zope, among other things) from home? Could it be our httpd.conf configuration? We use a VirtualHost block with the following RewriteRule RewriteRule ^/(.*) http://127.0.0.1:9673/VirtualHostBase/http/ OurSite.com:80/ploneFolder/VirtualHostRoot/$1 [L,P] where ploneFolder is a folder created in Zope root and in which we have Plone. I can't access the site using port 9673 from home as it is closed off. Any clues? Thanks! dennis - have gudulka, will travel http://KafanaKlub.com
Dennis Godfrey wrote:
We have Plone/Zope and Apache all running. I thought that we had it right until I tried to access the the zope 'manage' area from my home.
Our configuration is: ...
Here is what I see from my home location. http://OurSite.com/plone looks just fine http://OurSite.com/manage does not show the Control Panel, but looks like most of the other stuff is there.
From the location where we have the install, http://OurSite.com:9673/manage shows the Control Panel
My question is why can't I see the Control Panel (I can't restart Zope, among other things) from home?
Because you're being mapped into your Plone folder and not the site root. It's the same as saying http://OurSite.com/ploneFolder/manage I don't know why http://OurSite.com/plone works, unless you actually meant http://OurSite.com/ploneFolder (in which case acquisition is allowing the equivalent of http://OurSite.com/ploneFolder/ploneFolder to work right) or you have some other object called 'plone'.
Could it be our httpd.conf configuration? We use a VirtualHost block with the following RewriteRule RewriteRule ^/(.*) http://127.0.0.1:9673/VirtualHostBase/http/ OurSite.com:80/ploneFolder/VirtualHostRoot/$1 [L,P]
where ploneFolder is a folder created in Zope root and in which we have Plone.
I can't access the site using port 9673 from home as it is closed off.
Using the port like that goes direct to ZServer and skips the rewrite. As such, http://OurSite.com:8080/manage actually means 'manage' at the root. One thing you may do is create a subdomain that maps to the root rather than a subfolder, so that http://manage.OurSite.com/ would give you the root, and http://manage.OurSite.com/manage would be 'manage' on root. --jcc -- "My point and period will be throughly wrought, Or well or ill, as this day's battle's fought."
thanks for the quick reply.
Because you're being mapped into your Plone folder and not the site root. It's the same as saying http://OurSite.com/ploneFolder/manage
I think that I mis-typed. That should be OurSite.com/plone I actualy get a slightly different view between http://OurSite.com/plone/manage - I only see the plone site http://OurSite.com/manage - I see the Root Folder and acl_users and plone site (and no Control Panel)
I don't know why http://OurSite.com/plone works, unless you actually meant http://OurSite.com/ploneFolder (in which case acquisition is allowing the equivalent of http://OurSite.com/ploneFolder/ploneFolder to work right) or you have some other object called 'plone'.
I think the RewriteRule does the trick. ...
One thing you may do is create a subdomain that maps to the root rather than a subfolder, so that http://manage.OurSite.com/ would give you the root, and http://manage.OurSite.com/manage would be 'manage' on root.
Oh, that's an idea. To tell the truth, another person and I have debated whether is makes sense to put separate plone sites in separate folders and make a VirtualHost with each one OR just place each plone instance at Root. We don't know and haven't been able to find arguments either way (except among ourselves. :-) Since we are spanking new to Zope and Plone, we felt it might be a good idea to have a real site and a playground site. So, we created two folders and in each one is Plone and two VirtualHosts in httpd.conf. We may want, in the future, to create additional Plone site, so some good hints from others who have trod this path are very welcome. dennis - have gudulka, will travel http://KafanaKlub.com
Dennis Godfrey wrote:
Oh, that's an idea. To tell the truth, another person and I have debated whether is makes sense to put separate plone sites in separate folders and make a VirtualHost with each one OR just place each plone instance at Root.
In general, the root of the zodb should be considered "special" and not directly used to store content. It is always advisable to create a folder (or folders) in the root of the zodb and build a site from within it (them), rather than directly mapping the root URI of the site to the root of the zodb. This is because there exist a number of special objects (HelpSys, Control_Panel, etc.) in the root folder which shouldn't be publically exposed if they have no good reason to be. Of course, even when you store your site content entirely within a folder in the root of the zodb, if you don't change the default permissions of root container these special objects will still be traversable thanks to acquistion, so you'll need to investigate the root container permissions and lock them down to gain any real advtange from this layout. -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa
Quoting Jamie Heilman <jamie@audible.transient.net>:
In general, the root of the zodb should be considered "special" and not directly used to store content. It is always advisable to create a folder (or folders) in the root of the zodb and build a site from within it (them), rather than directly mapping the root URI of the site to the root of the zodb.
I kind of like this from the standpoint of ZMI asthetics, and you provided additional reasons why this is a good idea. But does that mean that one is always using Apache mapped down one level into the Zope hierarchy to avoid urls like http://mysite.com/mysite/? And what if you are using ZServer directly? then do you have to use the Virtual Host Monster to remap the url? (And am I the only one who thinks it is weird to have a specialty web server (presumably for specific functionality) and then ALWAYS proxy it through a different web server?) -- Cynthia Kiser cnk@caltech.edu
On Wed, 2003-11-19 at 17:25, Cynthia Kiser wrote:
But does that mean that one is always using Apache mapped down one level into the Zope hierarchy to avoid urls like http://mysite.com/mysite/? And what if you are using ZServer directly? then do you have to use the Virtual Host Monster to remap the url?
Yes and yes. Since it's an aesthetic issue, the value of doing this is totally up to you.
(And am I the only one who thinks it is weird to have a specialty web server (presumably for specific functionality) and then ALWAYS proxy it through a different web server?)
It's less weird if you think of Zope as a development platform... that's where it excels. As a web server, it's merely adequate. Zope's built-in web server is good enough for a decent range of applications... but since it's just as easy to run best-of-breed software in both roles, that's what most people here choose to do. $.02, Dylan
Quoting Dylan Reinhardt <zope@dylanreinhardt.com>:
(And am I the only one who thinks it is weird to have a specialty web server (presumably for specific functionality) and then ALWAYS proxy it through a different web server?)
It's less weird if you think of Zope as a development platform... that's where it excels. As a web server, it's merely adequate.
Zope's built-in web server is good enough for a decent range of applications... but since it's just as easy to run best-of-breed software in both roles, that's what most people here choose to do.
I don't really think that explanation holds water because you can't NOT run ZServer after your development is done. You just end up running a second layer of web server in front of the obligatory ZServer one. One of the recent emailed links (http://audible.transient.net/zope/#root) has me more or less convinced I have to start running my ZServer behind something else for safety. Annoying but I don't have the Python + security skills to go after the issue I wish were addressed so am stuck. -- Cynthia Kiser
On Wed, 2003-11-19 at 18:27, Cynthia Kiser wrote:
Quoting Dylan Reinhardt <zope@dylanreinhardt.com>:
(And am I the only one who thinks it is weird to have a specialty web server (presumably for specific functionality) and then ALWAYS proxy it through a different web server?)
It's less weird if you think of Zope as a development platform... that's where it excels. As a web server, it's merely adequate.
Zope's built-in web server is good enough for a decent range of applications... but since it's just as easy to run best-of-breed software in both roles, that's what most people here choose to do.
I don't really think that explanation holds water because you can't NOT run ZServer after your development is done.
It used to be more common to run Zope as a cgi. That's not common usage any more... but IMO, Zope's essential role is unchanged.
You just end up running a second layer of web server in front of the obligatory ZServer one.
But the second layer isn't obligatory at all... just smart. :-)
One of the recent emailed links (http://audible.transient.net/zope/#root) has me more or less convinced I have to start running my ZServer behind something else for safety.
Yep.
Annoying but I don't have the Python + security skills to go after the issue I wish were addressed so am stuck.
Well... that's a bigger problem. I'd like to tell you there is such thing as a secure, ready-made web app platform that's easy to set up and run... but if there is, I haven't been made aware of it. I'm not sure there ever will be such a product, either. Zope makes a lot of things easier than they used to be, but a lot of this is still difficult. I wish you the very best as you work through the documentation and pick up as much knowledge as you can get your hands on. I'm sure you'll find this list a good resource for tips & clarification as you proceed. HTH, Dylan
participants (5)
-
Cynthia Kiser -
Dennis Godfrey -
Dylan Reinhardt -
J. Cameron Cooper -
Jamie Heilman