Catching TrendNet "End-Of-Motion" Signals

Anyone using a CGI to grab notifications from a TrendNet IP camera will know that the TrendNet doesn't send a signal when all is clear - it simply sends repetitive "motion" signals.  It makes it difficult to receive an "all clear" without doing some fancy "touches", and you won't get it in any sort of real-time status.  So, how can you grab an "All Clear", and have it happen when the camera stops recording (meaning that you can configure a camera to record an extra 30 seconds, then get the "all clear" when the recording stops) ?  Well, it turns out it's simple, if you are using Samba.  Here's how I did it.

Configure Samba :

The later versions of Samba (e.g. 3.x) include "VFS" modules - or "Virtual File System" modules - which allow Samba to handle virtual tasks such as translating new lines on-the-fly, or checking new files for virus or malware.  There is are two included VFS module for auditing, and one will log messages when a file is closed.  The full_audit.so VFS module is the one we need.  It's included, so we simply need to enable it.  Open your /etc/samba/smb.conf, and in the [global] section :

vfs objects = full_audit
full_audit:prefix = %u|%I|%m|%S
full_audit:success = close
full_audit:failure = none
full_audit:facility = local6
full_audit:priority = DEBUG

If the priority is NOTICE, you will get the messages into /var/log/messages, so beware of your config.  I went with DEBUG, so that I can then restrict that to one destination (I'll talk about that later).

The secret is in the "full_audit:success" and "full_audit:failure" parameters.  These allow you to configure what system calls you want logged, either on failure or on success.  In the above configuration, I log nothing on failures, and I log "close" on successes.  This means that the syslog configuration will get a log message for every time a file is closed (whether being written to or just read from).  The log messages look like :

Oct 15 22:44:01 localhost smbd[20487]: anne|10.0.0.73|mediacenter|movies|close|ok|disney/the_little_mermaid.mp4

Oct 15 22:44:02 localhost smbd[20487]: secuser|10.0.0.41|tv-ip322p-0015f|camerashares|close|ok|path_to_storage/20131015/22/224315.mp4

So, since we will end up with all closings, you want to ensure either the username ("secuser" in the above messages) doing the writing or the hostname (tv-ip322p-0015f) that is writing to the Samba share is unique and you can filter out the rest of the stuff.  In my case, the host is "tv-ip322p-0015f", so I can easily just watch for those messages for closings from the camera(s) in question through logcheck, and have an instantaneous notification via e-mail when each camera clears itself and stops recording.  However, since we want the notification to enter our event server (e.g. Nagios), and... since full_audit already runs through syslog, it's simply a matter of setting up a named-pipe.

Named Pipe Creation :

1. Create the named-pipe :
   
   

   mkdir /etc/syslog.pipes
   mknod /etc/syslog.pipes/sambaEvents p
   chmod 600 /etc/syslog.pipes/sambaEvents
   
   

2. Next, configure syslog to write to that named pipe.  In your syslog config (e.g. /etc/rsyslog.conf), add a line such as (make sure it matches your customizations) :
   
   

   local6.* |/etc/syslog.pipes/sambaEvents

3. Then, restart syslog :
   
   /etc/init.d/rsyslog restart
4. Finally, you will have to write a tool that reads from your named-pipe.  In my case, I'm setting up an eventserver, and I'm using a plugin for that one.  For anyone else, you can do a cron (example http://svn.silverhawk.net/files/syslogSambaEvent.sh) such as :
   
   * * * * * /usr/local/bin/syslogSambaEvent.sh < /etc/syslog.pipes/sambaEvents
   
   That will run the job once a second looking for messages from the queue, and then e-mail them out if they match my tv-ip322p.

SELinux note :

Oct 16 08:30:21 cottonwoodheights rsyslogd-2039: Could not open output pipe '/etc/syslog.pipes/sambaEvents' [try http://www.rsyslog.com/e/2039 ]
Oct 16 08:30:24 cottonwoodheights setroubleshoot: SELinux is preventing /sbin/rsyslogd from 'read, write' accesses on the fifo_file sambaEvents. For complete SELinux messages. run sealert -l 0f6ad628-c737-452f-a4a2-fbf240519594

If you are running SELinux, you will probably see something like the above.  Simply run the sealert command it names, and follow the directions the command provides.  You may also find more messages in there for the script that reads from the named pipe.

Added Notifications :

Just a note, if you want other functions (for example, if the camera you are using doesn't have a "motion detected" notification method but does capture only the motion video, you can add the "open" to the full_audit:success line such as "full_audit:success = open,close"), I grabbed a list from the vfs_full_audit.c source, so these are things you can monitor if you really want, but beware things like "pwrite" are called multiple times in a file write, not just once for the entire file, so you could have a log inundated with verbose messages.

aio_error
aio_force
aio_fsync
aio_is_offline
aio_read
aio_set_offline
aio_write
brl_cancel_windows
brl_lock_windows
brl_unlock_windows
chdir
chflags
chmod
chmod_acl
chown
close
closedir
connect
connectpath
create_file
disconnect
disk_free
fchmod
fchmod_acl
fchown
fget_nt_acl
fgetxattr
file_id_create
flistxattr
fremovexattr
fs_capabilities
fset_nt_acl
fsetxattr
fstat
fsync
ftruncate
get_alloc_size
getlock
get_nt_acl
get_quota
get_real_filename
get_shadow_copy_data
getwd
getxattr
init_search_op
kernel_flock
lchown
lgetxattr
link
linux_setlease
listxattr
llistxattr
lock
lremovexattr
lseek
lsetxattr
lstat
mkdir
mknod
notify_watch
ntimes
open
opendir
pread
pwrite
read
readdir
readlink
realpath
recvfile
removexattr
rename
rewinddir
rmdir
seekdir
sendfile
set_quota
setxattr
stat
statvfs
streaminfo
strict_lock
strict_unlock
symlink
sys_acl_add_perm
sys_acl_clear_perms
sys_acl_create_entry
sys_acl_delete_def_file
sys_acl_free_acl
sys_acl_free_qualifier
sys_acl_free_text
sys_acl_get_entry
sys_acl_get_fd
sys_acl_get_file
sys_acl_get_perm
sys_acl_get_permset
sys_acl_get_qualifier
sys_acl_get_tag_type
sys_acl_init
sys_acl_set_fd
sys_acl_set_file
sys_acl_set_permset
sys_acl_set_qualifier
sys_acl_set_tag_type
sys_acl_to_text
sys_acl_valid
telldir
translate_name
unlink
write

Alarm Switch Installed

Well, it's amazing what you can accomplish when you have a little time.  I was able to install the alarm lock cylinder into the fender (wires, lock retainer, and gasket), and I was able to get the hood hinges in place and connected to the body and the hood.

I need to figure out how to adjust the hood at this point, and then I can install the hood support (which I received - thanks, Corvette Central!), and then finish plumbing the carburetor.  That would leave simply the headlights, steering column reassembly, electrical testing, door glass adjustment (need to get the battery in place to do the adjustment, which is also why I needed to get the electrical tested, which is why I needed the alarm switch functional and installed).

So, here's my to-do list (yes, it has gotten to the point that it is very specific) :

• Reassemble the Turn Signal Switch and Ignition Switch
• Install the Tilt/Tele Steering Wheel Components
• Have Someone Clean the Steering Wheel Leather (Not sure how expensive)
• Install the Steering Wheel
• Hood Adjustment
• Plumb the Fuel-Filter-to-Carburetor Lines
• Headlights
  
  • Obtain Ford Probe Headlight Motors (model year 1993 to 1997, about $60 for the set)
  • Wire up a Headlight Control Relay (from Napa, EC23 $15 and BK3007884 $9)
  • Manufacture a Bracket to Hold the Probe Headlight Motors (not sure how much this will cost)
  • Assemble the Electric Headlight System
  • Get the Headlight Bezels and Lids Painted to Match (at $300 a pint for the color coat alone)
  • Install Headlights Themselves
• Probe Electrical Connections (before Adjusting the Door Glass)
• Connect the Battery
• Adjust the Door Glass
• Disconnect the Battery
• Install Door Panels
• Ensure Interior Light Bulbs are in Working Order
• Complete Air Ducts
• Install the Drivers' Dash Panel
• Obtain a Map Pocket ($85) for the Passengers' Side and Install (with Springs)
• Install the Passengers' Side  Dash Panel
• Bolt Down the Center Console
• Bolt Down the Parking Brake Cover
• Install Transmission Tunnel Covers
• Bolt Down the Seats and Test
• Connect the Battery and Test All Electrical Components (EXCEPT FOR STARTER)
• Fill with coolant
• Add Oil and Prime the Oil Pump
• Add a LITTLE Gasoline to the Tank
• Add Gear Oil to the Tremec TKO II
• Add Windshield Washer Fluid
• Lift Rear Wheels into the Air (don't want to have the transmission fail to disengage)
• Connect the Battery
• Put some Gasoline in a Glass cup in Preparation to Test Fire
• Test Fire
• Stop Engine
• Engage Wheels with the Ground
• Start, and Drive a Short Distance (less than a mile)
• Return and Check the Oil
• Raise the Back End
• Run the Car in Gears for 20 Minutes Each (Transmission Break In)
• Drop the Car
• Check the Oil
• DRIVE IT LIKE I STOLE IT

CentOS 6 and Standard X ScreenSavers

I use CentOS as a desktop, primarily because I need to be able to work on scripts and ensure they work on the servers before I throw the things over to the servers for production runs.  However, the default number (and style) of screensavers for Gnome are pitiful.  Popart, the insecure "photos", and some weird "gnome feet" screen saver.  Because of this, I needed to have the original X screen savers.

I'm using CentOS 6.4, and due to previous histories, I knew I needed packages named with the following :

gnome-screensaver (already installed)
xscreensaver-base
xscreensaver-extras
xscreensaver-extras-gss
xscreensaver-gl-base
xscreensaver-gl-extras
xscreensaver-gl-extras-gss

I loaded up http://rpm.pbone.net/ (way better than http://rpmfind.net/), and tracked down RedHat EL6 RPM URL's.  Then threw them into the following command :

yum install ftp://ftp.muug.mb.ca/mirror/fedora/epel/6/x86_64/xscreensaver-base-5.11-7.el6.respin1.x86_64.rpm \
ftp://ftp.muug.mb.ca/mirror/fedora/epel/6/x86_64/xscreensaver-gl-extras-5.11-7.el6.respin1.x86_64.rpm \
ftp://ftp.muug.mb.ca/mirror/fedora/epel/6/x86_64/xscreensaver-gl-base-5.11-7.el6.respin1.x86_64.rpm \
ftp://ftp.muug.mb.ca/mirror/fedora/epel/6/x86_64/xscreensaver-gl-extras-gss-5.11-7.el6.respin1.x86_64.rpm \
ftp://ftp.muug.mb.ca/mirror/fedora/epel/6/x86_64/xscreensaver-extras-gss-5.11-7.el6.respin1.x86_64.rpm \
ftp://ftp.muug.mb.ca/mirror/fedora/epel/6/x86_64/xscreensaver-extras-5.11-7.el6.respin1.x86_64.rpm

This gave me a requirement for a package that was missing with the following error :

Error: Package: 1:xscreensaver-base-5.11-7.el6.respin1.x86_64 (/xscreensaver-base-5.11-7.el6.respin1.x86_64)
           Requires: xorg-x11-resutils
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

I found the missing package that was required (news to me), and fired off the command :

yum install ftp://ftp.muug.mb.ca/mirror/fedora/epel/6/x86_64/xscreensaver-base-5.11-7.el6.respin1.x86_64.rpm \
ftp://ftp.muug.mb.ca/mirror/fedora/epel/6/x86_64/xscreensaver-gl-extras-5.11-7.el6.respin1.x86_64.rpm \
ftp://ftp.muug.mb.ca/mirror/fedora/epel/6/x86_64/xscreensaver-gl-base-5.11-7.el6.respin1.x86_64.rpm \
ftp://ftp.muug.mb.ca/mirror/fedora/epel/6/x86_64/xscreensaver-gl-extras-gss-5.11-7.el6.respin1.x86_64.rpm \
ftp://ftp.muug.mb.ca/mirror/fedora/epel/6/x86_64/xscreensaver-extras-gss-5.11-7.el6.respin1.x86_64.rpm \
ftp://ftp.muug.mb.ca/mirror/fedora/epel/6/x86_64/xscreensaver-extras-5.11-7.el6.respin1.x86_64.rpm \
ftp://ftp.muug.mb.ca/mirror/fedora/epel/6/x86_64/xorg-x11-resutils-7.1-10.el6.x86_64.rpm

Success!  Note that you will have TWO screen saver options.  If you use gnome-screen saver and hot keys to lock your workstation, you should continue to use that one (your new screensavers will show up in it's configuration pane).  If you open the first one and it says it needs to stop the gnome screen saver, cancel that, close that preferences pane, and open the other one.

Steering Column - Coming Together

With some bad engineering drawings, a bad memory, and some skill with Tetris from growing up, I finally figured out how the steering column's Tilt/Telescopic components fit together.  There were a few steps to get me to a point that the Chevrolet manuals talked about :

1. Find out how the light dimmer switch shaft sets into the housing.
2. Find out how the turn signal switch connects to the dimmer switch (hint - it uses a plastic carrier that sets into a plastic shell that the tilt/telescopic lever runs through).
3. Understand how the wiring fits into the wiper/turn signal switch carrier housing (that also houses the ignition lock cylinder)
4. Locate a suitable pivot pin for the wiper/turn signal switch that connects the switch to the housing.
5. Put that all together in one fell swoop (you kind of have to do this - without the housing, the parts will fall out, and without the parts in the right place, the housing won't connect.

For the pivot pin, I had lost mine, and found out that no one sells a replacement.  Goofing off, I realized that my Honda Civic (metric) had six bolts for the timing belt cover, and (since I had replaced the engine this year) I had the old bolts laying around.  Those bolts fit into the threads for the housing, and the shoulder on the bolt had a slightly larger diameter (that's a good thing) than what it should be (it wouldn't fit into the switch).  I grabbed my drill, slapped the bolt into the chuck, and grabbed a file.  I basically turned the shoulder without a lathe until it was the right size.

Then I ran out to grab the ratchet to install it..... and found the old pivot bolt still in the socket from nine months ago!  I compared them, and they were almost identical, the original had an extra pivot pin on the end (e.g. two shoulders of different sizes with a threaded section sandwiched in between).  The "replacement" would have still worked, but I opted for the original (anyone wonder why?).

I set about installing everything, and had success in getting those parts completely installed (complete with a new ignition lock cylinder).  Next up, finishing the rest of the assembly, which I can now use the AIM for (the assembly instruction/engineering diagrams at the factory).

Bluetooth USB Desktop with VOIP

I'm running as a guinea pig for the corporate office, helping to set up a software-based phone (no VoIP hardware).  That means that I needed to set up a wireless headseat, which forced an interaction with Bluetooth on my CentOS workstation.  I bought a Sabrent BT-USBT 2.0 adapter (small, which is good, you can find one on overstock.com's website).

I got the adapter fairly quickly, and plugged it into the workstation, and did an lsusb to see what I had :

[username@hostname video]$ lsusb|grep -i bluetooth
Bus 003 Device 040: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
[username@hostname video]$

It looks like it's a re-badged device, but that also means that it it can communicate with the USB system.

In preparation, ensure you have the right tools for this :

yum install bluez-alsa bluez bluez-compat

You will first need to enable the bluetooth services.  The first thing to do (before you forget) is to enable the bluetooth service at startup (the first command following this paragraph).  The second thing is to actually start the bluetooth service.  The commands :

[root@hostname video]# chkconfig bluetooth on
[root@hostname video]# service bluetooth start
Enabling Bluetooth devices:
[root@hostname video]#

Next, you will need to pair a device to your new bluetooth connection.  This is done fairly easily through the GUI (if you needed this faster than a crazed admin with a site down).  In gnome, click "System" from your menu, then "Preferences", then "Bluetooth". e.g. :

This should present a window with courses of action - a check box entitled "Make computer discoverable", and a button to "Set up new device".  The "Make computer discoverable" is to use the computer as the peripheral device, while the other will add a device to your computer.

For a bluetooth wireless device, click on "Set up new device".

However, I never work through the GUI unless it is imperative.  The tool for you command-line folks to use is "hcitool".  First, run an "hcitool scan" (to look for your device), followed by an "hcitool info" (get more information on the specific device) :

[root@hostname video]# hcitool scan
Scanning ...
 60:33:4B:07:15:49 appletv
 50:3D:E5:7D:62:FD CP-8945
[root@hostname video]# hcitool info 60:33:4B:07:15:49
Requesting information ...
 BD Address:  60:33:4B:07:15:49
 OUI Company: Apple, Inc. (60-33-4B)
 Device Name: appletv
 LMP Version: 2.1 (0x4) LMP Subversion: 0x422a
 Manufacturer: Broadcom Corporation (15)
 Features page 0: 0xff 0xff 0xcf 0xfe 0x9b 0xff 0x79 0x83
...snipped...
 Features page 1: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
[root@hostname video]#

This should give you most basic information, but to pair it up, simply run (where XX:XX:XX:XX:XX:XX is the device hardware address from above) :

hidd --connect XX:XX:XX:XX:XX:XX

For example :

[root@hostname video]# hidd --connect 60:33:4B:07:15:49
[root@hostname video]#

And then you can configure the device as needed through the normal methods.