What not to buy: Dynex 1.3MP Webcam

I've spent the time across the weekend, tinkering with a USB webcam -- particularly a Dynex 1.3MP Webcam (USB ID: 0x19ff:0x0102 ). As I recall, Dynex is a BestBuy house brand. The Linux USB device driver support table indicates that the device is supported under _some_ Linux variant

The need was occasioned because some small animal, probably a groundsquirrel, has been digging in the garden of missus, and she wanted confirmation on what to go after. The local cat, Malaki, heard it and darted to the door, but I was too late letting him out to track down the intruder ... this time

My laptop at home has been my primary compute platform there, since I crushed my ankle late last December. I still need to post a page with all the gory x-ray details, to go along with the twitter pictures I sent along the way with recovery. The medical bill cost was staggering as well, and I'll sanitize and post details of that as well. Back to the laptop -- it runs a reasonably stock CentOS 5 most of the time, except when I've been trialling rebuilds of part of Red Hat's '6' series SRPM rebuilds

The seemingly needed 'uvcvideo' video driver was present, and I forced it to load, at the cost of the machine locking up in short order thereafter. I had to power cycle the unit to recover use of it. Hmmm ...

So I went looking for an application to pull content off of the newly present /dev/video0, and turned to the native 'ekiga' that CentOS 5 carries. It refused to acknowledge anything useful at that device, and so ... I had to power cycle the unit to recover use of it. Hmmm ...

Perhaps it was 'ekiga'. So I set out to solve the needed packaging to attain a current 'zoneminder' ... a bit more complex chain:

06:42:44 PM libgcrypt-devel-1.4.4-5.el5
06:42:44 PM libgpg-error-devel-1.4-2
06:42:46 PM gnutls-devel-1.4.1-3.el5_4.8
06:42:47 PM pcre-devel-6.6-6.el5_6.1
06:44:49 PM perl-MIME-Types-1.19-2orc
06:46:55 PM perl-TimeDate-1.16-5.el5
06:47:02 PM perl-MailTools-1.74-1orc
06:47:38 PM perl-DateManip-5.44-1.2.1
06:47:59 PM perl-DBD-MySQL-3.0007-2.el5
07:19:55 PM perl-PHP-Serialization-0.27-4orc
07:20:50 PM perl-MIME-Lite-3.01-5orc
07:23:33 PM perl-IO-Stringy-2.108-3.orc
07:23:54 PM perl-MIME-tools-5.411a-12orc
07:34:34 PM perl-IO-Zlib-1.10-1orc
07:43:10 PM perl-Compress-Raw-Zlib-2.027-1orc
07:47:54 PM perl-Archive-Zip-1.16-1.2.1
07:48:05 PM perl-Archive-Tar-1.39.1-1.el5_5.2
07:49:54 PM php-pdo-5.1.6-27.el5_5.3
07:49:55 PM php-mysql-5.1.6-27.el5_5.3
07:50:28 PM perl-Module-Load-0.10-3orc
07:51:38 PM perl-Device-SerialPort-1.002-3orc
07:51:49 PM zoneminder-1.23.3-2orc

and went through the very nicely done configuration. Oops -- it wants a mysql database server running to save state:

07:59:18 PM mysql-server-5.0.77-4.el5_6.6
08:03:20 PM mysql-test-5.0.77-4.el5_6.6

Zoneminder was willing to admit it could read /dev/video0 but all it returned was a black image. Grrr. ... and then after a few minutes, the laptop locked up again, and I had to power cycle the unit to recover use of it. Hmmm ..

So I spent a few minutes with Google doing some research, and found what looks like a ratehr nice little application for USB frame grabbing called: gideo -- see: A GTK video grabber designed with spca5xx components. Building it dragged in the Gnome / GTK development environment of thirty or so packages, and I only had to fix up a dependency's .spec file to handle Red Hat's multilib conventions

05:27:56 PM libtiff-devel-3.8.2-7.el5_6.7
05:29:52 PM gideo-0.1-1orc
05:43:18 PM SDL_image-1.2.10-2orc
05:43:18 PM SDL_image-devel-1.2.10-2orc

But now, 'gideo' is unwilling to admit, or loading the module is unwilling to produce a live /dev/video0, and ... you guessed it: The laptop locked up again, and I had to power cycle the unit to recover use of it

I think perhaps I'll try a different video camera

Reading the logs, part 3 -- Run your updates

It looks like I'll be writing these for a while as I clean up logfile noise. The earlier pieces are here and here. I say 'noise' here because they are not false positives, but neither are they material, just more a nuisance

One the things every admin who reads log files sees are automated scanners looking for exploits in 'canned' packages that were installed but have not been updated, either because the admin for a given machine has neglected to run updates, because it is not a publicly known exploit, or because the upstream has not yet addressed the matter.

