Economy Size Geek - Who Goes There? Adventures in Amateur Security
Knowing someone is in my office is a great improvement. In the event of an actual compromise, it would be better to have some information about who the intruder was. That brings me to the second part of the solution, the Webcam. I had one lying around and figured this would be a good use for it.
The Vera appears to be a rebadged ASSU WL-500gP. It is running OpenWRT with custom modifications to it. This turned out to be a good thing, because it means software compiled for OpenWRT works on the Vera. Mi Casa Verde does not officially support changes at this level, but it gives you full root access, so at least it doesn't get in the way.
The first step to doing this sort of thing is hooking up the Webcam to my normal workstation. I've learned from experience that if you cannot get it to work easily on a full Linux install, you have no shot at getting it to work on an embedded device. The Webcam plugged in, and I installed luvcview, a simple viewer program that lets you see what the Webcam sees. I ran luvcview and immediately was looking at a small picture of myself. This was awesome on two fronts. I'm pretty sure this cam didn't work under Linux the last time I tried it, and now I can move on to the hard stuff.
Getting shell access on the Vera is really easy. Go to Advanced→Net & wifi→Advanced configuration. It will ask you to set a root password. From that point on, you will be able to ssh in as root. The filesystem is a little confusing at first. Using df, the root filesystem appears to be completely full. The way the system is created, that is not actually true. In most cases, you can ignore that and simply untar things on to the root filesystem with no problems.
OpenWRT normally uses ipkg to manage packages, and that is broken on the Vera. The workaround is very straightforward though. You simply follow the same process for all packages. It turns out that the ipk package is just a set of nested tarballs. Here is the process for installing the gphoto2 package:
cd /tmp wget http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/ ↪brcm-2.4/packages/gphoto2_2.4.7-1_brcm-2.4.ipk tar -xzvf gphoto2_2.4.7-1_brcm-2.4.ipk cd / tar -xzvf /tmp/data.tar.gz
I was really excited, because there are two options for doing the image capture: gphoto2 and motion. gphoto2 is a command-line tool for controlling a normal digital camera. motion is a tool for controlling a Webcam and detecting motion.
What I really, really wanted was motion, which would provide an actual video of the person entering, but I ran into a classic version problem. The Vera/ASUS uses a Broadcom chipset for the onboard wireless. This is apparently flaky under the 2.6 kernel, so it is using a 2.4 kernel. The Webcam drivers for 2.4 are really limited. It turns out the uvc driver that allowed the Webcam to work on my workstation is available only in 2.6. I couldn't find a Webcam around the house that was supported with the drivers at my disposal.
So, that sent me on the hunt to get gphoto2 to work. It requires an actual digital camera. I had three different cameras from which to choose: a Canon SD1100, a Canon SD780 and a Canon EOS 400. You probably are noticing a theme here—they are all Canons. I love the little Powershot cameras. The last one is a DSLR that actually belongs to my wife (she's more serious about photography).
Here is where I learned that Canon has used its own protocol in the past, but apparently it's coming around. As a result, you need a recent version of gphoto2 in order to access the above cameras. In this case, I was incredibly lucky. It turns out the latest, greatest version was available and compiled already for me (downloads.x-wrt.org/xwrt/kamikaze/snapshots/brcm-2.4/packages).
In order to make this work, you need three different packages: gphoto2, libgphoto2 and libgphoto2-drivers. The instructions above work for installing gphoto2. The libs take some extra steps:
cd /tmp wget http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/ ↪brcm-2.4/packages/libgphoto2-drivers_2.4.7-1_brcm-2.4.ipk tar -xzvf libghoto2-drivers_2.4.7-1_brcm-2.4.ipk tar -xzvf data.tar.gz wget http://downloads.x-wrt.org/xwrt/kamikaze/snapshots/ ↪brcm-2.4/packages/libgphoto2-_2.4.7-1_brcm-2.4.ipk tar -xzvf libghoto2_2.4.7-1_brcm-2.4.ipk tar -xzvf data.tar.gz
This gives you the /tmp/usr/lib directory. Then:
cd /tmp/usr/lib/libgphoto2/2.4.7/ rm -f any_drivers_for_cameras_you_dont_have
In my case, I left canon.so, directory.so and ptp2.so. The last two are needed to talk to my camera. If you don't clear out the drivers directory, you will run out of space when you try to copy this on to the Flash portion of the Vera:
cd /usr/lib cp -R /tmp/usr/lib/* .
Now you can hook up your camera. Typing gphoto2 -a should list all your camera's abilities. The most important ability is capture. The Powershots reported being able to capture images, but I was unsuccessful in actually getting them to do so. They require a special command to open the lens that did not work. I hooked up the EOS and got an IO error. After some research, I found I needed to format the memory card. Once that was done, I could trigger the camera from the command line. Thanks to an idea from wearetherock (snipplr.com/view/19935/post-twitpic-with-curl), I found out that posting a tweet with the picture was super easy. This solved two problems at once. The first is that the Flash memory in the Vera can not keep very many pictures around, and second, the system is more secure if I can store the picture off-site, safe from intruders.
The script is dead simple:
#!/bin/sh cd /tmp gphoto2 --capture-image-and-download --filename=now.jpg ↪--force-overwrite curl -F "username=USERNAME" -F "password=PASSWORD" ↪-F "message=Intruder Cam" -F media=@//tmp/now.jpg http://twitpic.com/api/uploadAndPost
(Replace USERNAME/PASSWORD with valid credentials.)
Now that I had the picture capture happening, I just needed to connect it to the open door event. I found some people were monitoring a logfile (which in recent firmware has changed to /tmp/log/cmh/LuaUPnP.log). That would be fine if I wanted a record of what happened. Instead, I want the camera to trigger on an event.
It turns out Mi Casa Verde has a solution for this. The latest firmware adds in Luup. This is a Lua-based interface to the system. It allows you to do some pretty advanced scripting. In my case, I only need to do some simple scripting.
I put my shell script in /root/upload.sh. The scene I already had created had a button for Luup scene. I don't actually know any Lua, but in this case, Lua expertise wasn't really required. I simply entered:
os.execute("/root/upload.sh >/dev/null 2>&1")
This told Vera to run my little shell script whenever that scene was triggered. So when the door was opened, the camera would take a picture and upload it to Twitter.
Now when I open the door, it takes a picture. If I spend some more time on this, I could add more logic so that the notification and picture happen only at certain times of day or night. This would be useful to cut down on the notifications I was getting every time I left the office to do something else like eat lunch.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SourceClear Open