Hudson, SmartFoxServer, Plink, and Running Command as Local System Account

SmartFoxServer is a platform for developing massively multi-user applications. SmartFoxServer is a Java application and supports calling extensions in Java, Action Script, and Python. As a Java application, SmartFoxServer runs well on Windows or Linux.

Ryzing tested running SmartFoxServer on Windows and Linux. We ended up using an Amazon EC2 instance running Ubuntu Linux to host the SmartFoxServer. SmartFoxServer interprets the Action Script extensions. You cannot compile the extensions. SmartFoxServer caches all the Action Script extensions. The server will not reload the extensions if they change. SmartFox developed an admin Flash client application to manage the SmartFoxServer. You can use the Flash admin client to force extensions to reload.

I designed the Hudson build process at Ryzing to push the SmartFoxServer extensions to the Linux server. Fortunately, SmartFox implemented a set of command line tools in addition to the Flash client. The process of pushing the extensions to the server is a simple task in Hudson.

1. Extract the source from SVN
2. Rename some files to match the destination server
3. Push the sources to the server using PSCP
4. Reset the SmartFoxServer

Pscp is an implementation of scp or secure copy that runs on Windows. Pscp is one of the tools included with Putty. The process should be simple. However, there is a problem. The first time Putty, Pscp, or Plink connects to a server, they cache the host key in the registry. You get something like the following.

The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is.
The server's rsa2 key fingerprint is:
ssh-rsa 2048 hh:hh:hh:hh:hh:hh:hh:hh:hh:hh:hh:hh:hh:hh:hh:hh
If you trust this host, enter "y" to add the key to
PuTTY's cache and carry on connecting.
If you want to carry on connecting just once, without
adding the key to the cache, enter "n".
If you do not trust this host, press Return to abandon the
connection.
Store key in cache? (y/n)

Putty, Pscp, and Plink support a batch option. With the batch option, if the host key is not in the registry cache Putty, Pscp, and Plink automatically exit. The problem is the registry cache is user specific. This causes a problem with Hudson installed as a service running on Windows. When installed as a service, Hudson runs as the Local System Account. Running Pscp as a task in a Hudson project will lock up waiting for the user to press "Y" or "N". If you add the option to run as batch, the command will always fail.

How do you install the host key in the registry for the Local System Account? I am sure there are other solutions. The one I found was to open a command prompt as the Local System Account. Unfortunately, this is not as simple as it sounds. I finally found the solution here: http://johnnycoder.com/blog/2008/11/10/run-cmdexe-as-local-system-account/.

The solution is to use psexec.exe, which is part of PsTools from SysInternals. Microsoft acquired Sysinternals in July 2006. The following opens a command prompt as the Local System Account.

psexec -i -s cmd.exe

After the command window opens, attempt to connect via Pscp or Plink. Answer "Y" to "Store key in cache?"

Now Hudson can copy the files from SVN to the Linux server and restart SmartFoxServer.

Using Hudson for Unusual Tasks

Martin Fowler wrote, "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly." (http://martinfowler.com/articles/continuousIntegration.html)

Hudson is a continuous integration solution. "In a nutshell, Hudson provides an easy-to-use so-called continuous integration system, making it easier for developers to integrate changes to the project, and making it easier for users to obtain a fresh build." (http://wiki.hudson-ci.org/display/HUDSON/Meet+Hudson)

I found somewhat unusual uses for Hudson.

Ryzing follows a standard development setup with a set of servers (or chain) for each stage of development: Alpha, Quality Assurance (or QA), and Production. We chose the Amazon Cloud to host the servers. Three chains mean three separate databases running on three separate database servers. I firmly believe in automating routine tasks. A daily backup is definitely a routine task. My solution to automating the backups was to use our Hudson server.

The Ryzing applications use PostgreSQL as the database server. I installed the full PostgreSQL tool set on the Windows 2008 server dedicated to running Hudson (http://www.postgresql.org/download/windows). I made sure that both the Windows firewall and the Amazon security zones allowed the build server to talk to the database servers in the Alpha, QA, and Production chains.

The project in Hudson is simple. The build process uses a Windows batch command. Below are the commands I used.

SET PGPASSWORD=PASSWORD
"C:\Program Files\PostgreSQL\8.4\bin\pg_dump.exe" --no-password --file=DATABASENAME.backup --format=c --host=HOSTNAME --port=HOSTPORT -U USERNAME DATABASENAME

You will need to set the appropriate password, database name, host name, user name, and host port. I checked a Post-Build action to Archive the Artifacts telling Hudson to archive DATABASENAME.backup. I selected the build trigger of building periodically. Each morning the build server runs the backup on each database.

Hudson provides a convenient place to store the database backups along with all our software builds.