Tutorial problem: accessing Toolbox from 127.0.0.1
Back2Python
docs.turbogears.org/1.0/Wiki20/Page3). So far so good, except that I
can't access Toolbox even though my client is on the same machine as
the http server. I get this pretty ironic error:
No access for 127.0.0.1
By default only localhost (127.0.0.1) has access to the Toolbox
You can provide access to your client by passing your host address to
Toolbox as a parameter. Ex:
tg-admin toolbox -c 127.0.0.1
I have no proxy configured in Firefox. I tried the "-c" option by
adding 127.0.0.1 (even though it shouldn't be needed) or my network IP
address and still no success. I tried to invoke while disconnected
from the network (so I have no other IP than 127.0.0.1) and still no
luck. The weird thing is that I assume the first line repeats my IP
address as it sees it, so it knows I am 127.0.0.1. So why is this
rejected?
The suggestion to try "tg-admin toolbox -c 127.0.0.1" doesn't return
any hit on Google so it sounds like not many people have had the same
problem. Or they've all been smarter than me and figured it on their
own...
Thanks for any help.
B2P
Florent Aide
<allthegoodlogi...@gmail.com> wrote:
>
> I am new to TG. I am on page 3 of the 20 minutes tutorial (http://
> docs.turbogears.org/1.0/Wiki20/Page3). So far so good, except that I
> can't access Toolbox even though my client is on the same machine as
> the http server. I get this pretty ironic error:
>
> No access for 127.0.0.1
Hi,
This is CP which changed the data structure for its cherrypy.request
object... and we needed this upgrade for security reasonfs... I'll fix
this ASAP (in a few minutes).
Sorry for the inconvenience.
If you are not using file based session (it's not the default, so if
you just quickstarted an app you don't need to fear) then you could
temporarily use tg 1.0.4b4 by doing:
easy_install -UZ "TurboGears==1.0.4b4"
the only difference is the requirement on the CP version so you'll be safe.
Regards,
Florent.
iflo_8
I had the same problem this morning.
Thanks a lot for your comment.
It works perfectly with turbogears-1.0.4b4 and cherrypy-2.2.1,
but it won't take 20 minutes now !:)
Good luck for your update..
Florent Aide
>
> Hi,
>
> I had the same problem this morning.
> Thanks a lot for your comment.
>
> It works perfectly with turbogears-1.0.4b4 and cherrypy-2.2.1,
> but it won't take 20 minutes now !:)
Hi Florent,
TG 1.0.4b6 fixes the toolbox issue introduced with the CherryPy 2.3.0 release.
Please try to update to 1.0.4b6.
For the moment the eggs are only available on the TurboGears server
and not on the CheeseShop. They will be uploaded there tonight.
Cheers,
Florent.
PS: sorry for your stats, you'll have a 70 minutes wiki now :-)
Kevin Cole
CherryPy-2.3.0-py2.4.egg
TurboGears-1.0.4b6-py2.4.egg
But now I get:
cherrypy.msg INFO HTTP: Serving HTTP on http://0.0.0.0:8080/
--
Ubuntu Linux DC LoCo
Washington, DC
http://dc.ubuntu-us.org/
Kevin Cole
the cause as some weirdness with that 0.0.0.0. That was not the
issue. All is working, though that's still an odd debugging message
to get.)
Florent Aide
>
> Oops. Never mind. (Something else was failing and I misinterpreted
> the cause as some weirdness with that 0.0.0.0. That was not the
> issue. All is working, though that's still an odd debugging message
> to get.)
0.0.0.0 seems quite normal because it means that the server will
answer on any interface on your system.
In theory if the server said "serving on 127.0.0.1" you should not be
able to connect to it from something else than the loopback interface.
so in this context the new message seems to be more explicit than the
previous one.
Florent.
l3dx
>
>
>
> > Hi,
>
> > I had the same problem this morning.
> > Thanks a lot for your comment.
>
> > It works perfectly with turbogears-1.0.4b4 and cherrypy-2.2.1,
> > but it won't take 20 minutes now !:)
>
> Hi Florent,
>
> Please try to update to 1.0.4b6.
>
> For the moment the eggs are only available on the TurboGears server
> and not on the CheeseShop. They will be uploaded there tonight.
>
> Cheers,
> Florent.
>
> PS: sorry for your stats, you'll have a 70 minutes wiki now :-)
But instead of "No access for 127.0.0.1", I get this message : "No
access for ::ffff:127.0.0.1"
I don't know if this is a different version of the problem, or if it's
something messy in my Ubuntu(7.10) setup.
Anyways...hope there are someone else that know why! :)
Florent Aide
> I also had a similar problem, but this didn't solve it.
Do you mean that using TurboGears 1.0.4b6 you still have an issue to
connect to the toolbox?
> But instead of "No access for 127.0.0.1", I get this message : "No
> access for ::ffff:127.0.0.1"
this seems strange... "::ffff:" resembles an IPV6 address... do you
have a specific setup on this machine ?
Maybe just try to add the exact address which is denied to the command line:
tg-admin toolbox -c <theexactaddresswhichwasrefused>
> I don't know if this is a different version of the problem, or if it's
> something messy in my Ubuntu(7.10) setup.
> Anyways...hope there are someone else that know why! :)
We'll see what we can do.
Florent.
l3dx
I upgraded to 1.0.4.2, but still get the message. But now it works
with "-c ::ffff:127.0.0.1" :)
I don't know if it is because of the upgrade, or if the reason is that
I did something wrong without noticing last time.
-l3dx
On 17 Jan, 23:46, "Florent Aide" <florent.a...@gmail.com> wrote:
>
> > I also had a similar problem, but this didn't solve it.
>
> Do you mean that using TurboGears 1.0.4b6 you still have an issue to
> connect to the toolbox?
>
die...@googlemail.com
there was a tg-admin in /usr/local/bin which was a relict from
installing not by easy_install....
so i deleted that one.
On Jan 23, 11:29 am, l3dx <thomas.skar...@gmail.com> wrote:
> Just wanted to let you know, that I got it to work now.
> I upgraded to 1.0.4.2, but still get the message. But now it works
> with "-c ::ffff:127.0.0.1" :)
> I don't know if it is because of the upgrade, or if the reason is that
> I did something wrong without noticing last time.
>
> -l3dx
>
> On 17 Jan, 23:46, "Florent Aide" <florent.a...@gmail.com> wrote:
>
> > On Jan 17, 2008 9:39 PM, l3dx <thomas.skar...@gmail.com> wrote:
>
> > > I also had a similar problem, but this didn't solve it.
>
> > Do you mean that using TurboGears 1.0.4b6 you still have an issue to
> > connect to the toolbox?
>
> > >accessfor ::ffff:127.0.0.1"
Jorge Godoy
> I got it on my system:
>
> there was a tg-admin in /usr/local/bin which was a relict from
> installing not by easy_install....
> so i deleted that one.
I was thinking about how often this happens here and maybe if we include a
requirement for a specific version of TG in each tg-admin binary we could
minimize those problems.
It would still allow installing different versions if the required version of
TG could be found by the specific tg-admin bein run, so this wouldn't reduce
the possibility of having multiple versions of TG installed that we have
today while it would give a clear message that there is a version mismatch
between the installed TG and tg-admin itself.
--
Jorge Godoy <jgo...@gmail.com>
Chris Arndt
> I was thinking about how often this happens here and maybe if we include a
> requirement for a specific version of TG in each tg-admin binary we could
> minimize those problems.
2.4:
#!/home/chris/lib/tg10-py24/bin/python2.4
# EASY-INSTALL-ENTRY-SCRIPT:
'TurboGears==1.0.4.3','console_scripts','tg-admin'
__requires__ = 'TurboGears==1.0.4.3'
import sys
from pkg_resources import load_entry_point
sys.exit(
load_entry_point('TurboGears==1.0.4.3', 'console_scripts', 'tg-
admin')()
)
Doesn't this mean that tg-admin requires a specific TG version
already?
Chris
Jorge Godoy
>
> Doesn't this mean that tg-admin requires a specific TG version
> already?
Yes, it does... But then, maybe we need a better error message. Maybe trap
the exception from pkg_resources and give a more informative message to the
user.
--
Jorge Godoy <jgo...@gmail.com>
Christopher Arndt
> Em Tuesday 05 February 2008 09:52:08 Chris Arndt escreveu:
>> Doesn't this mean that tg-admin requires a specific TG version
>> already?
>
> Yes, it does... But then, maybe we need a better error message. Maybe trap
> the exception from pkg_resources and give a more informative message to the
> user.
The problem is that this script is only a wrapper script generated by
easy_install from the console script entry point. I don't know if it's
possible to influence the contents of this script.
Chris
Fred Sells
app. I've got 10+ years of Python experience but most of my web stuff to
date is simple cgi or JSP.
Objective: We've got a lot of legacy code that needs to invoke Python to do
some business rule stuff. The API is based on HTTP. Generally there is no
need to respond with a web page, just an "OK" or some simple json. There is
not a significant throughput requirement, 100~1000 hits a day is a good
guess.
But we have numerous small, unrelated or loosely coupled business rules.
I'm developing the business rules as standalone logic with it's own test
scripts, independent of any web related issues; then just placing the on
PYTHONPATH. All this will run on a single server.
What is recommended:
1. A different turbogears project for each "business app" which would then
require a different port. Requires a little config management to keep track
of the ports, but separates them better, and allows independent restart.
2. Or a single project with a "subcontroller" for each business app.
Provides a single "master node" and everything under that. In a small
company (I'm the only Python programmer) this provides ease of tracking
what's "out there".
I realize this is probably subjective, but I would appreciate knowing what
others have encountered. Once I deploy my first app, it's pretty hard to
backtrack, given that the legacy code I'm supporting is out of my hands.
Mark Ramm
> 1. A different turbogears project for each "business app" which would then
> require a different port. Requires a little config management to keep track
> of the ports, but separates them better, and allows independent restart.
>
> 2. Or a single project with a "subcontroller" for each business app.
> Provides a single "master node" and everything under that. In a small
> company (I'm the only Python programmer) this provides ease of tracking
> what's "out there".
I would go the second route personally. You'll have less memory
consumption, cleaner URL structures, and easier deployment.
But I would guess that there might be other things that push towards
the first option. You mention independent restarts, which is an
advantage and a disadvantage (you need ot monitor them all, and make
sure they are all up.) If you hadn't mentioned that traffic was not
an issue, that would be another thing to consider.
---Mark
Christopher Arndt
[something unrelated to the posting he replied to]
Please don't reply to unrelated postings when opening a new topic. Use
the "new message" function of your mail client. Otherwise, your message
gets sorted in the thread of the message to which you were replying and
this is rather annoying.
Chris
Jorge Godoy
> > What is recommended:
> > 1. A different turbogears project for each "business app" which
> > would then require a different port. Requires a little config management
> > to keep track of the ports, but separates them better, and allows
> > independent restart.
> >
> > 2. Or a single project with a "subcontroller" for each business
> > app. Provides a single "master node" and everything under that. In a
> > small company (I'm the only Python programmer) this provides ease of
> > tracking what's "out there".
>
> I would go the second route personally. You'll have less memory
> consumption, cleaner URL structures, and easier deployment.
What I do is a mix of 1 and 2.
Every "business app" is a different TG project, but all of them are imported
in a master app using entry points. So, to add a new app it is just a matter
of installing a new business app and restarting master app (if you don't code
the logic to create links on your main entry page, then you'll have to change
it as well ;-)).
> But I would guess that there might be other things that push towards
> the first option. You mention independent restarts, which is an
> advantage and a disadvantage (you need ot monitor them all, and make
> sure they are all up.) If you hadn't mentioned that traffic was not
> an issue, that would be another thing to consider.
Can't he have them as separate WSGI applications? If he is proxying to TG
then he'll need different ports, but if he's using WSGI then Apache will
start things by itself, right?
--
Jorge Godoy <jgo...@gmail.com>
Lukasz Szybalski
>
> Em Tuesday 05 February 2008 12:12:49 Mark Ramm escreveu:
> > > What is recommended:
> > > 1. A different turbogears project for each "business app" which
> > > would then require a different port. Requires a little config management
> > > to keep track of the ports, but separates them better, and allows
> > > independent restart.
> > >
> > > 2. Or a single project with a "subcontroller" for each business
> > > app. Provides a single "master node" and everything under that. In a
> > > small company (I'm the only Python programmer) this provides ease of
> > > tracking what's "out there".
> >
> > I would go the second route personally. You'll have less memory
> > consumption, cleaner URL structures, and easier deployment.
>
> What I do is a mix of 1 and 2.
>
> Every "business app" is a different TG project, but all of them are imported
> in a master app using entry points.
How would the controller look for that?
>So, to add a new app it is just a matter
> of installing a new business app and restarting master app
Is master app the only one you are setting up as far as apache is concerened?
(if you don't code
> the logic to create links on your main entry page, then you'll have to change
> it as well ;-)).
I don't see how you combine all apps in master since you either have
to have them installed in python path (then import
my3rdapp.controller), or if you use wsgi then you would have to set
the path to each app?
>
> > But I would guess that there might be other things that push towards
> > the first option. You mention independent restarts, which is an
> > advantage and a disadvantage (you need ot monitor them all, and make
> > sure they are all up.) If you hadn't mentioned that traffic was not
> > an issue, that would be another thing to consider.
>
> Can't he have them as separate WSGI applications? If he is proxying to TG
> then he'll need different ports, but if he's using WSGI then Apache will
> start things by itself, right?
yes
Lucas
--
Vehicle Information Number. Check for Authentic VIN
http://lucasmanual.com/vin
TurboGears from start to finish:
http://www.lucasmanual.com/mywiki/TurboGears
Jorge Godoy
>
> By entry point do you just mean a link or you actually importing each app?
> How would the controller look for that?
No. I really mean entry point. Take a look at setuptools. The code is the
same that TG uses to find new components -- e.g. widgets, commands to
tg-admin, etc. -- and we can also benefit of this tool on our applications.
> Is master app the only one you are setting up as far as apache is
> concerened?
Yes.
> I don't see how you combine all apps in master since you either have
> to have them installed in python path (then import
> my3rdapp.controller), or if you use wsgi then you would have to set
> the path to each app?
I use entry points to automatically import them on the master application.
After that, then it is just a matter of importing things, like in modules.
The difference is that it is all done automatically by setuptools.
http://peak.telecommunity.com/DevCenter/setuptools
http://peak.telecommunity.com/DevCenter/setuptools#dynamic-discovery-of-services-and-plugins
--
Jorge Godoy <jgo...@gmail.com>
Lukasz Szybalski
>
> Em Tuesday 05 February 2008 17:12:24 Lukasz Szybalski escreveu:
> >
> > By entry point do you just mean a link or you actually importing each app?
> > How would the controller look for that?
>
> No. I really mean entry point. Take a look at setuptools. The code is the
> same that TG uses to find new components -- e.g. widgets, commands to
> tg-admin, etc. -- and we can also benefit of this tool on our applications.
>
> > Is master app the only one you are setting up as far as apache is
> > concerened?
>
> Yes.
>
> > I don't see how you combine all apps in master since you either have
> > to have them installed in python path (then import
> > my3rdapp.controller), or if you use wsgi then you would have to set
> > the path to each app?
>
> I use entry points to automatically import them on the master application.
> After that, then it is just a matter of importing things, like in modules.
> The difference is that it is all done automatically by setuptools.
>
I read over the website but I don't see how you can do that.
Could you show me some sample code on how does your master app looks like.
Lucas
> http://peak.telecommunity.com/DevCenter/setuptools
> http://peak.telecommunity.com/DevCenter/setuptools#dynamic-discovery-of-services-and-plugins
>
>
> --
> Jorge Godoy <jgo...@gmail.com>
>
>
>
> >
>
--