Aaron Toponce : Linux. GNU. Freedom.

It’s That Time Again

1	echo 'by9+IEhhcHB5IEJpcnRoZGF5IHRvIHlvdSEgSGFwcHkgQmlydGhkYXkgdG8geW91ISBZb3UgbG9vayBsaWtlIGEgbW9ua2V5LCBhbmQgeW91IGNvZGUgbGlrZSBvbmUgdG9vISBvL34K' \| base64 -d

2009 06 09 Personal Comments (9) Permalink

Every GNU/Linux distribution ships with GnuPG by default. While they all don’t ship with the same GUI frontend, they do ship with the the same CLI backend. So, we’ll be interfacing with that throughout this informational session. I’m not presenting this as anything necessarily useful. Rather, I hope you find it informational/educational, and learn a little bit with how GnuPG works “under the hood”. So, let’s have some fun. First, a list of the “standard” algorithms that ship with GnuPG on a GNU/Linux system. This is completely based on the type of main public and private keys as well as any subkeys that you’ve generated. You can see a list of supported cipher, digest and compression algorithms by invoking the gpg binary and passing “–version” as an option. For example, here is the output from my Debian GNU/Linux unstable laptop:

$ gpg -v --version
gpg (GnuPG) 1.4.9
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: 3DES (S2), CAST5 (S3), BLOWFISH (S4), AES (S7), AES192 (S8),
        AES256 (S9), TWOFISH (S10)
Hash: MD5 (H1), SHA1 (H2), RIPEMD160 (H3), SHA256 (H8), SHA384 (H9),
      SHA512 (H10), SHA224 (H11)
Compression: Uncompressed (Z0), ZIP (Z1), ZLIB (Z2), BZIP2 (Z3)

So, for ciphers, I support 3DES, CAST5, BLOWFISH, AES, AES192, AES256 and BLOWFISH. For digest hashes, I support MD5, SHA1, RIPEMD160, SHA224, SHA256, SHA384 and SHA512. Lastly, for compression algorithms, I support uncompressed, ZIP, ZLIB and BZIP2. Your output my vary slightly one way or the other. For example, you may not see the full suite of SHA algorithms. This can be obtained by generating an RSA subkey for signing only. Other ciphers might include IDEA, CAMELLIA128, CAMELLIA192 and CAMELLIA256, and you could have TIGER and WHIRLPOOL as possible supported hashes.

With all these algorithms, how do you know which to use and when? Fortunately, GnuPG takes care of that for you automatically. However, you can tell it what you would to prefer to use for each, if you like. You can set these in your ~/.gnupg/gpg.conf file. The options you are looking to set are “default-preference-list”, “personal-cipher-preferences”, “personal-digest-preferences” and “personal-compress-preferences”. For myself, here is what I have set in my gpg.conf:

default-preference-list 3DES CAST5 BLOWFISH AES AES192 AES256 TWOFISH MD5 SHA1 RIPEMD160 SHA224 SHA256 SHA384 SHA512 Uncompressed ZIP ZLIB BZIP2
personal-cipher-preferences TWOFISH AES256 AES192 AES BLOWFISH CAST5 3DES
personal-digest-preferences SHA512 SHA384 SHA256 SHA224 SHA1 RIPEMD160 MD5
personal-compress-preferences BZIP2 ZLIB ZIP Uncompressed

Now, when we printed out the verbose version, we saw in parenthesis S2, S3, H8, H9, Z1, Z2 and so on. We can use these instead of the name in our gpg.conf if we so wish. I prefer the name, as I can’t recall the key to the algorithm, and it’s easier to read. So, in my case, I list out everything that I want for a default list of preferences, then I choose the order of which to pick from when encrypting, signing and compressing. So, for encryption, I have set TWOFISH as my first choice, with AES256 as my second choice, then AES192 as my third, and so forth. I’ve done the same with my preferred digest hashing algorithm choosing SHA512 first, then SHA384 second, and so on, and the same with compression.

Why set the preference? For starters, if you’re like me, you sign all your email by default. You probably want your signature to withstand the test of time as long as possible. Given the strength of today’s hardware, why not choose the strongest encryption and hash algorithms? But on a more practical note, if you’re encrypting data to yourself, this would tell GnuPG to use TWOFISH as the encryption algorithm. This means that if you want to decrypt it at a later date, maybe on another computer, you’ll need to make sure TWOFISH is compiled into GnuPG. How would you know what was used? We’ll cover that in a bit.

However, what about encrypting to someone else other than yourself? How do these preferences come into play? Well, you can also set preferences in your public key. The purpose of this, is when people grab a copy of your key, and they want to encrypt something to you, GnuPG will negotiate the first preferred algorithm that is common between the two end points (the one doing the encrypting and the one receiving the encrypted data).

For example, let’s suppose Alice has a GnuPG keypair as does Bob. In Alice’s public key, which Bob has a legitimate copy of, she has set a cipher preference order of: TWOFISH BLOWFISH AES CAST5 and 3DES. Bob wants to encrypt data to Alice. Because he has a copy of her public key, he can do this. The question here is, which algorithm will be chosen for the encryption? Well, Alice prefers TWOFISH as a first pick. If Bob has compiled TWOFISH support in his copy of GnuPG, then it will be used. Suppose he doesn’t have TWOFISH support. Then the next preferred algorithm is BLOWFISH, because it’s Alice’s second pick. Let’s say Bob does support it, then BLOWFISH is the algorithm used for encrypting the data to Alice. When Alice receives the encrypted data, she’ll use the BLOWFISH algorithm along with her private key to decrypt the data. Should she wish to reply, her copy of GnuPG will pull out the preferences from Bob’s public key, and go through the same process looking for the first preferred algorithm by Bob that is supported by both parties. The “SSL handshake” works much in this same manner.

Digest hashing works much the same way, but slightly different. Because the recipient doesn’t matter with signed data, then rather than looking to public keys for the digest algorithm preference, you turn to your gpg.conf file, if listed, and use that there. If the recipient, or recipients have a copy of your public key, and the same digest algorithm compiled into their copy of GnuPG, they can verify your signature. If either is missing, the public key, or the algorithm, the signature will fail, and GnuPG will explain the problem. This process is the same for compression algorithms.

So, we’ve made the preferences in our gpg.conf, but how do we set them in the public key, so we can distribute this to others? Well, in this case, we need to edit our key. From the terminal (I’ve snipped out the noise, focusing only on what’s important):

$ gpg --edit-key KEYID
gpg (GnuPG) 1.4.9; Copyright (C) 2008 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.
[ ... SNIP ... ]

Command>

We are now sitting at a command prompt that we can use to pass commands in an interactive fashion. I should mention that all this can be done non-interactively. Checking out the gpg manual will provide the list of options for making this possible. Typing “help” will give us the list of commands that we can pass:

Command> help
[... SNIP ...]
pref        list preferences (expert)
showpref    list preferences (verbose)
setpref     set preference list for the selected user IDs
[... SNIP ...]

The commands that we are interested in “pref” and “setpref”. Passing “pref” might give us something like the following:

Command> pref
[ultimate] (1). Aaron <aaron@example.com>
     S10 S9 S8 S7 S4 S3 S2 H10 H9 H8 H11 H2 H3 H1 Z3 Z2 Z1 Z0 [mdc] [no-ks-modify]

See those algorithm codes we saw at the beginning of this tutorial? They are listed in the preferred order that we wish to have each algorithm. In my case, I have all my encryption algorithms lists, from strong to weak, then hashing from strong to weak, then compression from most tight to no compression. What if I wanted to set a different order, or maybe not include some preferences: Using “setpref” makes this possible:

Command> setpref S10 S9 S8 S7 H10 H9 H8 H2 H3 Z2 Z1 Z3 Z0
Set preference list to:
     Cipher: TWOFISH, AES256, AES192, AES, 3DES
     Digest: SHA512, SHA384, SHA256, SHA1, RIPEMD160
     Compression: ZLIB, ZIP, BZIP2, Uncompressed
     Features: MDC, Keyserver no-modify
Really update the preferences? (y/N)

Typing “y” will of course make the setting in your key. At this point, you’ll be asked to enter your private key passphrase successfully before continuing. At that point, it will be statically set in your public key, and you can send your key off to the keyservers and emailed to your family and friends, so they can immediately start taking advantage of the new preferences. Type “quit” to leave the prompt.

Now, let’s say you have some signed and encrypted data, and you’re curious of the algorithms used when creating the cipher text. This can be done by passing the “–list-packets” option to gpg to see the data packets. We’ll need to turn on verbosity as well. For example, the output of a file I sent to a friend using the Mutt email client (emphasis mine):

gpg -v --list-packets file.txt
gpg: armor header: Version: GnuPG v2.0.11 (GNU/Linux)
[... SNIP ...]
gpg: AES256 encrypted data
:compressed packet: algo=3
:onepass_sig packet: keyid CE7911B7FC04088F
	version 3, sigclass 0x01, digest 8, pubkey 1, last=1
:literal data packet:
	mode t (74), created 1244484492, name="mutt-helios-1000-24974-13",
	raw data: unknown length

Here, I can easily see that AES256 was used for the encryption algorithm, but what’s this compressed “algo=3″ and “onepass_sig packet digest 8″ stuff? Well, in order to understand those, we need to turn to RFC 4880. This RFC describes the OpenPGP message format and the standards used. Browse your way down to section 9, and you’ll see what “algo=3″ means for compression and “digest 8″ is for signatures. It appears, according to that RFC, that BZIP2 was used for compression and SHA256 was used for the hashing algorithm. So, in this case, Christer and myself preferred those settings higher than the others, and my GnuPG acknowledged those preferences and did the encrypting, signing and compressing as told. We can see these by “editing” his key:

$ gpg --edit-key christer
[... SNIP ...]
Command> pref
[  full  ] (1). Christer <christer@example.com>
     S9 S8 S7 S3 S2 H2 H8 H3 Z2 Z3 Z1 [mdc] [no-ks-modify]
[... SNIP ...]

Command> quit

Christer places AES256 has his first preferred encryption algorithm. Because I also support this algorithm, this is used for the encryption. SHA1 is his preferred digest hashing algorithm with SHA256 as his second preferred, but remember that for the signature and compression, these preferences are found in my gpg.conf instead. I prefer SHA512 as my first preference, but he doesn’t list it as suported (according to his public key), so I move down to SHA384. Again, he doesn’t list it, so I try SHA256. He lists it, so it’s used. Lastly, BZIP2 as the compression algorithm, and he lists it, thus it’s chosen. Thus, the results we got. Make sense?

I hope this has been informative. It’s been great discovering the details of how these algorithms were chosen, and it’s been fun playing with all sorts of encrypted emails and files to get to the guts of the GunPG process. If I’ve misrepresented any data here, or you have questions, please let me know.

Password Policies Suck

I’ve been getting a flurry of emails at work, reminding me that my passwords are about to expire on several Unix and Linux machines in our production datacenter. They have a policy in place, where the password much be changed every 90 days, and I have to keep my current password for at least 7 before changing it, and I can’t use any password that has been used previously, let alone, the insane requirements for the password. So, rather than fight it, I thought I would make this easy on myself.

First, I’m a big fan of SSH key authentication. Because I’m allowed to use SSH authentication, I have my public SSH key on all the servers in the datacenter. When my password is about to expire, I get an email notice once per day two weeks in advance. I can use this email as an opportunity to execute a script that will change all the passwords on all the servers for me. In the script, I’ll have it grab some data from /dev/urandom, and create a sha1sum of the input. An encrypted version of the hash will then be saved locally to disk, which will be encrypted with my GnuPG key, and emailed to myself, should I need the password for something other than SSH. Lastly, just so the password can’t be compromised, only the encrypted versions of the password remain on disk. The hashes themselves are shell variables that are cleared when the script exits. Further, I’ve changed the permissions on my home directory, where my SSH keys and GnuPG keys exist, such that everything sensitive is only accessible to myself. I realize that convenience comes at the sacrifice of a bit of security. My laptop is running full disk encryption, and my password to guard my account is strong. I am the only one on my machine, and I expect it to stay that way. As such, I’m not worried about anything getting compromised.

All of this is stored in a simple shell script, shown below. You will need the “expect” and “sha1sum” packages installed on your system before executing this script. You will need a GnuPG key pair generated for encrypting and decrypting data. You’ll need SSH keys created and distributed to each server beforehand. You should probably have your SSH keys added to your SSH agent, as well as your GnuPG key added to a GPG agent before executing the script, to save you some serious typing. I won’t cover that here, but Seahorse is a great utility for managing GPG and SSH keys. Of course, your SSH keys and GPG keys should be passphrase protected.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

#!/bin/sh

# License: public domain

if [[ -f newpass.gpg ]]; then

    mv -f newpass.gpg oldpass.gpg

    OLDPASSWD="$(gpg -d oldpass.gpg)"

fi

# Change "Your Name" to fit the user ID that matches in your GPG key

dd if=/dev/urandom count=100 2> /dev/null | sha1sum -b - | \

gpg -ar "Your Name" -e - > newpass.gpg

# Change "username@domain.tld" to match the email you wish to send this to

cat newpass.gpg | mail -s "Password for servers" username@domain.tld

NEWPASSWD="$(gpg -d newpass.gpg)"

# Change "server1 server2 sever3" to match the hostnames of the servers you'll loop over

# Change "domain.tld" to match the FQDN for your servers

