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. Here’s how to do it.

Now with a screenshot.

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.

Time to play with blogshares a bit. And now for the grubstake… This is of course a sneaky ploy to get everyone + cat to link to them.

We rented a film scanner (Nikon Super Coolscan 4000) to scan all of the negatives from the wedding. I’ve learned a few things – the first is that scanning at high quality takes more work then it should. Color correction is hard to do well. And it’s not done well with automatic settings.

Some is the software. It’s clear that the either the Nikon Scan software isn’t designed to be used all day, or there are hidden options that I don’t know of. Things that could be automatic aren’t. I would imagine that a common method of scanning is to scan an entire strip with one set of parameters, save them, and give them reasonable names. It was certainly a common mode for me. Operations can be queued, but everything has to be done for each frame: Select it, load settings, click scan, save as, type name. There’s also no control of the scratch directory. It just uses virtual memory instead. But apparently, it never frees any, so there’s a 60 meg per image memory leak (at my 30 meg color scan size). That starts to starve my machine for swap space pretty quickly. At least it crashes often enough that that isn’t as much of a problem as it seems.

For all 5 of you paying attention, the hosting for this site has moved around a bit, and I’ve lost various services at times (images, the site itself, membership, you know little things.) I’ve found most of the services again.

In the process of moving, I’ve refined the directions for serving Frontier/Manila behind Apache on OSX to allow for full use of Frontier’s Multihoming.

I’d also like to point out that there is a great difference between “rm -r foo*” and “rm -r foo *”. And that difference is one that calls for good recent backups, because unix doesn’t have a trash can. For that reason alone, rm could be considered dangerous equipment.

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.

• 2006
• 2005
• 2004
• 2003
• 2002
• 2001
• 2000
• 1999

Today’s and yesterday’s shots are all from our photographer. These are quick scans off of the contact sheets (or print, for the color one). I’m going to be doing high res scans of the negatives soon- there’s no way that I can live with this quality as the only digital version.

There’s a camera store downtown (Glazer’s) that reportedly rents Nikon 35mm and medium format slide scanners by the day. I think that’s probably the best option right now, unless I can find someone I’d trust with these negatives.

No comments

No comments