A homebrew ATSC multi-room PVR project

I'm not involved in technical matters much at work right now and thus I've fallen back to updating my own home on my spare time. This is a six-month project that will consist of:

Canada has switched to ATSC on September 1st, so my main objective is to cut cable TV and modernize my 2 current standalone cable-company-supported-PVRs which have an interface that dates back to 2001.

In a nutshell, I'll do this in the following weeks:

• No more lightning in the house: Installing and grounding an exterior OTA antenna
• Thank you foxconn and the MediaPortal Team: Building and configuring a "budget" Windows 7 TV Server with MediaPortal
• Rsync now, robocopy later: Dismantling my FreeNAS-based NAS to consolidate data on the TV Server.
• PXE for the masses: Deploying 2-3 MediaPortal client nettops using PXE and OpenWRT

I've got some of the pieces in place. The Win7 server is running and I should be ready to test MediaPortal soon. Why Win7 and not Win2008? The reason is that my ATSC card (an AverTVHD Duet) doesn't have drivers for 2008, and I don't need a domain controller for my house anyway. For the nettops, I have one in hand already, and wish to try installing them using PXE (just for the kicks).

I'll try to post some pictures and details over the coming weeks. They should roughly follow the 4 steps above.

Olivier

Yes, I'm still alive.

Not many posts lately huh?

My older blog, Technocrat-UX, consisted of a way for me to document quirks and techniques related to HP-UX, BladeSystems, and some other technologies. Technocrat-UX enjoyed some success as these were niche, but relevant, subjects.

That model doesn't fit well with The ex-sysadmin where I originally had the intention of documenting my new job as a systems architect. The main problem when designing IT architectures is that the ideas and diagrams that result of my efforts are not generic and reusable enough, thus not interesting. Furthermore, in a security perspective, a lot of work needs to be done to obfuscate the information - any information - before it is released. I can't, for instance, publish a networking topology just like that to the public.

Up until recently I did, however, have the intention of writing a paper and presentation documenting a reference architecture for IED event and measure collection following my 18 month experience with Cooper's products. But due to some restrictions, that has not been possible yet.

In the mean time I'm keeping the blog going with posts that I *think* could be interesting to sysadmins, architects and... ex-sysadmins.

O.

HP's Power Advisor

This morning I had to use HP's Power Advisor to estimate the load of small servers I need to deploy (DL360G7s). I remember using an older tool some years ago but this new one is much better. It's available here:
http://h18004.www1.hp.com/products/solutions/power/advisor-online/HPPowerAdvisor.html

Dealing with MFT servers: a systems architect versus systems administrator love story

In my past life as a system administrator, I once had to build from a ground up a secure MFT (managed file transfer) server. I've pulled it off by using the HP-UX infrastructure I was comfortable with, and built something from the ground up using OpenSSH. You wouldn't believe, however, how much tweaking had to be done to have the user accounts (which were stored in /etc/passwd and /etc/shadow) synchronized reliabily in a clustered system spanning two sites. It took me a few days to make sure everything was correct.

Now it is time to do it again at a new place. I have to design another highly-available MFT server that will be wedged between two DMZs, and besides supporting SFTP I want it to have an HTTPS-based, "drop box" feature for end-users do be able to upload files easily without needing an SFTP client. Oh, and by the way, I need it to be able to authenticate users with a Windows domain this time.

If I was still a sysadmin, I'd have to extend the first solution further by adding an Apache HTTPD server and some open-source file upload solution. Then, I'd have to find a solution *BOTH* for Apache and OpenSSH to authenticate users. OpenSSH would probably need to rely on PAM, and for Apache I don't have a clue. Yet no problema; I would just shrug and say I can do that, then spend a few days tying everything up. The end.

But, as a system architect, things don't work this way.

Why? Because I have to assume that there is no guarantee the sysadmin who will have to do the grunt work of building this up will be willing, or have enough experience, to install and configure a custom solution. And assuming he/she is willing to do it, I have to consider that each man-hour counts for serious dough within the frame of a project. With custom hacks like this, these can sum up to a lot of hours depending on whose desk the work falls on.

Therefore, I did what system architects do: I tried to pick a turnkey solution, and it will have to be shoved down the IT team's throat.

I always hated this when it happened before. Picture this: The architect goes on a golf course or whatever, and randomly picks a solution based on bullet points and checklist tables. Then the IT operations guy has to take whatever crappy, slow and expensive "enterprise" software the architect purchased at a pharaonic price, and make it work satisfactorily to fulfill a business need. More often than not, such lame software ends up in the garbage bin with the IT team developing its own in-house solution to patch things up.

As I've been on that side of the fence before, I try to do things differently to prevent this from happening. So when I technically can, I actually try out software before choosing it, when it's not too daunting for me to do so.

So back to the MFT. I went searching on the web and picked a market "enterprise" leader to try it out. Not only doesn't it support high availability easily, the software is clumsy and it took 30 minutes to run its installshield sequence on a Windows 2008 VM. Uninstalling took the same. And to have SFTP support, I actually had to pay a premium over the base price. Not good.

