First, go to Google and run some bandwidth tests in order to get a good idea of your actual line speed. Take note of your maximum upload and download speeds. On my home network, I measured around 23Mbit down and 1Mbit up. Write these numbers down and save them for later…

Next, make sure that you have the iproute package installed, to install the necessary prerequisite programs.

# yum install iproute

Now we can download the necessary htb.init script and examples to get us started. The htb.init script can be downloaded from here. Stick this script in your /etc/init.d/ directory. Next, download the example files and put them into the /etc/sysconfig/htb/ directory. Below are the commands I ran…

# wget http://sourceforge.net/projects/htbinit/files/HTB.init/0.8.5/htb.init-v0.8.5/download
# mv htb.init-v0.8.5 /etc/init.d/htb.init
# chmod 755 /etc/init.d/htb.init
# wget http://downloads.sourceforge.net/project/htbinit/Examples/LARTC/htb-lartc.tar.gz
# mkdir htb
# tar zxf htb-lartc.tar.gz -C ./htb
# mv ./htb /etc/sysconfig/

Now, one other set of commands I want to run, to slightly change the names of the htb files to fit my needs. I am only going to have two classes of traffic, plus the default. I want to make sure my www and ssh connections each have a separate allocated bucket of bandwidth, and everything else can share the default bucket. The commands below will rename the htb configuration files to match. Please note that we are using the eth0 device in this example, since it is our internet connection.

# cd /etc/sysconfig/htb
# mv eth0-2\:10.www eth0-2\:10.ssh
# mv eth0-2\:20.smtp eth0-2\:20.www

Ok! Now that we have the init script in place, and the rules files in place, we can actually start some bandwidth shaping!

You will notice in the /etc/sysconfig/htb/ folder that there are a number of different files, with some slightly different names. The first file we’ll look at, eth0, is just to specify what device we are working with. Inside this file are lines setting the default rule (the one used when no others match), and our R2Q. Note that the rate divided by R2Q gives us our quantum, which is the amount of bandwidth given to one class before servicing another class. The faster your available network connection, the larger your quantum can be. I’m using a r2q of 100, however you can always adjust this value depending on your needs and bandwidth speed. Below are the contents of the eth0 file:

# eth0 device
DEFAULT=99
R2Q=100

Next, the eth0-2.root file. This specifies the default rate, ceiling rate, and burst speed. The default rate is the minimum rate for the class (device eth0 in this case). The ceiling rate is the maximum rate for the class. Finally, the burst rate is the maximum amount of bandwidth that can be sent through the hardware without moving on to service another class. Below are the contents of the eth0-2.root file:

# root class containing total bandwidth
RATE=20Mbit
CEIL=20Mbit
BURST=1Mbit

Notice here that we are setting the rates at 20Mbit, which is below our maximum tested rate of 23Mbit. By setting our rate lower than the actual link rate, we limit the buffering done by any network equipment beyond our router (like the cable/DSL modem). This will decrease our lag time by keeping any traffic buffers on our faster equipment. I will gladly sacrifice a small amount of total speed for lower latency.

Finally, we have our rules files. I set my ssh traffic to be given a minimum of 128Kbit, and a maximum of 20Mbit. This traffic also has the highest priority, in order to increase the availability of bandwidth to ssh traffic. A similar setup is done for the www traffic, and the default traffic. Below are the three files defining these classes…

eth0-2:10.ssh

# class for SSH traffic
RATE=128Kbit
CEIL=20Mbit
PRIO=1
RULE=*:22,
RULE=*:22
LEAF=sfq

eth0-2:20.www

# class for WWW traffic
RATE=128Kbit
CEIL=20Mbit
PRIO=2
RULE=*:80,
RULE=*:443,
RULE=*:8008,
RULE=*:8080,
RULE=*:80
RULE=*:443
RULE=*:8008
RULE=*:8080
LEAF=sfq

eth0-2:99.dfl

# class for all other traffic
RATE=128Kbit
CEIL=20Mbit
PRIO=7
LEAF=sfq

Now, lets take a look at the RULE= lines from the eth0-2:10.ssh file above.

RULE=*:22,
RULE=*:22

Rules are specified with the pattern RULE=[[saddr[/prefix]][:port[/mask]],][daddr[/prefix]][:port[/mask]], so the first line, RULE=*:22, will match all traffic with a source port of 22. The second line, RULE=*:22 matches any traffic with a destination of port 22. We do the same thing with the appropriate port numbers for our www class in order to shape our www traffic. There are many options here, since this is where we control what traffic matches which class; you can specify traffic by source port, destination port, source IP, destination IP, or a combination of them! Take a look at the links below for some more examples. Finally, the default rule will apply to any traffic which does not match our first two rules.

The image below illustrates the hierarchy within this specific setup.

Now, in order to start using the rules and make them persistent on every reboot, we will add the htb.init service to the system, set it to start on boot, and turn it on right now! The commands below will do this for us:

# chkconfig --add htb.init
# chkconfig htb.init on
# service htb.init start

If you get a warning along the lines of find: warning: you have specified the -maxdepth option after a non-option argument -type, but options are not positional then you will need to uncomment the following line in your /etc/init.d/htb.init script:

HTB_BASIC="yes"

Using this simple HTB QoS setup, we can provide network bandwidth control to our small home network, preventing any one dogg from hogging all the internets! This setup will also scale fairly well to much larger installations.

Take a look at the htb.init-v0.8.5 we downloaded earlier for some more rule examples, as well as explainations of the configuration options.

Also check out the following websites for some more information on HTB QoS network traffic control.
HTB Linux queuing discipline manual – user guide
Linux Advanced Routing & Traffic Control HOWTO

