My biggest problem with Linux

For one of my wonderful classes, Internet Security, I'm doing a presentation on "patch management". While I'm obligated to cover Windows - and, of course, will talk about MacOS - I'll obviously be spending a good deal of time on the Unix/Linux side of things. This has gotten me thinking about one of my biggest problems with Linux (and specifically OpenSuSE, my usual default distro. Patch management is utterly awful.

Here's the problem: I have about a dozen machines under my control. I need to keep them all up-to-date. Currently, I manually do patches and upgrades via YaST or zypper. I thought about scripting this through zypper, but that doesn't make any sense - the packages on the machines are far from homogenous, so there's no clear way to make one script that updates them all. I considered using Puppet or CFengine or something of that sort, but that's too heavy-weight for me - for only a dozen machines, many of which are personal or development only, that's a lot to keep track of by hand, and a lot of work defining which patches should be applied, and which machines shouldn't be changed.

My other peeve is distribution upgrades. About three of my machines are still running OpenSuSE 10.0 or 10.1, both of which are unsupported, and no longer even have downloads available. Why? Becuase I've done major OpenSuSE upgrades before, broken a LOT of stuff, and I simply can't risk that on machines that can't stand extended downtime. This process *needs* to be made easier. Bottom line - it should be made no more difficult or unreliable than a kernel upgrade. IMHO, the biggest selling point for Solaris is its' ability to do a total upgrade to a second partition, and switch-over at runtime. Why doesn't Linux (or SuSE) have this yet?

What's my ideal solution? A curses application that uses text-file backends (curses so I can run it over SSH even if I have a slow link or high latency, like from a SSH session on my cell phone, if need be). The app would allow me to list all of the machines I want managed. It would connect to the machines over standard SSH, and would leave an extensive audit trail of what's done, both on the management console and on the machines (as well as running as a dedicated user). The application would maintain an inventory of all of the packages on every machine. It would check daily for new patches/updates to any of those packages, and e-mail me a daily summary of what's new, including all dependency changes, and which machines need the update. It would also allow me to define, on a per-machine (or per-group-of-machines) basis, rules for packages that must stay at their current version - i.e. I have a bunch of PHP4 apps, so machine X needs to stay at PHP4. The e-mail summary would include any packages that aren't going to be updated for a specific machine because of dependency/version rules, as well as warnings about any new packages that have a dependency that has a rule set. I could then run the main curses app on my admin machine and, starting from NO selections, select which updates I want to apply and whether I want to ignore or create new rules to keep something at its current version, on a per-machine or per-group basis. This curses app would generate a file (XML?) of what to do (which would also be generated or edited by hand, easily). The XML file would then be fed into a script that downloads all of the needed packages to a central (local) mirror (or, optionally, for remote machines, has them download locally on the machine), checksums them, and then installs them (running commands over SSH) on all applicable machines. It would then keep a log of all changes, both on each machine changed (in a master changelog file) and on the central administrative machine. Most importantly, the curses interface would have a simple, quick way to back out any specific update or group of updates for all machines, a group of machines, or one machine. All data needed to back out a change would be kept on each machine (say, cleaned up at the next update of that package and all of its' dependencies) with machine-readable instructions kept in a central file, allowing local rollbacks - i.e. a machine goes down, I realize that it was because of an update to package X, and on the local machine I can check the changelog, see an entry like "Package X updated 1.0.0 to 1.0.1 on yyyy-mm-dd, Change ID 1234" and then, to rollback, simply issue a command like "patchmgt rollback 1234" on the effected machine.

Just some ideas, and a little rant.

eeePC stronger than ever

It seems like every time I open up my Google Reader account, there's news about another company that released a knock-off of my beloved Asus eeePC 4G Surf (701) (interestingly, it looks like eeepc.asus.com is down at the moment of writing). Even Asus has released numerous (I think the product like is now up to about 10 variations) follow-ups to the 7" beauty, now up to 10" in size (though, admittedly, I'm less-than-enthused about their Windows models).

With the new semester here, I am (unfortunately) back in class. And I'm very happy to report that I'm starting to see eeePCs in more and more hands. Granted, my classes are in the IT program, but I was quite surprised last night to be sitting in my Internet Security class and notice no less than four eeePCs in a class of about 25 people. While I've just relegated my own 4G to my server room bag, replacing it with a (used, surplus from work) IBM ThinkPad T41 (14.1" display, 1.4GHz Pentium, 768MB RAM, and a DVD drive). Though my heart sank when I found that half of the eeePCs were running Windows, it seems that in my travels around campus, I'm seeing more and more eeePCs, and more laptops running Linux.

While the academic world has surely embraced new technologies, and non-mainstream technologies, quicker than other sectors (specifically considering Linux and the apparent popularity of the eeePC), it's definitely a good omen. Seeing non-geek, and perhaps even non-CS and non-Engineering, students using Linux speaks quite well for the expansion of the Linux user base when these students graduate and enter the "real world"

