Currently viewing entries from 2008

My Less-Zealous Autoconfig

I recently created a wireless auto-config script myself. It is a bit more basic than the script depicted in today’s XKCD. Essentially, the user will run the program (netconf) with an argument to indicate what network to connect to. The script will then run ifdown eth0, remove and then add the bcm43xx module, select the appropriate /etc/network/interfaces file, and ifup eth0 again.

I made it because I often have issues with my bcm43xx after a sleep/resume cycle, and found that removing and then adding the module fixes it. It also makes it easy to switch between the WPA network at school and the WEP network at home.

To use it, you’ll need a broadcom card (using the bcm43xx module), then just set up your own /etc/network/interfaces.PLACE file, where PLACE is something like “home” or “school” to indicate where you will use the file. Then edit the script to reflect this filename and place name. You can download the script right here: netconf

Bookmark and Share

ForkBomb Prevention on Debian


originally uploaded by matthewpoer.

Forkbombs are nasty little programs that fork their process, and then do it again. And again. And so on, until they have consumed all of the available resources. By default, Debian systems are susceptible to forkbombs. However, there are precautions you may take to secure your Debian GNU/Linux box from being abused this way.

Simply alter /etc/security/limits.conf to fit your needs. The file is relatively easy to configure, and the changes you make will take place immediately (no need to reload any services). If there is a specific user you want to watch out for for forkbombs, just limit the number of processes he or she has access to:

isomk hard nproc 100

And if it is all of your users that you are worried about:

* hard nproc 1000

The wildcard refers to all users. Limiting to 1000 means that any user should be able to run all of his or her Desktop Environment applications, but should limit an forkbombs to being relatively ineffective.

/etc/security/limits.conf is how many webhosts are able to set a user or a group of users to be limited to a certain filesize, memory amount or CPU time. If you are considering making your Debian machine public as a shell server or web host or some kind, be sure to use this tool to keep your users under control.

By the way, forkbombs can be written in nearly any language, including scripting languages like BASH and Perl. There are many listed on wikipedia, but my friend Kyle Isom wrote this one in C (he calls it crashboom):

int main() {
        return 0;


Xterm Preferances with no Config File

green screen

green screen,
originally uploaded by matthewpoer.

Some of us geeks like the idea of colored terminals, especially when the resulting terminal matches our ultra-lean desktops (see right). But how can we make an aterm or xterm window launch with these colors without having to define them each time (xterm -fg green -bg black)?

I’ll tell you how! Create a shell script called xterm that contains the

/usr/bin/xterm -fg green -bg black
exit 0

Run “chmod +x xterm” to make the file executable. Store it in your own ~/bin directory.

Make sure that ~/bin is in the start of your path. Run “echo $PATH”
to see what it contains, it should be something like this:

  matthew@anewt:~$ echo $PATH

If you don’t see /home/USERNAME/bin in your path, add it via your .bash_profile. This line will do it: PATH=~/bin:”${PATH}”

After modifying .bash_profile, the user must log out and back in for changes to take effect.

Now, because you have your own executable named xterm, and it is before the /usr/bin/xterm in your path, your shell will prefer it over the other. So simply running ‘xterm’ runs your own.

However, menu entries and calls from other applications may still specifically call /usr/bin/xterm specifically, in which case you’ll still be given the default system settings. If and when this occurs, you must work with that menu or application to call your own program, either with ‘xterm’ or ‘~/bin/xterm’. Most window managers and desktop environments make this simple enough, so I must let you figure it out yourself.

Using fuser to to Work Around snd-cs46xx Suspend Bug

The kernel module snd-cs46xx contains a bug that makes it unusable after the computer has been suspended using ACPI or APM. At this point, I believe it is the only thing keeping me from 100% enjoyment of my IBM Thinkpad T21. Other IBM/Lenovo Thinkpad models may also use this chip and module, including the 600X, A20m, A20p, A21m, A21p, A22m, A22p, T20, T21, and T22. Probably other systems as well, this is not a Thinkpad-only chipset.

In my T21, the audio chipset is CS4624, and is identified in the following way by lspci:

matthew@anewt:~$ lspci | grep audio
00:05.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] (rev 01)

The bug makes the snd-cs46xx module unusable after a resume from suspend. To use the module again, it must be removed and reloaded again (modprobe -r snd-cs46xx, then modprobe snd-cs46xx). This process can be easily automated, unless there is a program using the module. An module that is in-use will be met with an error message.

There has been a purposed work-around/patch by Mark Stosberg on the Ubuntu Launchpad. It would identify processes using the kernel module and kill them. It does not seem to be effective on my Debian Etch system. It seems to utilize a list of applications somewhere in /proc that are using the sound module, but I just do not have that list. The patch was originally included in Mandriva, so perhaps something has simply been lost in translation from distribution to distribution.

Anyhow, I propose I more simple (three lines) code.

Fuser is an application that you probably already have installed on your GNU/Linux system, wheather your use it or not. It identifies applications and users that are accessing certain files on a system, wheather it is a document or a device file. It can use an argument, -k, to kill those processes using the file in question. The command “fuser -k /dev/snd/*” will kill any and all processes using a soundcard on the particular system.

Note that this is why my method is a work-around, and not a fix. Any program: a mixer, media players, or even a web browser, that is using the sound card is killed. You will lose any data that it was using (think unsaved playlists, unsaved game, perhaps the loss of a web browsing session). This would occur anytime you suspend the computer (i.e. shut the lid). If you feel that you can remember to close your audio programs, and reopen them when you resume, this work-around is for you! I have more to say about how programs handle this, later on.

So we have our three commands. In order, the computer must perform these at resume:

  1. fuser -k /dev/snd/*
  2. modprobe -r snd-cs46xx
  3. modprobe snd-cs46xx

Where to put them? Paste those three commands in the file /etc/acpi/resume.d/ and you should be ready to go. Next time you put your computer to sleep, your audio-enabled applications should crash. Yay.

Alternatively, you can create a shell script and store it in some directory in your exectuable path (think /usr/bin or ~/bin). This is the method I have chosen, and it involves manually running the script every time you resume and decide you want sound. It has the added benefit of restarting your mixer application (kmix, for me), because it is user-level, not root. The code for my ~/bin/

  1. #!/bin/sh
  2. fuser -k /dev/snd/*
  3. sudo modprobe -r snd-cs46xx
  4. sudo modprobe snd-cs46xx
  5. kmix

Replace kmix, if you wish, and you may also choose to load xmms or amarok.