First, you will want to install Fail2ban, so head over to Fail2Ban.org and follow their instructions for installing on your distribution. On CentOS or RedHat, you will need to first install the EPEL repository. After doing so, fail2ban can be installed with the yum command yum install fail2ban. That takes care of the installation!

Once you have Fail2Ban installed, you can start configuring it! One of the problems that I run into with Fail2Ban is that it will try to load all the firewall rules too fast, resulting in errors like this:
iptables -I INPUT -p all -j fail2ban-w00tw00t returned 400
You may also get some 100 or 200 errors as well. Well, the fix for this is easy enough (and hopefully it will be incorporated into upcoming versions; as of version 0.8.4 is is not). Simply edit the file /usr/bin/fail2ban-client and add the line time.sleep(0.1) into the __processCmd function. This is added around line #145. The first few lines of the function should look like this:

def __processCmd(self, cmd, showRet = True):
    beautifier = Beautifier()
    for c in cmd:
        time.sleep(0.1)
        beautifier.setInputCmd(c)
        try:

So, now that we have a working Fail2Ban setup, we can start configuring some rules!

First, take a look at /etc/fail2ban/fail2ban.conf. This lets us specify some log options. The only one that I am really concerned about is the logtarget, which I like to set to /var/log/fail2ban.log.

Next, let us look at the /etc/fail2ban/jail.conf file. Here you will want to configure your list of ignore IP’s, which should include localhost, and your trusted machine(s) or subnet (ex: ignoreip = 127.0.0.1 192.168.0.0/24 8.8.8.8). You can also adjust the bantime, findtime, and maxretry options, all of which are explained within the file.

Next you can pick what jails to run, and override any global settings with specific settings set here. Spend some time reading through the different jail configurations to get an idea for how to set yours up. I’m always a little more paranoid about security; I don’t want any cats in my dogghouse, so I will usually completely ban any user that fits one of my rules. You could optionally just ban them from using the service they are attempting to exploit, if you wish.

Lets take a look at a jail configuration that I wrote myself.

[dns-root]
enabled  = true
filter   = dns-root
action   = iptables-allports[name=DNS-ROOT]
           sendmail-whois[name=dns-root, dest=jerp@herpandderp.com, sender=fail2ban@myserver.com]
logpath  = /var/named/chroot/var/log/bind.log
maxretry = 2
bantime  = 86400

One of my nameservers was getting a large number of NS lookup requests for the root domains. Well, our server isn’t authoritative for the root zone, so we respond with a REFUSED notice, however this didn’t keep the requests from coming. At first I thought that it was some sort of lame DOS attack against one of my nameservers, but after investigation I found that this was likely a Root DNS Amplification Attack against Facebook! I would get approximately one request per minute for the root NS records, sending out one REFUSED response per minute to an IP address owned by Facebook. In order to combat these annoyances, I created the [dns-root] jail for Fail2Ban.

Lets take a look at what each setting in this jail does. First, the enabled line dictates whether or not the jail is active. Next, the filter line specifies the name of the filter that will be used to match undesired behavior. The action line in this case says to run the iptables-allports action, inserting an iptables rule into the chain named DNS-ROOT, which will drop traffic from the banned host on all ports. Optionally, you can select to only have specific ports dropped, instead of banning the host from your entire server. The sendmail-whois line lets us send an email, with whois inforation about the banned host, to whoever you like. Finally the logpath specifies the actual log to be checked against, and the maxretry along with the bantime values will override the global variables you specified earlier in that file.

Next, take a look at the matching filter. After removing some extra comments, we are left with this:

# Fail2Ban DNS-ROOT configuration file

[Definition]
failregex = ^.* security: info: client #.*: query \(cache\) './(NS|A|AAAA|MX|CNAME)/IN' denied

ignoreregex =

What we have are two variables. The first is failregex, which is a regex formatted statement to match denied root zone lookup lines in our log files. The next variable, ignoreregex, lets us specify something to search for, which will cause a matched line to be ignored. Basically, if the failregex line is matched, the host is banned. If both lines are matched, the host is not banned.

Now, once you have everything configured, you should be able to set the service to start at boot with the chkconfig fail2ban on command, and immediately make the service start with the service fail2ban start command.

Now you can finally have some piece of mind, knowing that those pesky internet cats wont be able to get into your dogghouse and steal your bone!

If you are interested in creating your own rules, check out Regexpal.com for help in writing and debugging regex.

Now, these instructions are for RedHat based distro’s, and were specifically written using CentOS 6. This type of ipv6 tunnel won’t work behind NAT, so your machine must be connected directly to the internet with a public IP address (UPDATE: Thanks to KingKurly for pointing out that you can forward Protocol 41 to enable a tunnel through NAT, if your device supports it). If you are looking for something that will work behind NAT, an AYIYA tunnel from SixXS.net should work over NAT for you, and we’ll cover how to do this in a future article. But, for now, let us continue with our 6in4 ipv6 tunnel from Hurricane Electric.

First, go to Hurricane Electric and get your free tunnel.

Next, open up ping requests from Hurricane Electric. This step is important, as they won’t allocate a tunnel if they can’t ping your machine. I normally don’t respond to ping requests, so I had to use a firewall rule like the one below to allow their pings through.

-A INPUT -p icmp -m icmp -m limit -s 66.220.2.74/32 -i eth0 --icmp-type 8 --limit 1/sec -j ACCEPT

Don’t forget to restart your firewall after making changes, to make sure your changes are active! service iptables restart

