wiredfool

Following the lead of Chris Double who got Radio Userland to run on Wine, I have now gotten the basic windows install of Frontier to run on Linux using Wine. It’s currently something that takes a bit of patience to do and should not be relied upon to serve anything important.

***How to do it

1. Install a recent build of wine. Anything since the 2003-04-08 release is probably new enough. If there’s a package for your distro, you probably want that. If not build from source. To be difficult, I wanted a packaged version for my Debian Woody (stable – read not really bleeding edge) machine, so I ended up grabbing the latest nightly debian source package from http://people.debian.org/~andreas/ and hacking at it till it built. If you’re using debian, you’ll need the winesetup package as well. Frontier doesn’t seem terribly particular about wine’s settings.
2. Get the windows Frontier installer from frontier.userland.com and run it using “wine Frontier90Setup.exe”. I chose all of the default options. Launch Frontier from the final dialog box.
3. When Frontier launches, you will just see a Wine-Systray window. Right click on it to bring up Frontier in a window. At least that’s what I’m seeing, since I’m running Afterstep, an old NextStep inspired desktop. In something a little more modern like KDE, the Frontier icon actually shows up in the app tray. (I’m getting the distinct feeling that Afterstep is a little 1995 ish in its capabilities.)
4. Let the startup script run long enough to open the guest databases and enter their info in user.databases. Then make the change to system.startup.startScript reported by Chris:

   if system.environment.isWindows
     user.webBrowser.winDefaultBrowserApp = "notepad.exe"
   

   I suspect that we may be able to fix this by the addition of registry keys in the wine user registry.

5. Complile this, save Frontier.root and all of the other databases, and quit Frontier.
6. Make sure you’re in the Userland directory and start Frontier from the command line using “wine Frontier.exe 2>&1 >/dev/null &” (this is a bash command that supresses all the error output). Frontier should run through the entire startup script now, and at some point go to 5 threads and be ready to serve hits on the admin (port 5336) website.
7. Since the first run of Frontier ‘failed’, we need to add an admin user. Jump to the admin membership group (cmd-j admin) and add a user:

   users
      foo@example.com
         hitcount        0    number
         lastVisit       clock.now()
         password        pw   binary
         personalInfo 
            name         foo  string
   

   You should now be able to log into http://127.0.0.1/setupFrontier with the email and password that you supplied. Run through the setup as normal.

8. The final tweak is to get the port 80 webserver running. Since we’re running this on unix, non-root users can’t listen on the webserver port. This is the same problem as has been solved by Frontier-OSX users. You can either setup apache to proxy requests or use the kernel ipchains/iptables service to portforward for you. I set user.inetd.config.http.port to 8000 and user.inetd.config.http.apparentPort to 80, then set apache to forward all traffic for http://wine.wiredfool.com to Frontier.

***Bugs and other issues

This is certainly not a production system yet. I’ve noticed issues ranging from cosmetic to data loss.

• [modifier]-double click sometimes hangs wine or the X server.
• Sometimes clicking on a window close box for user.databases or system.temp generates an attempt to save the table. That fails, then the table is deleted. Deleting system.temp generally causes frontier to Function very badly.
• 2 way dialogs that should be ok/cancel are cancel/retry.
• Outline/table display has lots of artifacts and dirty redraws.
• Font handling is very tempermental. The same line sometimes has multiple fonts per character.
• Performance is decent for webserving, not all that good for console access. I don’t think I’d want to use it all day, but it’s certainly better than timbuktu/vnc.

This article is an addition to an article that I wrote about a year and a half ago. One of the limitations to this approach is that was only complete for older sites that didn’t use Frontier’s virtual domain system. This was noted by Michael Zajac in a post to the Frontier-osx discussion group. His solution was to hardwire a host name from a script at config.mainresponder.callbacks.controlAccess.rewriteHost, which is called early in a Mainresponder response. My updated method builds on this and goes somewhat further towards a more complete integration – allowing all normal Frontier webserver actions: virtual hosting in Frontier and Apache, control panel access, working referer checking, and IP address control.

***The Key Change

There are two key changes that I’ve made: I trust a couple of the extra headers that the Apache proxy module adds about the real client and I’ve moved the callback to user.webserver.prefilters to allow all of the responders to work normally.

The proxy module adds the client and host info to the request in X-Forwarded headers.

X-Forwarded-For: 216.231.55.35
X-Forwarded-Host: leek.wiredfool.com

These should only really be trusted if there is no way that any untrusted user can access an http port directly on your system, either on the main or the management port. I suspect that the only danger would be due to ip spoofing.
Download my user.webserver.prefilters callback here. This filter sets the client ip and host information from the extra request headers. (note that something similar could be done with any proxy that adds this sort of headers)

***The full apache config file

