Moonlight Sonata

With help from the project wiki, I succeeded in configuring MPD on my server. Then I installed the Sonata client on my laptop. However, it refused to connect. When I ran it from a terminal, I saw this message:

[Errno 111] Connection refused

I guessed there was a problem with my server configuration, but I didn't know what it was. Luckily the troubleshooting section of the wiki pointed out that bind_to_address should not be set to "localhost" if you want to connect from a client on another host. I commented out that line and got a connection the next time I started Sonata.

It's Alsa Confusing

I decided to install the ubuntu-desktop metapackage on top of my existing Ubuntu Server system. Since the tower is already hooked up to a KVM, I sometimes find it useful to sit down in front of it and use it as a desktop instead of connecting via ssh.

Unfortunately, sound did not work out of the box, despite the fact that ubuntu-desktop has dependencies on ALSA and PulseAudio. I was pleased to find that the solution was relatively easy. I only had to fire up alsamixer, unmute PCM, and raise the volume. My next task is to get Music Player Daemon (MPD) working.

Suspended Animation

I read somewhere that you can specify the resume device that uswsusp uses by UUID. I edited my config as follows:

josh@penryn64:~$ cat /etc/uswsusp.conf
# /etc/uswsusp.conf(8) -- Configuration file for s2disk/s2both
resume device = /dev/disk/by-uuid/ba2d5cd5-fd65-46c6-9be1-70851d8038f2
splash = y
compress = y
early writeout = y
image size = 1427192791
RSA key file = /etc/uswsusp.key
shutdown method = platform

It seems to work. There are no errors in /var/log/pm-suspend.log.

Permission to Land

Last week, I installed CentOS on my old tower. The installation was a breeze. However, afterward, I was annoyed to find that sshd prompted me for a password, even though I had appended my public key to ~/.ssh/authorized_keys on the server. As it often is, the solution was simple.

I spotted the problem in /var/log/secure:

Jul 1 22:08:44 madhatter sshd[25996]: Authentication refused: bad ownership or modes for file /home/josh/.ssh/authorized_keys

I had the wrong permissions on my .ssh directory and my authorized_keys file.

chmod 755 ~/.ssh

and

chmod 644 ~/.ssh/authorized_keys

did the trick.

Temporary Like Achilles

Today I got a perfect demonstration of why you want /tmp and /var/tmp on a separate partition in any serious server installation.

It came at an inopportune moment, as I was already cursing at Amarok 2 for its failure to copy all the music from my Creative Zen to my laptop. I discovered a way to downgrade to Amarok 1.4, but when I went to run Synaptic I got an error: "Failed to run /usr/sbin/synaptic as user root. Unable to copy the user's Xauthorization file." I tried it a few more times with the same results.

After Googling for an answer, I came upon a forum post that suggested I might be out of disk space. So I checked. Yep, sure enough, something had barfed about 2.3 GB into my 8-GB root partition. It was almost completely full.

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             7.6G  7.2G     0 100% /
tmpfs                 1.5G     0  1.5G   0% /lib/init/rw
varrun                1.5G  164K  1.5G   1% /var/run
varlock               1.5G     0  1.5G   0% /var/lock
udev                  1.5G  164K  1.5G   1% /dev
tmpfs                 1.5G  1.7M  1.5G   1% /dev/shm
lrm                   1.5G  2.5M  1.5G   1% /lib/modules/2.6.28-13-generic/volatile
/dev/sda1             111M   28M   77M  27% /boot
/dev/sda6             129G   71G   51G  59% /home

I went on the hunt for the offending files. With the du command, it didn't take long to find them—in a directory called /tmp/kde-josh/amarok4ddofD, of course. (Curse you, Amarok 2!) They were all the MP3s I had been trying to copy to my home directory but somehow never made it there. I removed them in a hurry and breathed a sigh of relief.

Now to see if the Amarok downgrade worked…

Adventures in Gentoo

I made some abortive attempts at installing Gentoo on my old PowerBook G4 a few years back. I haven't fooled around with it since. I decided to give Gentoo another chance, so I popped the 20090616 minimal install CD into my old Pentium II tower.

I was unsurprised to meet with trouble running a bleeding edge kernel on legacy hardware. Here are the issues I encountered and how I solved them:

1. I get an error that says, "Undefined Video Mode Number: 317." I pressed Enter to see the list of available modes. After some quick calculations, I decided 80x43 (option 2) was most appropriate for my monitor dimensions. It looks okay, so I'll stick with that setting.
   