Once you have an account you will want to create a regular tunnel. This is basically an IPv4 tunnel between your computer and Hurricane Electric which carries your IPv6 traffic. Enter your IPv4 address as the tunnel’s endpoint address. After entering your IPv4 address, the website will check to make sure that it can ping your machine. If it cannot ping your machine, you will get an error like the one below:

If this happens, go back and check your firewall rules, and make sure that you can ping your machine from the outside. If all else fails, try a more relaxed firewall rule, like this:

-A INPUT -p icmp -m icmp -s 66.220.2.74/32 -j ACCEPT

Or, even more relaxed:

-A INPUT -p icmp -m icmp -j ACCEPT

The first rule accepts all ICMP traffic from 66.220.2.74, while the second accepts all ICMP traffic from everyone.

Once everything is ready, you should see a message like this:

Now, it is time to configure our tunnel! Go to the Tunnel Details page of your tunnel, and start entering information. Give your tunnel a description, which can be anything you want. Then, assign a Routed /48, so we can have a larger block of addresses to play with. Finally, set up your rDNS delegations, by entering your DNS servers in the provided spaces. When you are all done, it should look something like this:

Next, it is time to configure the ipv6 tunnel on our server! We need to create an interface file for our IPv6 tunnel, so create the /etc/sysconfig/network-scripts/ifcfg-sit1 file and put the following in it:

# Hurricane Electric V6V4 ipv6 tunnel
ipv4a=209.51.xxx.xxx          # Server IPv4 Address from configuration above
ipv4b=66.228.xxx.xxx          # Client IPv4 Address from configuration above
ipv6a=2001:db8:xxxx:xxxx::1   # Server IPv6 Address from configuration above
ipv6b=2001:db8:xxxx:xxxx::2   # Client IPv6 Address from configuration above

NAME="Hurricane Electric SIT"
DEVICE=sit1
ONBOOT=yes
USERCTL=yes
BOOTPROTO=none
PEERDNS=no

IPV6INIT=yes
IPV6_AUTOTUNNEL=yes
IPV6ADDR="$ipv6b/64"
IPV6_ROUTER=yes
IPV6_AUTOCONF=no

IPV6_CONTROL_RADVD=yes
IPV6TUNNELIPV4=$ipv4a
IPV6TUNNELIPV4LOCAL=$ipv4b

PHYSDEV=eth0
TYPE=sit
DEVICETYPE=sit
NM_CONTROLLED=no

NETWORKING_IPV6
IPV6_DEFAULTGW=$ipv6a
IPV6_DEFAUTLDEV=sit1

Don’t forget to change the IP addresses at the top of the file to match yours!

Now, all that is left is to assign some IPv6 addresses to our interfaces! In your /etc/sysconfig/network-scripts/ifcfg-eth0 file, you can add a few lines like the following:

#HE.net ipv6 tunnel config
IPV6INIT=yes
IPV6ADDR=2001:db8:xxxx:xxxx::1/64
IPV6ADDR_SECONDARIES="2001:db8:xxxx:xxxx::1/64 2001:db8:xxxx:xxxx::1/64"

Make sure you change the IPv6 addresses to match what you have been given by Hurricane Electric!

After restarting your network (with service network restart), you should be up and running! You can browse to an IPv6 website or try to ping an IPv6 address, to see if your IPv6 setup is working.

Next, you can configure your forward and reverse DNS zones with the necessary records to show off your shiny new IPv6 addresses!

Installation was fairly easy, however the documentation to make it work how I wanted on an RPM based distro was conflicting, spread across multiple sites, and somewhat lacking…

First, we need to add the rpmforge repo, in order to install the prerequesites with yum. Instructions for installing RPMForge can be found at the CentOS RPMForge Howto, but it basically consists of the following:

rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt
rpm -i http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm

Next, we need to install some prerequisite packages:

yum install gcc mplayer ffmpeg mencoder java-1.7.0-openjdk ImageMagick

If you wish to stream web content, you will also want to install vlc:

yum install vlc

If you are having problems installing vlc, because of version conflicts with libupnp, add the line exclude=libupnp to your /etc/yum.repos.d/epel.repo, in the main [epel] section

We will also want to install libzen and libmediainfo for some additional features. You can skip this step if you like, but not all the features will work!

You can get RPM packages for libzen and libmediainfo from the MediaInfo Download Page, just select the appropriate distro and architecture, download the package, then install like this:

wget http://mediaarea.net/download/binary/libzen0/0.4.29/libzen0-0.4.29-1.x86_64.CentOS_6.rpm
rpm -Uvh libzen0-0.4.29-1.x86_64.CentOS_6.rpm
wget http://mediaarea.net/download/binary/libmediainfo0/0.7.64/libmediainfo0-0.7.64-1.x86_64.CentOS_6.rpm
rpm -Uvh libmediainfo0-0.7.64-1.x86_64.CentOS_6.rpm

Finally, we are ready to install ps3mediaserver! Go grab the latest ps3mediaserver package from the ps3mediaserver download page, and extract it somewhere. I like to put it in my /usr/local/share directory so that I can run it as a service in the background or as a non-privileged user.

Next, we will follow Geoff Hodder’s advice and create a symlink from /usr/local/share/pms to the current version of pms, which we can change in the future when upgrading, making the upgrade process easier!

ln -s /usr/local/share/pms-1.90.0 /usr/local/share/pms

Double check the ownership here on the pms-1.90.0 folder. I have mine owned as root:root. The default permissions should be correct. Below are what my folder permissions look like.

lrwxrwxrwx   1 root root   27 Nov 19 21:07 pms -> /usr/local/share/pms-1.90.0
drwx------   5 root root 4.0K Jan 29 07:48 pms-1.90.0

