OpenSUSE Archives - I.S. Prof

One of the items on my tinker list was to build a Subsonic streaming media server for home. For one, I do enjoy building things, and two, I continue to look for a clean way to stream music both at home and away without relying on a cloud service that has limited storage. Subsonic is a free, open-source, web-based streaming server. You can set up user permissions so you could allow access to your music and videos to your family and friends. When I started out this journey, I failed because I picked an operating system I was familiar with, but Subsonic didn’t really appreciate.

I began with an installation of OpenSUSE 11.4 on an old HP 6710b laptop. It had 2gb memory and a Centrino Duo processor, so I wasn’t too concerned with bogging it down. After going through the standard OS installation, I installed Tomcat to run the web server for Subsonic. I had planned to just download their WAR file, start up Tomcat and kick the tires. Not so. What I soon learned is that Linux doesn’t like wma (Windows Media) files — no surprise. I tried my best to locate codec converters such as lame and ffmpeg from third-party sites to no avail. Granted, I should have ripped my old CDs years ago in mp3 and not let Windows Media Player convert them to wma files in the first place, but the past is the past. I wasn’t about to go back and convert all those wma files into mp3 format. It sounded more intriguing to build a server than to watch music files convert from one format to another. Watching paint dry sounded more interesting. I digress.

With a rainy afternoon invested, I decided to scrap my escalation of commitment into a codec pit of despair and go with a different operating system. Subsonic offers a standalone, self-contained installation for Ubuntu 12.04 LTS. It seemed like the next best option since I wasn’t too keen on bringing up a Windows web server (ack!). I hadn’t played with Ubuntu for about 5 years and the OS has come a long way. I was impressed that while the software was installing, I was prompted to enter all the mundane info like name, time zone, and language. It seems little, but it’s a nice efficiency. The desktop interface would be very familiar for those used to using MacOS. I felt more confident about my OS selection, so now it was time to see if we could get things up and running.

A Rough Step-by-Step Installation Guide

Download and install the latest release of Ubuntu. I used the desktop version, which I’m sure will be fine for most people.
Download and install the latest software updates. I can’t stress enough how important it is to keep up-to-date with these to mitigate the risk of security vulnerabilities or defects within code.
Be sure to give yourself a static IP address on your network. This will make it much easier to access the web interface, and later, setup port-forwarding to access your songs away from home.
Follow the step-by-step instructions from Subsonic: http://www.subsonic.org/pages/installation.jsp#debian I followed the Advanced Configuration because I didn’t want to be exposed to security vulnerabilities by running the subsonic service as root.

Once you get logged in to the web interface, it will direct you through setting up locations for your music and videos. Rather than keep all my music locally, I have them hosted on my FreeNAS file server. I am able to maintain a multi-tier sever environment and keep single points of failure out of my hair for one, but I’m also able to tighten down security a little more this way too. Especially since I’d like to have Subsonic available away from home, this is good practice.

Now, it’s time for me to tinker some more and learn about the different Subsonic players. More to come, I’m sure.

I started this blog on May 8, 2013 with the hopes of sharing some of my I.S. “tinkering”. I’m fully intent on keeping my I.T. skills sharp so I can continue to be relevant in the classroom for Information Systems majors. One of the items on my list was to build an internal DNS server. If there’s anything that is slightly frustrating about a home network, it’s that you usually have to reference your internal devices with their IP Address (192.168.x.x usually). DNS works great for us on the Internet and is a whole lot easier than remembering IP Addresses. However, if your home network expands beyond a router and you have a file server, networked printer, etc., having DNS available to you on your home network can be rather convenient.

To Start

I started by taking an older HP nc6400 laptop with 1.5gb of RAM and installed openSUSE 11.4. 11.4 is an older Linux release, but it was the media I had on hand and Comcast was not being gracious to my download speeds the other night. I went through a typical install. In order to save on memory consumption, I did a minimal server (text only) install and made sure to set the RunLevel to 3. For running network services like this, there is no reason to have a GUI. Besides, command line is all you really need to survive 🙂

After the install, I loaded up Yast2, configured the network interfaces and then ran all the software updates that were available. I also needed to get some basic tools that don’t install by default with the operating system like vim.

yast2 -i findutils readline libgcc glibc-devel findutils-locate gcc flex lynx compat-readline4 db-devel wget gcc-c++ make vim telnet cron iptables iputils man man-pages sudo

