the

Little Projects

of Shawn M. Jones

Recently, I had to set up Samba on a new CentOS 5 system. Samba is used to provide Windows file sharing from non-Windows systems and can be quite a pain to set up. Red Hat, from whom CentOS is derived, has included a default configuration that works pretty well out of the box for what most people use Samba for: sharing home directories.

So, I fired it up and found that I could browse the shares on the server from my Windows XP system, but got the following message when I tried to open one of them (Iris is the name of the file server.):

Iris is not accessible. You might not have permission to use this network resource. Access is denied.

After beating up Google a bit, I decided to actually journey into the smb.conf file again and noticed that Red Hat had left a comment about SELinux.

Viola! Typing the following solved my problem:
/usr/sbin/setsebool -P samba_enable_home_dirs on

I noticed when ripping and encoding my CD collection that GRIP crashed on certain CDs. Thinking this had to do with poor handling of CD scratches, I started setting CDs aside.

I should have known better. Having used it for years, I’d never seen this behavior before in GRIP.

It turns out that there is a buffer overflow that manifests itself when the genre of the music is set to something “nonstandard”, so, as a workaround, I have to check and sometimes set the genre on CDs to “Alternative” or another “standard” genre.

This isn’t really a problem solved, but more a problem identified and worked around. There is a patch in Ubuntu to fix this problem, but I guess it hasn’t made it into my version (Intrepid Ibex) yet.

Ref: https://bugs.launchpad.net/ubuntu/+source/grip/+bug/283658

This is a relatively simple trick, but one that I thought was rather clever.

I needed to SSH into a target server (172.16.4.1) that only allowed connections from a specific IP address (172.16.4.10). I knew that the system holding that specific IP address was down, yet I still needed to SSH into the target.

To further complicate matters, I did not have physical access to the target network at the time. But, I did have remote access (and root) to another Linux box on the network.

Hmmm…

So, all I needed to do was change the IP address of my one good box to the one expected by the target system, but if I changed the IP address on the main interface, then I would disconnect myself.

Enter virtual interfaces and routing.

I created a new virtual interface with ifconfig (assuming 172.16.4.10 is the IP we want to come from):

/sbin/ifconfig eth0:1 172.16.4.10

This does not, however, mean that my SSH connection will come from this address, so I needed to change the routing table (assuming 172.16.4.1 is what we want to connect to):

/sbin/route add -host 172.16.4.1 eth0:1

Now, I will effectively be coming from my new interface when I connect to the target server.

So, today I decided to set about the task of backing up my Gmail to my home server. I pay Google for 99% uptime, and really don’t expect their service to fail, but I have to account for more likely scenarios. For example, I may conceivably delete a message and find out I need it later; or, I may not want to keep a message on Gmail anymore but still need to retain it.

The players in this setup are a server running CentOS 5.2 and Gmail itself. My plan is to create a cron job that backs up the email at some fixed interval (daily) and saves it to a folder. At some point, I will back that up to DVD in case I or Gmail lose everything one day.

Gmail Backup runs on Windows and Linux. Gmail Backup does something that fetchmail or other solutions fail to provide: your Gmail labels are actually stored. This made it appear to be a better solution overall, so I decided to give it a whirl.

It is written in Python and requires Python to run on Linux (the Windows version is compiled). Unfortunately for me, the Python that comes with CentOS 5.2 is Python 2.4.3 and Gmail Backup requires Python 2.5.

I could just rip out the Python 2.4.3 libraries and replace them with Python 2.5 libs, but that would create problems for some of CentOS’s native utilties. So, I’ve installed Python 2.5 and wxpython in a different directory on my server and pointed Gmail Backup at the correct Python files.

According to the documentation, I just needed to run:

gmail-backup.sh backup my-backup-directory gmail-username gmail-password

The first attempt at running Gmail Backup met with failure:

Error: IMAP: [ALERT] Invalid credentials (Failure)

which I realized was because the shell was not escaping the ! in my password, so I changed the password.

Then I got:

ValueError: time data did not match format:  data=XXXXX  fmt=%Y%m%d

The XXXXX was the last half of my new password, which had a space in it. I consider this a bug in the implementation of Gmail Backup. I’ll contact the author with a fix later. So, I removed the space from my password.

That did it. Off I went. Gmail Backup nicely put my email into a directory. Each message is stored as a text file in directories indexed by year and date. All of the labels are stored in a text file.

Restoring to Gmail is as easy as:

gmail-backup.sh restore my-backup-directory gmail-username gmail-password

With a little scripting and a cron job, now I can automate Gmail Backup with a script, having it create periodic backups of all of my messages, then compressing the backup directory into one big file for storage and offloading.

Thanks Gmail Backup for making this so much easier!

So, as noted in earlier posts, I decided the best way to share files between my Ubuntu 8.10 and Windows XP installations on my laptop was to use an NTFS partition for my home directory/My Documents.

Unfortunately, applications like wine issue serious warning messages or refuse to function all together.

Being lazy, I ignored this until I needed one of these applications.

At current, I’m attempting to mount the partitions with specified permissions and ownership.

UUID=4F975E2D139676A9 /media/HOME     ntfs    defaults,umask=077,uid=1000,gid=1000 0       1

The important entries are:

• umask=077-This entry sets the permissions on all NTFS-mounted files and folders such that only the owner has access. This satisfies many applications, such as ssh, that require that files are only accessible to their owner.
• uid=1000-This entry sets the ownership on all NTFS-mounted files and folders such that the owner is me. This solution is only useful because I’m the only one using this machine.
• gid=1000-This entry sets the group for all NTFS-mounted files and folders such that the group is my primary group. This solution is only useful because I’m the only one using this machine.

This allows wine to work and gets rid of messages from gdm. I’m not sure what other applications may object to these permissions being set as such on the home directory. If I want to run anything on files in the home directory that relies on a user other than me (such as a web server), it won’t work.