A pattern that has emerged with our PMman with a data center with large contiguous swaths of IP space (and hosts scattered in assignment in that relatively compact range, said hosts reporting to me centrally) is as follows. The hostile exploit scanners are not even trying to be subtle any more -- they simply march sequentially through IP ranges, and inventory if a given weakness is present on every host to which they connect

Today, I focus on one sample report stanza:

--------------------- httpd Begin ------------------------

Requests with error response codes
400 Bad Request
HTTP/1.1: 1 Time(s)
403 Forbidden
/index.html: 1 Time(s)
404 Not Found
/cms/e107_files/e107.css: 1 Time(s)
/db/e107_files/e107.css: 1 Time(s)
/e107/e107_files/e107.css: 1 Time(s)
/e107_files/e107.css: 1 Time(s)
/forum/e107_files/e107.css: 1 Time(s)
/index.php: 1 Time(s)
/manager/html: 1 Time(s)
/portal/e107_files/e107.css: 1 Time(s)
/site/e107_files/e107.css: 1 Time(s)
/web/e107_files/e107.css: 1 Time(s)

---------------------- httpd End -------------------------

and apache can handle this trivially:

#
# file: noexploit.conf
#
# send scanners off to see the wizard
#
Redirect permanent /cms http://127.0.0.1/
Redirect permanent /db http://127.0.0.1/
Redirect permanent /e107 http://127.0.0.1/
Redirect permanent /forum http://127.0.0.1/
Redirect permanent /manager http://127.0.0.1/
Redirect permanent /mysql http://127.0.0.1/
Redirect permanent /phpmyadmin http://127.0.0.1/
Redirect permanent /phpMyAdmin http://127.0.0.1/
Redirect permanent /portal http://127.0.0.1/
Redirect permanent /site http://127.0.0.1/
Redirect permanent /user http://127.0.0.1/
Redirect permanent /users http://127.0.0.1/
Redirect permanent /web http://127.0.0.1/
#

The obvious next step is to package deployment hardenings, and add them to a local RPM repository so that simply running updates, as with yum will get the current best approaches on hardening, en masse, on all the servers

Phat pipes

Check the top row, right entry ... peaking at 44 megaBytes per second, and a lesser rate sustained over 8 hours; all relevant filtering bridges, and servers in the transfer at our end are running ... CentOS

We've spent the last couple of months in the buildout of our (new) presence in the North data center. We have sites in the central city, on the Dublin fiber ring, and through the north end AT&T switching center, but each has had its faults over time. The downtown 'carrier hotel' was offline for four hours due to a lack of redundancy in its generators during last September's multi day power outage; the Dublin fiber ring peering exchange point had issues as well, but longer; our multi-site strategy saved the day as none of our customers lost inbound data nor went dark in their web presence; uplinks were not affected as we handle them over different routes. In the last couple weeks, AT&T's congestion issues have re-appeared at their plant as well when we were 'babysitting' a large CAD/FEA file transfer ... again multi-gig

The new data center is pricey -- but in addition to the care at the physical layer, it is BGP multi-homed and has really fat pipes. The screenshot up top shows the inbound consumption on the green. Iniitally we had a hard cap on our switch to limit it to 10 MegaBytes/Sec inbound -- but we were doing a large (a multi hundred gigabyte pull), and dropped the cap once it was clear all was working well

We are in the paperwork phase at the moment with ARIN, to clear up some 'lint' on our ASN, but with any luck by the end of the month, we'll have completed the cutover

score: pen one, orc zero

'Out, damned spot! out, I say.'

-- Lady Macbeth, Macbeth, Act V, Scene 1, Shakespeare

Came back from a trip out of town, and as is my usual custom, had all the dirty clothing on the top of the suitcase [for the TSA to appreciate digging through]. Now I am usually pretty careful to pull stray paper, change, and writing implements out of clothing as I disrobe. I missed a ball point pen this time, and in loading the laundry bin, missed it a second time.

We all know how this comes out, and indeed once the pen moved from the washer to the dryer, it opened up. Spots everywhere. Dr Suess would be proud, but no 'Voom' seems to be in our house. It spotted and gave its distinctive blue-black hue to the good towels, napkins, and other items which went through with a white summer weight cotton shirt in which pocket the pen was riding. There is probably nothing in the future of those towels than promotion to the 'rag box.'

But the issue remained of removing the ink from the dryer drum interior. I consulted Google, and a couple of commercial products were suggested, but it is Sunday, and I am not likely to go out again today. Household agents such as acetone (sometimes found in nail polish remover), denatured alcohol, Comet brand dry bleach powdered abrasive cleaner came to mind. Digging through the garage, I also came across an ether based starting fluid, and WD-40 brand spray lubricant.

Down to the dryer, and spot testing {ahem} began. Bottom line, alcohol on a paper towel and a bit of elbow grease triumphed.

Too late in the day for coffee, not late enough for Scotch. I'll go find a Miller Genuine Draft (bottled) in the 'fridge.