Author Archive

Grandstream HandyTone 286 Review

After my Digium AIXy 101 suddenly died I was left to find another ATA (Analog Telephone Adapter) for my home PBX. After doing some research I settled on the cheapest solution, the Grandstream HandyTone 286. Its a terrific little device which required very little effort to setup.

The web interface leaves a lot to be desired, but giving the price-point I believe its an outstanding value. The device was easy to locate in my routers DHCP and ARP tables. After upgrading I’ve found the calls sound better and connect faster.

The only pitfall is the device only uses SIP rather then my preferred method of IAX2. IAX2 has the benefit of transversing NAT / PAT without much trouble. SIP on the other hand is a major pain. Luckily the SIP server was on the same LAN so this was not an issue for me. The device does support STUN to allow proxying of SIP connections if you need to traverse NAT.

I would recommend this device to anyone looking to connect analog phones to a PBX using SIP. I have not tried the rest of their line of HandyTone products but look forward to giving them a chance.

, ,

No Comments

AWstats in a clustered environment

Below is a simple solution for operating AWstats within a clustered environment in CentOS 5. This solution should work for other operating systems as well. This explanation assumes you’ll be using two application nodes, with front-end directors. I have not tried this solution using three nodes.

  • Install AWstats & NFS from yum repository.
  • Create profile for your domain within /etc/awstats. (i.e. awstats.www.domain.com.conf)
  • Configure NFS mounts on each node. This can be accomplished by modifying your /etc/fstab file as illustrated below.
  • Adjust your awstats configuration file to point at both log sources now that the NFS mount has been created.
  • On second node, mount /var/lib/awstats
  • Configure nightly cron on first application node.
  • Configure calling either awstats.pl should display the data processed data stored on node 1, regardless of which node the user is accessing.

Notes / Exceptions

Be sure to backup your Apache log files, and your AWstats data. In this solution the processed information will only be stored on the primary node

Full Setup Process

1. SSH APP1
2. yum install awstats nfs -y
3. nano /etc/exports
4. Add following lines:
/var/log/httpd APP2(rw,sync)
/var/lib/awstats APP2(rw,sync)
/etc/awstats APP2(rw,sync)
5. nano /etc/fstab
6a. Add lines, APP2:/var/log/httpd /var/log/httpd-APP2 nfs rsize=16384,wsize=16384 0 0
6b. mount /var/log/httpd-APP2
7. ln -s /var/log/httpd /var/log/httpd-APP1
8. service nfs start
9. chkconfig nfs on
10. cp /etc/awstats/awstats.model.conf /etc/awstats/awstats.www.domain.com.conf
11. nano /etc/awstats/awstats.www.domain.com.conf
12. Configure normally, exception add
LogFile="/usr/local/awstats/tools/logresolvemerge.pl /var/log/httpd-APP1/domain.com-access_log \
    /var/log/httpd-APP2/domain.com-access_log |"
13. SSH APP2
14. yum install awstats nfs -y
15. nano /etc/exports
16. Add following lines:
/var/log/httpd APP1(rw,sync)
/var/lib/awstats APP1(rw,sync)
/etc/awstats APP1(rw,sync)
17. nano /etc/fstab
18a. Add following lines,
APP1:/var/log/httpd /var/log/httpd-APP1 nfs rsize=16384,wsize=16384 0 0
APP1:/var/lib/awstats /var/lib/awstats nfs rsize=16384,wsize=16384 0 0
18b. mount /var/log/httpd-APP1
18c. mount /var/lib/awstats
19. ln -s /var/log/httpd /var/log/httpd-APP2
20. service nfs start
21. cp /etc/awstats/awstats.model.conf /etc/awstats/awstats.www.domain.com.conf
22. nano /etc/awstats/awstats.www.domain.com.conf
23. Configure normally, exception add
LogFile="/usr/local/awstats/tools/logresolvemerge.pl /var/log/httpd-APP1/domain.com-access_log \
    /var/log/httpd-APP2/domain.com-access_log |"
24. SSH APP1
25. crontab -e add line, perl /usr/local/awstats/tools/awstats_updateall.pl now
26. Configure Apache to expose awstats.pl, refer to awstats setup for additional information.
27. Confirm setup (df -h, perl awstats.pl -update -config=www.domain.com)

