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.
- Load the etherw package onto your firewall. This lets you send WOL packets when you are logged into the firewall.
- Make sure the target computer supports WOL and has it enabled in the BIOS
- 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
- 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:
- Load the wold.lrp package onto the firewall
- 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
- 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
...
- 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).
- Configure hosts.allow to allow machines to connect to the firewall
- 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)
- Back up all the Bering packages you changed (wold, shorewall, etc)
- 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:
- 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…)
- 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:
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:
- Mount the disk image as a loopback filesystem:
$ mkdir mount_directory
$ mount -o loop -o umask=000 diskimage.bin mount_directory
- Some files, like syslinux.cfg, can be edited directly
- 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
- 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
- Finally, unmount the image:
If you want to test your images before unmounting them, call sync first to make sure the images are up to date.
dhcp_2_dns.sh is a script which updates tinydns with addresses handed out by dhcpd. This is useful for Bering firewalls because DNS and DHCP will be synchronized.
Here’s how to set it up:
- First, make sure tinydns is set up and running (directions are here).
- Copy dhcp_2_dns.sh onto your firewall. I put my copy in /usr/bin/. Add /usr/bin/dhcp_2_dns.sh to /var/lib/lrpkg/tinydns.list:
...
usr/bin/tinydns-data
usr/bin/dhcp_2_dns.sh
etc/tinydns-private/
...
(This adds dhcp_2_dns.sh to the tinydns.lrp package).
- Edit /etc/init.d/tinydns so that dhcp_2_dns.sh is run every time tinydns starts. Add the call near the end of set_dnscache():
...
echo "" > /var/run/resetdns.pid
/usr/bin/dhcp_2_dns.sh # run dhcp_2_dns.sh
RESET_DNS=Y
}
...
- Back up tinydns.lrp
- Edit /etc/multicron-p and add dhcp_2_dns.sh to periodic():
periodic () {
checkfreespace
pingcheck
/usr/bin/dhcp_2_dns.sh
}
By default, periodic() is run every 15 minutes. This can be changed in /etc/cron.d/multicron.
- Back up etc.lrp
This is an update to Michael D. Schleif’s dhcp_2_dns.sh script, which updates tinydns with addresses handed out by dhcpd. This includes the following changes from version 0.1:
- Fixed “out of range” problem when comparing lease dates
- Fixed problem where DNS entries were never replaced when a host’s address
changed
- New feature: fixed-address entries (from dhcpd.conf) are now added to the
DNS server
Download dhcp_2_dns.sh 0.2
I also have some simple directions for setting this up on a Bering firewall
A new version of metadate is available. This version changes the paths in the external metadate file. They used to be the full path of the file, now they are the path starting from $blosxom::datadir. This should make it easier to relocate the $blosxom::datadir (or have a blosxom installation on your desktop machine for testing)
Download metadate 0.0.2 Be sure to rename it to “metadate”
Documentation is available here.
This plugin lets you put metadates in an external file. This is especially useful when you want to specify metadates for files which can’t contain metadates themselves, such as directories, images, binary files, etc..
Download metadate 0.0.1 Be sure to rename it to “metadate”
Documentation is available here.
If you go snowshoeing, it might be a good idea to take a simple repair kit with you. We went cross country skiing to Fallen Leaf Lake today with my parents, who were on snowshoes. When we turned around to go back to the car we noticed one of the rivets was missing from my Dad’s snowshoe. My parents have had a few rivets pop out of their snowshoes in the past, so they were prepared when it happened again today:
Repair Kit
- A few washers
- A few small screws
- A few nuts
- A small pair of pliers
- A small screwdriver
These made the repairs simple and fast.
Here’s something to do while you watch TV: build paper models. Called “card modeling” or “papercraft”, it’s inexpensive and doesn’t take up as much room as regular plastic models. There are hundreds of free designs on the internet, and hundreds (thousands?) more you can buy for a few dollars each.
All you really need is a design, a printer, some heavy paper (card stock works well, look in office supply stores), a sharp knife, and some white glue. The best resource site I have found is cardfaq.org. They give much more detailed information on how to build the models than I ever could, plus they have a huge list of links to free designs.
Just to give you an idea of what kind of models you can find, here are a few links: