The 2Factor, Inc.

The RPM database has two functions,. First, it helps you manage software versions. Second, it eats itself. The “eat itself” functionality is second to none! I’ve never seen a function work as spectacularly as this one! As a result, I have to repair a corrupt RPM database quite often. So I wrote a quick and dirty shell script to do this. It backs up your current RPM database so that you can attempt further recovery if this scripts fails:

#!/bin/bash

DATE=`date +%Y%m%d%M%S`

echo "Before rebuilding the DB there are `rpm -qa|wc -l` rpms"

tar -cf /tmp/rpmdb.backup.$DATE.tar /var/lib/rpm
if [ $? = "0" ]
    then
        echo "Current RPM db has been backed up to /tmp/rpmdb.$DATE.tar"
    else
        echo "*ERROR* Problem backing up the DB, cannot continue"
        exit 1
fi

rm -f /var/lib/rpm/__db*
if [ $? = "0" ]
    then
        echo "The db lock files were successfully removed"
    else
        echo "*ERROR* Problem removing the db lock files, cannot continue"
        exit 1
fi

echo "Rebuilding the rpm db, this could take a few minutes..."
rpm --rebuilddb

if [ $? = "0" ]
    then
        echo "Rebuild appears to have been successful!"
        echo "After rebuilding the DB there are `rpm -qa|wc -l` rpms"
    else
        echo "*ERROR* Problem doing the rpm rebuild"
        exit 1
fi
exit 0

One solution to reducing spam is to use SPF in your DNS. SPF allows you to tell the world which of your servers are your mailservers. By doing this, if they receive a forged email NOT from your servers, they can be reasonably certain that it is spam, and they can handle the message accordingly.

To be clear, this does not really affect how much spam you receive (although I would suggest that you configure your MTA to be SPF aware), it mostly reduces the chances of other SPF aware servers from getting spam with your domain as the sender. Which benefits you in other less direct ways. You will not be blamed for a mess of spam you did not send, you could potentially reduce the load of NDA messages coming back to your server, and other admins are more likely to think you are cool. And what’s a better pickup line than “Hey, you didn’t get any unsolicited bulk mail from me today. That’s right, I did that! Pretty hot, huh?!” Don’t forget to nod your head a little and wink while saying that…

SPF Syntax
SPF Overview

Early on in my career I worked for a rather excitable man. He was very passionate about his work and solving problems. He also had a reputation for changing his mind… a lot… and then changing it again… and again… and it pissed people off. Ok, I should not speak for my peers, it pissed me off! He would ask for X, I would do X and then a day or two later he would say X isn’t a good solution, give me Y. Or, worse yet, X and Y would sit on his desk, and never looked at again.

I eventually learned that if I waited until he asked me twice to do something, my work load and frustration reduced dramatically. If he asked me twice to do the same thing, it meant he really needed it and he was not going to change how the problem should be solved.

To this day, I use a variation of this tactic. Some tasks that cross my path are real emergencies, and must be handled. Even if I know I will be solving the problem again a week later. But a vast majority of everyone’s workload isn’t an emergency. It may be presented as an emergency, but that does not make it true.

So I say do yourself a favor! Embrace your inner procrastinator! And with all that new free time you have, fix the things that cause REAL emergencies!

The screen command is used to manage multiple terminal sessions. It’s especially handy when you manage a lot of systems because you can have a screen session for each ssh session.

To start screen, just type in the command name:
$ screen

From inside screen you can start new sessions:
ctrl-a c

To give the session a label:
ctrl-a A

To see a list of screen session (use the arrow keys to select sessions):
ctrl-a "

To scroll up in a screen session:
ctrl-a ESC-Key

To disconnect from screen:
ctrl-a d

After you’ve disconnect from screen, you can confirm that the session still exists:
$ screen -ls

To reconnect to the screen session:
$ screen -RD

At some point in the future, I’ll expand on this. I prefer that my session’s get named automatically, among other things.

I hope everyone has a Happy SAAD day!

Sometimes it’s necessary to have an ssh connection from my house to my workstation at work. One method for doing this is using a remote ssh tunnel. Naturally, this is trivial with a grown-up operating system. It’s more complex with that other “operating system” which shall remain nameless. Although I suppose it’s possible…

In this example, I have a linux firewall/router at home with a public static ip and I have a linux workstation at work which is behind a firewall. From the workstation at work, I initiate the below command. The hostname “myrouter.domain.org” is going to be the hostname or IP address of my linux machine at home.