for host in server1 server2 server3; do

    EXPECT=$(expect -c "

        spawn ssh $host.domain.tld

        send \"passwd\r\"

        expect \"(current) UNIX password: \"

        send \"$OLDPASSWD\r\"

        expect \"New UNIX password: \"

        send \"$NEWPASSWD\r\"

        expect \"Retype new password: \"

        send \"$NEWPASSWD\r\"

    ")

    echo $EXPECT

done

Initially, when I started writing this script, I wanted it to run in cron locally on my laptop. As I began building the script, I realized this wasn’t a secure move, for a couple of reasons. First, as already mentioned, I’m using SSH authentication using public key cryptography. All of my SSH keys are passphrase protected. I didn’t want to store the passphrase in the script, so I could automate the process, and I didn’t want to remove the passphrase or generate new keys that didn’t have a passphrase. Further, wanting to encrypt the data, and send it to myself via email required that I store my GnuPG passphrase on disk as well. I didn’t like this idea either, as I’m already storing the new and old encrypted passwords on disk from the script, and that’s enough. No need to compromise security any further. So, I’ll run this script by hand.

However, we have a problem. You will be typing passphrases galore in this script if you have a decent number of hosts to loop through. So, as mentioned, it would probably be best to take advantage of an SSH and GPG agent to cache your passphrases to ease the pain before executing the script.

Looking over the script a bit. First thing to note, is it is sending the same password to every server. You might not want this. If so, feel free to modify the script to fit your needs. Second, the sha1sum hash is never stored on disk. Rather, it’s just stored in variables OLDPASS and NEWPASS. The idea between the old passwords and the new passwords, is so we can provide the current password when updating, as well as the old.

We’re pulling from /dev/urandom as a source for semi-random data. Yes, you can pull from /dev/random if it makes you sleep better at night. Also, we’re not pulling a lot of data, because ultimately, the SHA1 hash will be strong enough as it is. You’ll notice too that because we’re using STDIN for our data source, the hash contains a space, asterisk and hyphen following the hash, and we’re keeping it. I figured no reason to remove it, as spaces, asterisks and hyphens are valid UNIX password characters. If your company has a more draconian password policy than mine does, requiring specifically more than say 3 or 5 non-alphanumeric characters, then just append those to the end of hash before encrypting to disk. Maybe something like the string “!@#$%”.

Lastly, we’re emailing the encrypted password to ourselves, so no worries about compromising there, plus that gives us an extra backup in case we lose our disk that is storing the encrypted passwords. This also gives flexibility to where we can retrieve the password, provided we have access to the Internet and our GPG keys. Then we’re using “expect” to send the passwd command to the server and send our old and new passwords as prompted for each server. You might need to change the expected prompt depending on your GNU/Linux or Unix derivative (”New RedHat password: ” for example).

That’s it! Simple enough. If you have any questions, or improvements, please post them in the comments. Thanks!

2009 05 28 Linux
Scripting Comments (2) Permalink

Piracy Sucks

This is something that has been on my mind for quite some time (think years), but I’ve refused to blog it, because it goes against the beliefs of many of my friends. In short, this post is going to hurt, but I just can’t hold out on it any longer.

Question: Are you one that pirates music? Movies? Software? Any other digital media that is otherwise copyrighted in a manner that would consider your actions piracy? If so, then I have a second question for you: Do you believe in the principles of freedom and liberty? Then this post is for you.

I’m going to shoot straight- piracy is a slap in the face for those of us fighting for copyright restrictions to be lifted, for Digital Restrictions Management wiped from the face of the Earth, and the DCMA over turned. The fact of the matter is, we hate the RIAA, MPAA, blood sucking lawyers, and everything else wrong with copyright just as much as pirates. However, we recognize there are more mature ways to reaching our goals, and we further recognize that piracy is just hurting our cause, not helping it.

Think about it for a second. If you pirate music, books, movies, software, or any other copyright material, what are you saying? At first thought, you’re sticking it to the man, right? You’re also harming material that is open, in the public domain, or otherwise copyrighted in a manner that let’s you share to your hearts content (commonly referred to as “copyleft”). Look at all the artists who have chosen independent labels, if any label at all, that encourages sharing of their music. Instead, you’re sharing Tori Amos, Metallica or some other artist. What you’re saying, is their music is better, but I doubt you’ve given the other music a try, haven’t you? What about proprietary software? You’re saying that you don’t want to pay these outrageous prices on software. You’re also saying that this application is superior to Free Software. The same can be said for images, books, videos, and other digital works. Piracy isn’t liberating anything, it’s just making it so you don’t have to pay, and it’s making more laws on copyright further complicating the system. It’s not the solution to the problem.

Now, I understand the want, or even need, to get these materials. Maybe school requires Microsoft Office. Can you use OpenOffice.org, or some other Open Source office suite? If so, why pirate Microsoft Office? If you absolutely need that specific office suite, surely the school has student discounts. What about Metallica? I was just as pissed as the next guy when they went against Napster, but pirating their music only says you still like the band, and you still like their tunes. Why not boycott them? Why not find another artist in metal that allows sharing and free distribution? If you just like their tunes so much, why not listen to them on a radio service, like Last.fm? Using a service like this, not only will you get Metallica tunes, you’ll also get similar artists that you may not have known about. Discovering new artists is a great way to support music in the Free Culture. If you must have their stuff, is it really that hard to pay a dollar on Amazon or iTunes? If you don’t want the money reaching Metallica, why not get their albums from a gray market shop?

Piracy just doesn’t equate to honesty as well, no matter how you look at it. You’re not being honest in your dealings with your fellowman, and if you’re engaging in piracy, how can others trust you in different aspects of your life? Sure, you can admit that you’re a pirate, but you’re still not honest with the law. You’re not honest with the artists or developers. As much as it sucks sometimes, we should believe in honoring, obeying and sustaining the law. I’m not saying follow the law blindly, and there are always times when we should lobby changes to the law. This seems more the right path than ignoring the law and engaging in piracy, don’t you think? Now, we’re not perfect law abiding citizens. I for one have a hard time sticking to posted speed limits on the road and coming to a complete stop at stop signs, so I’m certainly not one get all high and mighty, but is that an excuse for me to break other laws? Further, what if I place something in your care that requires your trust? Can I trust you won’t put it on bittorrent, or otherwise break my trust?

Piracy especially is troubling for those of us who believe in the Free Software ideals. Here, we’re fighting the good fight for software freedom, then in the dark corners of the basement, we’re pirating proprietary software. Isn’t this hypocritical? You either believe in the ideals or you don’t. Playing both sides doesn’t work. Further, as already mentioned, pirating the software only pisses off the software execs and their lawyers, making the whole copyright process more complicated- it’s doing nothing to liberate the software at all. Boycotting the software, and using competitive open source applications are a couple ways of getting the point out that software should be liberated. If no one is using their software, how can they continue with their business models?

Finally, I admit to being a pirate many years ago. I had a collection of gigabytes of music, videos and software. I was on the peer-to-peer networks night and day. However, when I thought about it, I realized that my actions could not be justified. How could I promote and advocate “copyleft” licenses and continue doing what I was doing? No man can serve two masters, and I had to make a choice. I deleted my entire repository of music, videos, books, software and anything else that was pirated, and started anew. This was nearly five years ago, and guess what? I don’t miss any of it. I have all the music I want to listen to through Last.fm. I have all the software I want to install through my distribution’s software repositories. When I need movies or music, I hit up the gray market shops, getting them for cheap and in excellent condition.

Give yourself a soul-searching moment. Think about your beliefs and then your actions. I think you’ll find that piracy just isn’t the right way to go about removing all the restrictions we currently face. Piracy only makes more ridiculous laws and prevents the Free Culture from furthering it’s cause.

2009 05 17 Freedom
OSS Comments (34) Permalink

Ubuntu 9.04 Torrents

Tommorow is the Big Day for GNU/Linux, when Ubuntu goes through it’s regularly 6 month upgrade. Ubuntu 9.04, codenamed “Jaunty Jackalope” is due for release. The consequence is, these servers will get slammed, meaning that’s it’s difficult for people who use other distributions on some mirrors to update their distribution. As a result, rather than hit the servers with FTP or HTTP, it would make sense to pull as much strain off the big iron as possible. There are many ways to pull this off, such as rsync, jigdo and bittorrent.

Unfortunately, as efficient as they can be, rsync and jigdo still hit the servers, even if it’s light. Bittorrent doesn’t have to, being a peer-to-peer technology. So, when you’re looking to get your latest ISO downloaded and burned, so you can hand them out at release parties, install on new boxen, or just for archival, it would be best if you used bittorrent. Of course, if you use bittorrent, then rather than cut the connection when you’re done, get at least a one-to-one ratio on uploads to downloads, so everyone can benefit.

Many popular bittorrent clients exist as Free Software for GNU/Linux, such as Transmission, GNOME Bit Torrent and rTorrent (text-based). Trackers will be ready, if they’re not already, and the ISOs will be ready to go. Just find a link with a torrent to grab, and start downloading and sharing. No worries either for data speeds. Everytime I’ve used bittorrent on the release day, my connection was always filled to the max at 1 MB/s. Let us not forget how popular Ubuntu really is!

See you on the other side!

P.S.: The Ubuntu help documentation has a good guide for upgrading from 8.10, if you go that route. https://help.ubuntu.com/community/JauntyUpgrades

2009 04 22 Linux
Ubuntu Comments (0) Permalink

Mono And RHEL

With all the whoo hah about why GNote sucks for Tomboy, mono is patent encumbered software by Microsoft, people eating FUD for breakfast, and other things, one argument I’ve failed to read is this:

GNote can bring Tomboy to Red Hat Enterprise Linux, as Red Hat will not ship mono with its flagship product.

Whatever Red Hat’s reasons are for not shipping mono with RHEL, GNote is a major win for the open source community. Different people and different operating systems have different needs, and providing yet another application to fill a need is what Free Software is all about. This gives Red Hat the opportunity, if it desires, to bring Tomboy to RHEL through GNote.

Lastly, let’s not forget the Free Software Definition, which it seems GNote is taking advantage of:

Run the program, for any purpose
Study how the program works, and adapt it to your needs
Redistribute copies so you can help your neighbor
Improve the program, and release your improvements to the public, so that the whole community benefits

2009 04 20 Freedom
OSS Comments (5) Permalink

New Email Signature

I’ve been toying with the idea that I want a new email signature at the end of each message I send. For the longest time, I’ve been of the opinion to put an email netiquette topic in my signature on one point or another. For example, for the past 4 years, I’ve had one version or another of the following signature:

                       _
Aaron Toponce         ( )  ASCII Ribbon Campaign
www.aarontoponce.org   X   www.asciiribbon.org
                      / \

That signature has served me well the past few years, but I’m ready for something new and refreshing. I’m tired of the political stance that my signature carries, so how about something less political and more geek? I don’t want my name in the signature or anything vanity-related. No politics or netiquette advice. Just raw geek. I came up with the following:

. O .   O . O   . . O   O . .   . O .
. . O   . O O   O . O   . O O   . . O
O O O   . O .   . O O   O O .   O O O

Bonus points if you recognize this pattern, and can tell me where it’s from.

2009 04 18 General Comments (10) Permalink

Online Things That Bother Me

This is intending to be a quick post, so I hope I can keep it as such.

There are a few things online that are really starting to get under my skin. Thankfully, the problems can all be solved by an opt-out approach, one way or another, with of course the most dramatic staying offline. I thought I’d share my thoughts, as it seems others are following suit as well. Could this be the end of an old era, and the beginning of a new?

Email: Believe it or not, this is annoyance numero uno, and I think the problem doesn’t come from spam, but unwanted email nontheless. In my Gmail account, I probably receive somewhere in the neighborhood of 200 spam messages a day, all which Google does a good job sending to my junk folder. However, I still get unwanted email from services I’ve done business with in the past, such as eBay, Amazon and 1800FLOWERS. While I don’t regard these messages as spam, I don’t like them, or spend the time reading them. It seems to be quite the fad to auto-subscribe you to mailing lists when you do business with an online company. Even though I have Gmail automatically label this mail as Junk, mark it as read and archive it, it’s still annoying. Looking over my mail, I would dare say that less that 1% of the mail I receive, I’m actually interested in. Yet, other services like SMS, Microblogging, IRC and IM I’m much more inclined to read, for a couple of reasons. First, the interaction behaves much the same way email does, except with Microblogging and IM, I specifically opt-in to people that I want to follow or have a conversation with. This whitelisting, effectively and totally eliminates spam, and even further unwanted data. I probably read 90% of this data, and I’m more likely to read it first before my email. With SMS and IRC, while still subject to spam abuse, IRC has been around longer than email, yet spam isn’t a problem at all in the channels I frequent. Many channels are even an invite-only status, providing a strict whitelist to the participants. I can opt-out of SMS through my cell phone provider if spam SMS becomes an issue, even notifying those sending me the SMS that I am no longer receiving them.
Truncated feeds: Truncated RSS feeds are just flat out annoying. Imagine me publishing the first 1% of my photo, and requiring you to click further to see the rest of it. Maybe I just give you the first 30 seconds of my podcast, but the rest can be found by visiting the site. This is just silly. First off, the whole point of RSS is so I can read your content without going to your site. I want a single point for my news, not several. Further, if I’m willing to share the data in the first place, it just makes sense to me to share the data in its entirety. Your content has to be exceptional for me to subscribe to a truncated feed, otherwise I don’t bother. The only truncated feed that I subscribe to intentionally is LWN.net, due to the fact they require a paid subscription to view the content. Yes, it’s that good.
Ads: I’ve grown tired of ads, and it’s not really the ad itself, as much as the abuse of ad space on websites. I don’t want to read the wrapping text around your ad. I don’t want to scroll half a page to reach your content. I don’t want your ad distracting me from my reason for visiting in the first place. Your ad should be well placed, and out of the way. Putting the ad “above the fold” makes the most logical and monetary sense, but many web admins seemed to have interpreted this as “fill the entire top half with ads, make them large, make them flash, make them animated and make the user scroll for the content”. Additionally, posts or articles that require several clicks to navigate the post, just so you can maximize your ad exposure, chap my hide. I usually look for the “Print preview” link, which will publish the content, usually sans-ads. If one such link doesn’t exist, I won’t continue out of principle. So, over the years, ads on the web have brought me to keep an aggressive ad blocker installed in my browser. You might not like that as a site owner, as the vast majority of your income is coming from the ads. I’m sorry. I hope you can find another avenue for making money. I just won’t do it.
Voicemail: I’ve grown tired of voicemail. The reason is simple- it sucks retrieving it all the time. Why? Dial the number to access it, then enter your password or PIN, then navigate an automated menu to listen, fast forward and delete or save the message. Such a pain. It’s not uncommon for me to leave 5 or 6 new voicemails in the queue before I bother clearing them out, but by the time I do, I’ve already discussed with you the reason for your voicemail, so it promptly gets deleted. I’ve come to the conclusion that I don’t leave voicemails any longer. Everyone I call has caller ID, and they’ll notice my call. If they want to speak with me, they’ll call me back. If they don’t notice my call, or if I want to speak with them, I’ll call them back. The same is true from me. When I see missed calls on my phone, I’ll call the number back usually, even if it’s from numbers I don’t recognize. I don’t need to spend 3-5 minutes listening to a voicemail, when I could call them directly, and speak to them just a quickly. I must say, however, that Vonage makes voicemail less painful, by emailing to the email address in your account an attachment in WAV format of the voicemail. This makes it easy to just pull up the email, click the attachment, and click play. However, Vonage also well tell me who called, so rather than wait for the WAV attachment to download, again I’ll just call back.

I would like to think that these dinosaur technologies are actually going the way of the dinosaur. Looking at many of the social media applications online, such as Facebook, Identi.ca, Jabber, Freenode, and others, I see no reason really to hold on or pay attention to email. Sure, there are communities on mailing lists, but there are also communities on Facebook and the other technologies with just as active posts. I could entirely eliminate email, and not even miss it. I could turn off voicemail, and still get a hold of the people that need me and the reasons they called in the first place. I’ve already eliminated ads, and RSS is opt-in, so I don’t need to subscribe to truncated feeds, or click through for content.

Just some thoughts about what is really starting to annoy me from the world of the Internet. If you’re of the same opinion or not, I would be interested in your reasoning.

2009 04 12 General Comments (14) Permalink

Ubuntu Debit Card

My bank allows customizing the front of the card with an image of your choice. So, I figured why not represent Free Software and Linux everywhere I use my card? I struggled for some time finding the right image to represent Free Software. The GNU logo is almost as horrid as Tux, the Linux kernel logo, so that was out. I thought about putting the free Debian logo on it, but if I was going to represent a specific GNU/Linux distribution, I might as well represent the one I worked so long with- Ubuntu. Plus, it will match my license plates, so why not? Well, I just got my new debit card in the mail yesterday from my bank. Here it is:

Picture of an Ubuntu logo branded debit card

2009 04 02 Ubuntu Comments (13) Permalink

Add Vim Editing Mode To Your ZSH Prompt

I’ve decided to go back to vi mode with my shell. Of course, by default, BASH, ZSH and others use emacs mode for the keyboard bindings. This is fine for the generic case, but if I’m using Vim for my default editor, it makes sense to use the Vi keyboard bindings in my shell as well. However, I have an extremely dynamic shell, so if I’m going to start using Vi mode, I better have my shell tell me when I’m in command mode or insert mode.

On Vim, the default mode is command mode, and when you go into a different mode, you’re notified, such as going into insert mode. However, with the ZSH, when you start up your prompt, you are in insert mode by default, and you must press your ESC key to go into command mode. So, seeing as though insert mode is default, rather than be notified constantly that I’m in insert mode, I’d rather be notified when I enter command mode. Also, I wanted a way to do this dynamically, so when I pressed my ESC key, I got an immediate visual that I entered command mode. The same event should happen when I go back into insert mode- my visual should disappear.

I wasn’t sure how to approach this, so after a bit of Googling, I discovered that I need to write a ZSH widget. I’ve never written a ZSH widget before. In fact, to be honest, I didn’t even know they existed. However, I was curious, and learned that I need to use the ‘zle -N’ command on a widget. By doing so, this widget will operate on the shell in real time, without waiting for the enter key to be pressed. This is exactly what I’m after. So, the only thing left to do was write a bit of logic handling when I’m in command mode, and when I’m not. Here’s the relevant bit of code:

1
2
3
4
5
6
7
8
9

# If I am using vi keys, I want to know what mode I'm currently using.

# zle-keymap-select is executed every time KEYMAP changes.

# From http://zshwiki.org/home/examples/zlewidgets

function zle-keymap-select {

    VIMODE="${${KEYMAP/vicmd/ M:command}/(main|viins)/}"

    zle reset-prompt

}

zle -N zle-keymap-select

Fairly straight forward I think. If the KEYMAP variable is set to “vicmd”, then we’re in command mode with vi on the shell, and we can set our VIMODE variable to ” M:command” (to match the rest of my prompt). If the KEYMAP variable is set to “main” or “viins”, then we can unset VIMODE. The way we do this is using inline ZSH substitution using ${VARIABLE/PATTERN} syntax. This says to search for our pattern anywhere within our variable. Check out the zshexpn(1) man page for more info and examples. Notice I’m running ‘zle reset-prompt’. Because this is a widget, I can take advantage of redrawing the prompt whenever I need. Now, the only thing left to do is put the $VIMODE variable in my prompt, and I’ll have a dynamic visual of when I enter command mode and when I leave it. Here’s some screenshot candy:

Screenshot showing a ZSH prompt without the command mode visual.

For the need-to-have-it readers, here’s the full source to my prompt. Just source the file in your .zshrc, and make sure that your TERM variable is set appropriately to handle terminal colors.

2009 03 28 Scripting Comments (2) Permalink

Spacewalk/RHN Satellite Registration Script

At work, we have an RHN satellite that is registered against RHN, and pulls down all the updates as necessary for the 32-bit and 64-bit RHEL servers that we have in our network. We currently have 34 RHEL servers in operation, with the expectation to grow past 40, all without virtualization. When we really start taking advantage of Xen and/or KVM, so our developers each have their own sandbox, our RHEL saturation will grow past 200. We need a simple way to manage this. My solution was simple: install clusterssh on my Linux desktop, then write a simple script to automate the regestration. First, the script:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#!/bin/bash

# Register the machine with the local satellite

# Replace 'server.com' with the FQDN of your satellite server

rpm -Uvh http://server.com/pub/rhn-org-trusted-ssl-cert-1.0-1.noarch.rpm

sed -i 's/https:\/\/xmlrpc.rhn.redhat.com/https:\/\/server.com/' /etc/sysconfig/rhn/up2date

sed -i 's/RHNS-CA-CERT/RHN-ORG-TRUSTED-SSL-CERT/' /etc/sysconfig/rhn/up2date

rhn_register

if rpm -q yum &> /dev/null; then

    yum clean all

    yum -y update

else

    up2date -u

fi

This script doesn’t have much to it, but it sure beats the pants off doing it manually. It installs the SSL certificate necessary for communicating with the satellite. Note: if your date timestamp is not in sync with the satellite, then the SSL certificate will fail validation against the satellite, and you won’t be able to continue. It would be ideal if you are taking advantage of NTP, encrypted or unencrypted, to keep all your dates in sync.

After installing the certificate, we make only two edits to the /etc/sysconfig/rhn/up2date file, pointing our updates to our satellite and telling it the certificate that it needs to use. After which, we run ‘rhn_register’ to register ourselves against the satellite. This will require interaction, specifying your username and password to login to the satellite, and so forth. Lastly, after the registration, we update our system to grab and install the latest packages.

Simple.

Now, with 200 possible RHEL systems, doing this on each system one by one could be problematic. My solution? I installed clusterssh to manage the large amounts of servers that I’m interacting with. I then created a .csshrc file to store all the profiles that I need. Now, when I’m ready to register the systems, I can do them in bulk, rather than one at a time. Of course, you can have X11 forwarding to your display, if you want, as clusterssh reads the standard SSH config file in your home directory, as clusterssh is just a frontend to multiple SSH connections. This could get messy though, with several popups on your desktop. Your mileage may vary.

Now, the results. I have just registered 16 RHEL 5.2 servers against my satellite in the time in would take me to do one. Good thing for good GNU/Linux tools and a little bit of hackery.

2009 03 25 Linux Comments (3) Permalink

Use The Tools

When I taught Linux system administrators, I would go through a series of rules, and rule #1 was always:

Whenever you’re editing config files, and a tool exists to make the change, use the tool instead of editing the config by hand.

The logic is easy to follow. We as humans are capable of error. Unfortunately, error happens all too often. The more we rely on ourselves to make changes by hand, rather than use an automated system, we’ll be bound for mistakes. So, use the tools are the most appropriate means for making changes to your config file in Unix and Linux

For example, editing the /etc/sudoers file. Many will just use vim or emacs, edit away, save and quit, and call it good. This is unfortunate, as your editor probably doesn’t have a syntax checker for the /etc/sudoers file. As such, you should be using the ‘visudo’ binary which does ship with a syntax checker. What about editing the /etc/passwd file? ‘usermod’ is your tool. And for the /etc/shadow file? ‘chage’ my friend. You should even use ‘postconf’ for your /etc/postfix/main.cf file. Of course, there are config files that don’t ship with an appropriate tool to edit the config file correctly. Further, there are times when editing a config file by hand is called for. However, you should be reaching for the tool first.

Now with this in mind, let me tell you an experience I had breaking this rule.

At my current place of employment, I’m in charge of several HP-UX 11v1 servers. Being new to HP-UX, I’ve been spending many an hour reading the documentation off of HP’s site, and dorking around when I have the time. It’s been a fascinating experience. Recently, I discovered that HP-UX can access software from a software repository (they refer to them as “depots”). This was great news to me, as I was getting real tired of the Bourne shell. I miss my tab-completion, inline history editing, and other shortcuts I’ve grown accustomed to. So, I looked for BASH, and it was available. I installed it using ’swinstall’, and I was up and running. Now all I needed to do was make BASH the default shell for my account and the root account, and I’d be in heaven.

It worked fine setting the shell for my unprivileged user, but not for root. Every time I ran ‘usermod -s /usr/bin/bash root’, it came back with an error saying that the root account was already logged in. Well, of course! How do you expect me to change root’s login shell? Well, rather than troubleshoot the issue, and learn if there was an appropriate way to accomplish this task, I jumped into the /etc/passwd file with vi, and edited root’s line. Except, apparently, unknown to me, I made a syntax error.

This was discovered when I wanted to login. Even after providing the password successfully, I was unable to reach a shell prompt. I tried everything I could think of to become root, but everything was failing. I thought further about single user login from a reboot. Could that even be possible? Will single user mode still process the /etc/passwd file? Frantic, I started thinking irrationally, thinking about sending a password file via SCP, FTP or NFS, logging in without creating a new login shell, and other craziness.

I was bothered the rest of the day, and through the night. I didn’t sleep well, and I was up very early before the day started to see if I could think of anything new. Thinking of sending the file via SCP, I wanted to check the permissions of /etc. I looked, and saw ‘r-xr-xr-x’. I thought this was odd, so I thought I’d look at the permissions of the passwd file itself: ‘rw-rw-rw-’. Yes, you read that correctly. Anyone and everyone on this system could edit the passwd file!!! Could this be true? I logged in as my unprivileged user, made the edit, saved the file, and exited. I still didn’t believe what just happened, so I had to cat the file out to the terminal to double-check: just in case. Sure enough, the edit stuck, and I could login as root. The unprivileged user saved the day, due to a horribly bad permission set on the /etc/passwd file.

Sometimes, it takes the worst of experiences to teach us lessons in life, and one such lesson was taught to me that I spent so much time teaching to my students. I should have spent the time learning why usermod would not let me change any login attributes for root. Rule #2 to my students was always:

If the tool doesn’t succeed, learn why.

Maybe editing the config file by hand was the appropriate solution. Maybe not. All that matters here, is I made a rash decision that could have had disastrous consequences, all because I didn’t want to use the appropriate tool or troubleshoot the problem.

2009 03 13 Linux Comments (5) Permalink

The Sheer Size of IPV6

I wanted something to sink my teeth into on just how large IPV6 really is. As such, I decided to do it graphically. Initially, this meant just representing each IP address with a single pixel. Surely, the images would be doable. However, as I started crunching the numbers, they were much larger than I thought, and I came to a very quick realization that this wouldn’t be possible. I needed to do some compression if I wanted to show it visually. So, I took advantage of compression where possible, and I let your imagination work in a couple spots where even compression won’t turn out anything reliable or representational.

To start, it’s well known that we’re running out of IPv4 addresses. IPv4 only address 2^32 possible IPs, which is 4,294,967,296. There are already 6.5 billion in the world, so we don’t even have enough IPs for 1 per person. Given the fact that many of us have more than 1 (Internet, cell phones, cable/satellite TV) and many businesses have gobbled up millions at a time, such as IBM and Sun Microsystems, we’re in trouble. It’s estimated that we’ll be out of IPv4 addresses within the next 2 years. There are things we can do to extend that life, but for the most part, it’s time to move on to IPv6. To give a visual of how much of the space is left, consider the image below.

This first image is 256×256 pixels, for a total of 65,536 pixels. As already mentioned, there are currently 4,294,967,296 possible IPv4 addresses. As such, each pixel in my image represents 256 unique IPv4 addresses. There are currently only 511 million addresses left, or about 12%. My graphic below gives an accurate representation of the exhaustion, if black is all the used addresses and white is what is available.

Now, what about IPv6? Well, to start, it addresses 2^128 possible IPs, which is 340,282,366,920,938,463,463,374,607,431,768,211,456 possible addresses. There are a lot of technical points of interest with IPv6. First, it is NOT backwards compatible with IPv4, which means we’ll be living a dual IP stack for some time. Second, 64-bits of the 128 in IPv6 are dedicated to your Ethernet hardware address, commonly referred to as the MAC address. Which means, that your ISP could give you the other 2^64, or 18,446,744,073,709,551,616 unique IP addresses when you sign up for an account. After all, as you’ll see, we have more than enough room.

This number may not look large, but I want to put it into perspective visually, so you have an idea of what we’re looking at. If each IP was a single pixel, this would produce an image 18,446,744,073,709,551,616 pixels square. Now, my monitor has the capability of showing 105 pixels per linear inch. This means my monitor would need to be 2,772,778,991,358 miles in length and width if I wanted to see the image without any scrolling. Just for comparison, a light year is 5,865,696,000,000 miles. It would take almost 6 months traveling at the speed of light to start from one end of my monitor to reach the opposite. Want an image to wrap your mind around it? The maximum distance of Pluto from our Sun is approximately 4,557,000,000 miles away. We need to do that distance about 600 times before reaching the end of my monitor. We’re still well within the Milky Way however.

Let’s get closer though. If I were to keep the same allocation of 256 IP addresses for a single pixel, as I did with my first image, then I would need a monitor capable of showing 72,057,594,037,927,936 pixels square. A linear distance of that size is about 1,083,116,793 miles across. This is slightly more doable as a visual representation. The distance from our Sun to Saturn is roughly 886 million miles. So, drive about 200 million miles further, long before we reach Uranus and we’ll reach the edge of my monitor. Want a visual representation to scale? The yellow blob on the far left, just outside the white monitor is our Sun. The pink dot on the far right just inside the monitor is Saturn. Remember, this is our monitor size if each pixel on my monitor was 256 IP addresses.

IPV6 image of 256 IP addresses per pixel shown to scale on the Solar System

Certainly, this is much too large. Can’t I get a monitor to fit on my desk? Let’s allocate the entire IPv4 space to a singe pixel on my screen. This should give us a more manageable image, no? That means that I would need an image size of 4,294,967,296 pixels square. An image of this size would require a monitor width of only 645 miles. Putting the center of the monitor in the center of the United States, and I can see that my monitor is large enough to cover 6 states in the Midwest- Nebraska, Iowa, Missouri, Kansas, Oklahoma and Arkansas. Again, remember that each pixel in my monitor would be occupying 4.2 billion IP addresses. Think any hardware manufacturer is willing to make a monitor this large for me?

IPV6 image of 2^32 IP addresses per pixel shown to scale on the United States

So, there you have it. A visual representation of IPV6 as best as I could do. Hopefully, this will help you understand just how large IPv6 is, and that I don’t expect us to run out of addresses with that vast number. Unless, of course, we enter inter-galactic communication on the same protocol.

(If I wanted to fit the entire IPv6 space on my physical monitor right now, each pixel would need to represent 192,903,836,122,980,988,357,922,113,056,557 IP addresses. Cool.)

2009 03 08 General Comments (21) Permalink

Server Migration From Ubuntu 8.04 To Debian 5.0

Last night, I spent a few hours migrating this production server from Ubuntu 8.04 “Hardy Heron” to Debian 5.0 “Lenny”. Many have asked me online and in person why I would make the switch, especially being a heavy Ubuntu advocate. I hope I can explain that in a clear manner in this post. But first, let me make it crystal clear that I’ve in no way abandoned Ubuntu or its ideals. I am running Ubuntu in VirtualBox on my work laptop, Ubuntu on my personal laptop and Ubuntu on the home desktop. I am only running Debian as servers.

So, why migrate from Ubuntu to Debian on the server? Surely, Ubuntu isn’t that bad of a server platform. You’re correct. It isn’t. In fact, it’s been “good enough” for me since installing it, which actually has an interesting history. This server came from a repossession when I used to work for a major home furnishings company in Utah. It was a home HP desktop computer that was old enough, my employer wasn’t interested in reselling it, so I asked if I could have it, and brought it home for $20.

This was back in 2005, so I put Ubuntu 5.04 on it as a desktop with XFCE as the window manager, as it’s only a Pentium 700 with at the time 128MB of RAM and a 10GB HDD. I’ve since beefed up the RAM and disk space. It was updated from 5.04 to 5.10, and it was at this time, I realised that I could ditch my then running Windows Server 2003 for Linux. So, Ubuntu 5.10 became a server, hosting my blog and a couple other web sites. When Ubuntu 6.06 LTS was released, it was running full time as my production server, and I became convinced of the LTS releases, determined to keep this server on LTS versions only. Also, I realised that it was running headless, so there was no reason to have X11 installed any longer, so I went through the pain of removing every last package that I didn’t need for a headless server. This was done for security as well as resource management.

It stayed on 6.06 LTS until 8.04 LTS released, at which point I upgraded the server yet again. So, from roughly May of 2005 to Feb 2009, it had been a desktop and a server spanning four upgrades. Not a big deal really. Upgrading servers and desktops is getting easier and easier these days, with less headaches being encountered. I would keep it on 8.04 LTS waiting for the next LTS release, and upgrade again if I hadn’t decided to change operating systems to Debian.

During the path of an Ubuntu server, it’s had some rough spots, as some of my friends can attest to, none of which were Ubuntu’s fault at all, but the system administrator hacking it (me). For example, when I wanted to host my web site on it, I needed to know how to make that happen. I found a HOWTO on howtoforge for installing Apache, as well as ISPConfig, and a number of other packages that I realise now were not necessary. In fact, I ended up removing ISPConnfig a couple years later, as it was causing problems with logs, consuming a large amount of RAM, and just getting in the way. Then I wanted to run my own email server. Not knowing how to set an email server up, I fiddled with Exim, Sendmail, Postfix and others, failing at every pass, and further causing havoc on the filesystem and DPKG database. Eventually, I found the help I needed from a friend, and was able to get a Postfix server up and running as an external MTA. There were many other services I messed with from time to time, testing this out or the other, slowly filling the filesystem with pointless stuff. In a nutshell, what I’m trying to say, is the Ubuntu 8.04 install, while functional, was no longer pretty. It was hackish at best.

This prompted me to do a reinstall of Ubuntu 8.04 LTS. I wanted a fresh, clean install, restoring the needed data from backup (yes, I actually run backups). However, as I began thinking about it, I realised that I didn’t trust the build quality of the LTS releases as much as I trusted the build quality of Debian stable releases. Thinking about it further, I was having a hard time convincing myself to run an Ubuntu server. The reason being the way packages are tested in the Debian repositories. Consider for example a package that’s uploaded to the unstable repository. Before that package can reach the testing repository, it much meet certain criteria:

After the package has been in unstable for a given length of time, it can qualify for migration to testing. This depends on each package, and the urgency of the migration.
The package can only enter testing if no new release critical bugs exist. This means, that the package must have fewer release critical bugs than the current package in testing.
All dependencies needed for the package must be satisfiable in the current testing repository. If not, those packages must be brought in at the time the current package is, and they must meet the same criteria related to time in unstable and the number of release critical bugs.
The package migrating to testing must not break any other packages currently in testing.
It must be compiled for all release architectures it claims to support, and all architecture specific packages must be brought in as well, meeting the same criteria as mentioned.

The above criteria for packages entering the testing repository ensure that packages are reaching a bug-free state for the next stable release. The goal is to have the number of release critical bugs drop and drop and drop approaching zero. Of course, bugs are only brought about by an active community reporting them, then decided on whether or not the bug is critical enough to be labelled a release critical bug. After the packages in testing have reached sufficient maturity and have few enough bugs to qualify a release, the testing repository is brought to stable. The current stable becomes “old stable”, and the current testing is reprepared for the next stable release. So, in theory, the stable distribution is STABLE. Rock sold stable. Anyone who’s anyone in the Linux world knows that Debian stable is just about as stable as you can get for an operating system.

Another nice thing with Debian stable, is it releases when it’s ready. The Debian community has taken some flack for this, with 2-3 years at times between releases. However, Debian stable is the operating system that is high production quality. While most end users tend to run testing or unstable on their desktops or laptops, many prefer stable for their production server.

Now, I ask the Ubuntu community, what are we doing to ensure the same build quality for the LTS releases? I would think that each 6 month release would hold the some criteria as Debian, namely that packages can’t enter that release unless it has fewer RC bugs than current. This way, as we approach the LTS release, we’re slowly but consistently stabilising the operating system. Unfortunately, this would mean that Ubuntu wouldn’t be as bleeding edge as it is currently. Many packages would stay rather old, due to having less RC bugs than the current release. But then, the LTS releases would be much more stable.

Now, with that said, I personally have never had any problems with my LTS server, either Dapper 6.06 or Hardy 8.04. But do I want to risk it? Should I chance it? While nothing may ever happen that causes critical concern for me with an LTS release, I feel more comfortable putting my trust in Debian stable than I do Ubuntu LTS. However, I want to see Ubuntu LTS succeed in the server arena. I was ecstatic to find that Wikimedia moved all their servers, or are moving, to Ubuntu LTS. I’ve heard other success stories of migrations to Ubuntu LTS. I think this is good, and the larger the community gets, hopefully, the more bugs will be reported, the more patches will be submitted, and more work will be done upstream to Debian. There’s no reason why Ubuntu can’t learn from Debian, and vice versa, creating a solid symbiotic relationship.

So, in a nutshell, I’ve put my faith behind Debian stable for any production servers personally, and Ubuntu for any desktops and laptops that can afford a little wiggle room in relation to stability. This is my opinion with my hardware, and your mileage will probably vary. That’s what makes our community as a whole so great. I want to see Debian succeed on the desktop, laptop and netbook arena, and I want to see Ubuntu succeed in the server / Big Iron arena, and I’ll do what I can to make that happen. But for now, I am where I am.

Any questions or comments of course, please populate the comment form below.

2009 02 19 Linux
Ubuntu Comments (19) Permalink

Debian 5.0 “Lenny” Released

Debian 5.0 Lenny Banner Debian released 5.0 codenamed “Lenny” last night, after just 1 month shy of two years since 4.0 “Etch” was released. I’ve been running it on my messaging server for nearly a year now, and it’s great. I had one hiccup with the kernel not wanting to communicate with my HappyMeal ethernet cards, but a fix in the latest release of the kernel brought it online. But, that wasn’t a Debian specific bug, so I can say that for me, 5.0 has been rocking! Of course, Debian stable is a thoroughly tested platform, so I’m not concerned about its stability.

Some notes about it’s release. This is a GNU/Linux release which supports 12 CPU architectures (1 up from 4.0 “Etch”), ships with four desktop environments and strictly adheres to the FSH 2.3 and LSB 3.2 standards. 23,000 binary packages come from 12,000 source packages, making it one of the top distributions shipping the most software. Most software in this release is the latest version or one release old, and thoroughly tested. 5.0 only shipped with only about 120 outstanding RC bugs. The KVM and Xen hypervisors are shipped, as well as improved support for laptop power management and even adding netbook support. The Debian installer now supports installing important security updates before the first reboot of the system. In terms of continued security, many SETUID binary executables have been removed and Debian GNU/Linux is now listening on fewer ports with a default install than previous. Lastly, live images have shipped with 5.0, making it easy to test Debian GNU/Linux without installing it on your system. Kernel version 2.6.26 is the shipped kernel.

As with every Debian stable release, this is a thoroughly tested, highly featured, stable release on par with the most advance “Enterprise” Linux distributions. As with every stable release, you can easily upgrade to 5.0 by changing your /etc/apt/sources.list, and running ‘aptitude update’ and ‘aptitude full-upgrade’ as root from the terminal. If your sources.list already is using “stable’ as it’s repository, then you’ll get the upgrade automatically.

This is a well received release. As you can see, a lot has gone into it, and the Debian Developers have done a good job putting it together. The next stable release, codenamed “squeeze” is now the current testing repository, and hopefully will be out sooner than later. Put this on your servers, if you haven’t already, because you know you can kick a Debian stable box, and it’ll keep humming right along.

Congrats everyone on a solid release!

2009 02 15 Linux Comments (5) Permalink

Aaron Toponce