iceflatline

I finally got around to registering an IRC channel. You’ll find #iceflatline over at DALnet. I’ll be hanging out there so swing by and say hi.

I’m fortunate (or cursed) enough to be able to upgrade the desktop computers here at the iceflatline compound fairly often. The way this usually works is that my personal desktop computer gets overhauled and then the older parts are used to build, upgrade and/or maintain the other machines in the house – call it the “trickle down” method of upgrading.

Recently I decided it was time to start this cycle again. I had elected to skip over Intel’s X38 and X48 chipsets (and p45/p55 chipsets too) and Windows Vista, and so my computer – still based on the x975 chipset and Windows XP Pro was definitely in need of an upgrade.

This will be the first in what I intend to be three related posts documenting this upgrade – the parts I selected for it and why; the assembly of the system and the challenges I encountered; and finally, the steps taken to overclock the system.

The Parts

I’ve built a good many PCs over the years. Everything from bleeding-edge, fire breathing, water-cooled dragons to systems just fast enough to run Puppy Linux. My goal this time was to use the best quality components I could find for a low price, and build a fast, reliable machine for right around $1000 – $1500. In other words, build a machine that’s a good value. Since this was an upgrade, I also had a couple of other objectives in mind. First, since this machine, like its predecessor, would be used primarily for PC gaming and the occasional video/audio project, I wanted to upgrade the graphics capability; second, I wanted to significantly increase the amount of system memory; and finally, I wanted to use Windows 7.

The case – I’ve been a fan of Lian Li cases for some time; however, while they look great and their quality is second-to-none in my opinion, they’re not what you would characterize as a “gamer” or “enthusiast” case. This is primarily because they typically lack good cooling. I’m currently using water cooling in one of their tower cases and so the lack of good case cooling has not really posed a problem for me. However, I wanted to try and save on what I anticipated would be the cost for a new water cooling solution to fit a new motherboard and instead go with air cooling if I could. That steered me towards a mid-tower case with good air flow. I decided on the NZXT Tempest case. I had built a system for one of my kids with this case and really liked it. The three 12cm fans provide good air flow; it’s easy to work in, and it looks good.

The power supply – This was an easy one. I almost exclusively use power supplies from two manufacturers. For lower cost builds I use Fortron and for everything else I use PC Power & Cooling. I was already using a Silencer 750 in my current system so my solution here is to simply reuse this unit.

The CPU – This was a tough choice. Being somewhat of an Intel fan boy I had more or less settled on going with one of their Core i7 products. But Intel has presented a very challenging decision for the gamer/enthusiast building a new system today. Intel’s newest CPUs – code-named Lynnfield – include the 2.93GHz Core i7-870, the 2.83GHz Core i7-860, and the 2.66GHz Core i5-750. Lynnfield chips use essentially the same “Nehalem” 45 nm architecture as Intel’s other Core i7 CPUs, code-named “Bloomfield.” However, the Lynnfield CPUs are incompatible with existing Bloomfield-based Core i7 motherboards. The most notable difference is Intel’s decision to use a new socket for the Lynnfield CPUs – LGA1156, which is incompatible with the current Bloomfield-based CPUs. To make matters even worse, the fan/heatsink mounting holes for each socket type are also incompatible.

A significant advantage in using Bloomfield is Intel’s use of tri-channel DDR3 memory (to save cost, Intel uses dual-channel DDR3 for Lynnfield). So then why go with Lynnfield if a bigger memory bus is arguably better? I want a fast rig right, and I have to get a new motherboard in either case. Well, for one thing, LGA1366 motherboards aren’t cheap. Those added traces from the socket to the RAM slots to support tri-channel RAM mean more layers and pricier motherboards. Yet another factor to consider is that while Lynnfield is cheaper and gets you 90 percent the performance of a Bloomfield system, Intel will purportedly introduce a yet another new CPU skew in 2010 (“Gulftown”). This architecture supposedly adds two more physical cores to the CPU, add to that hyper-threading, and that’s 12 threads available to the OS. But alas, it will only be available on the Bloomfield/LGA1366 platform.