This is the full working config file for wiredfool.com, in all it’s gems/static/dynamic glory. I’ve stored this at /etc/httpd/users/wiredfool.conf so that is it not going to get tromped on in any Apple updates. The only changes to the main httpd.conf file are to uncomment the mod_proxy lines.

#This prevents running an open proxy.

    ProxyRequests Off

 
NameVirtualHost 216.231.55.38
 
AddType  application/octet-stream  .root
AddType  application/x-frontier-tabl  .fttb
 
# static portions...
 

    DocumentRoot "/Frontier/Guest Databases/www/pictures"
    ServerName static.wiredfool.com

 

    DocumentRoot "/Frontier/Guest Databases/www/gems/wiredfool"
    ServerName gems.wiredfool.com

 
#passthrough to frontier   
 

    DocumentRoot "/Frontier/Guest Databases/www/gems/wiredfool"
    ServerName www.wiredfool.com 
    ServerAlias wiredfool.com leek.wiredfool.com
 
    RewriteEngine On
    RewriteRule ^/(.*)$  http://127.0.0.1:8000/$1 [P,NE]

The last virtual host clause could be done in the default host, so that any domain not explicitly mentioned in the static section would be passed into frontier. If I were doing more than two or three dynamic sites on this machine, that is the path that I would take.

Download Last Updated 4/17/02

***What it is

If you’re administering a Frontier server on OSX, you need a way to set up port forwarding at startup. This archive contains a startup item that will set up portforwarding for all your machines ip addresses from port 80 to port 8080.

***Installation

Download. Get a command line prompt in the download directory. Use the following commands:

pwd
cd /Library/StartupItems 

if the cd command fails, type

sudo mkdir /Library/StartupItems
cd /Library/StartupItems 

Then type (replace /path/from/pwd with the path that is printed by the pwd command)

sudo tar -xvzf /path/from/pwd/portForward8080.tgz

This will expand the archive in the correct location to be execute on startup. If you want to, look at the script that is run (/Library/StartupItems/Multihoming/Multihoming ) to make sure that I’m not doing anything nasty to you.

Restart your machine to test that the command has been run properly. To check to see that it has been installed, run ‘ipfw show’ from a command prompt, and you chould see something like

[tibaby:~] erics% sudo ipfw show
00101        7        665 fwd 127.0.0.1,8080 tcp from any to any 80 in
65535 12709 53678 allow ip from any to any

The first line is the rule that was inserted, the second line is the default firewall configuration.

*** Update

As of August 2002, this has been released in the Frontier and Radio Userland update stream as part of tcp.im. Further updates to this code are unlikely.

Version 0.21 Released 5-10-2002
Download. Updates

Frontier-TOC is a Frontier implementation of the AOL TOC protocol, one of the two that is used for AOL Instant Messaging. It enables scripters to write chatbots and other IM clients that work in Userland Frontier or Radio Userland. This implementation is a direct port of the PyToc 1.3 module by Jamie Turner. Frontier-TOC is released under a BSD license.

The TOC protocol spec has been published under the GNU public license and has been implemented in several open source chat clients. The other protocol, OSCAR, is used in AOL’s clients and has not been published. The OSCAR protocol is occasionally manipulated to break reverse engineered clients.

***Quickstart

Put it in your tools folder. Open ftocTest.startThread, and edit the screenname and password parameters. Run it and you should be able to IM yourself from another account.

***How to program it.

There is a basic echo bot implementation in ftocTest. It provides a setup script and a callback for incoming instant messages.

At a minimum, you will want to implement a on_IM_IN callback that will be called whenever an incoming im message is received.
One sample that strips any html and pongs back:

on on_IM_IN (adrSelf, data) {
	local {
		screenName = string.nthField(data, ':',1);
		message = string.mid(data, sizeOf(screenName)+4, infinity)};
	message = ftocSuite.strip_html(message);
	ftocSuite.do_SEND_IM(adrSelf, screenname, "Pong! You Said: " +message);
	return(true)}

The following code snippet (currently living at ftocTest.startThread) will start a bot using ftocTest.self for internal data storage. The go command logs into AIM and starts a thread to listen to the connection. The adrSelf parameter should be a location in the ODB, since it will be referenced by multiple threads.

local {
	adrSelf = @ftocTest.self};
ftocsuite.__init__(adrSelf, "screenname", "password", @ftocTest.callbacks);
ftocsuite.go(adrSelf)

More documentation to follow. For now, look at the code.

***Warnings and Caveats.

This is a second release. I am pondering changing some of the interfaces to make it a little easier for Frontier programmers. Documentation could charitably be called sparse. It does not make lattes yet.

***About the Port

This is a direct port of the Python class, and as such has some pythonisims that may not be familiar to most Frontier developers. Object orientation has been glossed over by providing a table of callback scripts and a table of instance values. Instead of function calls like objectName.functionCall(parameter), the calls look like ftocSuite.functionCall(adrSelf, parameter).

