*** duopollex has joined #zope3-dev | 00:10 | |
duopollex | Hi | 00:10 |
---|---|---|
duopollex | I'm wondering if it's possible to bind the zope3 daemon to a particular IP address. | 00:11 |
*** WebMaven has joined #zope3-dev | 00:11 | |
mexiKON | duopollex, try address ipaddress:port in zope.conf | 00:12 |
duopollex | yea I tried that | 00:12 |
duopollex | as per 2.7 | 00:12 |
duopollex | doesn't work | 00:12 |
mexiKON | hmm | 00:12 |
mexiKON | then i don't know | 00:12 |
duopollex | I keep getting "address in use" .. but it's not | 00:12 |
duopollex | which would indicate it's binding to either localhost, which won't work, or to something elese | 00:13 |
duopollex | ip-address also does not seem to work | 00:13 |
duopollex | the Zope3 book mentions nothing | 00:13 |
duopollex | :| | 00:13 |
dman13 | duopollex: use 'netstat -anp' to find the process that is currently using that port | 00:14 |
duopollex | yea | 00:14 |
duopollex | I know | 00:14 |
dman13 | sometimes there's a surprise when a daemon is running that you didn't thing was running :-) | 00:14 |
duopollex | oh | 00:14 |
duopollex | I know there are other zopes runnign on this server on ip:8080 | 00:14 |
duopollex | but none on that ip | 00:14 |
duopollex | it's unused | 00:14 |
dman13 | oh, ok | 00:14 |
dman13 | I haven't tried to limit zope to just one IP (hmm, I almost never have more than one ip, unless you count localhost :-)) | 00:15 |
duopollex | yea it's making setting this up as a test server for our developers a bit difficult | 00:15 |
duopollex | 'cause they wanted to take a look at it :P | 00:15 |
* duopollex grumbles | 00:15 | |
duopollex | I guess I could just hardcode it | 00:16 |
duopollex | but I'd need to grok the code first :| | 00:16 |
dman13 | or use a different port? | 00:16 |
duopollex | yea I suppose | 00:16 |
duopollex | whoa | 00:17 |
duopollex | gah | 00:17 |
duopollex | it binds to 0.0.0.0 | 00:17 |
duopollex | meh | 00:17 |
dman13 | that means all addresses | 00:17 |
duopollex | yea I know | 00:17 |
dman13 | ok, I didn't know you knew | 00:17 |
duopollex | no worries | 00:18 |
duopollex | I figured it would bind to loopback | 00:18 |
duopollex | I suppose this can be an interim solution :| | 00:18 |
dman13 | not by default .. because then people's public server wouldn't work until they put 0.0.0.0 in a config file | 00:18 |
duopollex | yea I guess | 00:19 |
duopollex | just binding to all the ip's on a server that has two class C's assigned to it is a bit erhmm yea :p | 00:19 |
dman13 | where's that code that binds to the socket? | 00:19 |
dman13 | haha | 00:19 |
dman13 | that's a lot of IP addresses for one machine! | 00:19 |
duopollex | yea well it's a test server :p | 00:20 |
duopollex | regardless maybe I can figure out a way to work around it | 00:20 |
duopollex | I just thought I'd ask here | 00:20 |
duopollex | I googled for like an hour | 00:21 |
duopollex | finding nothing | 00:21 |
dman13 | maybe you could modify src/zope/server/serverbase.py | 00:21 |
duopollex | I couldn't believe no one has come across this :P | 00:21 |
mexiKON | duopollex, you might want to read the source | 00:21 |
dman13 | line 49 | 00:21 |
mexiKON | duopollex, not yet, z3 isn't used in production much yet | 00:21 |
dman13 | change 'ip' to '"127.0.0.1"' (or whatever address) | 00:21 |
duopollex | yea actually I have a few of our python devs looking at it for me :p | 00:21 |
duopollex | yea I figured I could hardcode it | 00:22 |
mexiKON | ick | 00:22 |
mexiKON | let's find a general solution :) | 00:22 |
duopollex | well that's what surprised me | 00:23 |
duopollex | I figured there would be one :p | 00:23 |
mexiKON | well, maybe we still have to create one | 00:23 |
dman13 | mexiKON: I agree, but that would get duopollex off the hook for getting his test environment set up | 00:23 |
mexiKON | sure | 00:24 |
mexiKON | ok, the zconfig schema for 'address' supports host:port | 00:25 |
mexiKON | so far so good | 00:25 |
dman13 | where is that? | 00:25 |
dman13 | (I'm looking for that right now :-)) | 00:25 |
mexiKON | zope.app.server/schema.xml | 00:25 |
mexiKON | datatype="inet-address" | 00:25 |
mgedmin | duopollex, binding to a specific network interface can't be done with zope3 now | 00:25 |
dman13 | ahh, I was looking in zope/server for a config file | 00:26 |
mgedmin | look at zope/app/server/server.py | 00:26 |
duopollex | mgedmin: that would explain why I found 0 information on going about it :) | 00:26 |
mgedmin | it gets a tuple (ip address, port) as self.address | 00:26 |
mexiKON | mgedmin, question is: how hard would it be to add it | 00:26 |
mgedmin | then it discards the ip address and uses only the port | 00:26 |
mexiKON | mgedmin, right | 00:26 |
mexiKON | ah, i see | 00:26 |
mexiKON | in create() | 00:26 |
* mexiKON looks at IServerType | 00:27 | |
mexiKON | dang | 00:27 |
mexiKON | we'd have to change IServerType | 00:27 |
mexiKON | and all of its implementations | 00:27 |
mexiKON | but at least from an API standpoint we could be backward compatible | 00:28 |
mgedmin | you need to change ServerType | 00:28 |
mgedmin | and it is not too difficult | 00:28 |
mgedmin | zope/app/server/servertype.py | 00:28 |
mgedmin | line 56 | 00:28 |
mexiKON | right, i've been looking at that now | 00:28 |
mgedmin | the '' is actually the ip address | 00:29 |
dman13 | as for the zconfig part ... what if someone wants to bind to N addresses where N > 1 and N < all-on-machine? It would be cumbersome to make N (where N is "large") <server> sections. OTOH maybe that isn't common enough to worry about. | 00:29 |
mgedmin | PublisherHTTPServer et all already support that | 00:29 |
mexiKON | mgedmin, and ServerTyupe could sniff the 3rd argument if its an integer (just port) or a tuple (ip + port) | 00:29 |
mgedmin | so it looks like you'd only need to change two classess | 00:29 |
mgedmin | ServerType and ServerFactory | 00:29 |
mexiKON | yah | 00:29 |
mexiKON | right | 00:29 |
mgedmin | it'd be cleaner to pass ip as a separate argument, I guess | 00:30 |
mexiKON | probably. question is how bad we really need backward compat here | 00:30 |
mexiKON | probably not needed | 00:30 |
mgedmin | I do not think there are any users that specified 'port 127.0.0.1:8080' in zope.conf but actually wanted to listen on all interfaces | 00:31 |
mexiKON | of course | 00:31 |
mgedmin | and adding a new keyword argument to ServerType would not break backwards compatibility | 00:31 |
mexiKON | hmm. yeah, it could be an optional keyword arg, ip='' | 00:31 |
dman13 | true, but IMO it looks nicer to have 'ip, port' in that order for non-keyword usage | 00:31 |
dman13 | I don't care that much, though | 00:32 |
mgedmin | I think it is very unlikely there are any implementations of IServerType other than zope.app.server.servertype.ServerType | 00:32 |
mexiKON | right | 00:32 |
mexiKON | plus, an interface not in interfaces.py indicated it is not meant to be for a generic API | 00:32 |
mexiKON | s/indicated/indicates/ | 00:32 |
mexiKON | somebody should write a proposal and do the trivial patch (test will be harder) | 00:32 |
mexiKON | :) | 00:33 |
mexiKON | duopollex, ? | 00:33 |
duopollex | yea | 00:33 |
duopollex | I'm listening intently :p | 00:33 |
mexiKON | you familiar with python? ;) | 00:33 |
duopollex | no I'm the sysadmin here :p | 00:33 |
mexiKON | dang | 00:33 |
duopollex | I could get one of our developers in here probably :P | 00:34 |
duopollex | although they may actually be busy working on stuff | 00:34 |
duopollex | my expertise in python is limited | 00:34 |
mexiKON | oh, i gotta run. later guys. | 00:34 |
* mgedmin is slightly interested in this, but he is also busy | 00:34 | |
duopollex | bye, thanks for the input | 00:34 |
duopollex | heh | 00:34 |
dman13 | hmm, how would one go about writing the test? | 00:35 |
mexiKON | i know it sounds like a cheap excuse but i've got exams coming up | 00:35 |
duopollex | heh | 00:35 |
dman13 | I don't think 'netcat' would be suitably cross-platform | 00:35 |
mexiKON | dman13, stub server implementation i guess | 00:35 |
mexiKON | hehe | 00:35 |
mexiKON | no, not that functinal | 00:35 |
mexiKON | just have stub utilities report back the correct stuff | 00:35 |
mexiKON | anyway, gotta go | 00:35 |
dman13 | oh, ok. I was trying to figure out how to verify that the server really is listening on just the specified IP | 00:35 |
dman13 | ok, ttyl | 00:35 |
mexiKON | dman13, hmm, hard to do. testers would have to have that free port you specify in test config | 00:36 |
mexiKON | etc. | 00:36 |
*** mexiKON is now known as philiKON | 00:36 | |
* mgedmin cannot find the unit tests for ServerFactory | 00:37 | |
mgedmin | nor ServerType | 00:37 |
mgedmin | :( | 00:37 |
*** mgedmin has quit IRC | 00:41 | |
*** J1m has quit IRC | 01:01 | |
*** Aiste has joined #zope3-dev | 01:10 | |
*** duopollex has left #zope3-dev | 01:14 | |
*** srichter has quit IRC | 01:25 | |
*** dman13 has quit IRC | 01:33 | |
*** benji_york has quit IRC | 01:42 | |
*** WebMaven has left #zope3-dev | 01:46 | |
*** srichter has joined #zope3-dev | 02:08 | |
*** tvon|x31 has joined #zope3-dev | 02:11 | |
*** tvon has quit IRC | 02:11 | |
*** ChanServ sets mode: +o srichter | 02:12 | |
*** tvon|x31 is now known as tvon | 02:13 | |
*** tvon has quit IRC | 02:33 | |
*** tvon has joined #zope3-dev | 02:33 | |
*** `anthony has quit IRC | 03:32 | |
*** xenwryly has joined #zope3-dev | 03:47 | |
xenwryly | when last I got into z3, someone pointed here me to a third part who was doing skins or a skinning product for z3. I can't find their site again. Can anyone help me out>? | 03:48 |
philiKON | maybe roger's tiks.org? | 03:55 |
philiKON | or the now dead (or so it seems) siesa? | 03:55 |
xenwryly | hey there, BTW :) | 03:57 |
philiKON | hi | 03:58 |
xenwryly | I'm doing zope/plone stuff fulltime nowadays, pretty stoked on that | 03:59 |
philiKON | cool | 03:59 |
xenwryly | and no, tiks isn't it | 04:00 |
*** xenwryly has left #zope3-dev | 04:22 | |
*** d2m has quit IRC | 05:49 | |
*** alga has quit IRC | 05:58 | |
*** tvon has quit IRC | 06:36 | |
*** tvon has joined #zope3-dev | 07:20 | |
*** AL|-| has joined #zope3-dev | 08:33 | |
*** `anthony has joined #zope3-dev | 09:10 | |
*** tarek has joined #zope3-dev | 11:08 | |
*** `anthony has quit IRC | 12:41 | |
*** `anthony has joined #zope3-dev | 13:48 | |
*** mgedmin has joined #zope3-dev | 15:44 | |
*** d2m has joined #zope3-dev | 17:15 | |
*** alga has joined #zope3-dev | 18:10 | |
*** jhauser has joined #zope3-dev | 18:26 | |
mgedmin | I would like to run a functional doctest over real HTTP | 18:38 |
mgedmin | any ideas? | 18:38 |
mgedmin | the obvious solution is to write my own http() function that would actually make HTTP requests | 18:39 |
mgedmin | but I'd like to avoid wheel reinvention | 18:39 |
mgedmin | has anybody tried this? | 18:39 |
srichter | well, that would mean that your tests would depend on the server code | 18:51 |
srichter | why would you want to do this? | 18:51 |
mgedmin | several reasons | 19:17 |
mgedmin | one: automation of repetetive tasks with verification (ok, I want to set up a local utility this, register it, etc, etc) | 19:18 |
mgedmin | another: real functional tests (ok, let's see if the application is alive and kicking) | 19:18 |
mgedmin | I'm experimenting with a Zope3-based application that wants to use different configuration code (instead of zope.conf and site.zcml) and probably a differnt publication class as well (to get the application object instead of the root folder as traversal root) | 19:22 |
mgedmin | I thought it might be simpler and safer to test it functionally by running the server and talking to it over http, instead of trying to reproduce the same custom environment in functional test setup code | 19:23 |
*** BjornT has quit IRC | 19:26 | |
mgedmin | success! | 19:31 |
alga | hm | 19:34 |
mgedmin | I now have a very hacky script that runs functional doctests against a real HTTP server on localhost:8080 | 19:37 |
mgedmin | you can see it at http://source.schooltool.org/viewcvs/trunk/schooltool/doctesthttp.py?view=auto | 19:38 |
mgedmin | IANAL, but it is probably GPLed and (c) Shuttleworth Foundation | 19:39 |
*** BjornT has joined #zope3-dev | 19:40 | |
srichter | cool, though I think we do not need this for Zope 3 per se | 20:00 |
srichter | but of course, it would be cool for other projects as well | 20:00 |
* mgedmin nods | 20:01 | |
mgedmin | I'm not suggesting that functional tests in Zope 3 should speak HTTP instead of calling the publisher directly | 20:01 |
mgedmin | but having a tool that can run a doctest on a live server would be useful | 20:02 |
mgedmin | you could, for example, check that your deployed Zope 3 app still works after a software upgrade | 20:02 |
*** alga has quit IRC | 20:17 | |
mgedmin | cookies are painful | 20:23 |
srichter | have a chocolate chip cookie ;-) | 21:32 |
srichter | (joke trademared by my wife ;-) | 21:32 |
mgedmin | I'm trying to find the IDatabaseOpenedEvent handler that creates the root folder | 21:48 |
mgedmin | with no success | 21:48 |
mgedmin | am I looking for the wrong thing? | 21:48 |
*** philiKON has quit IRC | 22:03 | |
*** tarek has quit IRC | 22:12 | |
mgedmin | MenuAccessView.__getitem__ calls getUtility that may raise ComponentLookupError | 22:13 |
mgedmin | ComponentLookupError is a subclass of NotFoundError | 22:13 |
mgedmin | this triggers a DeprecationWarning in zope.app.traversing.adapters | 22:14 |
mgedmin | I'm going to change __getitem__ to raise KeyErrors instead | 22:14 |
mgedmin | or shouldn't I? | 22:15 |
* mgedmin composes an email to zope3-dev | 22:20 | |
*** jhauser_ has joined #zope3-dev | 22:27 | |
*** jhauser has quit IRC | 22:35 | |
* mgedmin ponders the difference between zope.app.authentication and zope.app.pluggableauth | 22:55 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!