Zelut’s Blog

I love FreeBSD for how efficient and minimalistic it can be.  For my web servers I like to add to this efficiency by using Lighttpd instead of the larger, older, Apache.

The one little issue with Lighttpd vs Apache is getting all the same module support setup for all the little tweaks that you’ve come to enjoy.

I should mention that Lighttpd supports many of the same modules that Apache does, and once you learn how they work I think they are even more intuitive than Apache’s config.  One of the most important to me is the mod_rewrite for use with my WordPress blogs.  As you can see from the URL I use fancy addresses for my posts.  %date%/%name%, etc.  I think this is more user friendly (not to mention Google-friendly) than something like php?=53.  What kind of URL is that?

In any case, a very simple way to achieve this in Lighttpd is to use the following single line in your lighttpd.conf file:

## added for WP pretty URLs
server.error-handler-404 = "/index.php"

Again, I’d argue this is much simpler than a dozen lines in an .htaccess file and gives you the same results.  It’s like magic!

Perhaps I’ll do a few more posts regarding other aspects of Lighttpd configuration as it compares to Apache.  Things like mod_redirect, mod_auth, mod_alias, etc.  Until then, if you haven’t tried out Lighttpd you really should!

Update: I have suggested a minor improvement to this setup.  Read More…

For some time now I’ve been maintaining about a dozen FreeBSD jails, each running a different set of services. Everything from email to BIND, DHCP to nagios. One of the difficulties of trying to maintain so many servers has been tracking and applying updates, particularly servers that use the ports system which is updated so frequently.

The solution that I’ve come up with is to use portmaster inside a weekly cron job to notify me of available updates on each machine. This requires a slightly different cron job on the host system that within the jails. Here is an example of what I’m running within each:

#!/usr/local/bin/bash

/usr/sbin/portsnap cron
/usr/local/bin/ezjail-admin update -P

/usr/local/sbin/portmaster -L | egrep -B1 ‘(ew|ort) version|Aborting|installed|dependencies|IGNORE|marked|reason:|MOVED’ | grep -v ‘^–’ | mail -s “Portmaster Weekly Check for $(hostname)” admin@domain.tld


#!/usr/local/bin/bash

/usr/local/sbin/portmaster -L | egrep -B1 ‘(ew|ort) version|Aborting|installed|dependencies|IGNORE|marked|reason:|MOVED’ | grep -v ‘^–’ | mail -s “Portmaster Weekly Check for $(hostname)” admin@domain.tld

As you can probably tell, the only major difference between the two is that the cron job as run on the host system also updates the ports tree prior to checking for updates. The cron job within the jail system simply runs the check.

I save these two scripts inside /etc/periodic/weekly/999.portmaster and make them executable.  From that point on I’m notified via email regarding updates available to my installed ports.

I’d be interested in hearing what solutions others have come up with for monitoring and maintaining ports updates from so many FreeBSD servers.

I have had all kinds of problems getting dhcpd running properly inside a FreeBSD jail.  I finally got it running this morning and wanted to document what I’ve done in hopes that I can recreate it.

On the host system I had to allow sockets within jails.  This is done by adding this line to your /etc/sysctl.conf:

security.jail.allow_raw_sockets=1

The above will make it a persistent change, but you’ll also need to make it an immediate change using the sysctl tool directly:

sysctl -w security.jail.allow_raw_sockets=1

Within the jail I then installed the net/isc-dhcp30-server port.  I configured this with just two of the available options.

1. Allow sockets instead of bpf (jails-only)
2. Use base openSSL

After this was compiled I configured my /usr/local/etc/dhcpd.conf and added the following lines to my /etc/rc.conf:

## dhcpd options
dhcpd_enable=”YES”
dhcpd_flags=”-q”
dhcpd_conf=”/usr/local/etc/dhcpd.conf”
dhcpd_ifaces=”"
dhcpd_withumask=”022″

The last thing that always caught me was that I never saw any log output in the /var/log/messages.  Turns out, at least on my installation, it doesn’t log there.  It does however log to /var/log/all.log, which is where I found that it was actually working.

I hope this works for the rest of you.  I had trouble with it for the longest time.

I want to thank one of the readers who left a comment recently regarding the use of cvsup.  Apparently, some time ago, cvsup was replaced with a smaller, faster utility which comes included in the base OS.  This tool is simply: csup.

Some of the benefits of using csup instead of cvsup are:

1. It comes preinstalled in the base OS.
2. No need to build cvsup and all its dependencies.
3. No need to install base ports in order to build cvsup in order to update your ports.

I tried csup and noticed that it should be a drop-in replacement for those that still use cvsup.  You should be able to use the same options and command arguments that you did previously.

Here is an example of something I’ve setup which allows me to update my base OS + ports using csup and one command:

/etc/make.conf

## csup config (just use 'make update' in /usr/ports or /usr/src)
SUP_UPDATE=yes
SUP= /usr/bin/csup
SUPFLAGS= -g -L2
SUPHOST= cvsup.freebsd.org
SUPFILE= /usr/share/examples/cvsup/standard-supfile
PORTSSUPFILE= /usr/share/examples/cvsup/ports-supfile

After adding those lines to your /etc/make.conf you can update your base OS and ports tree using ‘make update’ within the /usr/src directory.

For more info on using either of these tools see the CVSup Handbook page.

I spent some time this afternoon trying to setup named (BIND 9.5) within a FreeBSD jail for internal use.  I ran into an issue where it was unable to mount devfs and failed on me.  After a little bit of digging I found a solution.

This is the error that was reported (see link):

