Required Certificates

In order to connect securely over SSL to freenode you need to ensure you have the certificate installed. On FreeBSD, this port is ca_root_nss.

portmaster security/ca_root_nss

Configure the Network and Server

/network add -nick 'nick' -realname 'real name' freenode
/server add -auto -ssl_verify -ssl_cafile /usr/local/share/certs/ca-root-nss.crt -network freenode chat.freenode.net 7000
/save

Note: If the blog wraps the content, there are three commands above, prefixed with /. /network, /server and /save.

Now, when you open irssi, you’ll automagically connect to Freenode over SSL.

Installation

First, of course, I installed the git port:

portmaster devel/git

I made sure to select the gitweb option, which is de-activated by default. The other options are up to you.

Configuration

Second, I configured Lighttpd in the simplest manner I could find. This solution uses the existing gitweb files in-place. This is contrary to what the pkg-message prescribes, but I like this idea because it’ll ensure that upgrades are handled automatically. I don’t plan to run any additional repositories either, so using the one central set of files is preferable in my situation. This is my configuration:

$HTTP["host"] =~ "^origami.zelut.org" {
$HTTP["url"] =~ "/gitweb/" {
server.indexfiles = ( "gitweb.cgi" )
}
alias.url += ( "/gitweb/" => "/usr/local/share/examples/git/gitweb/" ),
cgi.assign = ( ".cgi" => "/usr/bin/perl" )
}


Repository Configuration

Lastly, I update the repository configuration in /usr/local/share/examples/git/gitweb/gitweb.cgi to my repository location:

our $projectroot = "/path/to/git/repository/"

Conclusion

I find that Lighttpd configuration, once you get used to it, is much simpler than Apache configuration. It’s all a matter of taking the time to learn the options (and finding examples, like this one) and it gets simpler.

I think this configuration for gitweb is very clean, requires minimal configuration additions, and is hopefully pretty self explanatory. I hope it works for you as well.

Problem

The web server seemed to work great. It was handling traffic efficiently. Logs were going where they were expected. Rewrites were working. All the main things that I would expect to test were working just fine. And then I uploaded a file.

Hard lock. Panic. Do not pass go. Do not collect $200. This was bad.

I was even able to reproduce it. Anytime I would upload a file to the server (in my case via WordPress upload form), the server would hard-lock and I’d have to manually bring it back up.

Solution

The solution was to manually define the server.network-backend value, instead of using the auto-detected value. Apparently, at the time of this writing, the auto-detection on FreeBSD is.. less than perfect. The solution that I found was to add the following line to my lighttpd.conf:

server.network-backend = "writev"

After restarting the lighttpd service things seemed to perform as expected.

Conclusion

FreeBSD is a great, stable hosting platform. Lighttpd is a lightweight, efficient web server. Together they provide me with a very efficient, stable web hosting environment. The simple detail is to define the right parameters for the platform in the configuration.

Linux

mount -o loop image.iso /mnt

This works fine in Linux and lets you “mount” the .iso file as if it were burned and in the drive. This does not work on FreeBSD. You get an error like:

mount: image.iso mount option is unknown: Invalid argument

FreeBSD

The solution (the only one I’ve found so far) is to use a much more in-depth command like:

mount_cd9660 -o ro /dev/$(mdconfig -a -t vnode -f /path/to/file.iso) /mount-point

Hopefully this little note helps someone else have less trouble than I did in mounting .iso images in FreeBSD.

Configure /etc/login.conf

The password format is stored within the /etc/login.conf file. The default value being “md5″. To update your configuration to use blowfish instead make the following change to your file:

-       :passwd_format=md5:\

+       :passwd_format=blf:\

After you’ve made this change you’ll need to rehash the login database, which is done using the cap_mkdb command:

cap_mkdb /etc/login.conf

At this point any newly assigned passwords will be created using blowfish instead of MD5. Any existing accounts will retain their MD5 password hash until the password is reset.

• Parallel Ports Build (announcement)
• Jails v2 (commit message)
• Xen Dom-U support (wiki page)

There is actually quite a bit more, but those are the immediate ones that look like they’d noticeably affect me. I’d really love to have FreeBSD setup on a VPS via Xen, with Jails for each of my services. Currently I have that setup at home (jails), but its on old hardware that takes forever to compile. Parallel Ports Build would sure be a nice improvement, assuming the hardware can handle it (which my current hardware cannot).