This should allow users accessing either node to display the same stats information compiled from both nodes access logs. Be sure to do backups!
Enjoy,
Dustin

, ,

No Comments

Routing public IP addresses across via virtual tunnel

A recent situation came up which required that I move a group of servers off-site without changing their public IP address. The off-site location is behind my cable modem at my house. To solve the problem I enlisted the help of an open source application called vtun or Virtual Tunnel and IP tables on a standard CentOS 4.4 installation. Below is a outline of the steps I took to solve the problem.

-> Build two CentOS 4.4 Linux routers. Minimal installation plus development tools. In my situation I used a dual 350Mhz PII and tunnel router #2 was an old Pentium Pro 200Mhz. The dual 350Mhz is located at the main data center and the older Linux box is located at my house.

-> Download and configure vtund from www.vtund.info. There are a number of example configurations available on their website. Below is what I have used.


# IP Tunnel Server Configuration
cobra {
passwd XXXXXXX; # Password
type tun; # IP tunnel
proto udp; # UDP protocol
compress lzo:9; # LZO compression level 9
encrypt no; # Encryption
keepalive yes; # Keep connection alive

up {
# Connection is Up
# XXX.XXX.XXX.XXX – local, XXX.XXX.XXX.XXX – remote
ifconfig “%% XXX.XXX.XXX.XXX pointopoint XXX.XXX.XXX.XXX mtu 1450″;
};
down {
# Connection is Down
# Shutdown interface
ifconfig “%% down”;
};
}

# IP Tunnel Client Configuration
cobra {
passwd XXXXXXX; # Password
device tun0; # Device tun0
persist yes; # Persist mode
up {
# Connection is Up

# Assign IP addresses.
ifconfig “%% XXX.XXX.XXX.XXX pointopoint XXX.XXX.XXX.XXX mtu 1450″;
};
}
The configuration above is very simlar to the example configurations provided by vtund. There is more you can do here to make this connection more robust but for the purpose of this blog entry I’ll show it works in more detail. To make the connection between to the two servers you run the following command on the client machine.

vtund cobra

This should create a new network interface called tun0 on both servers. This will allow you to connect across the tunnel. To test this i recommend using the following commands.


On the client
tcpdump -i tun0
On the server
ping

You should see packets come across the interface and reply back. Once you have established the tunnel connection there is a bit more required to route public IP address both in and out of the tunnel interface. For the sake of this example we’ll use 10.10.10.0/24 as the network block your routing. You’ll want to be using a public IP block for this to work correctly not the interal block from the example!

-> Assuming 10.10.10.0/24 is already routed to the tunnel server you’ll now need to route to packets from the tunnel server to the client. To do this you simply type:

ip route add 10.10.10.0/24 dev tun0

This will push packets from the server -> client. Once the packets are on the client end of the tunnel however they do not have a correct route back to the sender. In my situation the tunnel client is located on a cable modem with a default gateway on a different network. My block of 10.10.10.0/24 cannot be routed across someone elses network. The solution is to flag packets as they enter into the tunnel client router. Once the packets get flagged we can apply an alternate route table to them. The alternate route cable is identical to the standard table except the default gateway is tun0 rather then the cable modem interface. Below is a simple script to generate a duplicate route table and add the make the default gateway the tunnel server:


ip route show table main | grep -Ev ^default | while read ROUTE ; do
ip route add table 200 $ROUTE
done
ip route add default via XXX.XXX.XXX.XXX table 200

Now that the alternate table has been created you can verify it works by typing:

ip route list table 200

This should be a simlar table to your main route table except the default gateway should be the IP address of the server-side of the tunnel interface. Now that this table is in place we need to start flagging packets. In order to do this we need to make some special rules in ip tables. Below are the commands to create the flagging rules:

iptables -t mangle -A PREROUTING -i eth2 -j MARK --set-mark=200
iptables -t mangle -A PREROUTING -s 10.10.10.0/24 -j MARK --set-mark=200
iptables -t mangle -A OUTPUT -s 10.10.10.0/24 -j MARK --set-mark=200

