Stratus FT 4300 and RHEL, Part 3

Now down to some sysadmin hacking.

The object here is to create a custom software channel on our Red Hat Satellite server for Stratus' kernel rpm's for the ft 4300 and to make this as automatic as possible.
To see what I was getting into, I pulled down the rpm's from their repository at "http://pman3.com/ftLinux/4.0/redhat/." Basically they were just several debug kernels from Red Hat and yum. Nothing custom, nothing fancy, nothing numerous. I suppose Stratus wants the debug kernels available to help in troubleshooting issues.

A side note here: I have to laud Stratus' support. It is top notch, at least for VOS, their proprietary operating system.

Even though these rpm's are not critical to the operation of the ft4300 running RHEL, I decided to move ahead with the software channel.

First up, I wrote a bash script to pull down the rpms and push them into a software channel.

#!/bin/bash
#
# 5 Jul 2007 Jason B Consorti
# Rev 1.0

# Wget Options Explanation
# --no-verbose
# Quiet, but not TOO QUIET
# -e
# Use the following as if they were in a .wgetrc file.
# Used here to explicitly set the proxy server
# --no-clobber
# Don't bother downloading something we already have.
# --recursive
# Act like a crawler and grab everything
# -l 1
# Stop wget from moving about the website
# --no-directories
# Don't bother making a directory hierarchy; just put
# all grabbed files into one spot.
# --directory-prefix
# Put all of the retrieved files into /var/stratus
# --accept \*rpm
# We're only interested in pulling down rpm files.

/usr/bin/wget --no-verbose -e 'http_proxy = http://our.corporate.proxy.server' --no-clobber --recursive -l 1 --no-directories --directory-prefix=/var/stratus --accept \*rpm http://pman3.com/ftLinux/4.0/redhat/

# This find command will look in the /var/stratus directory for any recently
# downloaded rpms and will then push them into the Satellite server's
# software channel for our stratus boxes.
# A special user account set up for this purpose is used.


/usr/bin/find /var/stratus -mtime -1 -name \*rpm -exec /usr/bin/rhnpush --channel=stratus-yum-x86_64 --username=stratus --password=PASSWORD {} \;

I then created a user called "stratus" and a custom software channel called "stratus-yum-x86_64" and made it a child of RHEL AS 4 for x86_64 servers. I also gave the user "stratus" privileges to push to that channel.

I created the /var/stratus subdirectory and added this script to root's crontab.

# Daily pull of Stratus' YUM channel for RHEL 4
0 7 * * * /usr/local/bin/stratus_daily.sh >/dev/null 2>/dev/null


The script is a little kludgey: there are no locks and the find script is a cheap way out. I'll have to work on that later.

British style CCTV systems in the US

The recent attacks in Britain and the manner in which suspects were quickly rounded up, brought the attention of some news outlets to the UK's wide use of CCTV. I've seen some media exposure given to the question of not only whether the US should adopt a similar system but if such a measure would even be constitutional.

Let's set aside all arguments first as to whether the CCTV system was useful to the speedy apprehension of the suspected bombers. I can't foresee any reasonable argument to the contrary. Due to SCORES of years dealing with terrorism associated with the effort to unite Ireland, Britain seems to have very valuable experience in using law enforcement as a tool against terrorism. The CCTV system is but one consequence of this experience.

Concerns for a British style CCTV system on this side of the pond revolve around whether it would be a violation of American civil liberties. Indeed, this is a very valid concern.

Though I may not agree that a CCTV system that watches all public areas is a terrible intrusion into our right to privacy (a right interpreted by the Supreme Court as enshrined in the First Amendment, and therefore framed and even trumped by it), I in principle would not want a government bureaucrat overseeing such as system, especially with my tax dollars.

Could there be a way to have an effective CCTV system to aid law enforcement that would satisfy civil libertarians and fiscal conservatives? Possibly.

Today, there are cameras all over this nation; they are in ATM's, overseeing car lots, monitoring office buildings, in supermarkets, in malls and even private web cams. Often, law enforcement will ask for access to recorded tapes or even subpoena to have such access when investigating crimes.

Though these cameras are unconnected and, compared to the UK system, sparse, they are very useful to law enforcement. Imagine their usefulness with a system in place to expedite access to their content.