Now go to the directory you just created with the ln command above, (/usr/local/share/pms/ in my case), and edit the file PMS.conf, changing the following settings:

minimized = true
network_interface = br0
folders = /data/movies,/data/music,/data/pics

Optionally, edit the following settings to enable chapters on .mkv files, and disable forced subtitles:

chapter_support = true
mencoder_disablesubs = true

If you are upgrading from a previous version of ps3mediaserver, don’t just copy your old config file. Variable names are often changed, new variables are added, and old ones may be removed. Double check your settings and apply them to the new file!

Obviously you will want to change the folders and network_interface settings to match your setup. The defaults for the rest of the settings should be fine, but take a look through the other settings if you wish.

One additional change was made to the /usr/local/share/pms/renderers/XBOX360.conf file to allow avi streaming to the XBox 360. Find the StreamExtensions= line and avi to the end, so it will look like this:

StreamExtensions=wma,asf,avi

Phew… We’re almost there!

One of the things I specifically wanted was to be able to run this as a service on boot. I also wanted to specify my config file, instead of having it use one from my home folder. In order to do this we are going to edit the /usr/local/share/pms/PMS.sh file. Comment out the DIRNAME=`dirname $CMD` line and add a line like DIRNAME="/usr/local/share/pms/" right below it. Here is what the first few lines of my PMS.sh file look like:

#!/bin/sh

CMD=`readlink -f $0`
#DIRNAME=`dirname $CMD`
DIRNAME="/usr/local/share/pms/"

One more thing that I wanted was the ability to simply run a command from anywhere, as any user, and start the service. I just created a symbolic link in the /usr/local/bin to the PMS.sh script like so:

ln -s /usr/local/share/pms/PMS.sh /usr/local/bin/pms

We must now allow TCP traffic on port 5001 and UDP traffic on port 1900 through our firewall, along with multicast IGMP traffic, to actually let this thing work! Open the appropriate ports with some lines like this in your /etc/sysconfig/iptables file:

-A INPUT -s 10.0.0.0/24 -i br0 -p tcp -m tcp --dport 5001 -j ACCEPT
-A INPUT -s 10.0.0.0/24 -i br0 -p udp -m udp --dport 1900 -j ACCEPT
-A INPUT -d 224.0.0.0/4 -i br0 -p igmp -j ACCEPT

You will also need to set the default multicast address route. This can be set in the /etc/sysconfig/network-scripts/route-br0 file, looking like this:

# /etc/sysconfig/network-scripts/route-br0
224.0.0.0/4 dev br0

Make sure to change the source address mask to match your local network addresses, and the interface to match your local network interface. If you have IPv6 running, you should also open those same ports in your /etc/sysconfig/ip6tables firewall:

-A INPUT -p tcp -m tcp -s 2001:1234:5678:abcd::/64 -i br0 -j ACCEPT --dport 5001
-A INPUT -p udp -m udp -s 2001:1234:5678:abcd::/64 -i br0 -j ACCEPT --dport 1900

PLEASE NOTE!!! If you have IPv6 running, you will want to remove the -Djava.net.preferIPv4Stack=true parameter from the last line of the PMS.sh file. More details below…

Again, make sure that your source address mask and interface match your network configuration, and don’t forget to restart your firewalls to apply the new rules!

Now, before we go any further, we can attempt to run the server and make sure that everything is actually working correctly. Just type pms from a command prompt and watch it go!

If everything is working correctly, you will either have the GUI window pop up, or get a message like this:

GUI environment not available
Switching to console mode

or you may get a bunch of debug messages fly by. If there are any errors, double check everything before moving on.

If you are in the console mode, press crtl-c to stop the ps3mediaserver.

Finally, the last thing I want to do is set this thing to run as a service/daemon in the background and start on boot. In order to do this we need a startup script!

Create the /etc/init.d/ps3mediaserver file and put the following in it:

#!/bin/sh
#
# chkconfig: - 91 50
# description: Starts and stops the ps3mediaserver
# version: 0.8
# pidfile: /usr/local/share/pms/ps3mediaserver.pid
# config:  /usr/local/share/pms/PMS.conf

# Source function library.
if [ -f /etc/init.d/functions ] ; then
  . /etc/init.d/functions
elif [ -f /etc/rc.d/init.d/functions ] ; then
  . /etc/rc.d/init.d/functions
else
  exit 1
fi

# Avoid using root's TMPDIR
unset TMPDIR

# Source networking configuration.
. /etc/sysconfig/network

# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 1

PROG_NAME='ps3mediaserver'
PROG_ROOT='/usr/local/share/pms'
PROG_JAR='pms.jar'
PROG_EXEC='PMS.sh'

RETVAL=0

start() {
        KIND="$PROG_NAME"
        echo -n $"Starting $KIND services: "
        cd $PROG_ROOT
        daemon $PROG_ROOT/$PROG_EXEC
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ] && echo `ps axo pid,args | grep $PROG_JAR | grep -v grep | awk {'print $1'}` > $PROG_ROOT/$PROG_NAME.pid || \
           RETVAL=1
           ps axo pid,args | grep $PROG_JAR | grep -v grep | awk {'print $1'} > $PROG_ROOT/$PROG_NAME.pid
        return $RETVAL
}

stop() {
        KIND="$PROG_NAME"
        echo -n $"Shutting down $KIND services: "
        killproc -p $PROG_ROOT/$PROG_NAME.pid
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ] && rm -f $PROG_ROOT/$PROG_NAME.pid
        return $RETVAL
}

