Peregrine

This past weekend, I flew to Dallas, Texas in order to take the exams necessary for the RHEL6 version of the Red Hat Certified Engineer (RHCE) certification. I found out Monday morning (when I looked at the email they had sent me Friday evening) that I passed.

There’s sure been a lot of change in the 8 + years since I was awarded my first RHCE (back on Red Hat Linux 9). I proctored the certification exams for RHL9, RHEL3 and RHEL4 as well as beta versions for both RHEL4 and RHEL5. The whole process, the delivery method and even much content has evolved, but I think RHEL6 introduced some of the biggest changes yet. Of course, I cannot go into details beyond anything that Red Hat has already published on their web site, so I won’t.

I upgraded my HP Compaq 6715b from openSUSE 11.1 to openSUSE 11.2 on Tuesday. There have been a couple of minor bumps since, but all-in-all, I’m pretty happy with the upgrade. Here are some of the things that I’ve seen.
Read the rest of this entry »

Earlier tonight, Some friends told me that they saw a couple of emails they sent to me bounced back at them. I wrote about what happens “When Maildrop Fills a Log File” on one of my other blogs. Well, it’s happened again a couple of times since then. It’s happened again just a few days ago (ls showed -rw------- 1 lamontp lamontp 51200000 Nov 6 11:19 .maildrop.log).

That’s enough! I’ve had it; I’m going to prevent this from bothering me again.

Well, the right way to fix this is to grab a clue-bat and use it on the Maildrop developer(s) who decided that hardcoding a 50 MB log file size limit into Maildrop was a good idea, until they change their mind(s). Seriously, though, I’m going to send them a patch for this lame duck.

In the meantime, I’ve written rotate-user-maildrop-logs, a shell script to place into your /etc/cron.daily/ (or similar) directory. I am releasing this under the terms of the GNU General Public License, version 3 (a.k.a. GPLv3).

I really like Maildrop. It’s great for me, but it’s not for everyone. For example, my wife isn’t going to sit down and use vi (or any other text editor) to maintain her very own ~/.mailfilter file. For this reason, I will be switching to Sieve in the near future, using the Cyrus IMAP server instead of Dovecot, which I’ve been very happy with.

Is that the time? OK, maybe I’ll have to write that patch for Maildrop on Saturday.

It’s been bugging me for months that I had Adobe Flash in Konqueror (my favorite browser on Linux) working just fine under openSUSE 10.3 and 11.0, but with 11.1 it just couldn’t find the plug-in. I’ve just never had the time at the moments I ran into it to go hunting down a solution, until the other night. Some Googling didn’t help at all, just people saying that it wasn’t working in Konqueror although it was just fine on other browsers. So I left it for later.

This morning, at work, I’ve had a quiet moment so I thought I would open up my notebook and look at some code. When I woke it up, there was Konqueror (I was upgrading blogs last night). So, I thought, oh, let’s look at the list of plug-in directories. There was an entry for /usr/lib64/browser-plugins/wrapped/ which doesn’t exist, but not one for the /usr/lib64/browser-plugins/ directory, which does. I added an entry for /usr/lib64/browser-plugins/, clicked the Scan for New Plugins button and restarted Konqueror.

That’s all it took. It works.

Now, I just have to go file a bug report with a fix in their bugzilla. I love Free & Open Source Software.

