Back to topic, I also use cssh for working on multiple servers simultaneously. I’d recommend making a copy of your .cshrc file (cp -a ~/.csshrc ~/.csshrc_mosh) and working on the copy. Edit the  ~/.csshrc_mosh and change the lines ssh= and ssh_args= (diff of my files):

$ diff .csshrc .csshrc_mosh 
27,28c27,28
< ssh=/usr/bin/ssh
< ssh_args= -x -o ConnectTimeout=5
---
> ssh=/usr/bin/mosh
> ssh_args=

You will have to remove any parameters in ssh_args= and move them to your ~/.ssh/config due to the difference in command line parameters between mosh and ssh. Now all you have to do is call cssh with the new config file, e.g. with an alias to make things easier alias mcssh=”cssh -C ${HOME}/.csshrc_mosh” And your done.

Some spamassassin scores for your local/user settings:

score SPF_PASS -1.0
score SPF_FAIL 3.5
score SPF_SOFTFAIL 1.0
score SPF_HELO_PASS -1.1
score SPF_HELO_FAIL 3.5
score SPF_HELO_SOFTFAIL 1.0

SPF:
Syntax: http://www.openspf.org/SPF_Record_Syntax
Wizard: http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/default.aspx

DKIM:
Exim walkthrough: http://mikepultz.com/2010/02/using-dkim-in-exim/
Domain specific settings: http://www.debian-administration.org/users/lee/weblog/41

Graphics sources:
http://www.overkillsoftware.com/payday/
http://openclipart.org/detail/125695/diamant–diamond-by-lmproulx
http://openclipart.org/detail/31891/surveillance-camera-by-maxim2

The new server is from hetzner since I have been very satisfied with them in the past. Impressive hardware features for low prices and (what really makes me keep choosing them) fantastic technical support. I’ve been with a few companies in the past, but none have had as good support as hetzner. Sooner or later hardware will die, and having a hosting provider that responds promptly and knowledgeably to request is priceless.

Basically we rely on flock to do the heavy lifting and we just add some logic around it:

1
2
3
4
5
6
7
8
9

trap cleanup INT TERM EXIT # call cleanup() if script exits
 
cleanup() {
	  flock -u 200
}
 
exec 200>/var/lock/my_script.lock
 
flock -xn 200 || exit 1 # exit if a lock exists

man flock will show you more details to the parameters used and even some examples. Basically it will use trap to make sure the lock is released if the script ends in any way. 200 is a random file descriptor I chose for this example, it can be anything numeric. flock -xn means it will attempt to acquire an exclusive lock, and if that fails it will exit with an error.

Putting this somewhere at the top of your script will simply end the script if it finds an existing lock. flock has a few other options like -wait or nor using -n that allow you to not exit but wait for the lock to end (with wait a variable amount of seconds). And thus with a bit of creativity enabling you to only lock specific parts of the code (e.g. database calls, file changes, …) and handling failed lock attempts more gracefully than an exit.

So I decided to use the two access points for something more useful. I’m playing around with dd-wrt to build configurations to use them as WiFi probes (for an IDS), or as Rouge Access Points (for demonstration purposes and to test wireless IDS solutions).  I might compile my own dd-wrt version for the rouge version, there are a few things I miss to build a truly evil device.

I like the size of the devices (very compact) and that you can power them with 5V (you can run them off any USB port, right now the one here is hooked up to the USB port of a printer intended for cameras) the only thing missing to make them perfect would be Power-over-Ethernet and maybe a GSM interface to upload data online.

Fun having a cheap and small device like this with Wifi and ethernet running linux. Provides lots of possibilities and fun.

Below are some pics of the treat.

Skillet Cookie

10 Photos

Since my PC has more than enough RAM I decided to set up a 5Gb Ramdisk to see if that helped. It did, when writing the video files to the ramdisk I hardly had any performance hit. Unfortunately 5GB isn’t going to last long while recording 1920×1080 @ 40FPS (a few minutes footage at most).

Here is my little cmd file to create a 5GB ramdisk as drive J: and format it for usage:

1
2
3

imdisk -d -m J:
imdisk -a -t vm -s 5G -o rw -m J:
format J: /A:64k /V:Ramdisk /FS:NTFS /Q

So my next thought was to see if I could write a script to move files off the ramdisk when they were done being written to by Fraps. This obviously was going to cause IO load … the reason we were having performance issues in the first place, so I was skeptical about if this was going to help any. Especially since I also had to move the files away quick enough so that the drive wouldn’t fill up completely with the next file Fraps was writing. I wrote a little powershell script for this (yeah, a *nix Sysadmin writing scripts in powershell …)

Here is my little powershell script to copy the finished files from my ramdisk to a normal HDD (please excuse  possible ugliness, I’m a powershell noob):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

$source = "j:\*.avi"
$target_dir = "f:\fraps\movies\"
 
while ($true) {
    $files = gci $source
    foreach ($file in $files){ 
        $srcfile = echo $file.fullname
        $dstfile = echo $file.basename
        if ($srcfile) {
            try {
                move-item "$srcfile" "$target_dir$dstfile.avi" -ea stop
                "$srcfile Moved"
            }
            catch {
                "$srcfile in use, cannot be copied right now"
            }
        }
    }
    sleep 5
}

The last little problem I noticed is that the 5GB ramdrive wasn’t big enough (Fraps seems to create some dummy files and fills them up). Forcing Fraps to make smaller files by toggeling the recording fixed that though -> pressing F9 twice fast will drop a few frames though. I used my Logitech G13 for that, just had a key mapped to press F9 quickly every 60 seconds. The shortest gap I could get working reliably is 50ms.

This all probably sounds awfully complicated, but it works and solves my problem. Fraps is great software, but it would be immensly helpful if you could set the file size in the settings (instead of it defaulting to 4GB). Or, even better, if Fraps could rework their IO system to work more efficiently.

So to sum everything up:
- create ramdrive
- start script that copies files from the ramdrive to a normal HDD
- set fraps to store videos on the ramdrive
- start game, press F9 to start recording and then press the G13 key to toggle the F9 periodically

Yellowstone and Grand Teton

190 Photos

I didn’t get around to editing and stitching the panorama photos together yet, or doing anything interesting with the GPS data of our hikes yet. If I get that done I’ll probably update this posting.