Zovirl Industries

By default, blosxom will return results for partial category name matches. For example, if “telephone” is a category, these would all return posts about telephones:

• http://example.com/telephone
• http://example.com/telepho
• http://example.com/tele

(If “television” was also a category, that last example would include posts from both the television & telephone categories)

This behavior gets in the way of Fletcher’s emptymessage plugin, so I wrote the fullcatgory plugin. Fullcategory changes Blosxom so only full category names will give results. This lets the emptymessage plugin do its thing. I’m pretty sure that with both emptymessage and fullcategory installed, I will be able to run an automatic link checker over my site and find dead (404) links, where before some links went to empty blosxom pages.

Download fullcategory 0.0.1

Documentation is available here.

Want to remotely access computers behind your Bering firewall, but they aren’t turned on? You need the Wake-On-Lan Proxy written by Ken Yap.

Wake-On-Lan (WOL) is a technology that lets you turn on a computer on your network by sending a special packet to it over the network. The WOL proxy makes it easy to send these packets to your network from anywhere on the Internet, securely. It consists of a server (wold) and a client (wolc.pl). When the client sends the right password to the server, the server sends a WOL packet to the target computer.

If you want to set this up on your Bering firewall, first get WOL working. It is hard to debug, so it is best to get this out of the way before you add the proxy into the mix.

1. Load the etherw package onto your firewall. This lets you send WOL packets when you are logged into the firewall.
2. Make sure the target computer supports WOL and has it enabled in the BIOS
3. The OS on the target machine has to leave the network card in a WOL-ready state when it shuts down. Instructions for linux and windows. Here is how I set up my Shuttle SK41G for WOL
4. Turn off the target machine and send a WOL packet from the firewall:

   ether-wake 00:AA:BB:CC:DD:EE -i eth1
   

   The target machine should turn on

Once you have basic WOL working, it is time to set up the proxy:

1. Load the wold.lrp package onto the firewall
2. Go into “lrcfg”–>”packages”–>”wold” to edit the configuration file (/etc/wold.conf). Add the target machine’s MAC address, name, and password. You will need the same configuration file for the client
3. Add wold to the list of services (/etc/services) and give it a port number:

   ...
   # Local services
   wold 54321/tcp  # WOL proxy
   wold 54321/udp # WOL proxy
   ...
   

4. Configure inetd.conf to run wold when the client connects.

   ...
   wold stream tcp nowait sh-httpd /usr/sbin/tcpd /usr/sbin/wold \
      -f /etc/wold.conf -i 192.168.1.255 -p 54321
   ...
   

   Restart inetd (run svi inetd resart).

5. Configure hosts.allow to allow machines to connect to the firewall

   ...
   wold: ALL
   ...
   

6. Edit the shorewall rules file to allow incoming wold connections from the local network and the internet, and to allow outgoing WOL packets to the local network.

   ...
   # Allow WOLD requests to the firewall from anywhere,
   # Allow WOLD magic packets from the firewall to local
   ACCEPT loc fw tcp 54321
   ACCEPT net fw tcp 54321
   ACCEPT fw loc udp 54321
   ...
   

   Restart shorewall (run svi shorewall resart)

7. Back up all the Bering packages you changed (wold, shorewall, etc)
8. Grab the client (it is in the WOL proxy package, found here) and set it up with the same configuration file you used on the server (you can remove passwords if you want to be prompted). Run it like this:

   $ ./wolc.pl -f wold.conf 192.168.1.254:54321 computer_name
   

This is the Wake-On-Lan Proxy 0.5 written by Ken Yap, packaged for Bering firewalls. Only the daemon is included in the .lrp package, since that is the part that needs to run on the firewall.

Download wold.lrp version 0.5

I also wrote a short explanation of how to set this up here.

My main computer is a Shuttle SK41G. It is a great computer… elegant, powerful, and small. I have windows installed for games (the SK41G is great for LAN parties), but I use Mandrake Linux most of the time. To get Wake-On-Lan(WOL) working with it, I had to do two things:

1. Enable WOL in the BIOS. The options for this are in “Power Management Setup”–>”IRQ/Event Activity Detect”. There are two options: “PowerOn by PCI Card” and “Modem Ring Resume”. I’m not sure why, but either option enables WOL when the computer has just been plugged into power, but “PowerOn by PCI Card” is the only one I could get to enable WOL when linux shuts down the computer. (WOL is strange that way…)
2. Configure linux so WOL is enabled when the computer shuts down. This WOL FAQ suggests adding a post-install line to /etc/modules.conf to run ethtool, but that didn’t work on my system. Instead I put this in /etc/rc.d/rc.local:

   ethtool -s eth0 wol ubmg
   

The Bering installation instructions explain how to configure Bering on the firewall machine itself, by using the lrcfg program and backing up the files to the floppy disks. Sometimes I find it more convenient to edit configuration files on my desktop computer, and then copy the new image to floppy disk. (I have a linux desktop, by the way. I’m not sure how to do this on windows)

Here’s how I do it:

1. Mount the disk image as a loopback filesystem:

   $ mkdir mount_directory
   $ mount -o loop -o umask=000 diskimage.bin mount_directory
   

2. Some files, like syslinux.cfg, can be edited directly
3. lrp packages need to be uncompressed before they can be edited. This has to happen in a temporary directory outside the mounted disk image, since there won’t be enough room inside the mount directory:

   $ mkdir package_directory
   $ cd package_directory
   $ tar -zxvf ../mount_directory/package.lrp
   

4. After editing files in the package, re-compress it and replace the original lrp file:

   $ tar -cvf package.tar *
   $ gzip -9 package.tar $ cp package.tar.gz ../mount_directory/package.lrp
   

5. Finally, unmount the image:

   $ umount mount_directory
   

If you want to test your images before unmounting them, call sync first to make sure the images are up to date.