Centralising logs for fun and profit

October 16, 2012August 31, 2015 James Cort 14 Comments

It’s one of those things that usually gets pushed to the back burner because it seems like too much work for too little gain: setting up a central syslog server which all your other systems can report back to.

This is a shame, because there’s lots of benefits to having such a server:

You can analyse what’s going on in your network from a single, central location – saving you from having to log into a variety of devices for troubleshooting.
Improved security – if you have a security breach, the offender has to break into the logging server as well if they’re to cover their tracks properly. (I wouldn’t recommend re-purposing an existing server for precisely this reason – you want your syslog server to be as secure as possible, which means it needs to be running as few services as possible).
You only need to remember one set of tools to manage logs from a range of devices. Most routers will happily send logs back to a remote syslog server; there are also third-party products you can install on Windows.

It’s trivially easy to set this up in any reasonably modern Linux distribution. Once again, I’m going to use Debian for this example.

Out of the box, Debian uses rsyslog and stores the configuration file in /etc/rsyslog.conf. Fortunately, the default configuration only needs minor changes to two lines as shown in this excerpt:

# provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514

Uncomment the lines beginning $ModLoad and $UDPServerRun by removing the # symbols:

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

Restart rsyslogd (service rsyslog restart) and…. that’s it. Done.

Well, that’s not quite it. A remote syslog server isn’t much good unless you have equipment sending logs to it. On any other Debian servers you may have, this is just a matter of adding a line to /etc/rsyslog.conf:

*.* @192.168.42.39:514

(substitute your own logging server’s IP address or hostname for 192.168.42.39).

Restart rsyslog on the server that will be sending logs to your remote syslog server. Now when you check your remote syslog server, you should find logs appearing from both itself and anything else that’s configured to send logs to it.

Advanced Tweaks

Once you’ve got this done, there’s all sorts of things you can add. You can separate logfiles according to the host that generated them, you can have new logfiles created every day with an appropriate filename… or you can just stick with the basic configuration which will put everything in the same set of log files and just use grep to separate the interesting information.

Whatever you do, keep a sharp eye on disk space on your logfile server. Logs can grow very large very quickly, and a syslog server with a full disk won’t log anything at all.

Network booting without changing your existing infrastructure

September 18, 2012August 31, 2015 James Cort 16 Comments

There’s lots of instructions out there explaining how to set up PXE booting – but most of them assume you’re happy to mess with a perfectly good DHCP configuration. There’s lots of reasons you might not want to do this, but that doesn’t mean you have to forego the convenience of just hitting a key at boot and booting PCs or servers from the network. In this tutorial, we’ll be looking at setting up network booting from a Linux box without touching your existing DHCP infrastructure. This will work even if you’re using something else entirely for DHCP.

These instructions were originally written for Debian, though they should work equally well with minor tweaks on Ubuntu.

First, you want to install dnsmasq:

apt-get install dnsmasq

(use sudo if you’re not logged in as root!)

Once you’ve done that, you need to configure dnsmasq to act as a Proxy DHCP server. I’ve put this in a separate configuration file in /etc/dnsmasq.d/pxe.conf:

# Put your own DHCP range in here.

dhcp-range=192.168.42.0,proxy
pxe-prompt="Press F8 for menu", 20
pxe-service=x86PC, "Boot from local disk"
pxe-service=x86PC, "Install Linux", pxelinux
enable-tftp

# This can be anywhere you like.

tftp-root=/srv/tftp
tftp-secure

Make sure /srv/tftp exists:

mkdir -p /srv/tftp

That’s the hard work out of the way. All we need now is something that can be served up via tftp, and the nice people behind Debian provide that for us:

cd /srv/tftp
wget ftp://ftp.debian.org/debian/dists/stable/main/installer-i386/current/images/netboot/netboot.tar.gz
tar zxf netboot.tar.gz
rm netboot.tar.gz
chown -R dnsmasq /srv/tftp

Restart dnsmasq, check it’s started up using ps:

service dnsmasq restart
ps -ef | grep dnsmasq

Now you can test. Boot a PC from the network; if it all goes according to plan, you should see something like this:

Press F8 as per the instructions and you’ll be prompted to choose between booting from the local disk or installing Linux. Choose install Linux and you’ll drop into the Debian installer menu:

From here, you can install Debian as per usual.

Protip August: Quickly Determine Linux System Info

August 17, 2012August 31, 2015 Josh Reichardt 59 Comments

If you have ever found yourself in a situation where you are looking at a foreign Linux OS you know how handy it is to know exactly what type of system you are dealing with. Practically all modern flavors of Linux offer the following commands to quickly determine important information about a particular system.

lsb_release -a

This command is handy for obvious reasons. It quickly tells you what OS version you are looking at. As you can see it looks like my OS is a little bit out of date. 🙂

uname -a

This one is handy for quickly obtaining kernel information as well as generic OS info (OS, platform, etc).

Update (11/1/12)

I just found another way to gather the OS version quickly from the command line using the venerable cat command. The syntax for the command is as follows.

cat /etc/issue

Sweet! This is handy if you are only concerned with looking up the OS and version you are working.

Using Google Voice as a FREE VoIP Solution

May 12, 2012August 31, 2015 Josh Reichardt 41 Comments

This post will go over the basics in getting basic VoIP inbound and outbound calling to work using Google Voice as a SIP trunk in your home or lab environment. I believe this solution will work with domestic calling (I live in the United States) so I’m not sure about international calling, from what I’ve read it doesn’t sound like this solution will work out of the box. Since I just got this working myself so there is much to be learned as I have no prior background experience in the world of voice. But I do have to say though, I’m super excited to get this working, how cool is it to say that you have your own free phone commercial grade phone system working at home! Ok, maybe its just the nerd in me talking.

The first step is head over to Google and create an account to associate this phone number with. From what I’ve read it is good practice to separate this account from your main, day to day account to avoid unsolicited messages and spam to your main account. By no means is it absolutely necessary, but it is the way I chose to do things so that is how this the direction this tutorial will follow. Once the account has been created and you log in the first time you will need to associate a Google Voice number with the new account. After that is done you will need to adjust your Voice settings in your new account. Make sure your phone allows Google Chat, otherwise inbound calling won’t work.

Also make sure your Calls settings look similar if not the same as the following:

Ok, now we need to adjust the settings on our voice server. I will not be going over the details of getting your voice server up in running in this tutorial so if you need help getting to this point let me know and I will write something up to help. Suffice it to say, there isn’t much difficulty getting to this point, just install the ISO image and configure the networking, accounts and passwords and you will be ready. I used PBX in a Flash for my setup (box.net 64-bit version), so grab the latest ISO and get started on the install!

Once you have completed the installation and configuration go ahead and open up a browser and head to the address you configured when setting your environment up. If you can’t remember, run a status command from the PBXiaF command line to check the address as well as other important information.

You need to ensure that you have the Google Voice module installed by first checking to verify that it is installed and enabled (Admin -> Module Admin -> Third Party Addon -> Google Voice).

Then go take a look at the configuration page (Main Page -> Third Party Addon -> Google Voice). Here we need to configure our settings to match the new account we just created with Google. Make sure your settings look similar to the following:

Phone Number: The 10-digit Google Voice phone number we created.
Username: The uername we created through Google. Only use the first part witouth the @gmail.com.
Password: The matching username password for your Google account.
Add Trunk: Checked
Add Routes: Checked
Agree to TOS: Checked

Next, we need to create an extension to route incoming/outgoing traffic to. I chose 701 for mine (kinda borrowed it from another tutorial). These settings can be found by going to Basic -> Extensions and choosing “Add Extensions” on the top right of the page. There are tons of options to configure here but I am focused on basic functionality I picked a display name of 701 and a secret for that extension. These settings are what your phone uses to talk to the server.

After that is done, add in inbound route (Inbound Call Control -> Inbound Routes) and configure it to use your Google Voice phone number and point it to the extension you just created. The settings should look similar to the following:

Now we need to install and configure a phone to test out our new VoIP connection. Since I don’t have a hard phone to test with I decided to sample a few different Linux options, finally settling on Qutecom. It is relatively painless to install and configure and looks the best out of all the options I tried IMO. To install, sudo apt-get install qutecom from command line. Once it is installed open up the program and adjust the soft phone setting to point to your voice server, the secret you created and your newly created extension.