Few other vendors had solutions that seemed serious enough, though. By serious I mean that they have to offer technical support, and have some agility in dealing with enteprise customers. Then a colleague of mine found out a very elegant software named JSCAPE MFT Server. Installation is a snap and it's very easy to configure. I was up and running in a few minutes. And as a bonus, its feature set is actually useful and seems to have been designed based on user requests instead of some odd crystal ball. I've been trying it this morning and up to now, it works very well.

The MFT server itself works on Windows, Linux, some Unices and Mac OS X. Installing the RPM went without any problem on CentOS 6. It is managed by a Java-based GUI that I installed on Windows -- I wasn't fond of using a thick-client when compared to a web-based administration GUI, but their GUI is efficient and interface-rich without being clumsy. No bells and whistles, and it is fine that way.

The Java-based "Server Manager" does the job efficiently

Enabling the web-based transfer option was quick and easy to do. What helps is that the software comes with a manual that, without being too detailed, provides lots of screenshots and cookbook-like procedures to configure the server quickly. It took me maybe a minute or so to enable the web server, set up LDAP-based authentication, add a dummy user, and try it out.

The resulting web service might be bland but it does the job, once again no fireworks. This is very important as it will be deployed to users who might not always be too tech-savvy.

The web-based service might be simple, that's exactly what I want

As a system administrator, I would actually want to work with software like this because it's elegant. It does a few things, and it does it well. I like it when software feel natural, and everything works the first time without a glitch. As in every software, I'm sure there are some bugs somewhere, but it sure is a good start.

Is JSCAPE MFT Server, the iPod of MFT's? I'd say it's not far from it. Chances are that if my project is greenlit, I'll be the first in line to purchase it. Whoever wrote this, good work!

O.

Interesting thread on Slashdot

Sysadmins and developers aren't the same, but they both share a strong technical background.

I suggest you read this thread. The first comment named "Stay Put" might be hilarious, it makes a lot of sense.

http://ask.slashdot.org/story/11/08/12/1433239/Ask-Slashdot-Am-I-Too-Old-To-Learn-New-Programming-Languages

The ex-sysadmin I am often asks himself if moving up was a good decision. It turns out it might be after all.

A presentation on IMS and PI might be coming

After a hiatus in 2010 due to a career change, it's now time to start writing papers and building presentations again. I'll be submitting a paper for Cooper EAS's 2011 Smart Grid conference which will consist of my experience with a major Yukon IMS deployment I've been involved with as an IT architect. I'll also explain how we used the SMP gateway to link substations to the OSISoft PI data historian in order to collect critical data.

I'm not in academia so my work is in no way scientific. Furthermore, I'm part of a huge team which counts a fair share of people from IT operations, control engineering and electrical engineering, so my view is mostly IT-centric.

There are many air travel restrictions at the office so I hope I'll be able to make it. The worst case scenario would be driving from Montreal to Minneapolis for which, if it's any consolation, won't require a full body scan.

O.

Forcing laptop users to use only an Iron Key (and nothing else)

I need to transfer files between two networks which need to be physically isolated for a few months until a beefed up and permanent security solution becomes possible.

The easiest way to do this on a budget consists of using USB keys to transfer files between two laptops, one which is connected on the intranet, the other on the secure network. If course, the "secure" laptop must be stripped to the bone and have an up-to-date Antivirus so it can trap known viruses that are currently in the wild. That won't prevent any new virus from coming in, but there is an urgent business need to transfer these files so there is not much that can be done in the short term.

I'm currently using IronKeys to ensure the integrity of the data, and also to prevent any data theft if a key is ever stolen. However, one must "encourage" end-users to use these keys, else they might end up using whatever key they lay their hands on to prevent having to enter a password.

On Windows XP, there is no way to do USB key filtering based on the key manufacturer. IronKey has a partner named DeviceLock that they suggest, but being a commercial product, it comes with a price. There are many other endpoint security tools that can be purchased to offer similar functionality, too. In my case, I was in a deadline and had missed the opportunity acquire software and charge it to the project, so it was preferable to use something free as a stopgap measure.

This afternoon, I've been making a few tests with USBSecure. It SEEMS to be free. There is no license, but all code is published so it can be tweaked if necessary. USBSecure is simple to configure: define users that use the computer, and whitelist the device IDs that are allowed on the system. I've been making a few tests for an hour or so, and it seems to work correctly. I might come back and give more details later.

Of course, transferring files between two adjacent PCs might look clumsy. But there are a lot of (justified) restrictions on secure control networks. What is sad is that that Stuxnet worked exactly this way, by propagating using USB keys. No matter how much we try to control their usage using endpoint security software, USB keys still remain a vector of infection for secure networks. Better long-term solutions must be done to ensure that any file transferred on a secure network is, indeed, clean. I'll be working on such solutions in 2011-2012.

O.