There have been a few times now that I needed to start a VMware virtual machine on my server but I wasn't on a PC that had the VMware console installed. Besides, unless I'm on my own network, starting up a server with the VMware console can be a pain due to slower upstream speeds.

Well, I finally took the time to find out how to do this from the command line. It's simple.

Get the current state of the virtual machine. Is it running or not?

And start it.

There are many other things you can do as well. Just man vmware-cmd.

For the life of me, I couldn't figure out why I was unable to checkout from my Subversion repository while I was at work. It worked while I was at home (where my Subversion server is) just a few days ago, and I can view the repository using Subversion's built-in web page functionality, but if I tried to access the repository from the command-line client or TortoiseSVN, I would get an error message.

C:>svn co http://MyServer/Path/To/Proj/ MyProj
svn: REPORT request failed on '/Proj/!svn/vcc/default'
svn: REPORT of '/Proj/!svn/vcc/default': 400 Bad Request (http://MyServer)

Yeah, that's not cryptic. Fortunately, the solution is simple. Sander Striker explained in a thread REPORT request failed ... 400 Bad Request that if you're behind a proxy at work, and the proxy isn't configured to support the necessary Subversion calls REPORT, your request will fail.

Like he says in his message, you could request that the proxy be configured to allow the necessary requests, but you could just as well configure your server to work on a different port. Now, I like the fact that my Subversion calls can work on port 80, and I don't want to change that. So, I configured Apache to have my Subversion sites work on an additional port.

In the following example, let's use port 81 as the additional port. So my example URL http://MyServer/Path/To/Proj/ would become http://MyServer:81/Path/To/Proj/.

At the following spots in your httpd.conf file, make the one-time additions as marked in bold italics:

Listen 80
Listen 81

And...

NameVirtualHost *:80
NameVirtualHost *:81

And for every virtual host entry you have for a Subversion site (I host a couple different Subversion sites), add *:81 in the VirtualHost header:

< VirtualHost *:80 *:81 >

After restarting Apache, you will now be able to continue to use the URLs you normally use, but anytime you need to checkout from the repository while at work behind a proxy, you can use port 81 to do so successfully.

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.