restart() {
        stop
        start
}

rhstatus() {
        status -p $PROG_ROOT/$PROG_NAME.pid $PROG_NAME
        return $?
}

case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  restart)
        restart
        ;;
  status)
        rhstatus
        ;;
  *)
        echo $"Usage: $0 {start|stop|restart|status}"
        exit 2
esac
exit $?

One of the last things we need to do is make a small change to the last line of our PMS.sh script, to allow it to run in the background, and log to a file. The last line should look like this (note the difference between IPv4 and IPv6 networks!):
IPv4:

exec "$JAVA" $JAVA_OPTS -Xmx768M -Xss1024k -Dfile.encoding=UTF-8 -Djava.net.preferIPv4Stack=true -Djna.nosys=true -classpath "$PMS_JARS" net.pms.PMS "$@" >> /var/log/ps3mediaserver.log 2>> /var/log/ps3mediaserver.log &

IPv6:

exec "$JAVA" $JAVA_OPTS -Xmx768M -Xss1024k -Dfile.encoding=UTF-8 -Djna.nosys=true -classpath "$PMS_JARS" net.pms.PMS "$@" >> /var/log/ps3mediaserver.log 2>> /var/log/ps3mediaserver.log &

I have not been able to get the IPv6 configuration for PS3 Media Server to work reliably on all my devices… If you have any suggestions please let me know!

Finally, install the startup script and set it to run on boot!

cd /etc/init.d
chmod +x ps3mediaserver
chkconfig --add ps3mediaserver
chkconfig --level 345 ps3mediaserver on

Now, we can start the ps3mediaserver and be done!

service ps3mediaserver start
Starting ps3mediaserver services:                          [  OK  ]

Now that we are done, go ahead and get yourself a dogg treat!

Thanks to Geoff Hodder for some good tips left in the comments below. Go check out his page at PHReeK.oRG

Also, thanks to the following webpages for giving me some of the information necessary to get this thing working:
http://www.ps3mediaserver.org/forum/viewtopic.php?f=3&t=4374
https://help.ubuntu.com/community/Ps3MediaServer
http://otmanix.de/english/2009/05/17/java-ps3-media-server-for-dummies-chapter-3-installation-and-basic-configuration/

First, we need to configure radvd to advertise the IPv6 routing on our network, so lets take a look at our radvd configuration.

# RADVD with DHCPd6 configuration
# /etc/radvd.conf
interface br0 {
        AdvManagedFlag on;
        AdvSendAdvert on;
        AdvAutonomous off;
        AdvOtherConfigFlag on;
        MinRtrAdvInterval 3;
        MaxRtrAdvInterval 60;
};

This is a very basic radvd setup, which will just advertise the routing gateway to the network, and nothing more. If we are going to use DHCPd6 to hand out addresses, then this is exactly what we want for our radvd configuration. Make sure to change the interface name in the example to the interface name you will be handing out IPv6 addresses on; I have multiple interfaces bridged for my internal network and use interface br0.

If you want to use radvd to hand out addresses, then just use the following example instead.

# RADVD with no DHCPd6 configuration
# /etc/radvd.conf
interface br0 {
        AdvManagedFlag on;
        AdvSendAdvert on;
        AdvAutonomous on;
        AdvLinkMTU 1480;
        AdvOtherConfigFlag on;
        MinRtrAdvInterval 3;
        MaxRtrAdvInterval 60;
        prefix 2001:0db8:edfa:1234::/64 {
                AdvOnLink on;
                AdvRouterAddr on;
        };
};

Again, make sure to change the interface to your interface name, and change the IPv6 network prefix to your addresses.

Now, to use DHCPd for IPv6, we need a separate configuration and service/daemon to handle the IPv6 addresses, since DHCPd can’t give out both IPv4 and IPv6 addresses at the same time. If you already have a working IPv4 DHCPd setup, you can use a lot of the same configuration values in your DHCPd6 setup. Below is a basic configuration for DHCPd6.

# /etc/dhcp/dhcpd6.conf

ddns-update-style interim;
ddns-updates on;
ddns-domainname "your.domain.com";
ddns-rev-domainname "ip6.arpa";
allow client-updates;
update-conflict-detection false;
update-optimization false;
authoritative;
option domain-name-servers dns.your.domain.com;
default-lease-time 86400;
preferred-lifetime 80000;
allow leasequery;
option dhcp6.name-servers 2001:0db8:edfa:1234::1;
option dhcp6.domain-search "your.domain.com","domain.com";
include "/etc/rndc.key";
option dhcp6.preference 255;

zone a.f.d.e.8.b.d.0.1.0.0.2.ip6.arpa. {
        primary 10.0.0.1;
        key rndckey;
}
zone your.domain.com {
        primary 10.0.0.1;
        key rndckey;
}

subnet6 2001:0db8:edfa:1234::/64 {
        # Range for clients
        range6 2001:0db8:edfa:1234:5678::aaaa 2001:0db8:edfa:1234:5678::ffff;
        # Example of a fixed host address
        host client.your.domain.com {
               host-identifier option dhcp6.client-id 00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd;
               fixed-address6 2001:0db8:edfa:1234:5678::1;
        }
}

This configuration will get also give out a fixed address to one of our clients, to ensure that it always gets the same IPv6 addresses from our server. Make sure that you replace the IPv6 addresses, domain names, zone, host, and subnet settings with the correct info for your network.

Notice the line include "/etc/rndc.key";. This is where I keep the key that the DHCP and DNS servers use to allow updates, so we don’t have unknown unauthorized outside sources modifying our DNS records! Below is what my rndc.key file looks like.

