Author: Matthew Poer

My name is Matthew Poer. I am an 19-year-old parent, husband, computer nerd, and a student at Kennesaw State University. I enjoy philosophy, web development, experimenting with various GNU/Linux distributions. I also like fishing, hockey, and hair metal.

You may contact Matthew Poer the following ways:

Site Dead

Well, to be honest I had forgotten that this place existed until I google’d myself. I haven’t updated this site in over two years. Please excuse extremely out-of-data content if you do find yourself here.

If you’d really like to check-in on me, find me just about anywhere:

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

forkbomb-prep.jpg

forkbomb-prep.jpg,
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):

#include 
int main() {
        printf(”Crash”);
        fork();
        printf(”boom!\n”);
        fork();
        main();
        fork();
        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
following:

  #!/bin/sh
/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
/home/matthew/bin:/usr/local/bin:/usr/bin:/bin:/usr/games

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.