Windows Agent

The Windows version of the agent is currently under development. The original approach was to use an msi installer to run a VBscript, which would use the command line interface to the Windows task scheduler to schedule the running of an agent script repeatedly for a given time interval. However, due to problems with timing of the script invocation as well as issues in the scripting environment, the agent is now being implemented in the form of a Windows service in VB. As a service, the agent will be running continuously, but only fire the script after a defined interval (currently 10 seconds).

Some useful (and some not so useful) links about Windows services:

• http://msdn2.microsoft.com/en-us/library/d56de412(VS.80).aspx

• http://www.montgomerysoftware.com/CreatingWindowsServiceInCSharp.aspx

• http://weblogs.asp.net/jgalloway/archive/2005/10/24/428303.aspx

• http://support.microsoft.com/kb/317421

• http://www.devarticles.com/c/a/VB.Net/Creating-A-Windows-Service-in-VB.NET/

• http://aspalliance.com/1316_Working_with_Windows_Service_Using_Visual_Studio_2005.4

One should be particularly careful when developing a Windows service in Visual Studio 2005, particularly if the service will use a timer to perform a specified task periodically. Many tutorials, especially those dealing with earlier versions, advise the user to drag a timer object out of the toolbox in the design view of a service. There is a bug in VS2005 that creates the wrong type of timer when this method is used. This results in the service appearing to run as normal once installed, but the timer never fires, and hence the task triggered by the timer never runs. The timer method outlined in http://aspalliance.com/1316_Working_with_Windows_Service_Using_Visual_Studio_2005.4 should be used to ensure that the timer triggers properly.

Currently the windows service appears under the name lockdown_agent in the task manager. It executes a netstat command and redirects the output of the command to a text file, located at C:\ben\netstat.txt.

Installing/Uninstalling Windows Agent

The Windows service can be installed manually or through an msi installer. To install manually, open a VS command prompt (Start->Programs->Microsoft Visual Studio 2005->Visual Studio Tools->Visual Studio 2005 Command Prompt). In the command prompt, type InstallUtil? (path of service exe). For example, InstallUtil? C:\ben\lockdown_agent\lockdown_agent\bin\Debug\lockdown_agent.exe. The service can be uninstalled manually using a different option, InstallUtil? /U (path of service exe). Example: InstallUtil? /U C:\ben\lockdown_agent\lockdown_agent\bin\Debug\lockdown_agent.exe. The msi installer can also install or uninstall the service. If the service does not start automatically after installation, it can be started by going to Control Panel->Administrative Tools->Services. Then right-click on the lockdown_agent service and select start.

To use the setup, first go to Control Panel->Administrative Tools->Services and stop the lockdown agent service. Then open the lockdown_agent project in Visual Studio 2005. In the Solution Explorer pane, right click on lockdown_agent_setup and Uninstall the service. Then, build the lockdown_agent project and the lockdown_agent_setup project. Once the build completes successfully, right click the lockdown_agent_setup and click install. This will start the setup to install the service.

Installing wget

The gnu utility wget is being used to get a status message from a webserver. It can be installed on a Windows machine by going to http://www.christopherlewis.com/WGet/WGetFiles.htm and downloading the currently recommended version. Unzip the files contained in this zip file to the C:\WINDOWS directory and reboot the machine. Placing them here allows the wget tool to be invoked in the command prompt by simply using wget. If they are placed somewhere else, then the full path to the executable must be used.

Update -- 11/27/07

The wget invocation now times out after 10 seconds. This was added to assess problems occurring when the services starts at boot time. I believe that some of the necessary processes, etc. were not started up in time for the wget to work properly (and perhaps some of the file system interactions as well), which was causing some errors and hanging.

Additionally, the -N flag is now being used on wget. The wget was creating a new file each time it was invoked, adding a sequential .# to the end of the filename each time, instead of overwriting the local instance of the file. The -N flag in wget compares the modified date of the local file to that of the target file to be downloaded. If they are the same, nothing is done. If the target file has been modified since the last time we used wget to obtain it, then it is redownloaded.

Update -- 11/28/07

WinSCP? is being used to push data out to a server. It can be found at http://winscp.net/eng/index.php

I did a custom install of WinSCP? and added the option to Add installation directory to search path (%PATH%) to facilitate use of the command line options.

When using WinSCP? , do not attempt to use the /upload option to send things to the server, as this does not work properly. Instead, use WinSCP? 's scripting command to send. The syntax is: winscp user:password@host /command "put sourcefile destination". An example of the syntax for this is: winscp broesch:mypasswordhere@bach.helios.nd.edu /command "put C:\ben\scptest.txt /afs/nd.edu/user34/broesch/".

Final Update

The agent is no longer using WinSCP? to push data to the server. When using the command line interface, as in the 11/28/07 update, WinSCP? returns its own prompt in the command window. This prevents the Shell function (in the agent's VB code) from returning, which obviously presents a problem for the continuously running service. To combat this problem, the WinSCP? usage was converted into a script, using WinSCP? 's built in scripting functionality, that allowed for issuing an exit command to WinSCP? . This solved the problem of WinSCP? returning. However, since WinSCP? uses the SSH protocol, we must accept the RSA key for a host on the first time we accept it. This can be done easily when running the program at the command prompt, but doing so accepts the key for only the current user (HP_administrator). Since windows services run as a system process, we must also accept the key for the system. Since the service runs in the background, we do not see the prompt asking us to accept the key.

Because of this problem, the agent now uses PSCP to push data. PSCP is the windows implementation of scp provided by the makers of PuTTY? . It can be downloaded at http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html . There is no required installation for pscp, but the executable should be placed in the C:\windows folder to facilitate use from the command line.

PSCP runs into the same RSA key acceptance issue as WinSCP? . PSCP stores known hosts in the windows registry at HKEY_CURRENT_USER->Software->SimonTatham->PuTTY. In order to allow the system process to also "know" hosts, and therefore avoid the problematic prompt, I was able to add a similar string to the registry at HKEY_USER->.default->Software->SimonTatham->PuTTY. ADD KEY INFO HERE. Once this key was added, PSCP was able to successfully connect to minerva and upload data.

-- BenRoesch - 28 Nov 2007

-- Ben Roesch - 27 Nov 2007

-- Ben Roesch - 13 Nov 2007

-- AndrewBlaich - 15 Oct 2007