Configuring and Managing Seaside

I e-mailed David Shaffer (at in early September asking questions about how to configure Seaside. David wrote a tutorial on Seaside that’s available online.

Here, he talks about how to configure Apache to work with Seaside. Then we got into deployment issues: how to run Squeak in “headless” mode (where no GUI appears), and how to disable the “halos” in your Seaside application. From what I’ve been reading recently on the Seaside mailing list, the solution David gives for this may also disable the “development toolbar” that shows up in your app. during development. This is what I wanted, since in many apps it’s not appropriate to allow users access to the Code Browser, the CSS for the page, and whatnot. We also talk about how to terminate a process in Squeak, or terminate Squeak itself, in case of an infinite loop or some other lock-up.

Here are David’s responses to my questions:

Hi Mark,

Mark Miller wrote:

I found your tutorial, and it’s been helpful in answering some questions, but I have some others. They have to do with administration, which I noticed you have a slot for in your tutorial, but no link.

I’ve been approached to do a web project for a potential customer and I’m interested in doing it in Seaside. The way my projects typically work is that once I’m done with development, I deploy it to a customer’s system or a third party ISP, and they manage the web server while it’s in production. What concerns me some is it appears that in order for the Seaside app. to run, the web server must run inside the Squeak environment. I understand that of course the Seaside app. has to run in Squeak. When I first approached this I hoped that it would be possible to run the Squeak app. from something like Apache, through a plug-in runtime, so that all the administrator would have to worry about is doing some setup with Apache, or perhaps run something from the operating system command line. Is there a way to do this? The only web server I’ve read about so far for Seaside is Comanche. My concern is that the administrator will not know about operating in the Squeak/Comanche environment and will be resistant to taking the time to learn it.

You can have Apache proxy to the squeak server, no “plug-in” needed (well, mod_proxy has to be installed).  I do this on several production servers.  It has the advantage of allowing you to use fancy rewrite rules to load balance your requests across several squeak images/machines.  For example, on an apache server you can specify:

# seaside config site
ProxyPass /seaside/config http://localhost:8888/seaside/config

ProxyPass /seaside/config http://localhost:8888/seaside/config
<Location “/seaside/config”>
Order allow,deny
Allow from all
ProxyPassReverse /seaside/config

and all request to /seaside/config will be forwarded to localhost port 8888 (presumably running your Squeak/Seaside server).  You can get a lot fancier with Rewrite rules…here are a few references:

You can run squeak with the “-headless” option or “-vm-display-none” (I’m not sure about this last one) from a script and it won’t even raise a GUI.  I prefer to have the UI available for debugging purposes but there is no reason you can’t do things just the way you described.  I even wrote a little Seaside app that let’s me upload and run scripts on the server.  There’s also an app that someone wrote (Goran? Avi?) that starts up a Squeak-based VNC server on a headless squeak image so you can interact with it “on demand”.  Scan the mailling list archives for VNC and you’ll find some comments on this approach and probably some help getting started.  My servers are all Linux-based and I keep a (unix) VNC session with my Squeak images open (head-full) so I can deal with problems without having to start up the Squeak VNC server.

One word of warning…Kom’s keep alive is buggy when working through a proxy.  Disable it with:

(HttpService serviceNamed: ‘httpd’) keepAlive: false

Goran might have fixed that but it has bitten me enough times that I just disable it.

I’ve seen demos of the “halos” around elements on a web page, and the web-based code editing environment. These look great for doing my development work, but is it possible to restrict access to these features? I don’t like the idea of just any user being able to enter the code editing environment and change code in the app.

On the config page set “deployment mode” to true.  This is per application so once you’ve disabled halos noone using the app will see them.  I’m not familiar with a way to do this per-session.

In a different tutorial it talked about setting up a username and password when the Comanche server components are first installed. What features does this restrict access to?

Never heard of it.  Kom is a pretty plugable server, there is a ModAuth which allows you to specify an “authentication DB”.  This would only be useful if you were serving more than just Seaside from Kom.  I let Apache serve all of my static content so my production servers don’t even have ModFile in their Kom stacks (basically the config you get with “WAKom startOn: 8888”).  You can study your Kom config by using exploring:

HttpService serviceNamed: ‘httpd’

look at “plug” and work your way down.  Be ready for a mess though.

Lastly, in case something happens, like some sort of lock-up or infinite loop (an error on my part) in a Seaside app., is there a way to terminate a process? I’m not real familiar with Squeak at this point, so perhaps this is an elementary question.

You can

1) Terminate the squeak VM from the UNIX command line or from the windows task manager
2) Terminate a process from within Squeak using the Process Browser (ProcessBrowser open)
3) Hit alt-. in Squeak if it becomes unresponsive due to an infinite loop in a process

There is also a process which can be activated (via preferences, I think) which watches for CPU hogs and gives you the option to terminate.  I do not recommend this on a server though.  Maybe you can study the code and come up with something similar but more tunable…the existing one kicks in too soon.  As I said, I don’t use it right now so I can’t really give you specifics.

Deploying your first Seaside app generally takes a little more reading than deploying, say, a PHP or perl app but once you’ve got a working configuration you’ll find it to be simpler to manage than either of those two.

Good luck and let me know if you have any more questions…


Ramon Leon of On Smalltalk put up a post recently that also talks about how to configure Apache so it works with Seaside and IIS!

One thought on “Configuring and Managing Seaside

  1. Pingback: Smalltalk :: En nu hoe je Seaside configureert. : : October : : 2006

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s