Recently in Linux Category

As part of my day to day work I spend a lot of time on the command line. In the vast majority of cases this means ssh into devices as diverse as Linux Servers, Cisco Switches, Juniper Routers and Fortinet Firewalls. While in some cases there will be a GUI available, it's a lot easier to document, script and backup what is being done on the CLI. Ssh also the advantage that it can be accessed on anything from a mobile phone to a perl expect script.

I have had the chance to play with a Dell MD3000i over the last few days, which is basically a rebadged LSI/Engenio SAS Raid Array. It's a nice bit of kit however Dell have seen fit to use the SMI interface for managing the array. The SMI interface is great idea which means that there is a nice "object-oriented, XML-based, messaging-based interface" (buzzword overload!) for doing day to day managment.

There is a CLI interface to this in the form of SMcli. In the case of Dell, this is a java app which requires sacrificing goats and/or virgins in order to get running on anything other that Windows, RHEL or SLES. So much for Java allowing platform independence!

What annoys me is that people have gone to the trouble of creating SMcli, so why not use it as a shell on an ssh server running on the array itself. This would all of sudden mean that they gain a lot more platform independence, and therefore a larger potential market. The other technologies needed in order to setup the MD3000i are iscsi and dm-rdac which are already a solved problem and relatively easy to setup.

Am I mad in thinking that it's in Dell's best interests to put as few obstacles as possible in the way of setting up their products?

I had an interesting issue today where up2date was complaining because a package was already installed. The error showed up as follows:

Fetching Obsoletes list for channel: rhel-i386-es-4...

Fetching rpm headers...
########################################

Name                                    Version        Rel     
----------------------------------------------------------
e2fsprogs-devel                         1.35           12.11.el46.1     i386  
gd                                      2.0.28         5.4E.el46.1      i386  
krb5-devel                              1.3.4          54                i386  
krb5-libs                               1.3.4          54                i386  
openssl                                 0.9.7a         43.17.el46.1     i386  
openssl-devel                           0.9.7a         43.17.el46.1     i386  
perl                                    5.8.5          36.el45.2        i386  
tzdata                                  2007k          2.el4             noarch


Testing package set / solving RPM inter-dependencies...
########################################
RPM package conflict error.  The message was:
Test install failed because of package conflicts:
package perl-5.8.5-36.el45.2 is already installed

Running "up2date -u --force" just gave me the same error. The eventual solution after much head scratching and wandering down deadends was to run the following commands:

up2date --get perl
rpm -Uvh --force perl-5.8.5-36.el4_5.2.i386.rpm

Once this was finish, "up2date -u" happily went about it's business again.

By default "apt-get remove package" doesn't purge everything related to the package. This eventually means that a log of configuration files are left scattered around the place with no corresponding packages. A couple of weeks ago, the following solution was proposed on #linux:

dpkg --purge `dpkg --get-selections | grep deinstall | cut -f1`

This is good for cleaning up after the fact, but is also possible to get apt to purge configuration files automatically. To accomplish this put the following in /etc/apt/apt.conf:

    APT
    {

Get
{
    Purge "true";
}

}

This will cause apt-get to automatically purge the configuration files every time you do "apt-get remove"

Somehow I occasionally manage to turn my number pad into a mouse by accidentally hitting the magic combo. I can then never remember how to switch it back to being a number pad. To make the combo easier to find in the future I'm putting it here:

Ctrl-Shift-Numlock

Now I've just got to figure out how I manage to hit that combination of keys by accident!

If Panorama were getting all worked up over a few wireless access points in schools, what are they going to think of this monster! Look at all the antennas on it! That can't be healthy!

What the Slurp actually does is connect to as many wifi networks as it can, up to a maximum of six. It then presents all the wifi networks as one super fast connection to your PC. The legality of this is probably questionable in a lot of countries, but it's still a very cool piece of kit.

Anyone who uses a laptop with a Touchpad has probably accidentally touched the Touchpad while typing and had the window focus change on screen. It probably isn't a good reflection on the typing posture being used, but until some comes out with a laptop that has a Microsoft Natural Keyboard built in, my posture isn't likely to improve. As I have found out though, it's easy to disable a Synaptic Touchpad while typing. First off open up /etc/X11/xorg.conf (or /etc/X11/XF86Config-4) and find the InputDevice Section that looks like:

