...making Linux just a little more fun!

2-Cent Tips

2-cent tip: Wonky serial connections and stalled downloads

Ben Okopnik [ben at linuxgazette.net]

Wed, 5 Dec 2007 22:29:29 -0500

For various odd reasons [1], Ubuntu's 64-bit implementation of the 'usb-serial' module results in downloads over serial links using it (e.g., GPRS-based cell cards) stalling on a regular basis. Eventually - say, within a minute or two - these hangups resolve, and given that many protocols implement some kind of a retry routine, the download continues - but there are a few exceptions: notably 'apt-get' and some HTTP downloads. These simply drop the connection with a "timeout" error message. This, especially in the former case, can be really painful.

Here are a couple of methods that I've found to make life easier. In testing these over the past several months, I've found them to be fairly reliable.

HTTP: 'wget' is a great tool for continuing broken downloads (that's what that "-c" option is all about) - especially if it's properly configured. This doesn't require much: just create a ".wgetrc" file in your home directory and add the following lines:

read_timeout = 10
waitretry = 10
After you do that, both 'wget' and 'wget -c' become much more friendly, capable, and hard-working; they no longer hang around with shady types, drink up their paychecks, or kick the dog. Life, in other words, becomes quite good.

apt-get: This one takes a bit more, but still doesn't involve much difficulty. Add the following entries to your '/etc/apt/apt.conf':

Acquire::http::Retries "10";
Acquire::http::timeout "10";
Then, whenever you don't want to stay up all night nursing your 'apt-get upgrade' or whatever, launch it this way (assuming that you're root):

until apt-get -y upgrade; do sleep 1; done
This will keep relaunching 'apt-get' until it's all done - and will time out quickly enough when the link stalls that you won't be wasting much time between retries. This is a big improvement over the default behavior.

[1] I did some Net research at the time, and found several discussions that support my experience and diagnosis; unfortunately, I don't recall the search string that I used back then, and can't easily dig these resources up again. "The snows of yesteryear", indeed...

* Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *

2-cent tip: Starting screensaver in KDE

clarjon1 [clarjon1 at gmail.com]

Mon, 21 Jan 2008 14:04:59 -0500

Well, here's a little tidbit I've found that may be of use to some people. As many KDE users may know, you can have a keyboard shortcut set to lock the screen. You can do the same with just starting the screensaver!

Create a new item in the KDE menu editor, name it whatever youwant, and have it to run this command: kdesktop_lock --dontlock

Set it to a keyboard shortcut, save the menu, and viola! You now have a keyboard shortcut to start your screensaver.

[ Thread continues here (2 messages/1.63kB) ]

2-cent tip: finding a USB device with Perl

Samuel Bisbee-vonKaufmann [sbisbee at computervip.com]

Sat, 29 Dec 2007 06:05:08 +0000


I got a USB toy for Christmas that didn't have a *nix client. After some detective work I found a Perl module that did what I needed, except that the module tried to access the toy with specific vendor and product ids. For whatever reason my toy's ids did not match, so I modified the module to search for my device. [1]

The first step is to find the product name for your device. This is easily done with `lsusb` on the command line.

Next, break our your text editor and write some code. Remember, because Perl uses libusb you will have to run your code as root; if you get errors about being unable to access the device, then this is probably the cause.

Here is the code that I used (was inside a sub, hence the use of 'return'):

my $usb = Device::USB->new;
my $dev;
  $dev = $usb->find_device($_->idVendor(), $_->idProduct()) and last if $_->product() eq "YOUR PRODUCT'S NAME FROM lsusb";
return -1 if !$dev;
This code iterates over the buses, checking each product's name for our device's name from `lsusb`. If the device is found, then it will store the handler in '$dev' and break out of the loop, else it will bubble the error up by returning a negative value. When the device is found you would claim and control it as normal (example in the 'new()' sub from http://search.cpan.org/src/PEN/Device-USB-MissileLauncher-RocketBaby-1.00/lib/Device/USB/MissileLauncher/RocketBaby.pm).

If you are interested, I was playing with Device::USB::MissileLauncher::RocketBaby (http://search.cpan.org/~pen/Device-USB-MissileLauncher-RocketBaby-1.00/lib/Device/USB/MissileLauncher/RocketBaby.pm).

[1] It turns out that my USB toy uses the same ids; I probably just tried to run the code when the device was unplugged. Oh well, at least I got to learn how Perl interfaces with [USB] devices.

Sam Bisbee

[ Thread continues here (8 messages/18.33kB) ]

2-cent tip: Automatically reenabling CUPS printer queues

René Pfeiffer [lynx at luchs.at]

Thu, 27 Dec 2007 16:05:23 +0100


I have a short shell script fragment for you. It automatically reenables a printer queue on a CUPS printing server. CUPS takes different actions when a print job encounters a problem. The print server can be configured to follow the error policy "abort-job", "retry-job" or "stop-printer". The default setting is "stop-printer". The reason for this is not to drop print jobs or to send them to a printer that is not responding. Beginning with CUPS 1.3.x you can set a server-wide error policy. CUPS servers with version 1.2.x or 1.1.x cna only have a per-printer setting.

If you have a CUPS server an wish the print queue to resume operation automatically after they have been stopped, you can use a little shell script to scan for disabled printers (stopped printing queues) and reenable them.

# Check if a printer queue is disabled and reenable it.
DISABLED=3D`lpstat -t | grep disabled | awk '{ print $2; }'`
        logger "Printer $PRINTER is stopped"
        cupsenable -h $PRINTER && logger "Printer $PRINTER has been enabled."
This script can be executed periodically by crontab or by any other means.

Best, René.

[ Thread continues here (5 messages/5.98kB) ]

2-cent tip: Tool to do uudecoding

Mulyadi Santosa [mulyadi.santosa at gmail.com]

Tue, 15 Jan 2008 09:26:34 +0700

For some reasons, you might still need to uudecode a whole or some part of file(s). A good example is if you're a loyal Phrack reader just like I am. Most likely, the authors put uudecoded text right into the body of an article. Usually, it PoC (Proof of Concept) code so the readers can gain better understanding of the explanation and try it by themselves without re-typing the code.

So, you need uudecode but where is it? In recent distros like Fedora 7, it's packed into different name. For example, in Fedora it is gmime-uudecode and included in gmime RPM.

To execute, simply do something like below: $ gmime-uudecode -o result.tar.gz phrack-file-0x01.txt The above command assume you know the format of the uudecoded file. If you don't, just use arbitrary extension and use "file" command to find out.

You don't need to crop the text file, gmime-uudecode will scan the body of the text file, looking for a line containing "begin" string. The scanning ends at the line containing "end".

Talkback: Discuss this article with The Answer Gang

Copyright © 2008, . Released under the Open Publication License unless otherwise noted in the body of the article. Linux Gazette is not produced, sponsored, or endorsed by its prior host, SSC, Inc.

Published in Issue 147 of Linux Gazette, February 2008