/etc/rc.d/named: WARNING: devfs_domount(): Unable to mount devfs on /var/named/dev
devfs rule: ioctl DEVFSIO_RAPPLY: Operation not permitted
devfs rule: ioctl DEVFSIO_RAPPLY: Operation not permitted

In a nutshell, add the following line to the jail /etc/rc.conf and you should be OK.

named_chrootdir=""

Yes, this means that you’re not running named within a chroot like it would by default but remember its in a jail anyway–a really fancy, hardened chroot.

Why is it that wireless is the “killer-app” of hardware on the *NIX platforms?  I remember spending hours and hours getting it working via ndiswrapper on Ubuntu back in the day.  Luckily its simple to get working in FreeBSD 7.0, and adding WPA encryption is just a few more steps.

Here I’ll outline what I’ve added to get WPA-PSK working on FreeBSD 7.0 on my Dell Latitude D630.

First, if you are not using the default GENERIC kernel you’ll need to load some encryption modules.

You’ll want to load the following by adding the lines to your /boot/loader.conf:

wlan_ccmp_load=”YES”
wlan_tkip_load=”YES”
wlan_wep_load=”YES”
wlan_xauth_load=”YES”
wlan_acl_load=”YES”

If you are using the default GENERIC kernel these are already included so you can skip right on to the next step.

You’ll need to configure wpa_supplicant with your ssid, key type and pre-shared key.  This is an example of what my config looks like using WPA-PSK from my netgear wireless router:

network={
ssid=”ssid-name”
key_mgmt=WPA-PSK
psk=”pre-shared-key”
}

I also added this line to my /etc/rc.conf to automate the connection process:

ifconfig_wpi0=”WPA DHCP”

Hope it works for you as well.  Good luck!

After getting my desktop setup (following these steps) I realized that I didn’t have working sound.  It took me a bit of digging around and help from IRC to find out how.  I hope to make this a bit easier for others by getting it on the web and into the infinite wisdom of Google.

First of all you need to find the right module.  The method that I used initially was a bit of a shotgun approach, but it ended up telling me the right module in the end.

If you’re coming from Linux you might be familiar with the ‘modprobe’ tool for adding and removing modules from your kernel.  In FreeBSD this tool is ‘kldload’.  So, what we’ll do is load the ‘snd_driver’ module, which will end up telling us which one.  This may take some time and your machine may be unresponsive for a few moments.  Don’t panic (…unless, of course, it remains unresponsive for more than five-minutes).

kldload snd_driver

cat /dev/sndstat

On my machine I get the following output, which tells me I should use the ‘snd_hda’ module.

FreeBSD Audio Driver (newpcm: 32bit 2007061600/i386)
Installed devices:
pcm0: <Intel 82801H High Definition Audio Controller> at memory 0xf6dfc000 irq 21 kld snd_hda [20071129_0050] [MPSAFE] (1p:1v/1r:1v channels duplex default)

To autoload this module at boot time you’ll want to add the module to your /boot/loader.conf file:

snd_hda_load=”YES”

If your output reports a different module the syntax is still the same.  module_name_load=”YES”

Unfortunately, on the D630 and D830, this only activates sound from the headphones but not the built in speakers.  A workaround(?) that I found was to add another line to activate the built in speakers.  The following line goes in your /boot/device.hints file.

hint.pcm.0.config=”gpio0,gpio1,gpio2,gpio3,gpio4,gpio5,gpio6,gpio7″

note: I don’t know which of the gpioX values actually does the trick, but leaving all of them in doesn’t seem to negatively affect anything.  If anyone knows which value(s) actually does the job I’d appreciate the help.  (I haven’t had the time to try each one or a combination, followed by reboots, to test.)

By default FreeBSD sets a ten second delay during the boot process allowing the user to select alternate boot options.  Options such as single user mode, recovery, etc.  If you’d like to change this boot delay to something more reasonable you can add the following to your /boot/loader.conf:

autoboot_delay=X

I’ve set mine to two seconds (autoboot_delay=2) as I feel that is reasonable to give me time if I need it, but not sit and count down if I don’t.  If you’d like to bypass this menu altogether you can set the value to “-1″.

If you’ve used FreeBSD in the past you’re likely familiar with the mascot, Beastie.  In the past Beastie was part of the boot menu, but recently he was replaced with a simple FREEBSD text image.  To put Beastie back in the menu you can add the following to your /boot/loader.conf:

loader_logo=”beastiebw”

Next time you reboot you’ll see something a little more fun than the generic FreeBSD text.

Activating the wireless on your Dell Latitude D630 is fairly easy. For whatever reason its not supported in the default generic kernel, but all it takes is adding a few lines to a config file. A added the following lines to the /boot/loader.conf:

if_wpi_load=”YES”
wlan_load=”YES”
wlan_amrr_load=”YES”
firmware_load=”YES”
wpifw_load=”YES”
legal.intel_wpi.license_ack=1

These steps are also outlined in the wpi man page (man wpi). It tells you exactly the lines that need to go into the /boot/loader.conf. So, if you ever happen to forget again, at least that much of the instructions are on your machine (assuming you have man pages installed.)

At this point you should be able to reboot and be able to use your wireless. I use the following commands to activate and connect to an access point:

ifconfig wpi0 up
ifconfig wpi0 list scan
ifconfig wpi0 ssid [broadcast ID]
dhclient wpi0

I’ve had good luck with the wireless so far, outside of a few times when the device seems to have just switched itself off. In those cases I simply repeat the above steps after issuing a “ifconfig wpi0 down”.