To any of you other FreeBSD users out there, what are you excited for in the list and why?

The solution I found was a tool called “JailKit“, which allows you to create chroot jails is a very simple way. Below I’ll outline the requirements for installing JailKit and using it to create an SSH chrooted “Jail”.

Step 1: Install JailKit

I was unable to find an up to date package for JailKit on CentOS, so I did the following to install from source:

yum install gcc make
wget -c http://olivier.sessink.nl/jailkit/jailkit-2.7.tar.bz2
tar xf jailkit-*.tar.bz2
cd jailkit-*
./configure
make
make install


Step 2: Configuration

Once you have JailKit built and installed you’ll need to configure it to provide the needed libraries and devices for your chroot SSH setup. Below is an example configuration I used for a JailKit setup on CentOS 5 x86_64 (using JailKit 2.5 at the time). Note: This is not the entire configuration. These three sections, uidbasics, ssh and basicshell required minor changes and this was the end-product of those changes:

[uidbasics]
comment = common files for all jails that need user/group information
libraries = /lib/libnsl.so.1, /lib64/libnsl.so.1, /lib/libnss*.so.2, /lib64/libnss*.so.2
regularfiles = /etc/nsswitch.conf
emptydirs = /home

[ssh]
comment = ssh secure shell
executables = /usr/bin/ssh
includesections = netbasics, uidbasics
devices = /dev/urandom, /dev/tty, /dev/null

[basicshell]
comment = bash based shell with several basic utilities
executables = /bin/sh, /bin/bash, /bin/ls, /bin/cat, /bin/chmod, /bin/mkdir, /bin/cp, /bin/cpio, /bin/date, /bin/dd, /bin/echo, /bin/egrep, /bin/false, /bin/fgrep, /bin/grep, /bin/gunzip, /bin/gzip, /bin/ln, /bin/ls, /bin/mkdir, /bin/mktemp, /bin/more, /bin/mv, /bin/pwd, /bin/rm, /bin/rmdir, /bin/sed, /bin/sleep, /bin/sync, /bin/tar, /bin/touch, /bin/true, /bin/uncompress, /bin/zcat, /usr/bin/id
regularfiles = /etc/motd, /etc/issue, /etc/bash.bashrc, /etc/bashrc, /etc/profile
directories = /usr/lib/locale/en_US.utf8
users = root
groups = root
includesections = uidbasics


Step 3: Populate The Jail Environment

Once these changes are made JailKit should be configured to provide the needed libraries and devices to your SSH chroot. You can now generate the chroot by using these two commands:

jk_init -v -f /home/chrootusers/ ssh
jk_init -v -f /home/chrootusers/ basicshell


Step 4: Generate Users

The final step in an SSH-chroot Jail setup is the creation of users. This step is a bit more complicated due to the fact that the users need to be created within the chroot setup and on the host system itself. The users will never have access to the host system, but that is where the initial authentication happens. Once they are authenticated they are pushed into the chroot jail and have limited permissions.

This script assumes two things that you should be aware of. If your configuration doesn’t match you’ll need to update the script accordingly:

1. This script assumes your chrooted jail home directories will be in /home/chrootusers/.
2. This script assumes group-based SSH restrictions using a system group called sshaccess.
3. This script also attempts to create storage restrictions using filesystem quotas, but succeeds if quotas are not enabled. (See Appendix for information on enabling quotas.)

Here is the script:

#!/bin/bash
#
# This code is released under the Public Domain.
# create jailed ssh accounts
# christer.edwards@gmail.com
# usage: ./chroot-jail username 'passwdhash'
#