The most fiddly bits of the translation were that Frontier provides fewer binary packing tools than Python, and an isolated case of Frontier being 1 based instead of 0 based. Oddly enough, not knowing Python was not that much of an impediment.

***To Do

• I want to work on the pythonisims to make this look a little more like normal Frontier code.
• Better handling of network errors such as timeouts and dropped connections. Also need to figure out non-idle ping rates.
• Track updates to Py-toc since version 1.3

***Legal

Userland, Frontier, Radio Userland and AOL are trademarks of their respective holders. This is a derivative work of code copyright 2002 by Jamie Turner which was released under the BSD license. Frontier-TOC is copyright Eric Soroos, 2002 and released under the BSD license. This means that you are free to download it, use it, modify it, release it, or sell your changes. I can call you Betty, and Betty, when you call me you can call me Al. Just don’t strip out any copyright notices.

• Barcode Recognition in Python, in a functional style
• Flashing a Linksys WRT54GL with OpenWRT
• Flashing a Buffalo Airstation WBR2-G54 with OpenWRT
• How to build the Python Imaging Library For Windows
• Widescreen LCDs and Ubuntu Linux
• “Frontier and Apache, 1 Public Port”
• “Manila Behind Apache”
• “Frontier on Wine”
• Frontier and apache, 2 ports (Revised 4/19/2002)
• “Sample Port Forwarding Script” sets up port forwarding at startup.
• Server Management for OSX Also needs to be revised, but more for new practices than accuracy.
• Setting up a rh 6.2 box to my specs. Probably should be updated to Debian.
• Manila Feature Requests
• rpc handler patches and glue.
  

Documentation by others

• Frontier server Monitor
• Manila behind Apache
• Updated portforwarding

One of the lingering issues with serving using Frontier on OSX is integration with static content. I have a legacy site that is static html pages (served by webstar) administered by a set of fcgis (currently run by appleevents from WebStar) that I want to migrate to OSX. The appleevent interface appears to be gone from OSX, and I have apache instead of WebStar. But since Frontier has the CGI responder allowing it to respond to fcgi requests through its own webserver, the transition is surprisingly easy.

The basic idea is that I am going to use Apache to proxy requests to Frontier, running on the same machine but a different port number. The example I’m presenting here is for fcgi extensions, but by tweaking the expressions, it should be possible to forward any combination of requests to Frontier, while serving the rest from Apache.

For this example, I have Frontier listening to port 8000. The cgi responder should be enabled, and you should be able to access your fcgi script directly at http://yourmachine.com:8000/script.fcgi.

Apple helpfully ships Apache with the proper modules installed (mod_rewrite, mod_proxy), but you will need to enable mod_proxy. Mod_rewrite is already enabled in the default configuration.

Edit the file /etc/httpd/httpd.conf, (as root). Yon need to uncomment the following lines:

#LoadModule proxy_module       libexec/httpd/libproxy.so
...
#AddModule mod_proxy.c

so that they look like this

LoadModule proxy_module       libexec/httpd/libproxy.so
...
AddModule mod_proxy.c

For each site you wish to proxy, you will need to add a configuration file (as root) in the /etc/httpd/users directory (e.g. fcgi.conf) with the following contents:

    DocumentRoot /Volumes/Frontier/websites/staticSite
    ServerName virtual.example.com
    RewriteEngine on
    RewriteRule ^/(.*)\.fcgi(.*)$  http://127.0.0.1:8000/$1.fcgi$2 [P]

This is a standard VirtualHost directive the partial equivalent of config.mainresponder.domains, making the contents only apply to the host named virtual.example.com. ( where *.example.com points to the same ip address. (similar to how editthispage.com works)). The document root should be set to the #folder in the #ftpSite table. If you want to do this for all of the sites and pages served by apache, you can omit all but the rewrite lines.

The RewriteEngine line turns on mod rewrite so that it intreprets the next line.

The RewriteRule line means: match anything that starts with a slash (^/), contains “.fcgi” and might have something after it ((.*)$)., rewrite the url so that it points to our local port 8000, including all the stuff before and after the .fcgi, and proxy the request ([P]).

Any time you change an Apache config file, you will need to stop and restart web sharing in the System Preferences -> sharing control panel. (or sudo /usr/sbin/apachectl graceful)

When presented with the request, Apache will make a request to Frontier, which will serve the content to Apache, which will then return it to the client. Ths client will never see Frontier’s url.

The beauty of this approach is that any url that you can characterize bu a regular expression can be forwarded to Frontier for its response. For further information, see the Apache Manual for mod_rewrite or the Rewriting Guide. This should work for running Frontier behind Apache on any platform (OSX, Unix, Windows).