LIRC and Hauppauge PVR-150 on OpenSuSE 11.0

Well, despite what's been said elsewhere, it IS possible! It's a bit error-ridden at first, but here is the procedure that I used to compile and install the PVR-150 patched LIRC 0.8.3-CVS.

First, Download the tarball mentioned in the Version 3 blog post at Marks Braindump. You can pretty much follow his instructions on the installation in the blog post, with some changes that are specific to getting it to compile on OpenSuSE 11.

1. First, remove all traces of the OpenSuSE LIRC from you system. Uninstall the RPMS and everything else that goes with them. Then unload all of the kernel modules, especially lirc_i2c (if you have it loaded).


2. In your kernel source directory, run make oldconfig && make prepare.


3. In your kernel source directory, run make prepare scripts which, among other things, compiles the required genksyms scurript.


4. I was getting a compile error like "WARNING: Symbol version dump /usr/src/`uname -r`/Module.symvers is missing". Find out which kernel you're running (uname -r). In yout kernel source directory, copy your Module.symvers file from /usr/src/linux-obj. I was running i386 architecture with the "default" kernel, so mine was located at /usr/src/linux-obj/i386/debug/Module.symvers. Copy that into /usr/src/linux.
   
5. In the lirc (patched) directory, run setup.sh as instructed. DO NOT tell it to run configure - just save settings and exit.


6. Edit the generated configure.sh file, adding a --with-kerneldir=/usr/src/KERNELDIR, replacing KERNELDIR with the actual path to your kernel soruce (i.e. /usr/src/`uname -r`).


7. make. If no errors, make install.


8. I decided to reboot at this point, and when I did, everything worked perfectly.

Also, I found that I needed to explicitly specify --device=/dev/lirc0 when starting LIRC, as well as not specifying a driver. I just took the /etc/init.d/lirc from the official OpenSuSE 11.0 package, commented out line 108 in makeargs() that adds the -H $LIRC_DRIVER to the args, and added LIRC_DEVICE="/dev/lirc0" to the top after the INIT info.

Unfortunately, figuring out this process took me a long time. I've reconstructed these instructions from various post-it notes, the whiteboard next to my desk, and some bash history files and terminal dumps. If this doesn't seem to work for you, please drop an email to jason AT jason antman DOT com, with as much information as you have, and I'll figure it out and update the instructions.

Now, finally, an up-to-date system AND MythTV.

Linux, Choice, Updates, CitiBank issues

I know this blog has been less-than-active lately. Life has been pretty busy, between a massive network upgrade at the ambulance corps that I volunteer with, the impending doom of a new semester at work, scheduling courses, and a few personal projects. I do, however, have a long list of things to post, including some notes on my upgrade to Nagios 3, my recent experience with the PC Engines ALIX board, some changes to tuxOstat, and my plans to upgrade to Optimum Business cable with 5 static IPs - finally a real home for JasonAntman.com.

CitiCards Problems - I had a somewhat unnerving experience this morning. Having just gotten a Citibank credit card, and made my first few purchases on it, I browsed to CitiCards.com to check my account summary. I happened to be using a just-purchased IBM T41 laptop, running OpenSuSE 11.0 and FireFox3, so when I saw the page display and then go completely blank, I suspected a problem with my Flash plugin. Little did I know, but I tried the same page on 3 other Linux/Firefox machines, with the same result. I put in a call to the tech support line, and was gruffly informed by the representative that Firefox was not supported, they were unable to support it, and, to paraphrase, I should get another browser or f*** off. She was very well-aware of the issue, and stated that Citi would not fix it. At this point, I stated that I thought I would cancel my card, and she told me to have a nice day and hung up.

I decided to go to step 2 of the Generic Problem Solving Method, and found hundreds of references to a problem with CitiCards.com on Linux. I read through a lot of conspiracy theory, but decided to test one of the theories (and fixes). Sure enough, when I right-clicked on the blank white screen, I got a Flash context menu. Clicking "Play" showed the ad, and I was able to click the little "X" in the top right and bypass it, gaining access to the normal main page. Never to be one to ignore a conspiracy (or anti-Linux) theory, I pulled up the same page on a Mac. Sure enough, that particular ad (set not to play and with an opaque full-screen background) didn't show up. Hmm... maybe there's something to the theory put forth by the guy who said CitiBank is blocking Linux users.

I decided to call back, and this time spoke with Susan at CitiCards tech support. She was very understanding, and apologized for both the inconvenience and the previous representative's attitude. She said that she was aware of some issues with Firefox and Linux, but stated that they are only unsupported so far as Tech Support won't walk a customer using Linux or FireFox through any issue resolution, but that both the browser and architecture should, theoretically, work. She didn't know anything about a policy against Linux, or intentional blocking/sabotage. She did say, however, that they are "working on it". I did inform her that the problem could probably be resolved by simply editing the Flash ad to be properly transparent, or suppressing it for Linux architectures, though I doubt that the information will make its' way up the food chain. Unfortunately, I can't seem to find a contact email for anything site-related on CitiCards.com.