## sanity checks
if [ $# -ne 2 ]; then
echo "This application requires two arguments: username 'passwdhash' (single-quotes required)"
exit 1
fi

if [ ! -d /home/chrootusers/./home/ ]; then
echo "This application assumes installation to /home/chrootusers"
exit 1
fi

getent passwd $1 &>/dev/null
if [ $? -eq 0 ]; then
echo "User $1 already exists on host system. Please remove and re-create using this tool."
exit 1
fi

getent group sshaccess &>/dev/null
if [ $? -ne 0 ]; then
echo "This application assumes 'AllowGroups sshaccess' restriction in /etc/ssh/sshd_config. sshaccess group missing"
exit 1
fi

## creation
echo
echo "Creating User and Jailed Home Directory"
echo
useradd -m -d /home/chrootusers/./home/$1 -s /usr/sbin/jk_chrootsh -p $2 $1

echo "Adding User to 'sshaccess' Group"
echo
gpasswd -a $1 sshaccess &>/dev/null

JAILUID=$(id -u $1)
JAILGID=$(id -g $1)

echo "Creating Required Internal Jail Passwd and Group Files"
echo
echo "$1:x:${JAILUID}:${JAILUID}::/home/$1:/bin/bash" >> /home/chrootusers/etc/passwd
echo "$1:x:${JAILGID}:" >> /home/chrootusers/etc/group

echo "Applying Quota Restrictions"
setquota -u $1 10240 15360 0 0 /home || echo "Unable to Apply Quota Restrictions. Are Quotas enabled?"


If you create all of your users using this script you should save yourself a fair amount of headache. Between the user-creation script and the JailKit tools, creating SSH chrooted jails becomes a very simple task.

Appendix: Enabling Quotas

When I first implemented this JailKit setup in production I invited a few of the users to do their worst to break out of the jail or otherwise interfere with the system and other users. One of the potential problems that we found was that of drive space. Because there were no storage limitations for the chrooted users, one user could create large files and interfere with the others (or the host system) by filling up the drive. Below I’ve outlined how to activate filesystem quotas on Red Hat Enterprise or CentOS machines and apply a 15M hard limit to your chrooted users:

Configure usrquota

Quotas are a filesystem-based feature that needs to be activated within the fstab. To activate the use of persistent quotas append the term “usrquota” to the mount options of /home/ in your fstab. Example:

/dev/LocalVol/HOME    /home    ext3    defaults,usrquota    1 2

Activate usrquota

Once this is configured the following four commands will install, configure and activate quotas.

yum install quota
mount -o remount /home/
quotacheck -cmu /home/
quotaon /home/

At this point you aren’t applying any limits to the user (yet), but the quota management system is on and active. If you create your users using the script above they will be given a 10M soft limit (after 10M they will be given a warning) and a 15M hard limit (absolutely no more disk writes). You can change these values (last line in the script) based on your needs.

20090323:       p4      FreeBSD-SA-09:06.ktimer, FreeBSD-EN-09:01.kenv
Correctly sanity-check timer IDs. [SA-09:06]
Limit the size of malloced buffer when dumping environment
variables. [EN-09:01]

If you’re interested in applying this update to your system, here is the method I use:

csup -g -L2 cvsup.freebsd.org /usr/share/examples/cvsup/standard-supfile
cd /usr/src
make buildkernel && make installkernel
make buildworld && make installworld
reboot

There are other methods for keeping your base system updated, but I prefer the compiling method. What other methods might you suggest?

First of all, let me tell you about the issue I came across.

When I would recieve an email regarding available updates I would connect to the FreeBSD Jail and use portmaster -a -d to apply all available updates.  I noticed that the number of updates applied did not match the number of updates listed in the email.  Odd.  Well, after thinking about it for a bit I realized what the problem was.

The cron job (as seen in the previous post) was running at the same time on the FreeBSD host as well as the FreeBSD Jail.  Why is that a problem, you ask?  Remember the slight variation in the host cronjob verses the jail.  The host system is pulling down the updated ports tree before it compares and emails any available updates.  The problem is introduced because the jails start doing their comparison and email reporting right away, while the host system is fetching and applying the updated tree.  Oops!  The ports tree update isn’t finished fast enough for the jails to actually have the new information.

The solution I came up with is a very simple one.  Simply update the cron daily run time on the host to give it an adequate headstart from the jails.  On my systems the /etc/crontab files now look like this:

HOST:
# Perform daily/weekly/monthly maintenance.
1   2   *   *   *   root    periodic daily
15  4   *   *   6   root    periodic weekly
30  5   1   *   *   root    periodic monthly


JAIL:
# Perform daily/weekly/monthly maintenance.
1   3   *   *   *   root    periodic daily
15  4   *   *   6   root    periodic weekly
30  5   1   *   *   root    periodic monthly

If you didn’t notice the change look closer. It’s a very small fix. The “periodic daily” row on the host is now set to run at 2:00am while the same field is set to 3:00am on the jail. I’m sure that is more than enough time for the host to update the ports tree before the jails start to do their reporting.

In conclusion, if you’re using a similar reporting system you’ll likely want to apply this small change as well.  Giving the host system enough time to update the ports tree will be critical in getting updated, accurate information within the jail systems.