But, after weighing all these factors and the desire to stay true to be goal of pulling together the best system for the money, going with a Lynnfield build made the most sense to me. I chose the 2.83GHz Core i7-860, which should overclock quite well and, for ~$280.00, would seem to be the sweet spot for price versus performance. I also save at least $100 on the board and a little more on the RAM. However, I arguably give up a clearer upgrade path by passing on a Bloomfield-based system.

The Motherboard – I’ve traditionally used ASUS motherboards but then started to run into reliability problems with them. I also grew tired of the growing list of “features” their boards began to offer that I had no use for (e.g. WiFi, Bluetooth, etc.), resulting in time spent trying to disable them somehow. For my last build I used Intel’s D975XBX2, the so called “Bad Ax” board, and really liked it. No it didn’t have all the candy-ass features and overclocking capabilities of say an ASUS or Gigabyte motherboard at the time, but it turned out to be sufficiently overclockable for my needs and has been 100% reliable. Given this experience, I decided to go with an Intel motherboard again and chose their DP55KG.

The Heatsink – The Corsair Nautilus 500 water cooling solution I’m currently using, while it has served me well, wouldn’t be useable on the new LGA1156 motherboard. Besides, Intel’s latest CPUs run cooler than their predecessors and air cooling has gotten significantly more effective. So, there just wasn’t any reason in my mind to hassle with another water cooling solution for this build. However, finding a suitable fan/heatsink for an LGA1156 CPU turned out to be somewhat of a challenge. As I mentioned, the fan mounting holes for LGA1366 and LGA1156 motherboards are incompatible. So while there were plenty of options for 1366-based boards at the time I was pulling my parts together, very few of the more reputable heatsink manufactures had yet to put out parts yet that were made specifically for with newer.LGA1156. I ended up choosing the relatively inexpensive Arctic Cooling Freezer 7 Rev.2 with the hope of finding something a perhaps a bit more effective in a couple of months when other companies started to release parts for the LGA1156 motherboards. I also chose Arctic Silver 5 for the thermal compound.

The RAM – One of my goals for this build was to double my system memory. That meant 8GB for this build. After all, this is supposed to be an upgrade right? I was looking for either an 8GB kit (2×4GB) or two 4GB (2×2GB) kits with the timings as low as possible. Another factor that I was glad I considered ahead of time was whether the RAM would fit under the CPU’s fan/heatsink due to the close proximity of the RAM slots to CPU. I ended up eliminated a couple of products (Corsair Dominator I’m looking at you…) because they were too tall to fit. I ended up selecting two 4GB DDR3-1600 Mushkin Redline kits from which run at 1.65v with timings that spec at 7-7-7-18.

The Graphics – I have no allegiance to either AMD or Nvidia and was willing to go with either depending on price versus performance. I ended up going with AMD this time around though and chose a Radeon 5870 from ASUS. For ~$380, I felt it provided the best performance for the money.

The Optical Drive – Believe it or not I actually had to buy one of these. The Lite On drive I’m currently using is IDE and I needed one with a SATA interface. Sadly, I guess it really is time to move on. Here’s how much time I spent shopping for it though – I went to Newegg.com, navigated to the CD/DVD burners, selected “Best Rating” from among the search options and dutifully paid for the one that was at the top of the list. I think it was from Samsung :).

The Hard Drive – This was a tough decision too. I really really wanted to get a solid state drive but with prices so high and firmware support for features like Trim so fluid I decided to stick with with my trusty Western Digital Raptors that I currently have set-up in Raid 0. I fully expect that SSD performance will improve and prices will come down soon so I plan on revisiting this at a later time.

The OS – Not much of a surprise here. I went with Windows 7 Pro 64-bit. Why the pro version and not Home Premium? Remote Desktop. Home Premium doesn’t support it and I really wanted this feature so I could easily access this machine remotely.

Final Thoughts

Well, that’s it for the parts list. Most of which I elected to get from Newegg.com. Cost, not including shipping, came in right around ~ $1400.00. Next time I’ll share my experiences with assembling the system and the challenges I encountered.

