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).

Bats in the belfry

The other day I read that DC Comics is planning to 'promote' Bruce Wayne to the ranks of the New Gods. Despite the departure of Bruce Wayne, there will still be a Batman to watch over Gotham City. The role will be filled by Jason Todd, the second Robin.

Jason Todd was murdered by the Joker (beaten to death with a crowbar, if memory serves).

If the last couple of paragraphs don't make any sense to you, then you and I are of like mind.

This sounds like a publicity stunt to me, like when DC briefly killed Superman in the early 90s.

Guess they're running out of ideas over there.

Lame OpenDocument Foundation Blathering

I recently wrote about some strange announcements from the OpenDocument Foundation (which has since totally dissolved), and I said I didn't know what that meant for the OpenDocument format (ODF).

Not much, it seems. An Antic Disposition post has clarified the matter somewhat:

The adoption of the ODF standard is promoted by several organizations, most prominently the ODF Alliance (with over 400 organizational members in 52 countries), the OpenDocument Fellowship (around 100 individual members) and the OpenDoc Society (a new group with a Northern European focus, with around 50 organizational members). To put this in perspective, the OpenDocument Foundation, before it changed its mission and dissolved, had only 3 members.

Origin of Kryptonite

According to Wikipedia, Kryptonite (a fictional mineral, the green variety of which is toxic to Superman) was originally introduced in 1943 (about five years after Superman's first appearance in comic books) in the radio show. It was a plot device used to allow the actor portraying Superman the opportunity to take some vacation time.

Wacky.

trac: backups, Gantt plugin, concluding remarks

This is the third installment of a series on trac, Web-based pr0ject management software. The previous segments talked about installing and using trac.

trac comes with a command-line utility called trac-admin, which can (among other things) perform backups of individual trac projects. The following is a shell script you could put in /etc/cron.daily to back up all your trac projects each night:

#!/bin/bash

TRAC_ROOT=/var/www/trac/tracroot
TRAC_BAC_ROOT=/var/trac_bac

TODAY=$( date +%Y%m%d%H%M%S )
mkdir -p $TRAC_BAC_ROOT/$TODAY
for i in $TRAC_ROOT/*
do
 DEST=$TRAC_BAC_ROOT/$TODAY/$( basename $i )
 DEST_TARGZ=${DEST}.tar.gz
 /usr/bin/trac-admin $i hotcopy $DEST
 tar czf $DEST_TARGZ $DEST
 rm -rf $DEST
done

This uses the trac-admin hotcopy feature to make a compressed archive of each individual project (putting them in time/date-labeled directories in /var/trac_bac).

This series discussed the WebAdmin plugin. I also tried the TracGantt plugin, which makes Gantt charts of your project. I found that I didn't much care for this plugin. You have to enter an extra four data fields for each ticket, one of which is a list of ticket dependencies (e.g., completion of this ticket is dependent on completion of that ticket). The Gantt charts don't clearly display these ticket dependencies, so it seems like a wasted effort. And for a large project, the chart becomes too big for useful printouts, and the plugin doesn't offer exports in other formats. So TracGantt didn't really do it for me. shrug

In closing, I really like trac, and it's been very helpful to me in my work. Clearly, trac is designed to manage software development projects. But with a little imagination, I think it could be used quite effectively to manage just about any kind of project, even something as simple as a running 'to-do' list.

Using trac

In a previous post, I described installing trac, a Web-based project management system.

Now you can go to http://myserver.org/trac/ (substituting your server's hostname, of course), and you should see a link for your project. Clicking the link takes you to that project's homepage, which is a wiki. You can use this to provide as much or as little documentation as you like for your project.

One of the first things you'll want to do is to click the Admin link (upper-right, which would not be present without the WebAdmin plugin). The main admin page lets you set the name, URL, and description of your project. Clicking the Permissions link (left-hand side) lets you change who has what permissions to the project. By default, anonymous users have just about every right--you will probably want to revoke these rights, and then just dole them out on a per-user as-needed basis (for example, you may want to give people testing your project permission to create tickets). The WebAdmin plugin also lets you manage components, versions, milestones, and other items through the Web interface (you'd otherwise have to use the trac-admin command-line tool for all that).

The Browse Source link lets you poke around in your repository, even looking at the different revisions.

But my favorite feature is the ability to create and manage tickets. Clicking the New Ticket link lets you create a new ticket, in which you can enter a description of a problem with your project, the affected version, the relevant component, etc. (most of these fields are optional). And the View Tickets link lets you run pre-configured queries to display your tickets (you can also create your own custom ticket queries, but I've found the default set perfectly adequate).

Installing trac

I started using trac a few weeks ago, and now I don't know what I did without it. It's great for project management. trac is a multi-user Web-based ticket-tracking system which has a built-in wiki, integrates with Subversion, and offers a wide array of plugins.

It's written in python. Oh, well. Nothing is perfect.

Here I'll be describing how to install trac v0.10 with the WebAdmin plugin on CentOS 5. We'll pretend to be installing it at http://myserver.org/trac/ (upcoming posts will talk about using and maintaining trac).

Start by installing the trac and python-clearsilver RPMs from the EPEL repositories. This will add the /etc/httpd/conf.d/trac.conf file to your Apache configuration. I suggest replacing the default contents of that file with the following:

<LocationMatch /trac>
SetHandler mod_python
PythonInterpreter main_interpreter
PythonHandler trac.web.modpython_frontend
PythonOption TracEnvParentDir /var/www/trac/tracroot
PythonOption TracUriRoot /trac
SetEnv PYTHON_EGG_CACHE /var/www/trac/egg_cache
AuthType Basic
AuthName trac
AuthUserFile /var/www/trac/htpasswd
Require valid-user
</LocationMatch>

(Don't forget to restart Apache to make the new configuration take effect.)

I'll be putting all the trac files in /var/www/trac (outside the Apache docroot at /var/www/html). Each trac project will have its own directory in /var/www/trac/tracroot, and the subversion repository will be at /var/www/trac/svn.

The 'egg cache' (I guess that's some wierd Python drivel) will be at /var/www/trac/egg_cache. The egg cache is for plugins. It's actually not necessary for the WebAdmin plugin, but you may as well set it up, anyway, in case you want to add other plugins. It needs to be Apache-writeable: chown -R apache.apache /var/www/trac/egg_cache.

You'll notice that I've set up Basic Apache authentication. Use the command-line htpasswd command (part of the httpd package) to create and maintain the /var/www/trac/htpasswd. In my case, I created a user called carl: htpasswd -c /var/www/trac/htpasswd carl

If you want to use the Subversion integration, put your repository at /var/www/trac/svn (either drop in a hotcopy or use svnadmin load /var/www/trac/svn). Remember to make it Apache-writeable: chown -R apache.apache /var/www/trac/svn.

To install the WebAdmin plugin, you'll need setuptools. Download ez_setup.py and run
python ez_setup.py (this is all described on the TracPlugins node of the trac wiki). This installs the easy_install utility. Running easy_install http://svn.edgewall.com/repos/trac/sandbox/webadmin should install the plugin (verify the URL on the WebAdmin wiki node). Now you'll need to enable the plugin by adding the following text to /usr/share/trac/conf/trac.ini (this file probably doesn't exist yet, so you'll be creating it):

[components]
webadmin.* = enabled

You'll probably need another Apache restart at this point (editing /usr/share/trac/conf/trac.ini seems to require an Apache restart).

And now we can actually create a trac project. We'll call it foo, for laughs:

trac-admin /var/www/trac/tracroot/foo initenv

This will ask you a few questions (I'm assuming that your Subversion repository is set up such that there's a foo item just under the repository root, and that it corresponds to this trac project):

• project name: keep this short but descriptive
• DB connection string: just use the default (SQLite)
• repository type: use the default if you're doing the Subversion integration
• repository path: /var/www/trac/svn/foo
• templates: use the default

Your answers are used to create a project configuration file at /var/www/trac/tracroot/foo/conf/trac.ini. You can later edit this file by hand, but if you change the repository location (the repository_dir item), you'll need to run the following command:

trac-admin /var/www/trac/tracroot/foo resync

Now give yourself administrative rights to the project (using the same username you used with the htpasswd command, above):

trac-admin /var/www/trac/tracroot/foo permission add carl TRAC_ADMIN

Well, this has already run pretty long, so I'll break for now. In the next exciting episode, I'll talk a bit about actually using trac.

OpenDocument Foundation reversal

At times on this blog I've discussed the open document format (ODF), an XML-based file format intended to be used in office productivity software (word processors, spreadsheets, and the like). This file format would be a completely open standard, and would compete with proprietary file format like those used in Microsoft Office.

A major proponent of this format, the OpenDocument Foundation, has evidently recently decided to dump ODF in favor of an obscure alternative called the Compound Document Format, developed by the World Wide Web Consortium. So now I really don't know what to think. I wonder if the foundation will change its name.

Microsoft (with their OOXML format) must be having a good laugh about this.

perl breakage

I run a bunch of CentOS 4 boxes at work, and recent yum updates to perl caused me a lot of problems. If I tried doing just about anything in cpan, I'd get errors like this:

Use of uninitialized value in concatenation (.) or string at
/path/to/Scalar/Util.pm line 30.

and this

Undefined subroutine &Compress::Zlib::gzopen ...

After several Web searches, I found a Google Groups posting which recommended manually installing Scalar::List::Utils.

I have no idea what Scalar::List::Utils has to do with anything, but it seemed
to work. Thank you, Peter Scott.

If you try this, and the Compress::Zlib::gzopen errors persist, you could try the following (admittedly drastic) measure. It was successful for me in one case where just installing Scalar::List::Utils wasn't enough (for whatever reason). Try running the following search against your perl libraries (might be in a different directory on a non-RedHat-like distribution):

find /usr/lib/perl5/ -type f -path '*Compress/Zlib.pm'

Delete or rename the Zlib.pm files found, and then try 'install Compress::Zlib' in cpan (you may need to 'force install Compress::Zlib').

identity theft

Bruce Schneier has posted about a report giving some interesting statistics about identity theft.

lock pick gun

Here's an interesting video showing someone defeating 8 locks in less than 80 seconds. The person in the video is using a lock pick gun. I'd only seen these in movies and TV before this. I don't really understand how the thing works, but it may be similar to bumping. Note the use of the torsion wrench in the video.

Nuke Anything Enhanced Firefox Extension

One of my favorite Firefox extensions is Nuke Anything Enhanced. After installing this extension, right-clicking on something on a Web page gives a menu including an item called 'Remove this object'. Picking that item makes the object disappear.

This is useful sites like The Energy Blog. That's a great site, but there's always a really annoying vertical animated gif banner on the right-hand side. This extensions makes it easy to do away with such things.

mailinator

Every now and then I want to access content or a service on a Web site which requires registration with an email address (for example, live365.com started requiring registration a couple of days ago, and many online newspaper Web sites do this). I used to always give a fake address, for fear that the site will sell my address to spammers, or that the site will send me a bunch of promotional junk I don't want. But that doesn't always work. Sometimes the site requires a valid address so that they can send me something that I need to complete the registration. In this case, mailinator.com is a good way around this problem.

If you go to mailinator.com, it auto-generates an email address for you in the form of something@mailinator.com (you can also make up your own), and you can give that address when registering for the newspaper (or whatever) Web site. Then just go to mailinator.com and check for mail sent to that address. There's no username and password, so you wouldn't want to use it as an actual email account or for anything confidential (anyone who knows your mailinator address can read your mail). But it's a good throwaway email account, so that you don't have to give your real address.

(In fairness to live365, they don't appear to have sent me any mail at all after registering.)