# /etc/rndc.key

key "rndckey" {
        algorithm hmac-md5;
        secret "super-secret-key 31337";
};

Finally, we need to make sure that our DNS server is configured to accept updates for our zones.

In our named.conf file, we need our rndc key, controls, and zone info.

key rndckey {
        algorithm hmac-md5;
        secret "super-secret-key 31337";
        };
controls {
        inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { rndckey; };
        inet ::1 port 953 allow { ::1; } keys { rndckey; };
        };


zone "your.domain.com" {
	type master;
	file "/var/named/your.domain.com.hosts";
        notify yes;
        allow-update {
                key rndckey;
        };
};
zone "a.f.d.e.8.b.d.0.1.0.0.2.ip6.arpa" {
	type master;
	file "/var/named/2001:0db8:edfa::_48.rev";
	allow-update {
		key rndckey;
		};
	};

Finally, make sure that you have the correct firewall rules in place to accept DHCPd6 requests! You’re going to need to accept ipv6-icmp traffic, and both TCP and UDP traffic on ports 546 and 547 from the link-local address range fe80::/16 to the all-dhcp-agents link-local multicast group ff02::1:2. Here are some basic ip6tables rule examples for DNS and DHCP via IPv6:

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p ipv6-icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -p tcp -m tcp -m multiport -s fe80::/16 -d ff02::1:2 -i br0 -j ACCEPT --dports 546,547
-A INPUT -p udp -m udp -m multiport -s fe80::/16 -d ff02::1:2 -i br0 -j ACCEPT --dports 546,547

Now, this is a pretty basic setup, but should get you rolling with a working DHCPd6 DDNS setup!

One thing to note, I have found that Android devices (a 2.3 phone and a 3.2 tablet) don’t like to get IPv6 addresses from our DHCPd6 server; however everything else on the network (including other wifi devices) will correctly get addresses from the DHCPd6 server. Android devices will however get stateless autoconfiguration addresses from a radvd standalone setup. Perhaps this is a misconfiguration on my part, or an incompatibility in the Android OS; if you have any idea please let me know! Arf!

First, we need to make sure that all of our time settings are correct. Let’s compare the hardware clock settings to the current real time, which is 11:13AM EST:

[16:13] root@ns3:~ # hwclock
Wed 21 Dec 2011 04:13:49 PM EST  -0.297984 seconds
[16:13] root@ns3:~ # date
Wed Dec 21 16:13:07 EST 2011
[16:13] root@ns3:~ #

Well, here we can see that the hardware and system clocks are wrong! KVM/QEMU likes to keep its “hardware time” as UTC, so it takes the time from the host system and adjusts it to UTC, based off of the host system’s timezone setting. The host system shows the correct time (and actually this physical host machine’s hardware time is set to local, not UTC).

Ok, well lets make sure our timezone is set correct. The /etc/localtime file represents the timezone info for your particular time zone. This can either be a symbolic link to the correct file, or a copy of the correct file. On my system, it looks like this:

[16:20] root@ns3:~ # ls -alh /etc/localtime
lrwxrwxrwx 1 root root 36 Dec 21 15:14 /etc/localtime -> /usr/share/zoneinfo/America/New_York
[16:21] root@ns3:~ #

Now, you can either make a symbolic link using the command

ln -s /usr/share/zoneinfo/America/New_York /etc/localtime

or you can copy the zone file with the command

cp /usr/share/zoneinfo/America/New_York /etc/localtime

There are arguments for and against each method, use whichever method you prefer.

Next, we need to check our /etc/sysconfig/clock file to make sure it is correct. My file looks like this:

ZONE="America/New_York"

Some users will add a line that says UTC="true" (or false), but it isn’t needed and can just add confusion.

Finally, we need to check the /etc/adjtime file; this file was the key! The 3rd line in the file will say either UTC or LOCAL. Since our hardware clock was set to UTC time (as shown above), we need to change our adjtime file to say UTC instead of LOCAL. Here is what mine looks like:

-15185.281863 1324482636 0.000000
1324482636
UTC

So now everything should be set to keep the system time correct after a hard reboot (power off & on), but our current clock is still wrong! Well, we can fix the current time with the following command:

[16:24] root@ns3:~ # hwclock --utc -s
[11:24] root@ns3:~ #

This will set our system time from the hardware clock, stating that the hardware clock is kept in UTC time.

Now, in order to test everything, we need to completely power down the virtual machine and restart it. Simply issuing a reboot won’t force our host machine to apply it’s time settings to the VM. Previously, after every hard boot the time would be wrong, but now it’s correct!

You should also set up some NTP time synchronization to keep your time accurate; but this will at least keep the zone correct between power cycles.

First, in order to have a command run on boot we can either create a reboot cron job, or add a line to the /etc/rc.d/rc.local file. Note that the crontab @reboot job may only run when the machine is rebooted, not from a cold-boot (like after the power goes out).

To use the crontab @reboot option, start by editing your crontab file and adding a line like the following (edit your crontab file with the crontab -e command):

@reboot /root/emailnotify.sh

If you instead want a script that will run every time a server is booted, add the link to your script in the /etc/rc.d/rc.local file:

#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.

touch /var/lock/subsys/local
/root/emailnotify.sh

Now, on reboot our server will run the /root/emailnotify.sh script!

Next, we actually need to write the emailnotify script. This script will send us an email with some basic info when the server is started. The contents of my script are below:

#!/bin/bash

sleep 60

#/bin/systemctl restart sendmail.service
/sbin/service sendmail restart

