When installing a configuring Subversion to work through Apache, you might get an error like this when attempting to start up httpd:

Cannot load /etc/httpd/modules/mod_dav_svn.so into server: /etc/httpd/modules/mod_dav_svn.so: undefined symbol: dav_xml_get_cdata

Please note! Some people have indicated that this is because Apache wasn’t configured with DAV support when it was compiled on your distro. The answer might be a lot simpler than that.

Garrett Rooney noted that it might be as simple as just making sure that mod_dav is loaded before loading mod_dav_svn! I was experiencing this error, and a simple rearrangement of my LoadModule commands in httpd.conf fixed it.

New Atlanta supports only Fedora Core 1, 2, and 3. This is sad, since Fedora Core 6 came out recently.

BlueDragon 6.2 and 7 beta don’t appear to work on Fedora Core 5 and 6, but just because they come with Apache 2.2. The installer script crashes initially, but with this Installer Setting Hack, the installer will be able to install BlueDragon. That’s fine and good, but once it runs, the mod_servletexec.so and mod_servletexec2.so files freak out when you actually try to start up HTTPD with BlueDragon. This appears to be caused by an updated version of the APR package (Apache Portable Runtime library). It’s pretty much a roadblock to installing BlueDragon on FC5 or FC6 unless you manually install Apache 2.0.

All of that said, Fedora Core 4 is the most modern version of this flavor of Linux that can run BlueDragon easily. But there is one serious problem with BlueDragon on FC4.

Some issue with Java 1.4.2 on FC4 causes it to want to look to IPv6 sockets instead of IPv4 sockets, which causes problems, like errors that say something like this:

java.net.SocketException: Invalid argument or cannot assign requested address

This problem is broader than just BlueDragon, but BlueDragon is how I found out about it. Because of this problem, BlueDragon has trouble stopping its service and possibly trouble starting sometimes.

I learned about this problem on this forum thread, which led me to a blog post called Fedora Core 4 and JDK 1.4.2 Problems, where a fix is described that basically tells Java to prefer the IPv4 stack over the IPv6 one by including -Djava.net.preferIPv4Stack=true as a parameter in your Java call to your app.

To apply this to BlueDragon, we have to modify the StartBlueDragon.sh and StopBlueDragon.sh scripts, which are used for starting and stopping the service. They are located under ~/BlueDragonInstallation/bin/.

In StartBlueDragon.sh, modify this line (addition in bold) near the bottom of the file:

“$JAVA_HOME/bin/java” -server -Djava.net.preferIPv4Stack=true $HEAPSIZES $OPTIONS -classpath “$NEW_CLASSPATH” com.newatlanta.webserver.BlueDragon &

In StopBlueDragon.sh, modify this line (addition in bold) near the bottom of the file:

“$JAVA_HOME/bin/java” -server -Djava.net.preferIPv4Stack=true -classpath “$NEW_CLASSPATH” StopServletExec -host 127.0.0.1:8080

After saving these files, you should now be able to successfully stop or restart the BlueDragon_Server service.

I have a server that has 2 IDE channels, no spare IDE cards, and 4 hard drives that I want to be running. This will obviously take up all 4 drive spaces in my 2 IDE channels. But to install the OS, I will need to use one of those spaces for the CD-ROM drive, meaning I can only install the OS with 3 of the drives.

To put the fourth drive in there, I would remove the CD-ROM drive after installation of the OS and put in the fourth hard drive. So how do I configure Linux to recognize the fourth and final drive? On my Fedora Core system, it’s easy. These steps will assume the drive is already partitioned and formatted.

The mount point. First, make the directory for the mount point. For instance, I’ll create a directory in the /mnt directory:

mkdir /mnt/mynewdrive

The fstab entry. You’ll have to know which letter your drive has been assigned, and the partition number of your volume. Likely, it will be hdd, since hda, hdb, and hdc will be assigned to the first three. And if the drive is just one large partition, it will obviously be partition 1. So, the desired volume in this instance would be hdd1. Thus, you can map /dev/hdd1 to the /mnt/mynewdrive directory by editing /etc/fstab with the following line:

/dev/hdd1 /mnt/mynewdrive ext3 defaults 1 1

Naturally, substitute ext3 with whatever filesystem you’re using, if different.

You could avoid using an editor to make this change by doing a command like this:

echo /dev/hdd1 /mnt/mynewdrive ext3 defaults 1 1 >> /etc/fstab

First-time mount. Then, simply call a mount command:

mount /mnt/mynewdrive

You’ll only have to do this the first time. If you have automounting set up, the drive will automount in the future.

This is primarily a reminder for myself. If you’re not authenticating against a database or network directory store, your web app may need to just authenticate against a standard Linux password file.

Creating one is easy:

htpasswd -c [filename] [username]

After prompting you for the desired password for this user, it will create the file (or wipe it out if it exists), and insert the user with the password, naturally encrypted.

Go without the -c parameter to add additional users to an existing password file. Finally, use a -d parameter to delete a certain user from a password file.