If this is really a case of intentional blocking, it would be quite infuriating - I filled out the application for the card on FireFox3/Linux... but then they block account access?

Hopefully more of an update tonight...

Practical PHP and MySQL

I'm taking a summer course in Building Data Driven Websites - not that I thought I'd learn much in such a course at SCILS, but I'd like to graduate on time, and need the credits, and Bill Crosbie is just the type of rare teacher that can keep even me awake and interested. Our book is Practical PHP and MySQL: Building Eight Dynamic Web Applications (Amazon by Jono Bacon. Now, I know it's not a real book like, say, ESA3 by Frisch, which has a healthy web presense. But this thing is all code and doesn't even have a web site, let alone easy code downloads!

The book does come with a heavily customized Ubuntu LiveCD. However, when I popped it in my OpenSuSE workstation, I couldn't really make much out of the CD - there was certainly no easy-to-find "this is the code" directory. Well, after some exploring, I mounted the SquashFS filesystem and poked around a bit. Strange... seems to only have one real user (root) and, though they claim this is a fully-functional LAMP server, no Apache or MySQL. Really weird. Well, after poking for a few minutes, I found the holy grail - /root/.bash_history was intact! Just a quick look through it with less and I found what I was looking for: /opt/lampp. It appears that the install is actually ApacheFriends' LAMPP, or XAMPP for Linux (gotta wonder if the guy writing this book doesn't even know how to install Apache... I'm sure XAMPP for Linux is more bloated than a customized build of Apache/MySQL/PHP from source, especially since it's only being used to host 8 sample projects, so a lot could be left out).

Anyway, it appears that LAMPP is running in a chroot'ed environment. The actual sample code is rooted at /opt/lampp/htdocs/sites. It seems that all of the PHP files are also owned by root and chmod'ed 777! And the top-level index.php file makes use of absolute links, so obviously he never thought that someone may want to copy the sample code and use it on a real box.

I just can't imagine someone who's a beginner with Linux, let alone a Windows person, trying to get this source code onto a machine where they can actually play with it. And... to make the situation worse... the LiveCD has vi and vim, but no Emacs!!!! Eeeek!!

For anyone who needs it, I have the archive available on my site. For non-*nix people, you'll need Gzip or an equivalent program to extract it.

Update

I've been incredibly busy lately. But I have 2 quick updates-

1) tuxOstat, my thermostat project, isn't totally finished, but is up and running. There's still some work to do, but the code is largely complete, and in CVS. There's also a web interface with temperature graphs, system status, and a (horrible) webcam view of the LCD control panel. I'll probably be finishing up a first version this week, finishing the documentation next week, and releasing what I have soon.

I got an e-mail today about one of my older projects, PHP EMS Tools, a PHP/MySQL based application for fire/EMS agencies to handle scheduling, membership rosters, equipment checks, etc. The potential user was asking about running the software on Windows - which, of course, I have no experience with. I'm pretty sure there aren't many, if any, Unix-specific calls hidden in the code, and advised him to try XAMPP (Apache/MySQL on Windows). But I did take a moment to comment on why I chose Linux. My pilot installation of PHP EMS Tools, at the Midland Park Volunteer Ambulance Corps, where I've been a member since 2005, has been handling our scheduling, roster, and equipment checks since June 2006. It's running on a generation 1 Compaq Proliant DL380, running dual Pentium III 733MHz processors and 1GB memory - and even with a number of other programs on it, including ieilogd which is reading from the serial port 24x7 - the load average has never passed 1.2 and the memory usage is well under 50%. More importantly, the system has been up for 442 days without a hiccup!

New Project

Well, TuxTruck has been temporarily put on the back burner. I priced out the hardware, and it looks like a minimum of $1000, more like $1000 if I get what I had originally wanted. This is complicated by the fact that my roommates and I were just hit with a $220 electric bill. Mostly, that's due to the central air conditioning in our apartment, and the horrible inefficiencies with it.

Inefficient? Yes. At the moment, I'm the only person in the apartment. I'm home for the weekend from 18:00 Friday through about 15:00 Monday. I have class Monday-Thursday night 18:00-21:45. I work Tuesday-Friday 0900-1700. Even though the thermostat we have is "programmable", it can only be set for 4 time periods per day, weekdays and weekends. So, I figured that a little added efficiency in calculating when the A/C should run would go a long way towards energy savings.

My idea - tuxOstat - is to have a Linux box that has temperature sensors placed around the apartment, and a bank of relays to control the heating/cooling systems. So, even though I only got the idea last Thursday, version 1 should be up and running next week.

In terms of hardware:

1. Originally I had planned on using a Soekris net4526 that I had lying around. However, the added cost of a MiniPCI USB card seemed prohibitive for a one-off project. Instead, I'm using an old HP OmniBook laptop that was already lying behind my servers. It's running Debian 4.0.
2. I've ordered (just 15 minutes ago) a Phidgets InterfaceKit 0/0/4, which connects via USB and provides 4 relays. One will control the fan, one for the A/C compressor, one for the heat, and one unused (for now).
3. I already had a DS9490 Dallas 1-wire USB adapter from Hobby-Boards.com along with five DS18S20P 1-wire parasite power temperature sensors. I've wired those up with one in the living room near the existing thermostat, one in my bedroom, and one stuck about five feet up one of the A/C conduits, to sense when the system is actually putting out cold air. I've had them logging to MySQL since 0200 today.
4. I decided to bite the bullet and order a beautiful CrystalFontz XES635BK-TMF-KU for the physical interface. It's a little backlit LCD display, in a surface-mount box, along with four bi-color LEDs and a 6-button keypad. That should handle the interface for anyone who doesn't want to grab a console.
5. I'll be looking for a eight-pin header so that the relays will plug right in to the screw-terminal block that the thermostat uses, to make for easy switching to the original thermostat if needed (or when moving out in a year).

Now, in terms of software:

1. A Python text-based configuration/administration program. Will be accessed via SSH or KVM for the actual machine.
2. Lots of state data stored in files under /var.
3. A python script, run via cron every 2 minutes, that checks temperatures from the 1-wire bus, logs them to MySQL (on a remote host) and updates the temperature files in /var.
4. A master control script, run via cron every minute, that looks at the temperatures, the current system state, any manual overrides that exist, and decides what relays should be on or off.
5. A daemon to handle relay control.
6. A daemon to handle the LCD display output and keypad input (including immediate manual overrides).
7. A method of providing overrides of the programmed schedule on a single-instance basis, i.e. "system completely off from 2008-06-06 18:00 to 2008-06-08 15:00".
   

Getting SunSPOTs working under OpenSuSE 10.1

So I've been playing around with SunSPOTs lately. Or trying to. My only x86 (32-bit) machines are an old desktop running OpenSuSE 10.1 and my eeePC. It looks like I just killed my new install on the 8GB SDHC card, so I gave the desktop a try. I'd already tried once with the install of Orange from the CD that came with them, and had NetBeans 6 installed, so I had to do some recovery. The procedure was as follows:

1. Install all of the Java6 java-sun packages (specifically the base as devel).
2. Download the Java 6 JDK from Sun, and install all of the RPMs.
3. Screw with /usr/lib/jvm and get it sane - specifically, replace all of the symlinks that point to /etc/alternatives with new ones pointing to the Java6 install in /usr/lib/jvm/java-1.6.0-sun-1.6.0
4. Delete your entire .netbeans directory (I was having serious issues with NetBeans).
5. Start NetBeans from the command line with an explicitly set jdkhome: "netbeans --jdkhome /usr/lib/jvm/java-1.6.0-sun-1.6.0
6. Download the SPOT plugin for NetBeans, following the instructions on Bruno Ghisi's blog.
7. Once installed, you should have a little SPOT-looking icon on the toolbar below "Navigate". Click on it, and launch SPOTManager from the link in the right panel ("Sun SPOTs Info", the link is an icon not text). Go through whatever configuration is needed.
   
8. Upgrade local SDK to Purple (Click the SDK tab, select "v3.0 Purple" from the right panel, click the Upgrade button near the bottom).
9. Upgrade your demos following davidgs's blog posting.
   
10. Upgrade all of the SPOTs to Purple (plug them in one at a time, on the SPOTManager SunSPOTs tab, click "Upgrade").
11. I'm still having some minor issues here. I'll update when I have everything figured out...
    

SunSPOT; CarPC; MediaWiki Logging

Well, finals season is upon me. That's probably why I haven't been posting much lately (I haven't even been checking Google Reader - I'll have to delete a few thousand entries when I get back into the swing of things). I've been pretty busy, between studying, projects, and work. I'll be working 4 days a week through June 20th, as well as taking night classes 4 nigths a week (unfortunately not the same 4 days) through July 3, in an effort to graduate Rutgers on time (after transferring in and also switching majors). Work after June 20th is up in the air - who knows how hard the budget cuts will hit.

My internship as the Sun Microsystems Campus Ambassador to Rutgers is over on May 12th. I got a chance to do the Rutgers IT Vendor Fair with Sun, and met a few cool people - especially including Matt McGrath of Continental Resources, a Sun Strategic iForce Partner, who's doing some wonderful things with the Sun Education Essentials Matching Grant Program, and Skip Paul, a Linux Systems Engineer for Novell's Open Platform Solutions group. I also finally cracked open my demo set of SunSPOTs. Wonderful little devices, radio, run Java on the bare metal, and have temperature sensors, accelerometers, and liberal I/O. My first development exereice will probably be making a temperature and acceleration data logger for my truck, but there's surely more to come. They're great!

My newest project - which I'm hoping to spend nearly the whole summer on - is the TuxTruck. I've been frustrated with the lack of "smartness" in my truck (an 06 Ford F-250), not to mention having to remember my MP3 player so I can listen to podcasts on the way to work, and having so many gadgets in my truck. So, the solution is obvious: a Linux-based CarPC. A nice little Mini-ATX box under a seat, with a 7" pull-out touchscreen in the dash (replacing the factory radio). It's a big, complicated, and expensive project - but I want one, and I could use some experience with smaller systems.
The major features I have planned:

1. Realtime GPS navigation
2. Hands-free bluetooth calls from my cell, with address book, routing to contact address, possibly voice dialing.
3. Realtime weather
4. OBD-II interface, for vehicle diagnostics and fuel efficiency/performance profiling
5. Audio - at a minimum searching and playing MP3s, and automatically downloading podcasts and throwing them in a playlist. Perhaps also an AM/FM tuner

It's not an easy project. So far, the major challenges seem to be:

• No full-featured GPS navigation package available. The ones that are available don't seem to be too easy to integrate into my planned GUI, which will allot them 800x420 pixels (on an 800x480 screen) and requre the bottom toolbar to be always available.
• How to handle processing of multiple data streams that require near-real-time processing - specifically, GPS with text-to-speech, turn-by-turn directions, plus playing audio, plus responding to an incoming phone call in a timely manner, pausing the audio, and stopping GPS audio but continuing navigation.
• Whether to install a smaller stereo and use aux input for audio, or totally rip out the stereo, use an amp with the computer as its only input, and then how to control volume?

There will be more to come in the future. For now, check out the wiki, or have a look through CVS. My current leading candidate for the GUI is coded in wxPython (Python and wxWidgets). You can take a peek at the current code (development - may be buggy) through ViewVC or just download a tarball.

Mediawiki Logging - I recently had a situation where I had to confirm how much work someone had done on a MediaWiki-based project. The Recent Changes page only goes back 30 days, and walking through the History of each page is a pain. After looking around in the database a bit, I found a few tables of interest:

• Table "users" includes fields "user_touched" (last time the user was updated) and "user_editcount" (a really simple count of the users' number of edits).

• Table "recentchanges" holds a lot of data... seemingly the entire life of the wiki

Asus eeePC Update

More to come sometime this week, when I have enough sanity and time to write.

In the mean time...

So it's been two weeks since classes started again, and that means two weeks using my now-beloved eeePC 4G Surf (details in a previous post). Granted, I have my "desktop replacement" laptop (a Linux Certified LC2464) to use at my desk at home or at my apartment - though the "desktop replacement" really means that it's easy to move from one desk to another.

So far, I really love it, but I have a few issues:

1. I should have bought an 8GB SDHC card instead of the 4GB that I got - especially with a full install of OpenSuSE with Sun's JDK and OpenOffice, the 2GB root partition is 99% full!
2. After using a desktop for hours, it takes a few lines of text for my fingers to re-adjust to the small keyboard. Hopefully it'll get easier with time.
3. Unfortunately, I don't have space for kernel headers or source, so I can't compile the customized version of asus_acpi. I can't find any binary packges, or binary kernel modules for my kernel version. That prevents me from using sleep/hibernate/suspend, and also means I don't get accurate battery calculations. I've found from usage that the battery lasts 2-3 hours with wireless on and minimal screen brightness. Also, unfortunately, (maybe because of the ACPI issue?) if I dim the screen and then the screensaver comes on, when I log back in it resets to full brightness.
   
4. As of this week, there's still no MadWifi driver for the Atheros card in the 4G. I have to run it under Ndiswrapper. As a result, I can't get monitor mode, so the eee is effectively useless for wireless site surveys and security work. There's talk of a forthcoming MadWifi, but if nothing shows up, I may have to go with a USB adapter (I don't want to void the warranty by swapping out the internal Mini-PCI adapter).
5. Not a problem with the eeePC, but it seems like quite a few web sites that I've visited are horribly coded - with static screen sizes assumed. On the small screen on the eee, the biggest issue is when the first few characters of every line on some sites are cut off, thereby rendering the content illegible. This is an issue out of Asus' control, but can be a hindrance to full use. I have, however, found that for many sites, switching FF to "full screen" mode (F11) helps.

Stay tuned for more, and some new scripts to automate wireless surveys, rogue AP detection, etc. And maybe even some work with autonomics and or configuration tools.

*nix