One of my favorite things about using Linux and BSD is Conky. Conky is a free, light-weight system monitor that can display nearly any information about your system directly on your desktop. Originally a fork of Torsmo, Conky’s torsmo-based code is BSD licensed. New code in Conky has been licensed under the GPL 3.0.

Installation is easy. On a Debian-based distribution like Ubuntu:

$ sudo apt-get install conky

On Fedora-based distributions:

$ su
# yum install conky

And on BSD, if you’ve installed the Ports collection:

$ cd /usr/ports/sysutils/conky/
$ su
# make install clean

Or if you would prefer to add the package:

$ su
# pkg_add -r conky

Conky is very simple to configure. Using a pre-defined set of variables in a configuration file you define what Conky should monitor and where those monitored parameters are displayed on your desktop. The look and feel of what’s displayed is highly customizable.

On most systems the default configuration file location is /etc/conky/. There you will find the sample configuration file conky.conf. You’ll want to copy it to ~/.conkyrc and then start modifying it.

When setting up my Conky configuration, I decided to dispense with the fancy network graphs and other eye candy that I’ve seen in so many others use and go with a more utilitarian approach. I settled on four areas for Conky to monitor:

System – basic system information showing kernel version, uptime, total RAM and Swap usage, etc.

Processor – shows the top five applications or processes based on CPU usage

Memory – shows the top five applications or process based on system RAM usage

Network – shows basic information regarding wired and wireless connections, including IP address, inbound and outbound speed, connection quality, etc.

This minimalistic approach looks good (less “cluttered”) in my humble opinion, and provides just the information I need while not straining system resources.

One of the many cool things about Conky is its support for the use of conditional operators within its configuration file. The $if_existing operator, as an example, checks for the existence of a file passed to it as an argument and will display everything between $if_existing and the matching $endif. I used this particular operator to my advantage when configuring the network monitoring section. Instead of displaying information about each wired and wireless interface, even when they weren’t up, I chose instead to display information about them only if they were up by using the existance of a particular interface (e.g., eth0) in the /proc/net/route file.

Anyhoo, here’s the configuration file I’m currently using. Feel free use it as is or change it to fit your needs and taste. Post your Conky configuration in the comment section.

### Conky Display Settings 

# set to yes if you want Conky to be forked in the background
background yes

#font
use_xft yes
xftfont Sans:size=8
xftalpha 1

# Update interval in seconds
update_interval 1.0

# This is the number of times Conky will update before quitting
# Set to zero to run forever.
total_run_times 0

# Create own window instead of using desktop (required in nautilus)
own_window yes

# Use pseudo transparency with own_window?
own_window_transparent yes

# If own_window is yes, you may use type normal, desktop or override
own_window_type desktop

# If own_window is yes, these window manager hints may be used
own_window_hints undecorated,below,sticky,skip_taskbar,skip_pager

# Use double buffering (reduces flicker-maybe)
double_buffer yes

# Minimum size of text area
minimum_size 210 200

# Maximum width of text area
maximum_width 240

# Draw shades?
draw_shades yes

# Draw outlines?
draw_outline no

# Draw borders around text?
draw_borders no

# Draw borders around graphs?
draw_graph_borders no

# Default colors and also border colors
default_color white
default_shade_color black
default_outline_color white

# Text alignment, other possible values are commented
#alignment top_left
alignment top_right
#alignment bottom_left
#alignment bottom_right
#alignment none

# Gap between borders of screen and text
# same thing as passing -x at command line
#(in pixels-me thinks)
gap_x 12
gap_y 12

# Subtract file system buffers from used memory?
no_buffers yes

# Should all text to be in uppercase?
uppercase no

# number of cpu samples to average
# set to 1 to disable averaging
cpu_avg_samples 2

# Force UTF8? note that UTF8 support required XFT
override_utf8_locale no

### Conky Output 