IP=`hostname -i`
HOSTNAME=`hostname -f`
echo "$HOSTNAME online.  IP address: $IP" > /root/email.txt
echo >> /root/email.txt
date >> /root/email.txt

mail -s "$HOSTNAME online" -r restart@server.domain.tld myemail@mydomain.tld < /root/email.txt
mail -s "$HOSTNAME online" -r restart@server.domain.tld myotheremail@myotherdomain.tld < /root/email.txt
mail -s "$HOSTNAME online" -r restart@server.domain.tld mycellphone@txt.carrier.tld < /root/email.txt

#cat /root/email.txt
rm -rf /root/email.txt

#/bin/systemctl restart sendmail.service
/sbin/service sendmail restart

Ok, so let's take a look at what this script is doing.
First, the bash script waits for 60 seconds, to give everything on the system ample time to startup. This isn't really necessary, but if the power goes back off within that 60 seconds, you won't get hit with multiple emails. This will also help keep our server from trying to send an email when the network equipment (switches/routers) hasn't fully recovered yet.

Next, we want to restart the sendmail service. This was very important on my Fedora 16 test machine. Without restarting sendmail, the email would get deferred and placed in a queue, and not actually be sent for a while. The actual error was in the /var/log/maillog file, and looked like this:

sendmail[1076]: pBMFxVSH001076: from=, size=607, class=0, nrcpts=1, msgid=<4ef353e3.ZS93/Yzasdfp1B4q%restart@server.domain.tld>, proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1]

Also notice that there are two different lines in the script to restart the sendmail service. The top line will work on newer Fedora systems, while the bottom line should work on any RPM based system, at least for the foreseeable future.

Now we will find the IP address and hostname of our server, and create our email message.
Finally we are going to send our email to three email addresses. I like to have one sent to my corporate email, one sent to my personal email, and another sent to my phone as a text message. This ensures that I get the message in a timely manner.

Finally we will delete our text file now that the email has been sent, and restart the sendmail service again just for good measure!

SELinux has 3 basic operating modes:
Enforcing – SELinux security policy is fully enforced.
Permissive – SELinux prints warnings instead of denying actions.
Disabled – SELinux is completely disabled.

If you plan on ever utilizing the extra security available with SELinux, you should choose the Permissive mode, so you can log any potential problems and create policies within SELinux to allow those actions.

We can check what mode SELinux is currently running in with the following command:

bash# cat /selinux/enforce
0bash#

Notice the 0 at the beginning of the second line; that is our current SELinux mode.

To temporarily put SELinux into disabled mode (until the next reboot) use the following command:

bash# echo 0 > /selinux/enforce

Conversely, to switch back to enforcing mode:

bash# echo 1 > /selinux/enforce

Nest, to permanently change the SELinux mode, edit /etc/selinux/config

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
#     targeted - Targeted processes are protected,
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

Change the SELINUX= line to match your desired level.

Also, some Linux distributions use kernel flags at boot time to enable or disable SELinux. If you don’t have a /etc/selinux/config file, then look in your /boot/grub/grub.conf file, and add enforcing=0 to the end of your kernel boot line, like this:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/mapper/vg_kickstart-lv_root
#          initrd /initrd-[generic-]version.img
#boot=/dev/vda
default=0
timeout=0
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.40.4-5.fc15.x86_64)
        root (hd0,0)
        kernel /vmlinuz-2.6.40.4-5.fc15.x86_64 ro root=/dev/mapper/vg_kickstart-lv_root rd_LVM_LV=vg_kickstart/lv_root rd_LVM_LV=vg_kickstart/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb quiet enforcing=0
        initrd /initramfs-2.6.40.4-5.fc15.x86_64.img

To re-enable SELinux you must complete some additional steps.

First change the SELinux type to permissive and reboot. Next run the touch /.autorelabel command, reboot again to relabel all the files. Finally change the SELinux type to enabled and reboot again! Please note that all the files will be relabeled for SELinux, which can take some time if there are a lot of files.

The first thing you want is to start with a nice server with a good OS installed. I’m starting with the CentOS 6 operating system, and a newer Dell Poweredge server. Obviously the more powerful the hardware, the better, but you will want something that supports full hardware virtualization, which is important for security, stability, and speed, among other things. Check in your BIOS for something like “Enable Virtualization.” Check with your hardware manufacturer for details.

After you have your initial server set up, you’ll need to add some packages for virtualization support. We’ll use the yum groupinstall command to get our necessary package groups, then install the bridge software separately, make sure everything is up to date, and finally restart the server so that we have the latest kernel running.

bash# yum groupinstall "Virtualization" "Virtualization Client"
bash# yum groupinstall "Virtualization Platform" "Virtualization Tools"
bash# yum install bridge-utils
bash# yum update
bash# reboot

When you reconnect to your host machine, make sure to forward some ports so you can tunnel to the VM’s console display! With putty, you can use a command like this:

putty.exe -L 5900:127.0.0.1:5900 -L 5901:127.0.0.1:5901 user@server

This will forward two ports for us, 5900 and 5901 to the localhost (the machine we’re connecting to) that we will use for VNC connections. Our first VM will use port 5900, our second VM will use port 5901, and so on. You can easily add more port forwards to your SSH connection to enable connecting to additional VM’s.

The first thing we need to do are set up some network bridges. There are a lot of different ways to configure network bridges, but we’re going to keep this one simple. Let’s say our machine has two physical network interfaces, eth0 and eth1. We’re going to assume that both interfaces are connected to the same network (so we can’t bridge them together), that we will use eth0 to connect to our physical machine (aka hypervisor, dom0, host, or manager), and that eth1 has no IP address. So, just create a separate bridge for each physical interface, br0 and br1.