Visit [ http://www.utosc.com/ ] for the details.

This year, I’m not doing any presentation. I have some ideas for next year.

I will be running the keysigning party on Friday, October 9 at 7:15pm at the conference. I’m stepping into doing this a bit last minute, so we’re going to provide some additional info and the instructions for the keysigning party on the UTOSC website should be updated very soon.

To participate, just show up. If you want help generating a key pair and getting started, there will be several people there who can assist you, just be sure to bring your own notebook computer. If you have keys, please, email me your full key ID (not a short or medium) at keysigning@openbrainstem.net. It is a good idea to digitally sign that email. If you have multiple keys, include them all. I actually have three separate keys these days and 2 of them have multiple IDs associated with them.

(and PGP) allow us to digitally sign messages (usually email, but can be used with other communications systems, too), code and other documents. It also let’s us encrypt files, emails and just about anything else. This is an extremely important technology for a lot of reasons, some of which I’ve discussed in past articles on this blog (and others). Defending our privacy and ensuring the integrity of our personal, family and business communications is vital. We sign each other’s keys to build a “web of trust.” This is the critical step that makes the whole thing usable.

If you have never used PGP or GPG (a.k.a. GnuPG, Gnu Privacy Guard) before, visit the GnuPG website for a basic description of how to generate your key pair.

If you have never participated in a keysigning party, check out the Keysigning Party HOWTO and/or [ http://keysigning.org/ ].

Immediately following the Utah Open Source Conference 2007 keysigning party, I wrote a simple script to help help you sign-lots-o-keys. You can download the script from [ http://www.openbrainstem.net/download/sign-lots-o-keys ]. If I have time before the keyparty in just two days, I have some little updates that I would like to implement in that script. But don’t hold your breath. Perhaps there will be time at the conference on Saturday?

So, please, plan on joining us on Friday. These are always good fun.

My dual Opteron workstation has been around for nearly 5 years now. It’s had some bumps and bruises along the way (some of which were due to my own actions), but has been a great machine. It still has very good performance, especially given it’s age.

When I first built it in May of 2004, Fedora Core 2 was barely out and was the first Fedora to sport an AMD64 (x86_64) 64-bit version. That was the first and last time that I installed Linux on this box, from scratch. Since then, I’ve upgraded it to FC3, FC4, FC5, F6, F7, F8 and now F9 (I will upgrade to F10 in a week or so).

When I installed FC2, I used the ext3 filesystem for the root volume (I use LVM). I "converted" the root volume to the XFS filesystem on 2006/08/03. I also created a few volumes using XFS and reiserfs (v3.6) filesystems.

Over time, I’ve had a few minor problems with XFS. Recently, those problems grew in regards to the root volume to the point where I needed to convert it to something else, which I did the other day. The root volume is now on reiserfs. That leaves just 3 volumes that are still XFS.

After upgrading to F9 and installing updates, there were a couple of weird issues that I was dealing with. I also kept seeing some filesystem corruption messages (on the terminal, in the logs) for XFS volumes (but they don’t tell you which one). That’s it, I’m done with this XFS thing, so I’m going to convert those filesystems over to something else and get rid of XFS on this workstation.
Read the rest of this entry »

A few weeks ago, I was looking through some Netfilter documentation, just poking around, looking at some modules I’ve never seen/played-with/hear-of and I came across the recent module. I decided to try it out on one of my servers that gets anywhere from zero (0) to tens of thousands of crack attempts via SSH per day and see if I could weed out some of these bot-nets. It also occurs to me that this could help fight email SPAM-bots, too.

Of course, it’s very important to have good, strong password security practices. If you have poor passwords, none of this will matter, as you’ve probably already been compromised whether you know it or not. This means that all users have to have strong passwords. Techniques for helping users to create and use strong passwords are beyond the scope of this article, but I will write about these things in the near future.
Read the rest of this entry »

In dealing with nVidia and ATI drivers for Linux (both a kernel and X driver are needed), I’ve been using the Livna YUM repositories for Fedora to easily install them as RPMs using YUM.

I’ve run into trouble here and there as the Livna folks keep pulling RPMs from their repos for older versions of the kernels. At the very least, they should leave the kmod-* packages in there for the original kernels that shipped with each release. Then, people can install a release and get a good driver. I had to wait for about 3 weeks after I first put F7 on my home workstation (dual AMD Opteron) before I could get the nVidia driver from Livna because they didn’t have one for the older kernel packages and the newer kernels weren’t booting (turned out to be malformed initrd files, which I later fixed).

Yes, I understand that they take up some disk space, but it’s not really that much perhaps 100M per release to keep all kmod-* packages and their dependencies around.

Livna, if you’re listening, please, give us all the driver packages and don’t remove them. You don’t know which kernels are working for people and which aren’t, so you could really be making things pretty difficult for people.

A few minutes ago, I installed the kdebluetooth package. I was already logged in, so I had to launch the kbluetooth applet myself. I then clicked K Menu -> System -> KInputWizard, pressed the “reset” button on the bottom of my mouse and clicked “Add” in the Input Devices dialog. My mouse was discovered and I connected to it. Simple as that.

I have a Logitech bluetooth mouse that travels with me. I use it with my notebook computer, as I’m very, very not fond of trackpads. My favorite is the “TrackPoint” or “Eraser-head” mouse built into the keyboard, but this notebook didn’t come with one. Supposedly, I can buy a replacement keyboard from HP that includes the eraser-head pointer, but I have not yet done so.

When I wrote about installing Fedora 7 on this notebook (and now installing Fedora 8), one thing which I never documented was how I got the bluetooth mouse working with Linux (under F7). Now that I installed F8 from scratch, I need to set it up again.

When I installed F7, I spent hours dog-paddling through Google searches and horrible documentation and still hadn’t figured it out. Then, my friend and co-worker, Clint Savage (a.k.a. Herlo) popped into the office. It was him! He’s the one who has the exact same mouse as I do; I knew I’d seen it somewhere before I had bought mine. So, I asked him. He smiled and laughed, saying, “Not finding much useful documentation out there, eh?” He’d been through the same thing as me. He was impressed with how far I’d gotten through that process and estimated that I was probably 1-3 hours away from finding it myself, if I continued to follow the pattern he had. Well, he shared the information with me.

The good news was that it was pretty easy to get my bluetooth mouse talking with my bluetooth equipped notebook, just not really documented anywhere that one could point to just one thing (boy, I wish I’d documented those commands in a blog post; I’ll see if I can do just that next week, when I’m back at the office). The bad news was that one of them had to be run every time he started his computer. So, I put that command into a /root/bin/connect-to-my-bluetooth-mouse (or something like that) script. Then, a week later, I forgot to run that when I booted up and logged in, once, but was using the mouse anyway. I had discovered that it wasn’t necessary to run that all the time.

One of the reasons that it had been so difficult to setup bluetooth on Fedora 7 was that I was using GNOME on that installation. I stuck with entirely GNOME apps (except for Kdevelop) the entire time I had F7 on this notebook. Now that I have F8, I’ve gone back to KDE, which makes life so much better for me. GNOME still doesn’t have much bluetooth support and what is there is still very early half-baked and non-usable, for the most part. KDE’s bluetooth tools, on the other hand, seem much more comprehensive and “just work” for me.

The fact that Fedora (and by extension, RHEL, CentOS, etc.), supports bi-arch platforms is a great thing. However, it does get to be very irritating when YUM decides that it should just pull in 32bit versions on a system with no other 32 bit packages. I’ve experienced this problem during installations, as anaconda now uses YUM to process package selections (since FC5).

It doesn’t stop with just anaconda installation and yum update commands, either. Almost every yum install command that I run decides to install both 64-bit and 32-bit packages. That is, unless I explicitly specify that I only want the 64-bit for each and every package. For example:

# yum install foo.x86_64 bar.x86_64

Why is yum doing this? It didn’t used to. I started experiencing this a little bit on FC6, but F7 and F8 both have horrific troubles with it. I need to do some more digging through Red Hat’s Bugzilla bug/issue tracking system, however, my first pass didn’t find anything to help explain the changes. After a little more research, I’ll file this as a bug.

In the meantime, here’s a quick-n-dirty hack I put together to run updates. The first step is to capture the output of yum update to a file (be patient, this command can take for-freakin-ever to run). Step two is to run the update itself. Here it is as a shell script:

#/bin/bash
# Get a temporary file to use.
TO_UPDATE="$(mktemp)"

# Populate the temporary file with the list of available updates.
yes n | yum update > ${TO_UPDATE}

# Composite an update command that does not include any 32-bit stuff.
yum update $(for i in $(sed '/i[3456]86/d' ${TO_UPDATE} |
         sed '/^Updating/d' |
         sed '/^Installing/d' |
         grep -v "^$" |
         grep -v replacing |
         cut -d" " -f2); do
      rpm -q --qf "%{name}.%{arch}\n" $i; done |
   grep -v "is not installed$")

# Optional cleanup.
if [ "${1}" = "-k" ]; then
   mv ${TO_UPDATE} /root/$(date --iso-8601)-$(basename ${TO_UPDATE})
else
   rm ${TO_UPDATE}
fi

You will have to run a separate yum update command for any 32-bit stuff you really do have installed and want to update.

I know this could be streamlined (especially the part that constructs the yum update command), but as I’m not planing on making this a permanent fix, I’m just not going to bother with it right now. Still, feel free to comment or trackback with other solutions or optimizations of mine.