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.

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

One of the first things we need to do is create a user account for our self. Whenever we are logged in, we should be a normal user, not a super-user! This is one of the biggest problems with Windows operating systems; normal users are given administrative privileges by default. When you download something malicious on a Windows PC, the malicious software can easily wreak havoc on your computer, because you have the permissions necessary to do so! Under Linux, we are just a normal user, and only request administrative (root) privileges when necessary. This way, even if I did download a virus on my Linux machine, unless I executed the virus as root, there is very little damage that the virus can do, because my normal user only has a restricted set of privileges.

Create a new user using the useradd command. This will allow us to add a new user, and then we can create a password for this new user using the passwd command. So, go ahead and create a new account for yourself, as I am doing below. Replace [username] with your desired username. Remember that we have to be an administrative (root) user to run the useradd command.

[root@machine ~]# useradd [username]
[root@machine ~]# passwd [username]
Changing password for user username.
New UNIX Password:
Retype new UNIX password:
Passwd: all authentication tokens updated successfully.
[root@machine ~]#

Next, we will need to enable sudo access for our newly created user, so that we will still be able to run commands as root. To do this, run the visudo command, and add the following line to the bottom of the file, replacing [username] with the username you created above.

[username]		ALL=(ALL)	ALL

The visudo command will have you editing the sudoers file with the vi editor. If you’re not familiar with vi, here are some basics. Pressing i will put you into insert mode, where you can make changes much like any other editor. Pressing esc will take you out of the editor mode. You can then type :wq! to write your changes and exit, or just :q! to quit without saving.

Now that we have our own user account set up, and our user has sudo access, we want to disable root SSH logins. Script kiddies will often search for machines configured with weak root passwords, and gain access using a brute-force or dictionary password attack. I’ve seen it before; wallpaper isn’t a very good choice for a root password… But for some extra security, lets disable the ability of root logging on via SSH.

First, open /etc/ssh/sshd_config in your favorite text editor, and find the line containing PermitRootLogin and change the entire line to this:

PermitRootLogin no

Now, to make our changes to the sshd_config file take effect, we must restart the SSHD service. Run a simple service sshd restart as root, and you should see something like this:

[root@machine ~]# service sshd restart
Stopping sshd:								[  OK  ]
Starting sshd:								[  OK  ]
[root@machine ~]#

Now, before going any further, test that you can log in with the account that you created earlier, and that you can use the sudo -i command to enter an interactive sudo session. If everything is working, then lets keep going! BARK!

Next, we can optionally change the port that SSH is listening on. There are some pro’s and con’s of changing the port. We can hopefully avoid some of the script kiddies who are only scanning port 22. This won’t keep any determined hacker from finding the port number with a simple nmap command however. Also, if you change the port, keep the port number below 1024. Only users in the root group can listen on ports below 1024, so a standard user can’t replace our SSH daemon with their own, listening to incoming requests, stealing passwords, etc.

To change the SSH listening port, open /etc/ssh/sshd_config in your favorite text editor, find the Port 22 line, and change it to look like the line below:

Port 1000

This will have our SSHD server listening to port 1000 for SSH connections. Note that we must again restart the sshd service for our changes to take effect.

That should take care of securing our SSHD configuration. Next time we can work on configuring our firewall!

First, we will need to download the necessary software and burn it to a disc, so go grab yourself a copy of CentOS from one of their mirrors. There are both 32bit (i386) and 64bit (x86_64) versions. Download the best one for your hardware. If you aren’t sure, get the 32bit version. There are both CD and DVD editions available; again get the version that your hardware supports. There is no difference in the CD vs. DVD, except for the size and quantity of discs.

After you have downloaded the .iso image, burn it to a disc with your favorite image burning software. CDBurnerXP is a free disc burning application that works on many different Windows operating systems, and can burn many different types of discs.

Well, now we can actually get started with the installation! We’re going to have to boot from the CD we just created, and your BIOS must be set to boot from CD-ROM. Sometimes this is already configured for you, but you may have to configure it yourself. Configuration is accomplished by entering the BIOS immediately after turning on the computer, and configuring the boot order. To get in to the BIOS we must press the correct key, which can be different for each BIOS brand. Sometimes there will be a message telling you what button to press, other times there isn’t. Most common options are the F1, F10, DEL, and ESC keys. If you aren’t sure, and you don’t see a message telling you what to press immediately after turning on your PC, head over to Google and search for how to enter the BIOS on your specific PC.

Once we boot from the disc, we will see a message similar to what is below:

Here you can enter any special instructions to be used during boot.  We won’t need any here, so just hit enter and wait for the next screen:

You can test the media here, to ensure that the disc was burned correctly.  After testing we will be transported into a magical land of fire hydrants and graphical installers!  Ok, maybe no fire hydrants, but a dogg can dream!

The next few screens will ask you to select your language and keyboard layout, then move into setting up the hard disk:

Select the option to “Remove all partitions on selected drives and create default layout” from the drop down menu.  Also check the box next to “Remove and modify partitioning layout.”

It is important to know that after this point, we will be erasing everything on the hard drive, so any data on the drive will be lost!

We also need to talk about the disk partitioning structure real quick.  We can just choose the default layout, and with larger hard disks or less used servers, that is fine.  But that’s not what this dogg is all about!  So we are going to create a better layout.

We don’t want a rogue user or runaway log file to take up all our disk space (which can bring our server to a halt), so we’re gonna separate the /home directory (where all users will store their files), the /tmp directory (where temporary files are stored), the /var directory (which contains the log files, among other things), and the / directory (the root directory), which will contain everything else.

Some people will separate the directories even further, creating an additional separate partition specifically for the log files (/var/log), along with some others.  Take a look at the image below for a basic idea.  If you are lost at this point, just go back to the previous screen and uncheck the box next to “Remove and modify partitioning layout.”

Next we find ourselves at the GRUB boot loader setup.  Keep the default options here and continue to the network setup.  I like to specify the fully qualified domain name here in the hostname box.  You can just specify the hostname, if you don’t have a domain name yet.  Leave everything else as default, and continue on to the time zone configuration.  Select your time zone, and keep going!  Next we will create a root password, which we are going to need later, so don’t forget it!  Now we are finally ready to start selecting the software to install!

I like to install my servers with a minimum amount of software, and add what is necessary later.  This helps keep disk usage low, and avoids installing unnecessary software which can use up resources down the road.  Select just the option for the Server configuration, and click next.  You can optionally select the “Customize Now” option, and add any additional software you want, along with removing anything you don’t want.

Continue through the remaining menus, and you should be ready to install!  After installation you will be prompted to remove your installation disc and reboot.  After doing this, you will now have a brand new, fresh & clean, CentOS Linux server! Next time, we’ll cover some initial server security setup, and take a look at what all we can do with our server. But for now, I’m going for a walk!