In this system, private owners of CCTV could work to link their content. Sophisticated software already exists that can cull license plate (sorry, in Jersey they're plates, not tags) numbers automatically. Is it hard to imagine software in the near future that can be given fuzzier directives like "find a white male, late 30's, in a red shirt?" In the search of suspects over a wide area, either by request of the police or maybe even the victim themselves, this could be a powerful tool.

What would be the incentive to be a part of such a network? Perhaps there would be an advertising advantage. Wouldn't a car dealer want to proudly proclaim their social conscience in being a part of a system that helped recover X number of abducted children per year? As with many things, the more popular this system would become, the more powerful it would be.

This system would have to be funded by its participants, so this "advertisement campaign" isn't free. The power of this "endorsement" would have to outweigh its cost to the participants. This is a deep flaw in my concept.

The advantage of this system goes beyond just the fiscal. It would also tussle less feathers by demonstrating that the government is not in control of this system and therefore it is not the government that would "violate" people's rights to privacy. Less people would object and more people would support such a system.

But as with all "majority rule" decisions, that doesn't make it automatically morale or right. The argument would still remain that peoples' rights to privacy were being violated.

This is where I remind myself that the right to privacy is not enumerated, but framed by the First Amendment. I agree that the reasonable expectation of privacy has its limitations when you step out your door and walk down the street.

There should be no difference between a human being staring at me from across the street and a web cam perched on a roof down the block tracking me. I'm not uncomfortable with either. If that creepy guy stood in my bushes to look in my window, or that web cam was behind a hole in a ceiling tile in a bathroom, then there would be hell to pay.

Tying together ATM and convenience store cameras is not such a strong intrusion into our lives such that I would object to such a scheme.

Stratus FT 4300 and RHEL, Part 2

Well, it turns out that the only packages needed by the ft 4300 are just the kernel. This means that Stratus' customizations to the inittab and sysinit scripts are done manually. That could be done better.

I am a fervent believer in using rpm's for just about everything. We use them to create sysadmin accounts. We use them to delete old sysadmin accounts. We use them to distribute ssh keys. We "strongly" encourage the application developers to deliver all packages as rpm's and have been relatively successful getting them to follow through on that.

Typically the application developers will get third party software as tarballs or even (shudder) zip files. Turning these packages into rpm's is pretty trivial but it took a while to get the application developers into the habit of doing so. Having all of these packages as rpm's makes deployment and support possible across the hundreds of servers we support. Key to this success is using software channels on our Red Hat Satellite server.

But I digress.

Basically, I made backups of the two files in question and forced the up2date.

# cd /etc/
# cp inittab inittab.`date +%s`
# cd /etc/rc.d/
# cp rc.sysinit rc.sysinit.`date +%s`
# up2date --nox -f initscripts

It turned out that inittab didn't get touched after the up2date so no action was needed there. the rc.sysinit was a different story so I copied back the backup I made (even though up2date makes a backup itself, I am extra-cautious).

After that drama was over, I run the full "up2date -u" and watched it upgrade 551 other packages. 551. Why on earth did Stratus feel the need to do a FULL INSTALL? I don't need squirrelmail or thunderbird on a fault tolerant server!!!

Next up will be creating a custom software channel on the Satellite server for the ft 4300's kernel rpm's.

GRUB, RHEL and a corrupted MBR

GRUB

That's all the screen said.

Just "GRUB." It's almost like seeing "PC LOAD LETTER." My first reaction is "what the #$%! does that mean?" to coin the famous "Office Space" phrase.

Well, I know what GRUB is and what it does. What strikes me as why when it gets screwed up early in the bootstrap process, that's all it says on the screen. Couldn't it say "loading GRUB", or something more meaningful for me to know what stage in the bootstrapping it coughed blood?

But alas, no.

GRUB


Well, I've seen this several times before, and today saw it again: when booting, and after the BIOS work is done, the system just shows "GRUB" and hangs. Nothing else happens. Pretty much, this means that there is a problem with, well, GRUB.

Unfortunately, I've never taken a serious mental note on how the problem was fixed (I handed it off to other SA's to fix in the past) so I spent several hours today doing the same thing over and over again expecting different results.


IDIOT



In the end, the fix was as follows.

First, boot from the RHEL boot CD. When prompted, go into rescue mode.

boot: linux rescue

Follow through on the instructions to choose your language and keyboard. Don't worry about getting network up and running, so opt not to use it. Choose "CONTINUE" when prompted whether to have it find an installed copy of RHEL or not. You want it.

Next, when presented with a shell, chroot that RHEL image.

# chroot /mnt/sysimage

This will come back with another shell. Run a "df" to confirm it made the root change so that it appears you booted from the internal disks.

Next, invoke GRUB with the right options.

# grub --batch --device-map=/boot/grub/device.map --config-file=/boot/grub/grub.conf -no-floppy

From the GRUB shell, re-install the MBR.

grub> root (hd0,0)
grub> setup (hd0)
grub> quit

It is important to "quit" out of GRUB so that anything cached gets dumped.

My mistakes involved mainly re-installing GRUB without specifying the options, installing GRUB not on the master boot record but on the boot block of the first partition, and not using the rescue CD to execute the grub shell.

You must pay attention to your devices. For me, and the typical RHEL install, "hd0" is the root disk, and "hd0,0" is the "/boot" partition. If you have "/boot" installed on, say, your 2nd partition, you'd use "hd0,1" as your "root". You might not even have "hd0" mapped out. Review your "/boot/grub/device.map" file. For this particular RHEL install on an IBM 366 with a hardware mirrored internal drive, our file maps "sda" to "hd0". Our Dell boxes map the same way, too.