Ubuntu asking for the CD to install software

Sometimes I ask apt-get or synaptic to install something, and it asks for the CD. Turns out that this is an easily-remedied nuisance. A fosswire post (which I found by way of fsdaily) gives a GUI-based solution. An equivalent solution is to comment out the line in /etc/apt/sources.list which starts w/ 'deb cdrom:' (that's probably line 1).

Ubuntu firewall

This post offers a way of telling your Ubuntu system to set up a simple firewall at boot time. It assumes that you have a single network adapter called eth0.

I saved my firewall rules (in iptables-save format) to /etc/network/fwrules. My firewall rules are fairly specific to my setup, but the following might serve as a good starting point if you want to try this:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT 
-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT 
COMMIT

And then I just saved the following to /etc/network/if-pre-up.d/fw:

#!/bin/bash

iptables-restore < /etc/network/fwrules

(Be sure to make this file executable: sudo chmod 755 /etc/network/if-pre-up.d/fw).

This loads the firewall rules prior to bringing up the network interface, so that the firewall is in place by the time the network connection is active.

udev in Ubuntu

This post will be a recipe for configuring udev in Ubuntu so that if you plug in a USB storage device (like a flash drive, an MP3 player, etc.), it will get a consistent and predictable device name which you can attache as a non-root user to a fixed mount point. I'll be using my new Verbatim thumb drive as an example.

Plug in the flash drive, wait a few seconds, and type 'dmesg | tail'. The last few lines should show the USB system detecting the device and giving it the first available device name. In my case, the flash drive got /dev/sdd. Next, ask udevinfo for details about the device:

udevinfo -a -p $( udevinfo -q path -n /dev/sdd ) | less

Page through the output looking for the device's values for idVendor and idProduct. The udevinfo output for my thumb drive contained the following lines:

   ATTRS{idProduct}=="1e23"
   ATTRS{idVendor}=="13fe"

Next thing is to tell udev about the device. Create a udev rule file (I used /etc/udev/rules.d/99-thumb.rules) with something like the following:

SUBSYSTEMS=="usb", SYSFS{idVendor}=="13fe", SYSFS{idProduct}=="1e23", NAME="thumb", MODE="0660" OWNER="mbrisby" GROUP="mbrisby"

(Naturally, replace mbrisby with your username and group name.) You may need to run udevcontrol reload_rules to tell udev to read the new addition into its in-memory ruleset.

Now you can make a mount point:

$ sudo mkdir /media/thumb
$ sudo chown mbrisby.mbrisby /media/thumb

Finally, add the mount point to /etc/fstab:

/dev/thumb /media/thumb vfat user,noauto 0 0

And from now on, you should be able to plug in the thumb drive, wait a couple of seconds, type mount /media/thumb, and start accessing the files at /media/thumb.

fetchmail in Ubuntu

I recently wrote about using fetchmail for gmail. In the meantime I've switched my main desktop (at home) from CentOS to Ubuntu. Ubuntu's fetchmail build is a bit more picky about SSL certificates than the CentOS build, so this post will describe some of the changes I had to make to my ~/.fetchmailrc file.

(By the way, fetchmail should work OK without these changes, it'll just whine about the certificates.)

First I needed to install the ca-certificates package from the Ubuntu repositories, and then I needed to change the gmail line of my ~/.fetchmailrc file from

poll imap.gmail.com protocol IMAP user "my_gmail_username@gmail.com" there with password "my_password" nofetchall keep ssl

to

poll imap.gmail.com protocol IMAP user "my_gmail_username@gmail.com" there with password "my_password" nofetchall keep ssl sslcertck sslcertpath /etc/ssl/certs

This tells fetchmail where to find the public certificate it needs to verify the SSL connection to the gmail server.

I also use fetchmail to check some IMAP accounts on a server using self-signed certificates, certificates which don't appear in /etc/ssl/certs. One way of doing this is to compute the IMAP certificate's fingerprint and telling that to fetchmail. If the IMAP server is imap.example.com and it's running on the standard port (993), you can use openssl to grab the certificate like this:

openssl s_client -ign_eof -connect imap.example.com:993 > imap.cert

(You may need to Contol-C to get back to the command prompt.)
Then use openssl to find the MD5 fingerprint:

openssl x509 -fingerprint -md5 -in imap.cert

The output of this latter command should contain a line starting with MD5 Fingerprint. Add the fingerprint to your ~/.fetchmailrc file with something like this:

poll mail.example.com via imap.example.com protocol IMAP user mbrisby there with password "my_password" nofetchall nokeep ssl sslfingerprint "4C:69:E2:E6:F9:6B:6C:4E:E9:8B:E1:C8:2B:B9:4F:B9"

And then just run fetchmail in cron every now and then.

desktop Ubuntu

I recently converted my laptop from CentOS 5 to Ubuntu 7.10 and liked the change. So I did the same to my main desktop at home this weekend. Naturally, there were a few bumps in the road. Over the next several days I'll be posting about some of them.

But first, a couple of annoyances.

Ubuntu likes to beep. It rings the system bell a lot more than CentOS seemed to do: tab completion at the bash prompt, unsuccessful page text searches in Firefox, trying to go past the end of the file in vim, etc. It really enjoyed beeping at me, and putting set bell-style none in ~/.inputrc didn't help much.

It turns out to be a kernel module. A post in Dell's Linux desktop forums suggested modprobe -r pcspkr, and that worked right away. The post also suggests putting blacklist pcspkr in a file in /etc/modprobe.d to make the change permanent (I haven't rebooted yet, but I figure that oughtta do it.)

The other annoyance is that Ubuntu's grep isn't compiled with libpcre support (that's the Perl-compatible regular expression library). One of the bash scripts I use for backups has a grep -P in it. The -P options tells grep to regard the search pattern as a Perl-style regex. This gives the following charming error message:

The -P option is not supported

Someone else noticed this and filed a bug report. Looks like the Ubuntu developers aren't interested in fixing it in this version. Someone suggested installing the pcregrep package, but this has a few problems:

1. the binary is installed as /usr/bin/pcregrep
2. pcregrep doesn't have the same performance or options as grep
3. oddly, pcregrep doesn't accept the -P option (you'd think it would just ignore it)

So pcregrep is hardly a drop-in replacement for grep, even if you rename the binary to /bin/grep.

As it happens, I got lucky. My the regex in my bash script is dull enough that I was able to replace grep -P with egrep. But if you use something more sophisticated, you'll have a harder time of it.

But all in all, I'm enjoying my shiny new Ubuntu installation. I'll be back later to yammer on about using udev, fetchmail, iptables, and maybe some other stuff in Ubuntu.

Inspekt PHP library

A recent post on the Planet-Websecurity.org blog got me interested in Inspekt. It's a secure input validation library for PHP. It reminds me a bit of Perl's taint switch, in that Inspekt prevents you from directly using $_POST, $_GET, and their ilk.

Looks like it hasn't really hit release status yet, but I think it's going to be worth watching.

Ubuntu

I finally gave Ubuntu a try recently. I'd previously tried it as a VMWare Server guest and hated it. But that probably wasn't a fair shake, so I installed it on my laptop last week. I was really impressed by how easy it was to get everything set up. It only took a few hours to get it installed and pretty highly customized with some of my favorite packages, including gtkpod, grip, easytag, mplayer, fluxbox, VMWare Server, gkrellm (and a few of its plugins), and grisbi.

About the only thing that really took a while was getting fluxbox to work, and that's because Ubuntu does it rather differently than CentOS (what I'm used to). It took me a little while to realize that I needed to be using ~/.fluxbox/startup rather than ~/.Xclients, and it took me forever to cotton on to the fact that the ~/.fluxbox/keys syntax had changed between v0.9.x and v1.0.x. I'd never had the following three lines in my keys file before, but they're pretty important (you can't easily get to the fluxbox menu without them):

OnDesktop Mouse1 :HideMenus
OnDesktop Mouse2 :Workspacemenu
OnDesktop Mouse3 :RootMenu

About the only thing I couldn't do was install native drivers for one of my wireless cards. I have two cards: a Linksys WPC11v4 802.11b card and a Netgear 802.11g card. The Linksys card has open-source drivers which support monitor mode (so that I can run kismet), while the Netgear card only has Windows drivers. It was very easy getting ndiswrapper and wpa_supplicant set up for the Netgear card, but I never got the Linksys drivers working. Looks like other people have had the same trouble, and the solution may be to try a different kernel. Oh, well.

Anyway, it was all pretty easy, and I may start using Ubuntu on all my desktops. And O'Reilly's Ubuntu Hacks was pretty helpful.

fetchmail for gmail

If you have lots of email accounts, it can be a real pain checking all of them. But if you're running a mail server on a Linux box somewhere (like postfix on your workstation at home, for example), you can use fetchmail to download the messages from your IMAP and POP3 mail accounts. That way, all your mail is in one place (and you only have to go to one place to read it).

gmail recently added IMAP support (it's one of the tabs under Settings). Once you enable IMAP support in your gmail account, you could add something like the following to your ~/.fetchmailrc file:

poll imap.gmail.com protocol IMAP user "my_gmail_username@gmail.com" there with password "my_password" nofetchall keep ssl

nofetchall just gets the new messages, keep prevents fetchmail from deleting the messages off your gmail account (so that you can still read them by logging on the gmail), and ssl keeps your password encrypted when fetchmail connects to gmail. Then just run fetchmail -s in cron every now and then.

Something to keep in mind is that although this won't delete your messages from gmail, it'll mark them as read. So if you log in to gmail, new messages won't look new, they'll look read (because fetchmail has read them).