Why it might not: a potential (MA based) vendor we’re talking to says

We’ve not been asked this before and about 201 CMR 17 Compliance and I don’t particularly think it applies to our VoIP, or VoIP in general

Why it might: Section 17.04 qualifies the applicability of the rule to

Every person that owns or licenses personal information about a resident of the Commonwealth and electronically stores or transmits such information shall include…a security system covering its computers, including any wireless system

Like just about any business, we definitely transmit personal information over our phone system, so I think the technical / legal question is whether an electronic phone system of the type in question is covered under the “its computers” phrase.

Stepping back from the legal to the practical, however, it seems fair to expect reasonable information security from our communications systems, including VOIP. At least in its intent, I think that’s what 201 CMR 17 is after. VOIP is still new enough that I suspect many prospective customers (like us!) aren’t quite sure what constitutes a reasonably secure installation, though we sense that there are all kinds of potential attack vectors not present in POTS.

• Doesn’t really want to do more than one thing if you only have 1 GB RAM, very noticeably worse than Tiger in this regard (never ran Leopard much on only 1 GB).  I guess there are more ints running in the OS & in basic apps than I would have thought, if it is the 64bitness to blame.
• Doesn’t work with our older b/g Airport Extreme. Says it’s on the wireless network, but doesn’t configure TCP/IP settings — this is after much experimenting with various Airport settings. Search for ‘snow leopard wireless’ for a variety of related complaints.
• Doesn’t work with the Citrix XenApp web plugin. To be fair, this seems to be due to Citrix expecting Java 1.5 to be installed, which is kind of lame. Workarounds are reported on the internets, but then you’re managing your own Java installation, which seems to be one of the most vulnerability-plagued pieces of OS X.

My conclusion, as of 10.6.2: no reason to upgrade from Leopard, unless you’ve bought brand-new hardware that requires SL.

some tidbits:

• 201 CMR may even apply to entities entirely outside of MA, as long as they have any data about Massholes in their systems. So don’t get all smirky in Texas or wherever.
• Who knew? Martha Coakley, as AG, gets credit for helping adjust 201 CMR to work better with business’ realities. That, and her Harpoon preference, really ought to be pushed more strongly by the campaign.
• A useful collection of info can be found at one of the ugliest websites in recent memory.

Fortunately, there doesn’t seem to be anything particularly unreasonable in the requirements, so organizations following good data security procedures shouldn’t have to do much work (if any) to be compliant.

• restore many single files
• restore older versions of files
• restore entire drive / filesystem, compare to original (same size? etc.)
• recreate entire system
• pretend a given backup volume is bad, use alternate
• restore without touching backup server (as if it were destroyed)
• include database restores, inc. database at different point in time
• dream up painful scenarios with pessimists, test for those regularly

To actually do these tests, he suggests making a list & randomly picking a subset to test on a monthly basis.

Fun, huh? Beats holding the bag when your organization’s vital data goes missing.

1. FileMaker database sitting behind a firewall (though similar issues would pertain for other internal databases / services)
2. Website hosted elsewhere (i.e. other side of firewall)
3. Need to get data from #2 to #1 reliably and securely

Up until today, I’ve only had one instance of #2 in this situation. I dealt with it by storing data collected on the website (which happened to be written in Rails) in a database on the web server, and then running a periodic PHP script on the FileMaker server that connects to the Rails app via phpactiveresource, pulls in pending data, and inserts it into FileMaker via its PHP api.

That instance was such a roaring success that the requests have been pouring in for more of the same. Some of the new requests will be handled by a site running PHP, so I’ve got a bit of rewiring to do — I can’t see any sense in the getting the data from the PHP app into something the Active Resource client can talk to.

Stepping back and looking at the bigger picture, issues here include:

• the connection from the website to the FileMaker server could be down, so data collected by the website needs to be stored until it can be confirmed to have made it to FileMaker.
• it would be nice for this to happen in a timely fashion
• multiple technologies on the web side (PHP & ruby) are going to be collecting data to be submitted to FileMaker, so it’d be nice if the transfer machinery can be agnostic and just accept JSON or XML or something.

Sounds like a problem for a queue system, huh? So my current plan is to run a beanstalkd instance on the webserver, deposit JSON-endocded data into it from the web sites, and run workers that write to FileMaker using the Ruby FM API. I have no experience with beanstalkd, but a bit of googling suggests that it’s at a nice point in simplicity to configure & run, maturity, light weight, and easy access from PHP & Ruby.

A further benefit of working in beanstalkd is that, based on a quick perusal of the recommended Rails integration, it should be really easy to break Observers out to async code, thus making my rails apps snappier.

Any advice to the contrary is of course welcome. I’ll try to remember to update y’all on how this turns out.