Once the iptable rules are in place you can check them by issuing the ‘iptables -nvL -t mangle’ command. In the output you should see packets hitting your new iptable rules. Once you have active hits you’ll need to add a rule that all packets with a flag need to use the alternate table. To create this rule you need the following

ip rule add fwmark 200 table 200

To verify the rule was added you can issue the ‘ip rule list’ command.
Once you have does this your ready to route packets in and out of the tunnel. In my situation I added a third network interface card running NAT for my home computers.

No Comments

OpenTTD – My Addiction

You may be wondering why I haven’t posted anything to this blog recently. Although I am busy getting married and taking care of a puppy; I must admit something. I am completely addicted to OpenTTD. OpenTTD is based on the original computer game Transportation Tycoon Deluxe. It’s a complete rewrite and has major improvements over the original. Although not widely played in the United States, there is a large following in Europe. There are always servers available to play on. For anyone who played the original, this is something you should definitely check out. I’ve wasted a massive amount of my time on this game, so I thought it’s high time I pass this addition on to others.

No Comments

A Whole New World

I am in love with a Geek. It’s true… a big brain and lightning fast typing speed is a turn on. With such a love comes a wide range of new experiences however. I would like to take you on a magic carpet ride to the world of “geek” told from an outsiders view. It has been quite an experience trying to learn all the in’s and out’s of the IT world without seeming completely stupid.

First thing that I had to learn was slashdot. Yes, the wonderful world of slashdot….the last viewed page in every geek’s web browser. At first, I thought that this portal to the IT community was simply a page of enjoyment, a place to go when there is no better thing to do at work. I, however, was wrong. It is my firm belief that slashdot has hypnotic powers that are beyond my comprehension. Five, Six, Seven times a day I will see my geek viewing this site. Not much has changed from the last view, maybe a new post or two. Every time though, he goes to the site with anticipation…hoping….praying for new content. To me, this is absolutely silly. I have learned that I sometimes take the backseat to a good Slashdot post. Geeks need their slashdot, and I have just learned to respect that.

The next thing I have learned was that in every room of the house there needs to be some computer equipment. While it is helpful at times to be able to check my email at any point, sometimes such equipment can be excessive. Take for example the VERY large, cumbersome antanea in the upstairs “lab.” This antanea was in fact pointed at the neighbors house for weeks, before I relized that the neighbors probally assumed my geek was taping into their personal lives. The antenea was bought because my geek wanted to broadcast wireless internet to the neighborhood and market it. Well….for a year now that antena has been sitting in the “lab” doing nothing more useful than collecting dust. Why is such equipment so nessecary….well because it is “cool” of course! Why else would you need 17 computer cases, 2 boxes of mice, 2 boxes of keyboards, 37 “semi-functional” hard-drives, 3 non-working wireless network cards, 20 phone modems, 17 motherboards, a broadcasting antena, 295 feet of coax cable, 428 feet of ethnet, 12 access points, 3 routers,a voice of IP box, oh…and a partridge in a Pear tree.

So, in conclusion. Loving a geek isn’t easy…but hey, I guess someone has to do it.

No Comments

MX Server

With the additional load from virus / spam filtering effecting the performance of our core mail servers, we decided to create an MX server to place in front of our current mail system. This server is designed to receive all incoming mail for our domains, and pass them off to our primary mail server. The server is also designed to accept outgoing messages to prevent users from distributing viruses.

Some of the requirements we established:
1.) Quick processing, mail cannot queue longer then a few seconds. Remove load from current mail server.
2.) Detailed accounting, we need to know exactly why messages get blocked.
3.) Management, we need to be able to quickly add additional domains without complicated configuration. Release messages from queue which need delivered.

MailScanner

MailScanner
The solution we found which works best is Mail Scanner. Mail Scanner is an application which gives us the ability to integrate a number of application (SpamAssassin / ClamAV, etc) to give each message a complete score. This allows for use to run each message through multiple scans before eventually passing the message off to the primary mail server. This application gave us part of the solution, but didn’t offer the detailed accounting which we were looking for.

This is where Mail Watch comes into play.

Mail Watch is probably the most exciting piece of the configuration. It’s given us detailed accounting information, and lets us generate reports to get an idea on who is abusing our mail system. I would highly recommend this application package to anyone who is using Mail Scanner but wants to add an easy to use interface for quick accounting.

