[Grok-dev] Grok Admin App behind a http server.

Fernando Correa Neto fcdoth at gmail.com
Sat Mar 22 00:08:22 EDT 2008

Hi Uli!

On Fri, Mar 21, 2008 at 8:37 PM, Uli Fouquet <uli at gnufix.de> wrote:
> Hi Fernanando,
>  Fernando Correa Neto wrote:
>  > I am currently trying to set up the grok admin app behind nginx
>  Seems, nginx becomes more and more popular in Zope environments :-)

We are currently building packages for an upcoming hosting business
and grok will be listed. So our team needs to figure out how to make
it work with the possible choices we are going to offer. (Apache and
Nginx for now).

>  >  using
>  > the following proxy_pass statement:
>  >
>  > proxy_pass http://localhost:8080/applications/++vh++http:www.mydomain.com:80/++;
>  >
>  > This doesn't work because it seems that all the resources are loaded
>  > from http://localhost:8080/@@/grok.admin/some_resource.jpg and not
>  > from http://localhost:8080/APPLICATIONS/@@/grok.admin/some_resource.jpg;
>  > I didn't check but this is prooly a custom traverser for that app?
>  I'm not sure, what you mean. The main point here is, that the admin
>  application is currently bound to the root folder. Thus, its name is not
>  'applications' but, well, '/' ('applications' is only a view name).

Mmm...got it now. I got confused because when you try to access for
instance http://localhost:8080/ it redirects you to /applications so I
thought there were some kind of magic going on.

>  It has been discussed here to factor the admin app out of the grok core
>  and I already did an implementation of a 'standalone' admin-UI some
>  months ago. Unfortunately this was a bit overlooked among all the other
>  topics here. Beside this I am a bit scared about it, because a
>  standalone admin app would definitely break many existing installations.

I see there is a constant effort to make grok more componentized so it
can share its componets. Although the admin UI plays an important role
in grok because there is no other way to manage the grok apps, I don't
know where it fits. So if this is not part of the core, will it become
part of something like grokcore.web or something like that?

>  If you think the admin UI should come in an external package and as a
>  'real' grok application (currently it is merely a bunch of views), then
>  we should do that before the 1.0 release.

That would solve *my* problem but I don't know how it would impact in
someone else's life.
Currently we are packaging an empty grok app just to say right after
the sign-up process: "Look. Here is your pre-configured grok
environment." . So having it to work perfectly is something indeed
Just wondering how much effort would be taken to have the grok admin
app self-contained w/o breaking up other apps.

>  > This proxy_pass doesn't work either:
>  >
>  > proxy_pass http://localhost:8080/++vh++http:www.mydomain.com:80/++;
>  >
>  > Has anyone ever served the grok admin interface behind any http server?
>  The same with trailing slash works here with an older nginx version::
>   proxy_pass http://localhost:8080/++vh++http:www.mydomain.com:80/++/;

I didn't test it yet because is quite late here :). Will report as
soon as I test it.

>  What not works then is the docgrok part of the admin UI, which indeed
>  makes use of a custom traverser. This thing is buggy in that respect.
>  I'll try to fix that.

Me too. Tomorrow morning I will test this setup and try to provide
some feedback on docgrok.

>  In the long run I think also the admin-UI should make use of other, more
>  general object-browsers and API-tools. To build such things is currently
>  in discussion for the upcoming GSOC.

Good to know. As I said, the admin UI is something that we rely on to
manage grok apps. So having it to make use of better components is
indeed a good thing.

Thank you!


More information about the Grok-dev mailing list