Then, it was time to install BIND so I could get DNS up and running:

yast2 -i bind bind-chrootenv bind-devel bind-utils

Added to system startup so I didn’t have to start the service when the server rebooted.

chkconfig –add named
/etc/init.d/named start

I have to credit the following site for getting me started.

Configuring BIND

I had co-administered nameservers in my previous role, but I never had to get one going from scratch. This, naturally, didn’t come without a few hiccups. There are several resources online that can help you get this going. After you have BIND installed via the previous steps, you need to configure your /etc/named.conf file. Here are the spots I changed/tweaked from the default.

I set the forwarding DNS servers to the public Google DNS servers. I have much more faith in their
ability to resolve addresses as opposed to Comcast. Plus, Google has a shorter cache timeout, which means that if an address changes on the web, it will get picked up quicker by Google than Comcast.

forwarders { 8.8.8.8; 8.8.4.4; };

Next, I need to setup zone files for both internal DNS lookups and reverse DNS lookups. For example, I want 192.168.0.1 to resolve to router.somedomain.com and for the reverse, I want router.somedomain.com to resolve to 192.168.0.1.

zone “somedomain.com” IN {
allow-transfer { any; };
allow-query { 192.168.0.0/24; };
type master;
file “master/somedomain.com”;
};

zone “0.168.192.in-addr.arpa” IN {
allow-transfer { any; };
allow-query { 192.168.0.0/24; };
type master;
file “master/0.168.192.in-addr.arpa”;

};

Then, it was time to configure the zone files as mentioned in named.conf. In openSUSE, the zone files are stored in /var/lib/named. I first created my somedomain.com file in /var/lib/named/master:

$TTL 7200

@ IN SOA dns.somedomain.com root.localhost. (

2013052702 ; serial

28800 ; refresh, seconds

7200 ; retry, seconds

604800 ; expiry, seconds

86400 ) ; minimum, seconds

somedomain.com. IN NS dns.somedomain.com.

localhost IN A 127.0.0.1

router IN A 192.168.0.1

gateway IN CNAME router

To start with, I wanted to be able to resolve the router IP address and create an alias. The A record establishes the forward DNS lookup and the CNAME is an alias referencing router.

Then, I created my reverse lookup file 0.168.192.in-addr.arpa in /var/lib/named/master:

$TTL 86400

@ IN SOA        dns.somedomain.com.       root.somedomain.com. (

                2013052901      ; serial

                28800           ; refresh, seconds

                7200            ; retry, seconds

                604800          ; expiry, seconds

                86400 )         ; minumum, seconds

                IN NS   dns.somedomain.com.

1               IN PTR  router.somedomain.com.

The 1 in the last line references the last octet of the IP address for the reverse lookup. So, 192.168.0.1 resolves to router.somedomain.com.

Implementation

When finished, I restarted the BIND service from the command prompt:

# service named restart

To do some testing to make sure things worked, I used the dig and host commands to check my work.

# dig router.somedomain.com

# host router.somedomain.com

# dig 192.168.0.1

These commands should spit back results that indicate that your DNS entries correspond with the right domain and vice-versa.

The last step was to change the configuration on my router to reference the new internal DNS server so all devices on my home network could utilize the new DNS service. Ideally, you should have 2 internal DNS servers in case one fails. Down the road, I may bring up BIND on a separate box for fault tolerance. In the meantime, I made my internal DNS server the primary DNS and Google’s 8.8.8.8 the secondary.

After rebooting the router, I opened up a command window on one of my windows clients and issued the flushdns command. This cleared the local DNS cache so all new addresses would be pulled from the server.

ipconfig /flushdns

I then tried a few simple ping and nslookup commands to make sure things were working locally:

ping router.somedomain.com

nslookup 192.168.0.1

In Closing

All is working and now I can go back and edit my host files to include other static IP addresses I want internal DNS addresses for like printers, file servers, Nintendo WII, etc. At the end of the day, it was a fun tinker. That’s what I was looking for in the end. I’m curious now to see how feasible this is to deploy to students in a lab format so they can tinker as well. From my perspective, it teaches fundamentals on how to install and configure a server in addition to picking up network fundamentals at the same time. We’ll see if this one has viability down the road.