TEXT
${color 2F7CA9}
${font sans-serif:bold:size=8}SYSTEM ${hr 2}
${font sans-serif:normal:size=8}$sysname $kernel on $machine
Host:$alignr$nodename
Uptime:$alignr$uptime
RAM:$alignr$mem/$memmax
Swap usage:$alignr$swap/$swapmax
Disk usage:$alignr${fs_used /}/${fs_size /}
Total CPU usage:$alignr${cpu cpu0}%

${font sans-serif:bold:size=8}PROCESSOR ${hr 2}
${font sans-serif:normal:size=8}${top name 1} $alignr ${top pid 1} ${top cpu 1}
${top name 2} $alignr ${top pid 2} ${top cpu 2}
${top name 3} $alignr ${top pid 3} ${top cpu 3}
${top name 4} $alignr ${top pid 4} ${top cpu 4}
${top name 5} $alignr ${top pid 5} ${top cpu 5}

${font sans-serif:bold:size=8}MEMORY ${hr 2}
${font sans-serif:normal:size=8}${top_mem name 1}${alignr}${top mem 1} %
${top_mem name 2}${alignr}${top mem 2} %
$font${top_mem name 3}${alignr}${top mem 3} %
$font${top_mem name 4}${alignr}${top mem 4} %
$font${top_mem name 5}${alignr}${top mem 5} %

${font sans-serif:bold:size=8}NETWORK ${hr 2}
${if_existing /proc/net/route eth1} ${font sans-serif:italic:size=8} $alignc Wireless
${font sans-serif:normal:size=8}IP address: $alignr ${addr eth1}
SSID: $alignr ${wireless_essid eth1}
Speed: $alignr ${wireless_bitrate eth1}
Connection quality: $alignr ${wireless_link_qual_perc eth1}%
Inbound ${downspeed eth1} kb/s $alignr Total: ${totaldown eth1}
Outbound ${upspeed eth1} kb/s $alignr Total: ${totalup eth1}
${endif}
${if_existing /proc/net/route eth0} ${font sans-serif:italic:size=8} $alignc Wired
${font sans-serif:normal:size=8}IP address: $alignr ${addr eth0}
Inbound ${downspeed eth0} kb/s $alignr Total: ${totaldown eth0}
Outbound ${upspeed eth0} kb/s $alignr Total: ${totalup eth0}
${endif}
${if_existing /proc/net/route ppp0} ${font sans-serif:italic:size=8} $alignc Mobile
${font sans-serif:normal:size=8}IP address: $alignr ${addr ppp0}
Inbound ${downspeed ppp0} kb/s $alignr Total: ${totaldown ppp0}
Outbound ${upspeed ppp0} kb/s $alignr Total: ${totalup ppp0}
${endif}

And here are some screenshots:

I bought Borderlands on Steam; played as a soldier; spent ~30-40 hours on it; and finished at level 36. My favorite weapon was the Desert Stomper combat rifle.

Here are my quick thoughts on the game…

Pros…

The artwork – The watercolor look of the game is unique and a really nice break from the usual textures. It was always interesting but never distracting.

The loot – Ridiculous amounts of it really. It didn’t take long to rack tons of cash, weapons, shields, and grenades.

The weapons – The shear number and types of weapons turned into a sort of mini game for me. I found myself constantly swapping them looking for the best load out.

The save system – It’s a checkpoint system, but there are plenty of them; also, the game saves automatically when you exit. It was nice not having to manage the saves

Cons…

The map system – Essentially useless. There is no overall world map to show which part of Pandora your quest is located or how the various areas connect to one another. This makes using game’s teleportation system a lot like trying to find a needle in a haystack.

The vehicle weapons – You get a rocket launcher and a machine gun. Unfortunately, both are seriously nerfed. Luckily the best weapon on the vehicle is the vehicle itself – just running over baddies gets the job done.

The bad guys – In a word… repetitive. You can only fight so many bandits, burning psychos, and skags before you want to throw down your guns and head back to Fyrestone to have a beer with Dr. Zed.

The ending – No spoilers, but let’s just say that it left me wondering if maybe the fire alarm went off and Gearbox developers decided to finished the game quickly and run out of their building.

Tips…

Aim for the head – good advice in any game, but headshots are especially effective in this one.