ssh -N -f username@myrouter.domain.org -R 2222:127.0.0.1:22

“-N” tells ssh to not execute anything on the remote machine, just forward the designated port

“-f” is used to background the ssh session once it’s authenticated

“-R 2222:127.0.0.1:22″ means that it’s going to build a reverse tunnel between the workstation at work (127.0.0.1:22) and port 2222 on the router at my house.

Once this tunnel has been created, I use it by logging into my router at home, and ssh’ing to 127.0.0.1 port 2222. It automatically drops me onto my machine at work (well, I’ll need to enter my password)!

Another way I use this concept is for a webproxy. I set up Internet without ads at my house and sometimes I like to use that proxy instead of the broken wintendo proxy thing my MIS department forces on me. So instead of a remote ssh port redirect, I do a local port redirect. I redirect local port 3128 to port 3128 on my remote router.

ssh -N -f username@myrouter.domain.org -L 3128:127.0.0.1:3128

Another use for this proxy port redirect is a proxy for my AIM client. I don’t need my employer reading my Instant Messages, so in the AIM client I have a proxy of 127.0.0.1:3128. The employer cannot read the traffic, it’s encrypted over an ssh tunnel.

SSH keys make this really nice, but I’ll get into that later…

When a grumpy Sys Admin tells you to go away before they replace you with a shell script, this is the script they are referring to:

#!/bin/bash
rm -rf $0

As a rule of thumb, I do my best never to reboot a server. From my experience, that’s the most vulnerable time for the hardware. And besides that, there’s nothing sexier to me than fixing a server without restarting it.

But there is one scenario that requires at least one reboot. The scenario is when you are setting up a new server (or replacing one that died). Once you get the server running, and before you allow users to start hitting it, reboot it. You do this to make sure all the services start up properly, and make sure all the settings stick. If you find an error, repair it, and reboot it again.

This is very simple, but this can save you SO much time. This exactly the kind of thing that fits into the 2Factor philosophy. At 2am, when you need to reboot that box, it’s simply inexcusable that it doesn’t restart due to a configuration issue.

This is going to appear to start backwards, I’m not going to explain what a subnet is, or what it’s for. Google can answer that question better than I can.

The purpose of this article is to describe a method I use to determine an IP range when provided an IP and a subnet mask. It may help to see my CIDR article. The advantage to this method is that I don’t need a calculator.

Subnets octets can only be one of the following (with some exceptions that google can explain):

Decimal    Binary
0                00000000
128            10000000
192            11000000
224            11100000
240            11110000
248            11111000
252            11111100
254            11111110
255            11111111

Let’s jump right into some examples:

214.95.171.146/26

While CIDR is easy to write, I really want the actual subnet, which is 255.255.255.192

All I care about is the non-0 and non-255 subnet octet, aka the 192.

Take the 192, subtract it from 256 and you’ll get 64. This is the size of the range of each subnet.

The next step is simple division. We take the last octet from the IP address (we care about the last octet because it’s the same octet we are looking at with the netmask). We want to know how many times 64 goes into 146. The answer is two and we are now able to determine the network #, and then the first IP of this particular network. We take the two, multiply it by 64, giving us 128.

The network number is:
214.95.171.128

The first IP is 1 greater than the network number, or:
214.95.171.129

The subnet mask is the network number + 64 - 1:
128 + 64 -1 = 191
or:
214.95.171.191

The final IP in the range is the network mask, minus 1:
214.95.171.190

Another example, but with a different interesting octet:

185.247.25.144/21

Subnet Mask: 255.255.248.0 (if this doesn’t make sense, read my CIDR article)
256 - 248 = 8

25 / 8 = 3

3 * 8 = 24 (start of range)

24 + 8 -1 = 31 (end of range)

IP Range:
185.247.24.1 - 185.247.31.254

Recently I’ve been finding myself in a situation where I need to edit a handful of similar files. I typically like to script edits like this, or use sed, but it’s not always practical. For those cases, I edit them all in vim in one shot.

First, you need to open the files in vim (below are backticks ` not single quotes ‘ surrounding the find command):

vim `find -name *.conf`

That command opens vim with all the *.conf files it can find.

Simply edit the first file, and save it, but do not quit vim yet. You are going to want to move to the next file:

:n

And continue editing/saving. To move to a previous file:

:N

To get a list of all the files you have open:

:args

And when you are done. Just quit out as you normally do.