/dev/sda missing but system works

I ran into a strange problem yesterday, where a Linux system was able to boot from its SATA drive, and everything seemed fully functional. However, there was no entry for /dev/sda (the usual entry for the first SATA drive). Thus, I could not use fdisk to create a new partition. It turns out there is a script called MAKEDEV which solved this problem for me. I simply ran `cd /dev; MAKEDEV sda` and the entry was created. fdisk worked just fine.

Advertisements

Email archiving: PST to mbox

I usually create folders into which email gets sorted – either by me or by some program like sieve – which are valuable during the lifetime of some project. When that project ends, however, the only thing that mail is good for is aiding my poor memory. Thus, I might as well have it in a great big text file so it becomes easier to search, i.e., grep. It turns out that the “E” command in pine, if executed while a folder is selected, will do just that. Finally, something simple. 🙂 What is actually happening is that there exists a format called “mbox” which is a one-flat-file-per-folder email structure. This is great, as it is effective both while the folder is in active use and for searching once the folder is just an archive.

I also had a lot of old old email on an old machine which runs MS Outlook. I was able to successfully convert all that mail to flat files also. I exported all the mail into a “pst” file, which is the format which Outlook uses to store its mail. I then copied the pst file to my linux machine, where I used a utility called “readpst” to convert the archive file into a series of files, each of which is an mbox file containing the contents of each folder from my pst file. This is the default behavior, and it was exactly what I wanted. “readpst” is available as a Debian package, so you can just `apt-get install` it. Sweet.

The coolest part about all of this is that these “mbox” files are compatible with just about anything, so if I ever want to bring all that mail back into a nice graphical client, it should be easy.

Grub – Error 18

I recently received this error while trying to install Debian on an older Dell Machine. Section 14.3 of the Grub manual says:

18 : Selected cylinder exceeds maximum supported by BIOS
This error is returned when a read is attempted at a linear block address beyond the end of the BIOS translated area. This generally happens if your disk is larger than the BIOS can handle (512MB for (E)IDE disks on older machines or larger than 8GB in general).

I updated the BIOS but this did not solve my problem. Finally, I thought that perhaps things would work if I made a small /boot partition as /dev/hda1. I made a 1GB partition of that sort, and everything worked swimmingly. I never found any instructions or howtos which said this would help. Boo to the world.

DOS Boot CD and BIOS Upgrade

Some dude named Bart made this page which allows one to make a bootable CD-ROM which will yield a DOS prompt. This enabled me to upgrade the BIOS in an older Dell computer system without getting tangled up in the headaches of floppy disks (namely, that there weren’t any computers around that could read or write them). I downloaded 3 files: bcd111.zip, bfd107.zip, and cdromsi.zip, and unzipped them all into the same directory, c:\bcd. Bart also wanted me to download wnaspi32.dll from Nero. The link was broken but I searched my local hard drive and I already had a copy of that file into c:\bcd\bin. I then copied the actual BIOS flash utility from Dell, g1_a10.exe, into C:\bfd107\cds\cdromsi\files. I ran `bcd cdromsi` from a command prompt on my Windows XP system, and shockingly it burned me a CD. The CD booted, and I had to select “no emm386” for the BIOS flasher to be happy. I then executed r:\g1_a10.ece and successfully flashed the BIOS. Thank you Bart.

Apache2, Subversion, and SSL

So I am a big SVN fan, and I’m also a big fan of reasonably secure network traffic, so I prefer to use SVN over an SSL connection. The webserver I’m using is Apache2. The purpose of this post is to remind myself about the steps required to get SVN working via SSL only, as right now I have to diligently remember to use https:// instead of http:// when I do an SVN checkout.

The first step was to create a self-signed certificate for use with SSL. I could have paid some entity like VeriSign to give me a signed certificate, but VeriSign doesn’t really add much security. This page told me how to create the cert, the relevant commands from which I show here. I ran these commands with the working directory /etc/apache2/ssl.

Create the RSA keypair:

openssl genrsa 1024 > host.key
chmod 400 host.key

Create the self-signed certificate using that key (note that a certificate of this nature is just a certificate-signing-request that is signed; that used to confuse me):

openssl req -new -x509 -nodes -sha1 -days 365 -key host.key > host.cert

It is also necessary to modify your apache configuration to use SSL.
Apache needs to have the ssl, dav_svn, and auth_digest modules to
work correctly with SVN over SSL. Under Debian, at least, there exist
packages for all of these so installation is trivial.

