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.

A few days ago at work, I went to connect to a headless server at work, and it indicated that I couldn’t connect because all the Terminal Services connections were in use. What now?

There are graceful ways around the issue. You can (a) Reset one of the connections remotely, freeing up room for you, or (b) Connect to the computer’s console session and then reset the sessions from a GUI interface.

Resetting connections remotely. This method is more graceful, but requires a bit more work. As Scott Forsyth described in Managing Terminal Services Sessions Remotely, the qwinsta (query windows station) and rwinsta (reset windows station) commands can help you accomplish this.

Use qwinsta to find a session to clear, or reset:

C:>qwinsta /server:MyServerName
SESSIONNAME USERNAME ID STATE TYPE DEVICE
0 Disc rdpwd
rdp-tcp 65536 Listen rdpwd
console 5 Conn wdcon
rdp-tcp#59 MyUserName 2 Active rdpwd

In this example, “MyUserName” has a session, and I could clear that session to take it’s place. To do that, I would use rwinsta to clear the session, which has an ID of 2:

C:>rwinsta 2 /server:MyServerName /V
Resetting session ID 2
Session ID 2 has been reset

With the session being reset, I could now successfully login with Remote Desktop.

Connecting to a console session. Windows will always have a console session, which is the session that represents the session outputting to the physical monitor, if one were plugged in. If a user were logged into the machine and physically using the mouse, keyboard, and monitor that are plugged into the machine, and you then connected remotely to the console session, their session would be disconnected and you would connect to that console session. Obviously, this is not the typical approach you would want to take, but it is an option when you need to force yourself onto the computer.

Basically, this is accomplished by running Remote Desktop from the command line (mstsc) and invoking the command line argument to connect to the console session.

mstsc -v:MyServerName -console

That’s all there is to it! At that point, you can either proceed with your work or use the console session to clear any other Terminal Services sessions in the Terminal Services control panel.

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.

It’s easy to backup or restore your database directly with SQL.

backup database MyDatabase TO DISK=‘c:pathtoMyDatabase.bak’ with INIT

The syntax is pretty self-explanatory once you see it. Backup the database “TO DISK”, or to a file at the designated path. The “WITH INIT” specifies that any existing backup file will be overwritten.

The restore syntax is nearly identical. If the database you are restoring currently exists, be sure to drop the database before doing the restore.

restore database MyDatabase FROM DISK=‘c:pathtoMyDatabase.bak’

Simple as that.