First off, my Sun blog should be coming sometime this weekend/early next week. If I post anything interesting there, I'll be sure to cross-post it.
This morning at work, while reading Digg, I came by two interesting links that got me thinking:
5 Reasons Your Parents Should Use Linux and Ten Things Linux Distros Get Right (That MS Doesn't).
Now, I'll admit, my *nix experience is pretty much limited to Linux. I've used BSD a few times, but only as pre-built images for embedded systems like my Soekris boxen. I've used Solaris mainly just as a user/web developer in SSH at work. And while I now have a work computer running Solaris 10 and a SXDE image on my laptop, I'm still relatively new - and, given that I'm now doing hardware support and wireless work, I don't even know what I need another machine in the office for.
That being said, the second link got me thinking. Specifically, about something I read in The Art of Unix Programming [Wikipedia] by Eric S. Raymond (available online here) with regards to interface design. One quote that I was able to find in the online version, comes from Chapter 11, under the subtitle "Tradeoffs between CLI and Visual Interfaces",
"Resistance to CLI interfaces tends to decrease as users become more expert. In many problem domains, users (especially frequent users) reach a crossover point at which the concision and expressiveness of CLI becomes more valuable than avoiding its mnemonic load. Thus, for example, computing novices prefer the ease of GUI desktops, but experienced users often gradually discover that they prefer typing commands to a shell."
There is another similar quote in the book, mentioning how resistance to the CLI drops as typing speed increases.
Unfortunately, in some areas I'm still bound to Windows. Though my only personal use for it is to control an ancient Umax Mirage IIse SCSI scanner (with only Windows and Mac drivers), I ultimately need to touch it now and then - whether on my mother's box (she claims she has to have Windows and MS Office because "that's what businesses use") or as admin of the four boxes at the Ambulance Corps where I volunteer.
However, whenever I am (unfortunately) pushed into the task of working on a Windows box, I always feel something lacking. To be blunt, I don't see how experienced users can deal with it. And this isn't just an issue of multiple desktops, or reliability (I expect my desktop to have months of uptime, and my servers to have years). This isn't just pro-Linux, it's anti-Windows. Linux is great. Solaris seems wonderful, and I can't want to move my servers over. And, believe it or not, due to playing around with the Solaris Management Console, for the first time in 5 years, I plan on running X on my servers.
What this is, is a talk about total workflow. Years ago, I reached the point where I am more comfortable at the command line, or in an Ncurses-style GUI, than in X.
I an attribute this to two factors - verbosity and speed. The CLI is as verbose as anything can get. I remember setting a static IP on a Windows box. I had to navigate the Start menu, open up the control panel, the network thingy, click on the network card, and work through a series of dialogs. In Linux, I clicked on the terminal icon, typed "sudo ifconfig eth0 up 192.168.0.211" and then a password. Done. Likewise, refreshing a DHCP lease on Windows requires a whole bunch of "repair connection" nonsense, whereas in Linux all it requires is "dhclient eth0". The bottom line I know what I'm doing. Windows should have an option to let me quickly do it.
Speed is a related issue. Click, click-click, drag, click, click.... what about just typing? Even for people who aren't CLI-friendly, there's Ncurses. YaST2, the SuSE/openSuSE administration tool, has both GUI and Ncurses interfaces. I always use the Ncurses interface. Why? Because I've been using it for years. I know that if I want to add a user through YaST, I hit the down arrow 7 times, tab once, down 5, enter. Tab once more to bring up the add user dialog. I can do this in well under a second. What's the bottom line? Well, first of all, my hands are already on the keyboard. That's where they like to stay. That's where they're comfortable. My fingers need to move a *lot* less to navigate with the arrow keys, tab, and enter than they do to use a mouse. If you know what you're doing, if you already know what you're looking for, then a mouse is slower than the speed of thought (or reaction).
So where's the Windows bashing? Simple. How do people at Microsoft deal with this? How does the guy who *wrote* that network settings dialog deal with navigating the GUI every time, even though he already knows exactly what he wants to do - and probably the system calls to do it?
The bottom line is that every time I sit down at a Windows machine, I wonder how the most popular OS is one that doesn't give any thought to advanced users. I know that I can type faster than I can move a mouse, why don't you let me use that? More importantly, why didn't Microsoft ever think that people would use computers on a network? When I installed Solaris, I wanted to edit a config file. I hadn't customized *anything* yet, hadn't installed any other software, nothing. Yet, I was able to open up a terminal and grab my .emacs file from my laptop in one line (scp).
To be totally honest, the question running through my mind is something like "everything is so much quicker on Linux. How do experts deal with Windows?"

Update

I haven't been too active on here lately, mainly due to spending my summer as a paid transport EMT, working 50 hours a week or so, and still trying to keep up on "life".

I have a few things planned for the next month or so of summer, so stay tuned. Some of them include:

• Redesign of my site including lots of information that's been stored away in text files, and a new wiki for technical information.
  
• Some embedded development work, and notes on that.
  
• Converting some sort of low-cost handheld computer, tablet, or eBook reader for use as a Linux-based RSS reader (updated over LAN nightly and cached locally), hopefully including an image of my software as well as some conduit to an RSS reader program, and ability to email a list of "flagged" articles on sync (RSS update over network).
  
• A vast update of my Code Repo with most of my home-grown F/OSS programs, including my (very basic) web-based budget/finance program.
  
• An update to PHP EMS Tools
  
• Notes on my experience with MythTV, an integrating it with IR controls, Cablevision SA set-top box, and ultimately a "smart room".
  
• My never-ending quest to find a way to interface a CDMA handset to a computer for purposes of sending SMS from the command line (Nagios out-of-band alerts on a budget).
  
• A trial run of Asterisk and VoIP from the house to the dorm.
  
• Some more projects including:
  
  
  
  • Finding and implementing a hardware/software trouble- and change-tracking system, which will also integrate with my Wiki.
    
  • Choosing bug tracking software for my internal projects.
    
  • Choosing and implementing a network-wide backup system to handle *nix, Windows, and my remote *nix machines.
    
  • OpenSolaris.
    
  • Figuring out a system to handle automated nightly/weekly tasks on my diverse machines including log analysis, backups, software updates, and the usual stuff (SpamAssassin updates and training and other routine tasks).
    
  • A status tracker/to-do list of my numerous projects.
    
  • Releasing most of my web-based kludges under GPL for anyone who may be interested.
    
  
  
  

Managing G1 Proliant Servers with modern Linux

Not much of an "upgrade" for anyone who's in IT, but jasonantman.com is currently being upgraded from old desktops used as servers to a pile of generation-1 (G1) HP/Compaq Proliants. I know that there are utilities for Linux to manage the servers, specifically control fan speed and monitor hardware-level health for Linux. However, the most recent download on HP's site is for SLES9. All of my boxes will be running openSuSE 10.2, and the SLES9 version wouldn't install on them.

After an hour long phone call to HP support, I ended up speaking with Paulo, the third support person I was transferred to. #1 read off the web site, #2 knew what Linux was, but Paulo (#3) actually told me that he was experimenting with installing HPASM (HP's server administration/management utility) on an older Proliant as well. He spent about half an hour walking me through it. Here's what I found:

The most compatible version of HPASM (I guess it's some hidden feature for people who know it) is the version for the DL380 G4. Paulo instructed me to download this RPM from their site. I did, choosing the SLES10 (x86) download (hpasm-7.7.0-115.sles10.i586.rpm). This installed fine. Running hpasm status from the command line asks us to activate it first. Do the activation. Now, running hpasm status still asks us to activate. Paulo confirmed this as happening on his machine too. Try /etc/init.d/hpasm status and you should see that all of the modules are working.

Now, the install is complete. I'm not sure if the SNMP works, but it should as long as your snmpd is running. The hpasm activate command modifies snmpd.conf appropriately. and you will be queried for the currect configuration information.

To give it a test, run hplog -f or hplog -p and you should see fan and power status, respectively.

Paulo also told me that I could download the hpadu package (also DL380 G4 / SLES10) to get array diagnostics, He warned me that some of the install scripts in HPADU look for the web management homepage, which we haven't installed. To get around this, install the HPADU RPM file (hpadu-7.70-12.linux.rpm) rpm -ivh --force --nodeps --noscripts hpadu-7.70-12.linux.rpm. Be aware, though, that this package is supposed to be web-based. It installs to /opt/hp/hpadu.

The web interface, luckily for me, is written in PHP. It is pretty complex so it might take me a while to figure out the workings, but when I do, I'll post as much info as I can on how to make a CLI interface, or where one exists if I can find it.

Also, I'll most likely develop a Python check script to use with Nagios to monitor most of the hpasm-enabled components.

For the use of anyone else, here are some of the links that HP Support sent me after the call:


Link for users guide for Proliant Support Pack, which includes documentation on HPASM from the CLI:

http://h18000.www1.hp.com/support/files/server/us/WebDoc/720/psp-users-guide.pdf


Product manuals:

http://h20180.www2.hp.com/apps/Nav?h_pagetype=s-003&h_lang=en&h_cc=us&h_product=241435&h_page=hpcom&h_client=z-a-r1002-3&cc=us&lang=en


ML370 G1

http://h20000.www2.hp.com/bc/docs/support/UCR/SupportManual/TPM_143091-004/TPM_143091-004.pdf

Why hasn't Linux caught up to Windows?

Those of us who are involved in the Linux community are often frustrated by the lack of widespread acceptance of Linux. Granted, I haven't used all of the newest "desktop" distributions ('distros'), but I know that my choice - openSuSE - is far from being ready to compete with Windows for the novice user market. From the first few screens of the installation, it's clear that this isn't something for the uninitiated. However, to get off on a short tangent, openSuSE has also severely hampered access to the command-line-only, text-mode installation, which I need in order to install on many of my servers.

Granted, it will take a lot of work to get Linux to retain its' strong points, and still be user-friendly for the non-technical user. However, there are three main points that I see as being the biggest problems for new users. All of which, coincidentally, are ones which some people would bill as strong points of Linux. And they all have to do directly with some of the founding principles of Linux - interoperability and choice.

A) Packaging.
Searching for a package for a linux system goes something like this: figure out what package format your distro uses, figure out the distro version and architecture, and then start checking the online repositories. If it's something simple, you may be able to use a you distro-specific maintenance program to automatically upgrade it. If not, you can sift through the myriad online repositories for packages that fit your package manager (RPM, Apt, etc.) and your distro/architecture. If you have no luck there, find the package's homepage, and hope someone has contributed packages for your distro and architecture - usually a hit-or-miss situation. Last but not least, when all else has failed, you choose either to compile from source yourself, or give up. Compiling from source not only requires some knowledge of your system, Linux, and the compilation sequence used by the software - hopefully the generic GNU-style ./configure, make, make install and not some more esoteric scheme. Furthermore, compilation requires a whole slew of tools to be installed on your system - make, gcc, autoconf, and may others, depending on package. While it's not practical for people with limited resources, homogenous environments, or novice users, I operate in a largely heterogeneous environment - i586/compatible systems running SuSE 9.3-10.2 - and therefore maintain a dedicated system for compilation, if merited.

All of this complexity just enforces the novice's idea that there is not much software available for Linux, as many novices are limited (due to technical knowledge) to the packages that come with their OS.

While there are a few schemes to standardize all of this, the real solution is quite complex, and would be based on a single package system to be adopted by all distros (beginning with the main ones). Such a system should have the following features:
1) Ability to work easily with all distros
2) I main configuration file which can define which directories to use - i.e. /etc, /bin, etc.
3) Support for both simple, novice-oriented interfaces and expert-level configuration
4) Multiple interfaces, including command-line, text/ncurses, GTK, and other graphical subsystems
5) A generalized package format that is non-distro-specific
6) Integration with an online master-list of repositories
7) Ability to search, download, and install packages from these repositories
8) Automatic update ability
9) Ability to mine the repositories for updates, and display a list on screen or emailed to a user account
10) Very good tools for easy compilation from source.