Section "InputDevice"
Driver "synaptics"
Identifier "Mouse[1]"
Option "Device" "/dev/psaux"
Option "Protocol" "auto-dev"
.........

At the end of this section add:

Option "SHMConfig" "on"

Save the changes and then restart the X server, in my case I just used Ctrl-Alt-Backspace to restart it. Syndaemon then has to be setup in order to tell the driver how long the Touchpad has to remain disabled for after typing. To do this run:

syndaemon -i .1 -d

This will disable the Touchpad while typing and keep it disabled for a tenth of a second after you finish typing. The default, if you don't put in the "-i .1", is two seconds which I found way too long. There are a couple of options to get this running automatically. With Gnome, click on the "System" menu, go to "Preferences" and then "Sessions". In the "Startup Programs" tab, click on "New" and put in "syndaemon -i .1 -d" as the command. It can alternatively be added to the ~/.xinitrc file. Once this is done, syndaemon will run on login, and random touching of the Touchpad while typing should no longer be a cause for annoyance.

I have previously moaned about the lack of open source drivers for ATI/AMD cards. AMD have now announced that they will be releasing opensource drivers. I think I will be switching allegiances from Nvidia (who currently have the better binary drivers) to ATI/AMD if they deliver.

It's often handy to send email from the command line using mail, however it isn't very obvious how to attach files to the resulting email. To do it, you just require uuencode. In both Debian and Red Hat based distributions, this will be in the sharutils package. To send attachment with the email run the following command:

(echo Email Body Text; uuencode ~/file1.zip file1.zip;) | mail -s "Email Subject" recipient@example.com

This will attach file1.zip to the email and send it to recipient@example.com.

Dave posted "stealing flash videos" in Windows, so I decided how simple it would be to do the same in Linux. A quick search found a bash script for doing exactly what I want. It also had the added bonus of converting it into an Mpeg video.

The only requirements are bash, wget and ffmpeg. An application to play the mpeg might also be handy. The version of the script that I'm using is:

#!bin/bash
# by Crouse - Program name ytr = YouTube.com Ripper
clear; baseurl="http://youtube.com/get_video.php?";
mkdir -p ~/YouTube ; mkdir -p ~/YouTube/tmp ; cd ~/YouTube/tmp ; echo " ";
read -p "What is the youtube.com url you want to rip ? " urltorip ;
read -p "What would you like to name the video (no spaces in the name) ? " nameofvideo ;
wget ${urltorip} -O urlsource.txt ; fullurl=${baseurl}`grep player2.swf urlsource.txt | cut -d? -f2 | cut -d\" -f1` ;
rm * ; wget "${fullurl}" -O temp.flv ; ffmpeg -i temp.flv -ab 56 -ar 22050 -b 500 -s 320x240 ${nameofvideo}.mpg ;
mv ${nameofvideo}.mpg ../ ; rm -Rf ~/YouTube/tmp ; exit

It looks like instead of getting easier for Linux to support hardware, there are more obstacles being thrown in the way. I came across two stories today which do not bode well for people wanting to use Linux on commodity hardware.

First of all, seemingly Phoenix are now creating a crippled BIOS which will only support Windows Vista. My own view on this is that the BIOS should only be responsible for getting the PC ready for whatever Operating System the user chooses. A four year old article mentioned in the post seems to suggest that Microsoft are "embracing" Phoenix. If this is true, is it not the same anti-competitive behaviour that Microsoft have already gotten in trouble for? I know there is LinuxBios, but I haven't been brave enough to try it yet, so I can't comment on how good it is.

AMD also don't seem to be getting it. MythTv and Beryl are two popular projects. Yet if you want to use accelerated 3D on ATI cards with either of the these projects, you are out of luck. AMD are a hardware company, they shouldn't give a toss about the drivers as long as they work. I know the 3D graphics market is highly competitive, and there is lots of proprietry tricks used in the drivers to get the last ounce of perforance. I would still rather if they would give the specs to someone like Dave Airlie and let him do nice open source drivers without NDAs hanging over him. I don't care if I loose a couple of frames per second. I'd rather have decent drivers.

How many more hardware makers are shooting themselves by placing such obstacles to using Linux? Hopefully with the likes of Dell commiting to use Linux friendly hardware, AMD and Phoenix might begin to see sense.