Armor and health – With the plethora of weapon make and models it would be easy to focus on your offensive firepower. Spend time initially though building up your HP and getting the best shield you can.

Avoid weapons with ridiculously high damage – rocket launchers, some shotguns and sniper rifles in this game feature damage that seems too good to be true. “Damage 850!? Woo hoo!!” Turns out that most are significantly nerfed. Focus on having a balanced weapon. Accuracy and recoil reduction are important stats.

In my post Remote Access to Your Ubuntu Server using PuTTY, Hamachi and SSH, I discussed how to set up a secure virtual private network (VPN) between a remote Windows and Linux client, and a Ubuntu home server using LogMeIn Hamachi. In this post, I’ll discuss how to install and configure Hamachi and SSH on a machine running FreeBSD so it too can be added to your Hamachi VPN.

If you’re not familiar with LogMeIn Hamachi (formerly known as just “Hamachi”), it is a hosted VPN service that is capable of establishing secure LAN-like links between computers, even if they’re behind Network Address Translation (NAT) devices. You can use it to create secure virtual networks on demand, across public or private networks. In order for Hamachi to work, a “mediation server,” operated by the LogMeIn, is required. The mediation server stores machine nicknames, statically allocated 5.0.0.0/8 IP addresses and the associated authentication token of the user. Hamachi is free for non-commercial use. However, the Hamachi security implementation is closed source and as such is not available for review by the general public.

The versions for the software used in this post were as follows:

FreeBSD 7.2 RELEASE

Hamachi (Linux) v0.9.9.9-20

OpenSSH vSSH-2.0-OpenSSH_5.1p1

Install Hamachi

If you’ve installed the FreeBSD ports collection then run the following to install the Hamachi port:

# cd usr/ports/securityhamachi/
# make install clean

Otherwise you can grab the package and install it:

# pkg_add -r linux-hamachi

Note that Hamachi requires a Linux emulator in order to run on FreeBSD. Either install method described above will satisfy this dependency by also installing linux_base-fc4 (/usr/ports/emulators/linux_base-fc4), a set of packages that form the basis of the Linux compatibility environment needed by Hamachi in order to run on FreeBSD.

Now, let’s configure Hamachi and create our VPN. Hamachi requires the tap kernel driver to create and manage its virtual Ethernet network interface. No worries though, Hamachi adds a script (/usr/local/etc/rc.d/hamachi) that will automatically load the tap driver (if_tap.ko). This driver must be loaded and running before starting Hamachi itself. You can have it load it automatically when FreeBSD starts by adding the following line to /etc/rc.conf:

hamachi_enable=”YES”

If you want only to run Hamachi periodically and not start the tap driver automatically at boot time, you can use forcestart/forcestop, which will ignore the setting in /etc/rc.conf:

# usr/local/etc/rc.d/hamachi forcestart

Our next step generates the cryptographic key pair and creates a directory at ~/.hamachi where Hamachi will store these keys, as well as its configuration and state. This step only needs to be performed once per Hamachi install; however, it must be done for each user account that you plan to use Hamachi from, including root. In this case we’ll run it from our user account:

$ hamachi-init

Okay, now let’s start Hamachi. First, make sure the tap driver is loaded by rebooting the machine (assuming the hamachi_enable=”YES” line is in /etc/rc.conf as described above) or by using the forcestart command, then:

$ hamachi start

When Hamachi is run for the first time, the Hamachi daemon stays offline. Let’s bring it online:

$ hamachi login

Next, create a nickname for the FreeBSD machine so that we can identify it easily from another machine on your Hamachi VPN:

$ hamachi set-nick <nickname>

Now, let’s create our Hamachi VPN. In this step you’ll need to enter a unique name for your network as well as a password for it. If your network name is already in use somewhere you’ll need to keep trying until you land upon one that’s unique. If you’ve setup a Hamachi VPN previously and simply want to add your FreeBSD machine to it, then substitute join for create in the following command:

$ hamachi create <network> <password>

Now let’s put the FreeBSD machine online on the VPN:

$ hamachi go-online <network>

That’s it. Your Hamachi VPN should now be up and running with your FreeBSD machine added as one of the hosts. What if we reboot, do all these commands need to be entered again? The answer is no. Once the Hamachi VPN is created/joined, the nickname established, and the machine added with the go-online command, should you need to reboot your box, you can simply restart the tap driver (assuming you elected not have it start automatically) and then start Hamachi, you’ll then be back online. However, you can also have Hamachi start automatically at boot time by adding a script in your system startup sequence. You will of course want to have the tap driver start automatically as well for this to be of any benefit. Here’s a generic version of the script I use:

#!/bin/sh
#
### README
# Date:
# Description: sh script to start hamachi at boot
# Author:
# Process(s): hamachi
# Configuration: none
#
### START OF SCRIPT
USER=<user name>
case "$1" in
start)
su - $USER -c "hamachi start"
;;
stop)
su - $USER -c "hamachi stop"
;;
reload)
/bin/su - $USER -c "hamachi stop"
/bin/su - $USER -c "hamachi start"
;;
*)
exit 1
;;
esac
exit 0
### END OF SCRIPT

To use this script simply add your account user name, save it as hamachi_start.sh in /usr/local/etc/rc.d/ and make it executable. You’re free to choose a different name, however, note that scripts within /usr/local/etc/rc.d/ are executed in lexicographical order. Since it is desirable that the file hamachi start first in order to load the tap driver, you should name the hamachi start script something that will ensure it starts after hamachi. Numbers may be used as a prefix to the filename.

You can display the status of the Hamachi daemon at any time by running the command hamachi without any arguments:

$ hamachi
  version  : hamachi-lnx-0.9.9.9-20
  pid      : 846
  status   : logged in
  nickname : bsd

The following commands will retrieve the nicknames and print a list of the hosts that are currently members of your Hamachi VPN, as well as their Hamachi IP addresses (you will not see the machine you issued the command from listed):

hamachi get-nicks && hamachi list

And if needed, you can stop Hamachi with the command hamachi stop:

$ hamachi stop
Shutting down .. ok

Now then, to initiate a terminal session with another host on your Hamachi VPN:

ssh <hamachi-IP address-for-remote-host>

If this is the first time connecting, you’ll likely receive a warning concerning the authenticity of the host you’re trying to reach along with a fingerprint of its public RSA key, and asked if you’re sure you want to continue connecting. Accept by typing yes and you’ll be presented with the login and password prompt (this warning prompt will only occur once per machine). The public key from the remote host will be stored in ~/.ssh/known_hosts. If you don’t want to have to remember the Hamachi IP address each time you want to run a session with another host, simply add this IP address along with a name (e.g. home-server-ssh) to your hosts file (/etc/hosts). Next time you use Hamachi/SSH to connect to this host, use the name instead of the IP address and the host file will resolve the IP address for you.

SSH Server

Now that we’ve installed Hamachi, created or joined a VPN, and perhaps tested it by connecting to another host on the VPN. Let’s make sure there’s a running SSH server on our FreeBSD machine so that incoming SSH requests can be answered:

/etc/rc.d/sshd status
sshd is running as pid 811.

Should you need to install sshd, type sysinstall. Select Configure ->Networking and select sshd from among the options. Make sure sshd enabled by checking the /etc/rc.conf file for the line sshd_enable=”YES”. This will load sshd the next time your system starts. You can also start sshd manually through the /etc/rc.d/sshd script:

# /etc/rc.d/sshd start

Conclusion

This post described how to install and configure Hamachi on a machine running FreeBSD. The reason I like using LogMeIn Hamachi is that it allows me to connect via SSH, SCP or SFTP to my FreeBSD machine at home from essentially anywhere I have an internet connection without the need to make any changes to my router/gateway. To learn how to install and configure Hamachi on Linux or Windows machines, as well as how to improve the security of the connections over the Hamachi VPN using public key authentication, please see this post Remote Access to Your Ubuntu Server using PuTTY, Hamachi and SSH

References

http://www.openssh.com/
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/