Some of these ideas would be incorporated in the tool itself, and some as add-on modules.

The features that I, as administrator of a largely heterogeneous network of about 10 machines, would most like to see are:
1) Truly automatic updates via list - select which packages can be automatically updated, and run a cron job nightly to check for any updates for those packages and automatically get and install them.
2) LAN-based updating - A single server on the LAN maintains a list (perhaps gathered via an automatic tool) of ALL packages installed on ALL LAN machines. Each night the configured clients will update this list over the network, and then the master server will download all available updates for all packages. Once this is complete, it will send a message to all LAN machines, which will then update their software from the central repository on the LAN. This would, in effect, automatically keep all LAN machines 1) on the same version of each package and 2) totally up-to-date.
Kernel updates would be done manually, but should have an option for the administrator to push the update to all machines.

B) Distro-specific tools, filesystem layout, etc.
This is not only a barrier for novice users, but experienced users as well. If you do a search online for Linux training, you will surely come by a nubmer of certifications - NCLE, RHCE, etc. The many distinct certifications - offered by each Linux vendor and independent training companies - underscore the inherent differences in Linux distributions. While I'm perfectly comfortable working with SuSE Linux (by Novell), if I was to sit down in front of a Gentoo system, I would probably be totally lost.

While the LSB project (http://www.linux-foundation.org/en/LSB) has aimed to provide compatibility between distros, there are three main points which must still be addressed:
1) The organization of filesystems on different distros, specifically the directory tree and default locations for certain components, still differs. In the interest of usability, the Linux directory tree should be standardized, so that locations of programs, files, etc. will be identical across distributions.
2) An effort needs to be made to make administration as similar as possible across all distros. This means that program names, functionality, location, etc. should be standardized as much as possible.
3) It seems that each distro has its' own administration tool - YaST for SuSE, and others for other distros. An effort needs to be made to develop a tool encompassing all of the features in one, distro-neutral form. Webmin (www.webmin.com) has done this wonderfully in a web-based interface, but attention should be focused on a text-mode console version as well.

