[Pharo-project] Deploying Seaside: A tutorial

Schwab,Wilhelm K bschwab at anest.ufl.edu
Wed Sep 23 20:01:00 EDT 2009


I maintain it is not as trivial as some in the Seaside world keep suggesting, and sice I'm not alone in finding new ways that things fail to "just work," I stand by it.

You appear to have completely missed my comments on ipv4/6.  There are defects in Pharo's NetNameResolver, and they need to be fixed.  It has nothing to do with Seaside, other than the defects prevent some of the finer points of customizing the certificate and possibly (depending on what is actually required) hints for apache configuration.

I look forward to your blog.  Hopefully it can be as simple as you suggest.  Part of my interest in things like Apacheat is to capture the details to remove (to the extent possible) any human error components.

BTW, it is not *me* who is afraid of Linux.  I agree that Windows is much more to be feared.  There are still a few things that keep me tied to it, and my interest in Pharo is to cut the few remaining chains.  One of them will require a LOT of sawing, I'm afraid.


-----Original Message-----
From: pharo-project-bounces at lists.gforge.inria.fr [mailto:pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Miguel Enrique Cobá Martinez
Sent: Wednesday, September 23, 2009 11:29 AM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Deploying Seaside: A tutorial

El mié, 23-09-2009 a las 10:43 -0400, Schwab,Wilhelm K escribió:
> Sef, Miguel,
> I am very pleased to see you tackling this problem.  Answers I 
> received from elsewhere "oh, that's trivial..." were not at all 
> helpful.  Some web sites were helpful, but it was not always clear 
> whether or not they were complete solutions.  One comment (there might 
> be more by now??) to the new book mentions complexity with newer Linux 
> distributions or something.  I should review that, but I'm on a roll 
> :)

What type of complexity. My setup just use a bare bones OS install with the security configs applied and then just Squeak VM, Seaside and Magma.
Nothing else.

> I think we should build some tools to capture the details, and I have been working toward that.  The problem is complicated slightly by conflicting writings, and perhaps that the target moves over time.  Another wrinkle for me is that I want https connections.

My production server use https for all the site. It is going to be the last post, after the load testing one. Modify the lighttpd.conf config to add https to the mix. By the way this is a responsibility for the webwerver/proxy not for seaside. Don't do it on Seaside. The requests arrive encrypted to the webserver and then the webserver pass them unencrypted to the Seaside images that are behind. In fact the Seaside code doesn't know anything about ssl, just it asks Seaside to add the #https protocol in all the urls that it generates. But that is a one-liner in the initializacion code of the application. Give me a couple more of days and I will explain it on the blog.

> Things I can offer, in varying stages of dis-repair:
> (1) OpenSSLCertificateFactory.  I started this under Dolphin and was still thinking in Windows terms; I now consider Windows to be analogous to a draining wound in a part of my body I hope to keep.  I still do some Windows-specific things, but the factory itself is designed to run on Linux; it would probably also be workable on a Mac, given its unix roots.
> I found openssl.exe to be slightly uncooperative.  It would have been nice to have a library with entry points or at worst an executable willing to take arguments on the command line.  All I could think to do was to create a configuration file with easily-recognized tags (e.g. COMMON_NAME) and to write a customized version of the file into a specified location with values provided as arguments to the method that does the work.  I know I ran this on Linux at least once, but now I can't find all of the code (yet).  It looks like it was one of my earlier efforts with SIF, which does not do a very good job with Dolphin's virtual categories, turning them into things that severely confuse Monticello, effectively unpackaging methods.
> The factory is really only of value to those wanting to self-sign a certificate.  Some object mightily to this concept, but it works and it's FREE.  I have no plans to make this work on Windows, because Linux shell scripting is remakably more rational than are Windows(TM) batch files.
> (2) Apacheat.
> (2a) This is something that I see as needing to work on Windows, since I do not (yet) expose Linux servers to the world.  However, I have also reduced it to creating a batch file and a .reg file to configure a service (interestingly, that has broken AGAIN, this time on win2k3).  It uses srvany (or whatever the correct name is) to run the vm as a service.  Have I mentioned that I am tiring of Windows?  

I understand the part of tiring of windows. I don't understand why you have fear of exposing Linux to the internet and not Windows. I have the exact opposite fears ;)

> (2b) It also has some code that iterates the Seaside apps and writes virtual host entries suitable for copying into an apache configuration file.  The method in the new book might be simple enough to not bother with anything beyond a reference to where to find the relevant setup.
> Parts of the above depend on being able to get a fully qualified name for the local machine, and NetNameResolver is more than slightly broken in that area.  I am convinced that it invokes primitives that are known to fail for IPv4 on IPv4 networks.  I have something that appears to work on both systems on xp (perhaps IPv6) and 2k3 (IPv4).  I need to try it again on Linux, and might soon have the ability to try Linux on another network - in fact my new discontinued $399.99 laptop is being delivered today.  Tux and I are very excited.  Having recently tried Vista for a few days, I plan to try to begin repartitioning this drive before Vista can so much as boot ;)  Ok, maybe I should let it boot just to see if everything works; I'll think about it.

Don't even follow that path. The seaside application don't ever be exposed to the world. Just the webserver doing proxy to them. So is the webserver that must know about fqdn and ssl and virtualhosting and other websites on the same install, etc.
Seaside just do what it does better, run "applications".

> Back to work.
> Bill
Miguel Cobá

Pharo-project mailing list
Pharo-project at lists.gforge.inria.fr

More information about the Pharo-dev mailing list