Possum TV Live Server - Software

Operating-system-wise, I did things the hard way with this server, but even so, the process went fairly smoothly. Since this was my first effort at connecting a server to that wretched hive of scum and villainy known as the Internet, I decided to do my best to make it secure. My decision was to go open source and furthermore, I'd try to build everything on the system from the source code. I'd heard about LFS (Linux from Scratch) and it seemed worth a try. Not only would it (in theory at least) give me a lean system with a minimum of surface open to attack, but it would also be an interesting learning experience.

The first problem I encountered was that my motherboard was so new that it wasn't supported by the current release of LFS, and I even had difficulty finding a Linux CD that could successfully bootstrap the system. After a bit of searching, I managed to make a Kubuntu CD work with a bit of tweaking, but from that point on, things were fairly straight forward. It took major time (several days), even with the fast system I had, to compile and test all of the code, and there were a few issues to be resolved, but quite frankly it was easier (although admittedly slower) than installing XP. Every time I've installed XP, I've had to contend with blue screens and endless driver problems. By contrast, LFS (even the pre-release version) has been rock solid.

When I upgraded the system in March 2010, I went through this process again, and it was even easier the second time around, although it still took significant time to complete.

I should add that I'm not a Linux evangelist. I actually don't mind XP and can even cope with Windows 7; however a stripped-down version of Linux like LFS seems to be a perfect choice for a small web server like this and I'm very happy with it.

Once the OS was installed, I went about creating—the hard way—what is probably a fairly conservative LAMP (Linux, Apache, MySQL, Perl) webserver, with a program called Motion handling the video side of things. I installed the following software:

• ffmpeg library (required for Motion)
• libjpeg library (required for Motion)
• Motion
• OpenSSL
• MySQL
• Apache Web Server
• mod_perl module for Apache
• vsftpd FTP Server
• NTP Client
• fcron
• AWStats (page view statistics)
• Perl modules DBI, LWP, DBD::mysql, Astro::Sunrise and Geo::IP (the last two of these are to provide sunrise/sunset times on the index page, and to track page views respectively).
• Cambozola—not really a software package as such, but a java applet to allow streaming video to be viewed correctly on IE.

I also installed things like PCI Utils, Hdparm, cURL, Git and JOE for software development purposes and there might also be some other minor things I've forgotten, but I think the list above gives a good indication of the software needed for a webcam server like this one.

The server has only a command-line interface with no window manager. It makes the system much simpler and leaner to omit all of the Xorg stuff; the only down side is that you don't have any easy way of viewing movies or jpegs when setting up the cameras. I didn't find this to be a problem, because I could just access streaming video from Motion using a web browser on another computer.

Configuration

Configuring it all took a bit of time, but the main packages; Apache, MySQL and Motion, are fairly well documented and easy to work with, and the BLFS (Beyond Linux From Scratch) documentation is also very helpful. I won't go into the details of the configuration, but I'll just briefly mention a few relevant items which others might find helpful:

• Each daemon runs under its own user with restricted privileges. This makes the system more secure, but it creates all sorts of traps for the inexperienced (i.e. people like me). You need to have a clear idea of which program needs to read and write which files. For instance, initially Motion didn't have privileges to access /dev/video0 and also Apache didn't have privileges to read files created by Motion. This required a bit more than simply setting a few directory privileges, and I ended up having to add a umask command to the Motion startup file, and tweak the udev rules.

  
  

  By the way, don't be put off by those arcane *NIX incantations; I had never heard of them until I started this project, but this stuff is all documented and fairly straight-forward.

  
  

• There were some difficulties with the ffmpeg library. Initially I used SVN_20070606, as supplied by the BLFS site, because that was the only version I could get to work. After the upgrade, I used the latest release of ffmpeg (0.5) and this worked without any problems. I would recommend using this version.

  
  

• Although Motion has a classic webcam feature, I didn't want to use this because I didn't want it wasting power and disk space by continually writing files to hard disk even when no one was watching. Instead, I used the "snapshot" feature which is triggered from Apache via a Perl script sending http requests to Motion. This was a bit inelegant, and the script required a surprising amount of tweaking to cope with pathological cases (and deliberate abuse), but once I worked it out it seemed to be quite reliable.

  
  

• Since this site has the ability to search a database for movies (as well as edit this database and delete files, although these functions are inaccessible to the outside world), it is in principle open to the possibility of XSS and SQL injection attacks. There are right ways and wrong ways of defending against these, and it's worthwhile doing a bit of research before writing any server-side scripts—they will be the weakest point of your system.

  
  

• Just for the exercise, I validated all of the web pages as HTML 4.01 Strict with the W3C validator, used JSLint to audit the javascript, and the Perl scripts all have "-T", "use strict;" and "use warnings;". I would say that less than 10% of the "problems" turned up by these tools were actual problems that needed to be addressed. Also, these tools don't automatically guarantee that your site will be secure or will display how you want it on all browsers; which are ultimately the most important issues.

  
  

  I suppose there are different schools of thought here. On one hand, it's nice to know that your code conforms to very strict standards. It's more likely to work in unknown browsers and more likely to be correctly parsed by bots (which may help with SEO if you're worried about that sort of thing).

  
  

  On the other hand, how much of a problem is it in actual practice that you've omitted a redundant set of curly brackets in an IF statement or missed out an alt tag on a decorative image? Also, you often have to violate certain standards to get some things to work the way you want in certain browsers.

  
  

  My experience is that html and javascript validators are annoying and frustrating to use—something like having a really picky grammar Nazi looking over your shoulder—and most of the time not worth the aggravation. However, anything you can do to check your server-side scripts is worth doing, since they are what the bad guys will try to exploit to hack you. Turning on any checks you can in Perl is good, however recognise that these checks simply help you to achieve a secure system; they do not in themselves ensure security.

  
  

• When I first set this web site up, I tested everything under the latest versions of Firefox, Internet Explorer, Chrome and Safari, as well as some of the older versions, including the notorious Internet Explorer 6. Unfortunately, soon after this, the major browsers got caught up in an insane version-numbering race; rather than a new major version coming along every couple of years, it was more like every couple of weeks and it became impractical to re-test everything for every new browser version.

  
  

  My recommendations on testing: If you use a reasonably conservative set of web standards, testing with the latest versions of Firefox, Safari, Chrome and Internet Explorer should be quite adequate.

  
  

Recommendations

In general I would recommend starting with a stable and reasonably lean distro of Linux. If you are using Motion, there are pre-built packages available for Fedora, Mandriva, Debian and Ubuntu, so it would be easier to use one of these. Of these, Debian appears to have a particularly good reputation in web server applications and would probably be the best choice, although I haven't used it myself so can't really comment.

If you don't mind compiling Motion from the source code, you can use pretty much any distro you feel comfortable with (they all ultimately run on the Linux kernel, after all). Using LFS is taking things to extremes and only recommended if you want to learn about Linux, or if you're pushing the boundaries of performance.

Unless you've got specific preferences for other software packages, I would recommend installing the ones that I did. My understanding is that these packages are the Cisco routers or Fluke multimeters of the software world (although without the price-tag) and you can't go too far wrong by choosing them.

If you really wanted to, it would be possible to use Windows. Most video input cards come with Windows-based monitoring software, and you could combine this with a simple (and free) web server like WAMP. You'd probably have worse performance (although there may be little difference in practice) and you'd certainly have to pay extra attention to security issues, but I'm sure it would work.