In the beginning, I got a little confused by the HTTP auth options. I’d been hoping to use Digest mode, but a comment on this post points out the logical problem with that: Digest doesn’t involve the password making its way to Apache, so there’s no way for it to pass the password along over LDAP.

BTW this is under Tiger (OS X 10.4) — I’m not sure if anything changes with other versions of OS X.

Once figuring out that I did need to use Basic auth, Production Monkeys got me most of the way with my Apache config. What I missed is that, at least with our OD configuration, it’s necessary to include the server name in the dc list. Here’s what worked for me:

<Location "/somewhere">
AuthType Basic
AuthName "Whatever You Call This Auth"
Require valid-user
AuthBasicProvider ldap
AuthLDAPURL ldap://servername.yourdomain.org/cn=users,dc=servername,dc=yourdomain,dc=org?uid
AuthzLDAPAuthoritative off
 </Location>

Being a programmer, this kind of duplication smells bad to me, so I dug around for possible solutions. One of the systems happens to be Apple’s Open Directory, which speaks LDAP — seemed like the obvious integration point. However, it turned out that none of our other systems was predisposed to pulling in the auth info over LDAP. Since I only have a few dozen users to support, I filed the whole thing deep on my todo list and basically forgot about it.

Now, however, I’m starting to roll out new services, which are mostly web-based. Being loath to make the dup auth situation worse, I gave some more thought to this issue, and realized that OpenID might be a good solution. Off I went in search of an in-house OpenID server to store my user data. ( there is a tool for OpenID-enabling your LDAP server, but reading about implementing it makes my head hurt )

Surprisingly, there don’t seem to be a huge amount of people running their own organization-level OpenID providers. After digging around for a while, I ended up at a page on the openid.net wiki, which does list a number of projects that enable you to run your own OpenID provider. Most of them look a bit half-baked or abandoned, but two appear to be alive and potentially appropriate for my needs: clamshell and community-ID.

Next steps, then, are to install one or both & see how it goes.

I like ubuntu, so that’s where I started looking at for the host OS. Being on the client end of Xen via slicehost has been smooth, but there are also other virtualization options pushed in the Ubuntu docs, including at least VMware and KVM, so I’ve spent a little time looking into them. I’m a bit of a Free Software snob, so VMware was off the list. KVM requires one of a small set of recent processors to run — the CPU of the server in question is on that list, so KVM remained an option.

Due to previous experience, though, I started looking at Xen first, only to find that Ubuntu isn’t and won’t be supporting Xen from the current release onwards. Wondering why that would be, I came to the following debate, and became thoroughly confused.

After getting this far into the process, I revisited my reasons for looking into virtualization in the first place, and came to the conclusion that my relatively simple needs don’t justify the time to wade through the options.

• I’d forgotten how to figure out the Soekris’ MAC address, which is needed for the DHCP server config. Turns out it’s shown when you tell the soekris to try netbooting via boot f0.
• The ubuntu (& presumably debian) tftpd configures itself without the -s flag, which allows pxeboot’s requests for files like /bsd to be found in the /srv/tftp/ directory
• Despite rediscovering the above, I ended up reinstalling onsite from my macbook. Got most of the way thanks to tfpd tips here and the ISC dhcp server from MacPorts. However, as launchd was involved, there was much unhappiness getting tftpd to actually serve the files in question. Had just about thrown up my hands when I figured out that the -s flag actually works the same as it does in debian, not the way the OS X manpage says it does.
• After close to 10 years of being confused about why OpenBSD’s installer often pukes when trying to use a local ftp or http connection, I finally thought to look at my local webserver’s access log, and saw that the installer was trying to get an index.txt file. Creating one with the name of the relevant files did the trick.
• I thought to plug the Soekris into a Kill a Watt while installing, and never saw a draw of over 4 watts while formatting the CF, copying over the install set, or writing the files. Not bad! Idles at 2 watts.

Rather than taking Michiel’s exact approach with the memory filesystem, I decided I’d use the memoryfs for the commonly-changed files, but leave the root writeable, which has the benefit of allowing ports to be installed and configuration changes to be made on the fly.

I’d read that it’s a good practice to always use a dedicated layout for any PHP scripts you have that are talking to a FileMaker database. While I’d seen reasons of efficiency and reliability, today I learned another reason that’s true: it can eliminate otherwise hard-to-debug problems.

At first when working on my current FileMaker <-> PHP project, I was attempting to reuse an existing layout that had all the info I needed. While my permissions seemed to be fine for the data file and layout I was attempting to access, actually running the script kept resulting in “Error 100: File is missing” coming back at me as soon as I added any criteria to my search. FileMaker doesn’t bother putting anything useful in its server logs, either, so it wouldn’t have been much fun picking through the layout & figuring what linkage(s) were to blame.

However, by simply creating a dedicated layout, everything started working as planned. A practice I’ll be following in the future.