C) GUI
Perhaps the biggest hurdle for novices using Linux, and the biggest development challenge, is general ease of use. While the above two points may fall into this category, I am specifically referring to the general, day-to-day use of the operating system.

While I will not begin to suggest solutions, the main problems that I see are as follows:
1) The stability and security of Linux must be kept intact, unlike distros such as Lindows.
2) There must remain a way for advanced users to perform advanced tasks.
3) As much of the inner workings should be hidden from the end-user as possible, unless specifically requested.
4) I good system would have a field added to a users' GECOS data specifying their level of "novice-ness" - i.e. allowing a dumbed-down interface for users while retaining a full interface with Expert features for those who want it.
5) "Mysterious" things such as file permissions should be hidden from novice-level users when not absolutely needed.
6) There must be a strong integration with "anti-mistake" tools and DWIM technology. The system itself should manage file permissions in a way that grants only the minimum needed access.
7) There should be good, strong mistake detection, specifically in terms of catching a user's inadvertent changing of file permissions, deleting required files, etc.
8) Tools should be built so that the novice user is never required to login as root or run a root shell.
9) Perhaps, and I'm sure this is controversial, the root account should be given either CLI-only access, or should not have X running by default, so as to discourage novice users from running day-to-day tasks as root.

I'm sure I've missed a lot, and have also probably mentioned a number of things that are already in place. However, the bottom line is that Linux has to be able to achieve the easy of use and interoperability (between distros) that Windows currently has, while retaining the extensibility, advanced features, security, and stability that make Linux what it is.