Start by configuring eth0 (/etc/sysconfig/network-scripts/ifcfg-eth0):

DEVICE="eth0"
HWADDR="12:34:56:78:90:ab"
NM_CONTROLLED="no"
ONBOOT="yes"
IPADDR=10.0.0.100
GATEWAY=10.0.0.1
TYPE=Ethernet
BOOTPROTO=none
NETMASK=255.255.255.0
USERCTL=no
PEERDNS=yes
IPV6INIT=no
SEARCH=mydomain.com
DNS1=10.0.0.1
DNS2=10.0.0.2
DNS2=8.8.8.8
BRIDGE=br0

You could optionally configure eth0 to use DHCP, if desired. Be careful when remotely making changes to your active network connection; a misconfiguration could make you unable to connect!

Next, lets configure eth1 (/etc/sysconfig/network-scripts/ifcfg-eth1):

DEVICE="eth1"
HWADDR="12:34:56:78:90:cd"
NM_CONTROLLED="no"
ONBOOT="yes"
BRIDGE=br1

Restart the network connections to make sure everything is working so far:

bash# service network restart

Now that our physical interfaces are configured, lets configure some bridges! We can just edit the bridge scripts, so open the files and configure them already!

Bridge device br0 (/etc/sysconfig/network-scripts/ifcfg-br0):

DEVICE=br0
BOOTPROTO=none
ONBOOT=yes
TYPE=Bridge

Bridge device br1 (/etc/sysconfig/network-scripts/ifcfg-br1):

DEVICE=br1
BOOTPROTO=none
ONBOOT=yes
TYPE=Bridge

Restart the network services again, and we’re ready to go!

bash# service network restart

Check that our bridge devices exist with the following command:

bash# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.842b2b03fa01       no              eth0
br2             8000.0010186e94e8       no              eth2

This shows us that br0 has interface eth0, and br1 has interface eth1.

Ok, so now that we have our host correctly configured, we need an OS to install! You can use a disk drive with the OS installation, install from something provided on the network, or go get a .iso of your favorite OS, and install from there. We’ll just use an .iso. Take a look at the following command:

bash# virt-install -n newbawx --vcpus=1 -f /home/vm/newbawx -s 60 -r 2048 --nonsparse -w bridge:br1 --vnc --accelerate -c /tmp/Fedora-15-x86_64-DVD.iso --os-type=linux --os-variant=fedora13 --noautoconsole
Starting install...
Creating storage file newbawx                            |  60 GB     04:43
Creating domain...                                       |    0 B     00:00
Domain installation still in progress. You can reconnect to
the console to complete the installation process.

First we use the virt-install command to create a new virutal machine named newbawx. We give it a hard drive size of 60GB (-s 60), 2GB of RAM (-r 2048), tell it to use bridge 1 (-w bridge:br1), and have it use a Fedora 15 .iso as a virtual CD drive to install from (-c /tmp/Fedora-15-x86_64-DVD.iso). Don’t forget the --vnc option to enable VNC access to the guest console. Notice that the os-variant is fedora13; that is because it is the highest os-variant parameter currently supported for Fedora!

After the virt-install command is run, we can optionally set the VM to automatically start with the host server:

bash# virsh autostart newbawx
Domain newbawx marked as autostarted

Next, fire up your favorite VNC client and connect to 127.0.0.1:5000. You will be greeted with the installation walkthrough for your guest OS!

Also, if you wanted to delete and remove a virtual machine named newbawx:

bash# virsh destroy newbawx
bash# virsh undefine newbawx
bash# rm -rf /home/vm/newbawx

XML files containing your virtual machine settings are located in /etc/libvirt/qemu/.

Looking through the logs on the client didn’t reveal anything significant, however the logs on the NFS server were filled with these:

kernel: statd: server localhost not responding, timed out
kernel: lockd: cannot monitor client

At first it seemed that the statd daemon was not functioning. After restarting lockd and statd, the problem persisted. Even restarting the server didn’t fix the problem. The next thought was that something was blocking the loopback interface from communicating, since the localhost server wasn’t responding. After running some network tests, checking firewall and tcpwrapper rules, I found nothing that was keeping the server from communicating with itself.

After reading through the man page for statd and conversing with some of my doggs, I decided to attempt to remove the statd monitor and notify lists on the NFS server. This was the key! These files had somehow become locked or corrupted. These lists are located in the directories below:

/var/lib/nfs/statd/sm/ - directory containing statd monitor list
/var/lib/nfs/statd/sm.bak/ - directory containing statd notify list

Before removing these files, you should stop the rpcbind, statd, and lockd services. Below is a list of commands to run to fix this issue on a RPM based distro.

service rpcbind stop
service nfslock stop
rm -rf /var/lib/nfs/statd/sm/*
rm -rf /var/lib/nfs/statd/sm.bak/*
service rpcbind start
service nfslock start

After running these commands, it may be best to restart your NFS server.

Also check the permissions on these files and folders, to make sure that the NFS service can access them. Here are the permissions from my NFS server:

drwx------ 4 rpcuser rpcuser 4.0K Aug  1 15:00 .
drwxr-xr-x 5 root    root    4.0K Aug  1 15:00 ..
drwx------ 2 rpcuser rpcuser 4.0K Aug  1 15:00 sm
drwx------ 2 rpcuser rpcuser 4.0K Aug  1 15:00 sm.bak
-rw-r--r-- 1 root    root       4 Aug  1 15:00 state

A NFS FAQ can also be found here: http://www.sunhelp.org/faq/nfs.html