Edit /etc/apache2/ports.conf and add port 443, which is the default for SSL.

Now, it is necessary to make the SVN config entries for Apache2. My goal is for SVN to work via SSL only, so, e.g., svn checkout http://host.com/svn/REPOS will FAIL, but svn checkout https://host.com/svn/REPOS will succeed.

To achieve this, I created a new virtual host for Apache2. I.e., I created a new config file /etc/apache2/sites-available/010-ssl. I picked 010 because duplicating 000 seemed bad. I have no other explanation. I then symlinked that file to ../sites-enabled/. The contents of the file are the following:


NameVirtualHost *:443
<VirtualHost *:443>
ServerName mccune.ece.cmu.edu
SSLEngine on
DocumentRoot /var/www/
SSLCertificateFile /etc/apache2/ssl/host.cert
SSLCertificateKeyFile /etc/apache2/ssl/host.key

# Subversion
<Location /svn>
DAV svn
SVNParentPath /var/lib/svn
# our access control policy
AuthzSVNAccessFile /var/lib/svn/access

# try anonymous access first, resort to real
# authentication if necessary.
Satisfy Any
Require valid-user

# how to authenticate a user
AuthType Digest
AuthName "Subversion"
AuthDigestFile /var/lib/svn/users
AuthDigestDomain http://mccune.ece.cmu.edu/
</Location>

# websvn
<Location /wsvn/>
SVNParentPath /var/lib/svn
# our access control policy
AuthzSVNAccessFile /var/lib/svn/access

# try anonymous access first, resort to real
# authentication if necessary.
Satisfy Any
Require valid-user

# how to authenticate a user
AuthType Digest
AuthName "Subversion"
AuthDigestFile /var/lib/svn/users
AuthDigestDomain /
BrowserMatch "MSIE" AuthDigestEnableQueryStringHack=On # IE digest workaround
</Location>

</VirtualHost>

I also like the WebSVN interface, the configuration entries for which are also included. Be sure to restart apache, `/etc/init.d/apache2 restart`. You should be good to go.

Life is not always so simple, and I received the following error when trying to do an SVN checkout using https://


jmmccune@mccune(/tmp)% svn checkout https://mccune.ece.cmu.edu/svn/REPOS
Authentication realm: Subversion
Password for 'jmmccune':
svn: PROPFIND request failed on '/svn/REPOS'
svn: PROPFIND of '/svn/REPOS': 500 Internal Server Error (https://mccune.ece.cmu.edu)

A look in /var/log/apache2/error.log showed me the following:


[Fri Jan 20 15:24:01 2006] [error] [client 127.0.0.1] (20014)Error string not specified yet: Berkeley DB error for filesystem /var/lib/svn/REPOS/db while opening environment:\nDB_VERSION_MISMATCH: Database environment version mismatch
[Fri Jan 20 15:24:01 2006] [error] [client 127.0.0.1] Could not fetch resource information. [500, #0]
[Fri Jan 20 15:24:01 2006] [error] [client 127.0.0.1] Could not open the requested SVN filesystem [500, #160029]
[Fri Jan 20 15:24:01 2006] [error] [client 127.0.0.1] Could not open the requested SVN filesystem [500, #160029]

There was some kind of version mismatch, for which Google didn’t really offer any helpful solutions. I ended up doing an `aptitude update; aptitude upgrade` on my Debian system, which I’d been meaning to do anyways. After that the error persisted, but I blew away the repository and created a new one, and I had no further problems. I realize this is an undesirable solution if the repository is already up and running, but I did all this config on a non-critical machine first to see how it might impact a critical machine.

exim4 configuration

I am resisting an overwhelming desire to curse exim4, as I don’t know anything about it and its design will probably make sense once I understand it. However, my goal was extraordinarily simple: I want to be able to send mail from the command line using the `mailx` command. After a good half hour of Googling for results that were useless, with the exception of telling me I probably needed to configure exim4. I never did figure that out with Google. I logged into another host where mailx does work and grepped for the name of my SMTP server. Well, the answer is simple. Edit /etc/exim4/update-exim4.conf.conf according to the comments inside. Then, run the /usr/sbin/update-exim4.conf (yes that’s executable). Don’t forget to also run`/etc/init.d/exim4 restart`.

And maybe, just maybe, I was setting this up for use from a CGI script. Here are the Apache docs on enabling CGI.