Some of the additional tweaks we’ve made include:

1.) Leaving the incoming queue in memory rather then writing it to the drive. This seems to speed up the scanning process tremendously.
2.) Purging the MySQL accounting data every quarter to keep database queries quick.

As we continue to grow we will likely add two MX servers balancing via DNS. We currently process around 20,000 messages per day on our Dual Xeon 1.8Ghz server with 2GB RAM, running a RAID 1 Mirror. The extra MX server should add some additional reliability as well.

So far the MX server has worked prefectly. We could not be happier. Special thanks to everyone who helped make this project come together.

No Comments

OpenBSD 3.7 – Project Avatar

Approximately one week ago I was given an assignment to create a new dedicated server for a client. This would not be worth discussing in any normal situation, but as usual around here, this was a far from a normal situation. The client, who will remain nameless, wanted to host an advertisement splash page for an e-mail marketing campaign. Starting yesterday, they are planning to send out 60 million e-mails. To compound the matter I had no budget and three days to develop a robust, reliable solution. Needless to say I was concerned.

OpenBSD Logo

THE SOLUTION

OpenBSD has long been a pillar of security and reliability in the IT community. Until now I have never needed to use it. I have had experience with FreeBSD, and of course extensive experience with Linux. OpenBSD has always been on my list of exciting projects, but I have never had the opportunity to install it. With no hardware firewall, pissing off 60 million people requires a fairly secure operating system. Also, with little time to secure the server, I wanted a solution which was relatively safe out of the box. Below is the specific equipment

Dell OmniPlex GXPro
Intel Pentium Pro 200Mhz
256MB RAM
4GB Hard Drive

Yes that’s right, 60 million people are going to hit my old Pentium Pro. This might seem a little odd with the abundance of cheap equipment available. Frankly, I wouldn’t trust this project with anything else. This old workstation (around the office referred to as Old-Deller) is solid as a rock. Beside, it’s only going to be handing out two pages of static content. What could possibly go wrong?

I’ll admit the initial installation was a bit intimidating. Any time the install software recommends a calculator, you should be concerned. After some research I found a very helpful setup guide. I did not follow this exactly, but it helped me get past some of the initial sticky points, and gave me some helpful tips. If you’re going to install OpenBSD for the first time I recommend you read this guide.

Although the jury is still out, for now I can say this operating system truly rocks. Its fairly light weight so nothing get installed which you don’t need. If you like FreeBSD / Linux I recommend giving OpenBSD a try. It makes a prefect secure web server, firewall, or just about anything other mindless server job.

Below is a fairly interesting review of the latest release of OpenBSD.
http://os.newsforge.com/article.pl?sid=05/05/20/1426216&tid=8

No Comments

Dell Laptops Suck

I thought I would start my blog with some useful information specifically that Dell laptops suck. I hate to start off on a negative note, but I wanted to give everyone a heads up before they buy one of these paper weights. Maybe I’m just venting because I’ve had to ship defective drives back to Dell every two weeks. It just seems like over the last few years their quality has diminished.

Don’t get me wrong, their still better then the Packard Bell days. I’d also like to say their server / workstation lines are top-notch. At work we have a half-dozen or so laptops all of which have experienced some type of hardware failure. I’ve also noticed the durability isn’t what it was either. The laptop chassis, keyboard, and screen seem to be weak and fragile. The focus of my frustration is directed primarily at their Latitude D400 model. Between the random lockups, hard drive failures, and simple lack of processing power it finds it way to my desk about every two weeks.

This isn’t the only model with problems; we’ve had LCD fail on their entry level Latitude line-up as well. This is simply unacceptable; these laptops are under a year old, and lightly used.

MESSAGE TO MICHAEL DELL
If you’re going to sell junk at least make it easy to return! Sitting on the phone with technical support and having to convince them of a bad LCD shouldn’t take a half hour.

After careful consideration; I’ve decided to start the migration to an IBM only policy. Although I have far less experience with the IBM ThinkPad then the Dell Latitude, every bit of information points to a better product all around. I’ll post again once I get a few new IBM ThinkPad’s to test.

4 Comments