automated server and laptop sarsoft/radiolog update flow

[caver456]

New nightly builds of sarsoft (STO) have some very nice features, but, it feels wrong to put the latest nightly on the server. Even with a dead-simple way to revert to a previous version of sar.jar, the trailer server should not be any type of testing ground unless there is really no other way.

One thing that would make this all much easier is an automated updater - here's the desired sequence:

1. at home or any other computer, put the latest sar.jar on a thumb drive in the standardized directory name such as "udpate_dropbox".

2. before turning the server on, put that thumb drive in a usb port of the server.

3. turn the server on.

4. The new sar.jar on the thumb drive, if it exists, is automatically copied to the 'live' location on the server.

5. sar.jar automatically starts (via the startup script) as normal.

We already have some momentum using the name "update_dropbox": there is a dir by that name on the server, under the STO directory; the startup batch file first looks to see if there's a sar.jar file in that dir, and if so, moves it (with overwrite) to the location of the 'live' sar.jar. After that check, the startup script starts sar.jar. This flow has been in place for a few years and has come in handy - problem is, you need to have a keyboard and a monitor on the server to actually place a file in the update_dropbox directory. The intended sequence above gets rid of the need for anything interactive on the server.

This should be pretty straightforward; the startup script could be modified to look on all mounted drives for sar.jar in the correct directory name; if found, it copies it to the 'live' spot; then it proceeds with sar.jar startup like normal.

Use of a beep sequence (echo a couple of ctrl-G's) on the server would be a great confirmation that the new file was located and copied in to place.

This could also be extended to the laptops: in their startup scripts, the flow could be identical, assuming the network drives get scanned too, and the server startup script would also have to put the new file in the expected directory on its shared drive; you'd also need to either delete from that location on clean shutdown, or include a check to see if the file is identical before copying in to place. In reality it probably wouldn't hurt to re-copy it each time, but it just seems kind of silly.

Important caveat for all of this: the script that scans the drives should make sure to wait until thumb drive(s) and network drive(s) have all been mounted. Will need to test things out and see if this can be done reliably in a batch file that is triggered at startup on each computer.

Also, this idea could be extended to radiolog updates, but that work flow is a bit different.

[caver456]

drawing a flowchart to clarify the workflow; have been experimenting with windows batch files

[caver456]

flowcharts (one for the server, one for the laptops):

https://docs.google.com/presentation/d/1a7TpACSlabv2sZL-cnD-FAtoBGY9ENGwmr-7u5fWVBI/edit?usp=sharing

[caver456]

Finished a working prototype in Windows PowerShell after realizing how moronic the batch file language is and not wanting to have to install and rely on python:

# sarJarUpdate.ps1 - Windows PowerShell script to 
#  search all mounted drives for the specified update file;
#  if found, and if newer than the existing file, copy the
#  update file over the existing file.
# The intent is to let the user put a thumb drive in the server
#  BEFORE the server is powered on; if the update file is in
#  the specified location on the thumb drive, and if this script
#  is automatically run at startup, the update file will be
#  copied in to place before sar.jar is automatically launched.

# to do:
#  - try it on the NCSSAR server
#  - exception handling - make sure sar.jar will still be
#     automatically launched even if this update script dies
#  - append output to a log file (do not overwrite the log file)

$existingSarJarPath="C:\Users\caver\Documents\sar\sarsoft\sar.jar"

$updateDir="update_dropbox"
$sarJarName="sar.jar"

# check all mounted drives for the update file
$drives=get-psdrive -psprovider FileSystem
$updateSarJarPath=""
foreach($drive in $drives) {
	$root=$drive.Root
	$updatePath=join-path $root $updateDir
	$updateSarJarPath=join-path $updatePath $sarJarName
	"Testing $updateSarJarPath"
	if (test-path $updateSarJarPath) {
		"sar.jar found at $updateSarJarPath"
#		"�"
		[console]::beep(1000,500)
	}
}

# if the update file was found, check to see if it is newer
#  than the existing file; if so, copy it in to place
if($updateSarJarPath -ne "") {
	$eLWT=(ls $existingSarJarPath).LastWriteTime
	$uLWT=(ls $updateSarJarPath).LastWriteTime
	"existing sar.jar : $eLWT"
	"update sar.jar : $uLWT"
	if($uLWT -gt $eLWT) {
		"$updateSarJarPath is newer than $existingSarJarPath"
		"copying the update file"
		copy-item $updateSarJarPath $existingSarJarPath -force -verbose
#		"�"
		[console]::beep(200,300)
		[console]::beep(1500,500)
		[console]::beep(200,50)
		[console]::beep(1500,500)
	} elseif ($uLWT -eq $eLWT) {
		"$updateSarJarPath is the same age as $existingSarJarPath"
		"NOT copying"
		[console]::beep(200,500)
		[console]::beep(1000,500)
	} else {
		"$updateSarJarPath is older than $existingSarJarPath"
		"NOT copying"
		[console]::beep(200,500)
		[console]::beep(700,500)
	}
} else {
	"No update file was found; nothing to copy."
}

[caver456]

Note, the .ps1 file just searches all mounted drives; it doesn't make any attempt to look specifically for a thumb drive. Need to change the flowchart to match. Also, need to make sure the thumb drive gets mounted before the script is run.

[caver456]

In place and working on one laptop (computer #4 - successfully grabbed the update from a thumb drive in the laptop). Did not test to see if the startup script on the laptop will find the file on the shared drive from the server (if the server is already on when the laptop finishes booting). This would be handy since you would only ever have to put the thumb drive into the server and it would propagate to all the laptops the next time they are started up. Of course the laptops should still scan for thumb drives in case you want to update the laptop while the server is not on.
Note, the plan was to try it on the server first, but, since the wireless keyboard batteries were dead and there were no replacements (AAA) in the trailer, it got tried on the laptop instead.
Also note this does not do anything about radiolog updates.