2. The install CD hangs at wd7000 while loading the kernel modules. A bug report pointed me to a segfault that occurs when the pata_qdi module loads. Booting with the kernel option noload=pata_qdi results in a successful boot.
3. Near the end of the boot sequence, I see, "ERROR: cannot start nfsmount as rpc.statd could not start." A comment on another bug report indicates that setting RC_NET_STRICT_CHECKING="yes" in /etc/conf.d/rc allows NFS to start at boot time. I never had to do this because the error disappeared after installation.
   
4. Throughout the installation process, my hard disk was detected as /dev/hda. However, when I finished installing GRUB and rebooted, I got an error:
   
   
   CHECKING ROOT FILESYSTEM...
   
   fsck.ext3: No such file or directory while trying to open /dev/hda3
   
   /dev/hda3:
   
   The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock:
   
   e2fsck -b 8193 <device>
   
   * filesystem could not be fixed.
   
   I soon realized that my new Gentoo system, unlike the install CD, was using SCSI emulation. As a result, it detected my hard disk as /dev/sda instead of /dev/hda. I popped in the install CD, rebooted, and went through the process of mounting my filesystems and chrooting again. Then I simply changed every occurrence of hda in /etc/fstab to sda. For some reason, GRUB had automagically updated /boot/grub/menu.lst with the sda names, so there was nothing to do there.
   
   After one more reboot, everything is hunky dory.
   

GNOME Appearance Properties pegs CPU

After experimenting with Openbox for a while, I got frustrated and returned to GNOME. However, I discovered that every time I ran gnome-appearance-properties, it would use 100% of the CPU time—and, to make matters worse, the process would fail to terminate after I closed the window. I also noticed I couldn't change my theme to anything besides Clearlooks.

I did some Googling and came up with a solution.

1. Remove GTK-Qt Theme Engine and GTK Theme Switch. If you're using GNOME, you probably don't need these packages.
   

   sudo apt-get autoremove gtk-qt-engine gtk-theme-switch

2. Get rid of your gtkrc-2.0 file. You could rename it or just blow it away, depending on how confident you are that you won't need it again.
   

   mv ~/.gtkrc-2.0 ~/.gtkrc-2.0.bad

Samba and UFW

Earlier today, I found myself frustrated because I could not see my Samba shares when browsing my network in Nautilus. It turned out to be a firewall issue.

From The Official Samba 3.2.x HOWTO and Reference Guide:

Many people use a firewall to deny access to services they do not want exposed outside their network. This can be a good idea, although I recommend using it in conjunction with the above methods so you are protected even if your firewall is not active for some reason.

If you are setting up a firewall, you need to know what TCP and UDP ports to allow and block. Samba uses the following:

Port 135/TCP - used by smbd
Port 137/UDP - used by nmbd
Port 138/UDP - used by nmbd
Port 139/TCP - used by smbd
Port 445/TCP - used by smbd

The last one is important because many older firewall setups may not be aware of it, given that this port was only added to the protocol in recent years.

When configuring a firewall, the high order ports (1024-65535) are often used for outgoing connections and therefore should be permitted through the firewall. It is prudent to block incoming packets on the high order ports except for established connections.

In order to open these ports, you must run the following commands:

sudo ufw allow proto tcp to any port 135 from 192.168.1.0/24
sudo ufw allow proto udp to any port 137 from 192.168.1.0/24
sudo ufw allow proto udp to any port 138 from 192.168.1.0/24
sudo ufw allow proto tcp to any port 139 from 192.168.1.0/24
sudo ufw allow proto tcp to any port 445 from 192.168.1.0/24

Of course, you should replace 192.168.1.0/24 with the appropriate IP/CIDR subnet for your network.

Generally speaking, I find it useful to add rules by service whenever possible. For example, if I want to open up ports for AOL/AIM, I can add this rule:

sudo ufw allow aol

The syntax is much less verbose and thus easier to remember. You can see a list of all service names by doing

less /etc/services

Not everything will be listed, but most common services are.

Entering Unicode characters in Pidgin IM

For a long time, I didn't know how to type Unicode characters in the Pidgin IM client. Apparently, all I had to do was read the FAQ:

Entering character codes works differently in GTK+; press Ctrl+Shift+u and then type the Unicode number (in hexadecimal) with Ctrl and Shift held down. GTK+ 2.10.0 and later versions do not require Ctrl and Shift to be held down while typing the number. For example, Alt-164 would become Ctrl+Shift+u, f1.