It is finally time to test! At this point, I had outbound calls working through my SIP phone but incoming calls weren’t working. hmm, ok after some research I found that there was a patch for the Google Voice Addon that I needed. From the command line on your voice server issue the update-programs and update-fixes commands to update your programs and software fixes, pretty self explanatory but was pretty much impossible to find.

In my case this step was VERY IMPORTANT and was what allowed me to receive incoming calls. Make sure you don’t overlook this step if your are having problems receiving calls. There are still a ton of things to work on with this setup but I was just excited I got it to work to begin with. I hope you get som use out of this tutorial and try it for yourself.

Resources:
http://pbxinaflash.com/community/index.php?threads/2nd-google-voice-account-no-inbound.13152/#post-84527
http://www.pbxinaflash.com/community/index.php?threads/bad-week-for-google-voice.12396/
http://nerdvittles.com/?tag=google-voice

Setting up a Linux based DNS server with BIND

April 29, 2012August 31, 2015 Josh Reichardt 7 Comments

As my home lab continues to grow and becomes increasingly complicated I need an easy way to access my servers and network resources by their name rather than their addresses on the network. By using DNS I can quickly and efficiently access these network resources by their given host names, not having to worry about the growing complexity of the network. I looked into a few different options for accomplishing this task but ultimately decided to go with the tried and true Linux BIND implementation. The installation and configuration isn’t all that complicated to get up and running, so in this post I will go through some of the high points of my experience in standing up this service. Let’s get going.

First, we need to install the proper packages. By the way I was using a Debain 6.0 minimal VM for my server in this project. So to install this stuff you need to update your repos to look for the packages.

apt-get update

Then the necessary packages

apt-get install bind9 dnsutils resolvconf

We need to configure the correct files to make our DNS function properly. Everything that we need to configure (for Debian distros) should be located in /etc/bind. So the first thing to change is the named.conf.local file to create the zones for our local network. We need a zone for resolving names to IP addresses as well as a zone reverse DNS. If you don’t know what that is, you can find more here. In my configuration psa.local is my local domain so any hostname will resolve to hostname.psa.local in DNS. Here is what my named.conf.local configuration file looks like:

Next, we need to set up our zones to point to the correct hosts. The easiest way is to use the db.local as a template and copy it to a new file. cp /etc/bind/db.local /etc/bind/db.psa.local Here is what my db.psa.local file looks like:

We need to do the same thing with our reverse records. For me, his file is located in db.192 and we will use db.127 as the template for this file. cp /etc/bind/db.127 /etc/bind/db.192. If you are using a different type of network layout adjust accordingly. For example if your network is a 172.x.x.x network just name the file as db.172 or whatever the network is. Here is what the configuration looks like, it is similar to our forward lookup zone.

Now we should be able to resolve host names (both forward and reverse) to the entries we’ve added to these configuration files. Next we need to edit our resolv.conf file to get our host name resolution to work smoothly. So edit /etc/resolv.conf with your favorite text editor and make the necessary changes. Here is what mine looks like after the necesary tweaks. NOTE I haven’t figured out why yet, but every time you restart your bind service it wipes this config out, I will update this when I figure out how to make these changes persistent.

Finally, and most importantly, here is my final named.conf.options file, with all the troubleshooting done. This file tells bind where to forward DNS queries externally as well as other important configuration options. You can adjust the forwarders to whichever public DNS server you choose. I chose two well known DNS servers. There are a few things to note here. If you are having issues with anything check the log files 🙂 At first I had strange resolution errors for anything that was external to my domain. The logs helped me pinpoint where the problems were and to make the necessary changes. The most important iformation for troubleshooting is located in /var/log/syslog.

The last few entires in this file are very important for getting external DNS to resolve and is not part of the default configuration file. You will have to add these in yourself.

allow-recursion { any; };
21 allow-query { any; };
22 allow-query-cache { any; };

Start/restart your DNS service for these configuration files to get loaded in. /etc/init.d/bind9 restart and you should be able to ping your newly added entries by host name.

That’s it. You can test these settings for yourself, host -l psa.local will list the hosts in your zone file. I should also note, machines that were already on the network will need to have their DNS configurations adjusted to point to the new DNS server by editing the /etc/resolv.conf file like we did on the server itself. Piece of cake. With local DNS in place it makes things much easier for me to remember, just don’t forget to add new network devices to your zone files when bringing them onto your network.