An Introduction to MSERV
Have you ever wondered who picks the music in your office? What about in elevators? I bet you sometimes stand in the elevator thinking, “You know, I bet if I just hit this little red button.” That type of thinking is caused by elevator music. It never fails; unless you are employed by a progressive company, you will end up listening to artists that either: have been dead longer than you have been alive or make their money reproducing songs á la elevator music.
Obviously, this is a problem. A common solution for management is either to put everybody in cubicles, where they end up like trolls but can listen to their own music, or to dictate the music to be played.
The advent of personal jukeboxes like the NOMAD from Creative Labs (see Resources) can solve some of these problems. They have long play times, and the NOMAD can store over 150 CDs of music, something a walkman could never do. The problem with players is the word “personal”. You can't share your general music interest; plus, they are $500.00 US apiece.
The population of networks within the office and the proliferation of MP3 technology has spawned a new type of player. It is called MSERV. MSERV is a piece of open-source software that allows an office to turn a PC-running Linux, or another open-source operating system, into an MP3 jukebox; it's a lot like a personal jukebox but with centralized capabilities for the entire office.
When I first downloaded MSERV, I thought it was something other than what it is; I thought it was a broadcast server. In my mind it would be great to have over 500 CDs worth of music sitting on one hard drive that I or anyone else could access from their local web browser. We could set up our own play lists and listen to any music we wanted, separately. After realizing exactly what MSERV was, I had to readjust my thinking. I am glad that I did; MSERV provided the people in our office a compromise with regard to the music we listen to. A technical description of MSERV would be: client/server, TCP/IP-based, central music deployment and ranking software. In short, it is like a Web Board Poll for MP3 listeners.
From an end-user standpoint, MSERV is a dream come true. It is specifically designed to play only the songs that people in the office want to hear. For example, if you have ten people who all enjoy the Eagles but only one who enjoys Yanni, that one person is out of luck. Why? Because MSERV uses a ranking system to pick the songs it plays. The ranking system is completely controlled by the user.
Let's say you are plugging away at your current geek-of-the-week task, and for some insane reason, a strange noise starts emitting from the overhead speaker. You're not sure, but it sounds like something your mother used to listen to. Instead of complaining and grumbling through your day, you fire up the good old web browser (hopefully not IE) and point it to the local MSERV machine. Voilà, you were correct, it is something your mother used to listen to. It's the Righteous Brothers and you saw Dirty Dancing one too many times to ever want to hear them again. Don't despair! MSERV allows you, the end user, to rank them into oblivion with one little click.
Of course, if everyone else loves them, they can rank them right back up, and you will hear it hour after hour, but at least some power has been given back to the end user.
The installation of MSERV is not difficult. The web site offers source, tar and rpm-based versions of the software. If you are running an RPM-based system (and the majority of systems out there are), then you'd type, as root, rpm -i mserv-0.33-1.i386.rpm. This will install all of the required components.
Once the program is installed, log in as a normal user. As the non-root user, you may start MSERV by entering the /usr/bin directory and typing MSERV. When MSERV starts, it will create a directory in the non-root users' home called .mserv. The .mserv directory is where the configuration and password files live.
MSERV comes with a web client. The web client is very simple to install. It only requires that Perl be on your system and that the ExecCGI option be turned on in the directory that you install into. Just copy the web client files to the URL that you would like to serve them from. For example, if your document root for your web server is /usr/local/apache/htdocs, you can install the files in /usr/local/apache/htdocs/mserv. Once you have edited the httpd.conf for the ExecCGI option, restart the Apache server. You should be able to point your web browser to your URL and have MSERV come up.
Once Apache is loading the pages correctly, you will want to change a couple of parameters in the mserv.cgi program. You can find it under the installed path. The main parameter you are looking for is the $host line. The $host line is the line that tells MSERV where to look for the programs.
If a web client is not what you are looking for, MSERV has a CLI and MS Windows client as well. The CLI is a Command Line Interface client and basically acts like a Telnet client. The MS Windows client is written in Delphi. Unfortunately, we were unable to test the Delphi version, as we don't run Windows.
The Delphi-based client is good for offices. As we all know, the majority of offices out there still run MS Windows, and having a Delphi client makes sense. Besides, consider it a proliferation option. First an MP3 server on Linux, then a mail server, then a web server, then a desktop, etc. Before long everybody will be running KDE2, and nobody will know the difference.
If you are a developer, MSERV offers a wealth of opportunities for improvement. That is not to say that MSERV is a bad product, exactly the opposite. But like most open-source projects, it needs polish. It needs a simple install and configure program, something beyond RPM or compiling. It needs a prettier front end, and it needs to be centralized, but also offer broadcasting capabilities.
MSERV offers an opportunity to provide a new product to the market. Here are some examples: a jukebox in the back of a car that directly interfaces with the stereo—just like CD-based jukeboxes but not limited to ten CDs per cartridge. Instead, you are limited only to the size of the hard drive you put in it. You can purchase an 82 gig hard drive for $300.00 US—82 gigs of hard drive space is large enough to hold approximately 2,000 CDs worth of music.
Another example would be a set-top box. You could connect a little box to your stereo at home and have all of your CDs available instantly. You could even set it up so that as soon as you put in a new CD it would check the CD information from CDDB and start ripping the CD into an MP3 archive.
If you were to add remote control services to either of these, you would have instant emperor-like status among couch potatoes.
MSERV is only in release 0.33, and it is not considered stable. We at Command Prompt, Inc. World Headquarters, a three-person company, have been using it for almost three weeks. The consensus is that we like it and that it is stable. If you have a resident geek in-house, give MSERV a try. It's a fun little product and actually provides a useful solution to a common problem. The true power of the program is in the open-source nature of the product. Anybody can develop for it, and anybody can extend it. But then again, you're reading Linux Journal. You already know this.
Joshua Drake is an e-commerce and Linux consultant who owns his own company, Command Prompt (http://www.commandprompt.com/). He has been using Linux for almost nine years and is the Linux Documentation Project's webmaster. His other projects include the LinuxPorts.com website and the OpenDocs publishing company.
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- RSS Feeds
- Introduction to MapReduce with Hadoop on Linux
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?