Is it possible to run Seaside with apache without any access to any ports?
Is that what mod_lisp is for?
Thank you.
Derek Brans Nerd on a Wire Web design that's anything but square http://www.nerdonawire.com mailto: brans@nerdonawire.com phone: 604.874.6463 toll-free: 1-877-NERD-ON-A-WIRE
On Thu, 31 Jul 2003, Derek Brans wrote:
Is it possible to run Seaside with apache without any access to any ports?
Is that what mod_lisp is for?
mod_lisp would still require a port to be open, it just wouldn't be listening for HTTP.
If you truly wanted to run it with no ports, you would need to use a unix domain socket to communicate with apache. I'm not sure exactly how you would do this from Squeak, although the standard file primitives could probably be made to work.
But why do you need this? Firewalling off the port that comanche is listening on isn't enough?
But why do you need this? Firewalling off the port that comanche is listening on isn't enough?
Many web hosts will give you ssh access to your "virtual server" and let you install and run software. There is one apache server for several "virtual servers". Lettinging you have access to a port is a security violation for these companies (unless they're running user mode linux, which many aren't).
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
On Thu, 2003-07-31 at 20:40, Derek Brans wrote:
But why do you need this? Firewalling off the port that comanche is listening on isn't enough?
Many web hosts will give you ssh access to your "virtual server" and let you install and run software. There is one apache server for several "virtual servers". Lettinging you have access to a port is a security violation for these companies (unless they're running user mode linux, which many aren't).
So switch companies ;-)
Avi Bryant wrote:
On Thu, 31 Jul 2003, Derek Brans wrote:
Is it possible to run Seaside with apache without any access to any ports?
Is that what mod_lisp is for?
mod_lisp would still require a port to be open, it just wouldn't be listening for HTTP.
But that would be an internal port, meaning could be in user space (>1024) and hidden behind the firewall.
BTW, does anyone know the state of mod_smalltalk? The download doesn't seem to be available any more?
Michael
On Thu, 31 Jul 2003, Michael Rueger wrote:
mod_lisp would still require a port to be open, it just wouldn't be listening for HTTP.
But that would be an internal port, meaning could be in user space (>1024) and hidden behind the firewall.
Yup. But you could do the same thing with Comanche and mod_proxy.
BTW, does anyone know the state of mod_smalltalk? The download doesn't seem to be available any more?
That was a FastCGI implementation for Squeak, right?
FastCGI is more complex than it's worth, IMO. I do, however, want to write a mod_seaside that does intelligent things with load balancing and session affinity, so that you can have multiple images serving one URL.
I have a feeling this won't end up getting done until some client asks for it, however...
On Thu, 2003-07-31 at 22:13, Avi Bryant wrote:
Yup. But you could do the same thing with Comanche and mod_proxy.
The biggest drawback is that, AFAIK, mod_proxy lets all requests seem to appear from 127.0.0.1, which fouls up things like Wiki changes logging.
mod_lisp should be revived...
How do WASessions get terminated?
I'm asking because I want to release the database connection at some point once its expired (I'm just doing a naive one session one connection for now).
Some methods of interest.
WARegistry>>collectExpiredHandlers (handlersByKey reject: [:ea | ea isActive]) do: [:ea | self unregisterRequestHandler: ea]
WASession>>isActive ^ Time totalSeconds - lastAccess < (self application preferenceAt: #sessionExpirySeconds)
WARegistry>>unregisterRequestHandler: anObject handlersByKey removeKey: (keysByHandler at: anObject). keysByHandler removeKey: anObject
I suppose if you wanted to cheat you can add some termination code in #isActive, in the case that it's not active.
I think the proper thing to do would be to add a call to some cleanup method on WASession after the registry unregisters the session.
Derek Brans Nerd on a Wire Web design that's anything but square http://www.nerdonawire.com mailto: brans@nerdonawire.com phone: 604.874.6463 toll-free: 1-877-NERD-ON-A-WIRE ----- Original Message ----- From: "Todd Blanchard" tblanchard@mac.com To: "The Squeak Enterprise Aubergines Server - general discussion." seaside@lists.squeakfoundation.org Sent: Sunday, August 03, 2003 11:40 AM Subject: [Seaside] Session termination
How do WASessions get terminated?
I'm asking because I want to release the database connection at some point once its expired (I'm just doing a naive one session one connection for now).
Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
Derek Brans wrote: [...]
I think the proper thing to do would be to add a call to some cleanup method on WASession after the registry unregisters the session.
Sure, we could do that, I suppose. Keep in mind though that in many setups, sessions may remain in the cache for long periods of time. Some systems may even choose to write old sessions out to disk so they can be reloaded at any point in the future. It would be much safer to have a database connection pool that could deal with closing long-unused connections and handing out new ones if the session comes back to life, etc.
Julian
Derek Brans wrote:
WASession>>isActive ^ Time totalSeconds - lastAccess < (self application preferenceAt: #sessionExpirySeconds)
At about what version of Seaside did the above #isActive method become the above? What I have in my image is:
WASession>>isActive ^ Time totalSeconds - lastAccess < 600
It wasn't that long ago I rebuilt everything based on what is on SqueakMap, so I suppose the version on SqueakMap probably has the hardcoded number 600 in it, too.
Nevin
Nevin Pratt wrote:
Derek Brans wrote:
WASession>>isActive ^ Time totalSeconds - lastAccess < (self application preferenceAt: #sessionExpirySeconds)
At about what version of Seaside did the above #isActive method become the above? What I have in my image is:
WASession>>isActive ^ Time totalSeconds - lastAccess < 600
It wasn't that long ago I rebuilt everything based on what is on SqueakMap, so I suppose the version on SqueakMap probably has the hardcoded number 600 in it, too.
Not sure what version, if any that's in. I added the preference at work a month or two ago because I was getting tired of my sessions timing out while I was writing code and wanted to be able to raise it easily. So it's in CVS for sure, but I don't know if it's in the current release (would be easy to check but I'm lazy)
Julian
Nevin Pratt wrote:
Derek Brans wrote:
WASession>>isActive ^ Time totalSeconds - lastAccess < (self application preferenceAt: #sessionExpirySeconds)
At about what version of Seaside did the above #isActive method become the above? What I have in my image is:
WASession>>isActive ^ Time totalSeconds - lastAccess < 600
It wasn't that long ago I rebuilt everything based on what is on SqueakMap, so I suppose the version on SqueakMap probably has the hardcoded number 600 in it, too.
Nevin
I rebuilt my image last night, using Seaside from SqueakMap, and the 600 is no longer hard coded. Not sure when the SqueakMap version got updated, but it couldn't have been long ago. In any case, it now uses the application preferences for session expiry.
Nevin
seaside@lists.squeakfoundation.org
-
Avi Bryant -
Cees de Groot -
Derek Brans -
Julian Fitzell -
Michael Rueger -
Nevin Pratt -
Todd Blanchard