Category: Open Source

My friend Leanne has a wisdom that I am only beginning to understand. A couple of weeks ago we were having pints of beer at an old college hangout and topic of conversation got onto computers. At this point a mutual friend interjected:

“But the Macintosh is the best computer platform available. How can you not think it will take over the entire PC marketplace?”

— DW

Now, if someone accuses me of being a Mac fanboi I’ll demure so I agree with his statement about the best platform. But I’m more than willing to argue over his question. As I learned long ago from Leanne:

 “Being the best product in the market place does not guarantee that you will win in your market.”

–LF

 As denizens of open source this is an axiom that we would do well to understand. Most time when I meet Linux fanbois, especially in businesses outside of the computer industry I both admire and am appalled by  some of the things that they want to do. I wish they would ask themselves the question:

 If Microsoft is not the best product in it’s marketplace why does it have the best marketshare? 

In operating systems Microsoft is certainly not the best product in the marketplace. It has the most users because of a combination of things. Not to be minimized in that list of attributes is the support that Microsoft gives to it’s customers. (In fact support is probably the main reason why Mac OS X is the best product in the OS market).

 For denizens of Open Source the support line is critical. As this economy rolls onward more and more of us will be getting the opportunity to build cool business projects on Open Source. When we do this we must understand that being the best tool in the market place isn’t enough. So when you are making the decision between say FreeBSD, CentOS, and Red Hat Linux: Unless you know that you or someone a lot like you will be supporting the project until you are  90 years old and buried. You’d better choose Red Hat or have a damned good reason for choosing something else. As a consultant I’m getting used to seeing and hearing IT managers freak out when they find out that some mission critical app is running on an operating system that they haven’t heard of. Trust me, you are very lucky if your Manager is even aware of CentOS.

 If you must choose an open source application for your project it’s very important that the application has developed to the point of having both a stable and a development branch. Because no matter how sexy the development branch is, if you want to see the project end up with a reasonable life span then you’d better choose the stable one.

 These are two of the things that your Director of Open Source Development and CIO want to see. They want to see it for a lot of reasons:

 Imagine, a mission critical app is intermittently up and down because of a bug in the operating system. Two managers, one’s on the phone to Red Hat in North Carolina and the other is grovelling through Google looking for a source code kernel patch for FreeBSD. Which one gets to keep his job after the problem is fixed?

 Imagine, your intranet project that needs just a couple of tweaks to authenticate against Active Directory so it can go corporate. The expertise to do so doesn’t exist in house because you left for that cherry job at Google. What does your manager say when he finds out from his consultant that you need another 20 man hours to pull the project onto a stable release the wiki software that you chose for the foundation?

 Peace

My father-in-law asked a question about email the other day that perplexed me. We recently got him a Mac and he was complaining about the “spinning beach ball of death” when he tried to send a message. It turns out that the message was 50 full sized digital photos for my brother-in-law. After he explained that detail it made sense that Mail was choking. I told him that the mail was simply too big and that the better way to share the pictures would be to post them in a website. I also promised to come up with a solution for him in a week or so and give him a helping hand getting everything posted.

Normal people would look at Picasa or Flickr or something but neither of those sites interest me. Most of the photo sites on the web  want you to sign up which infringes on my privacy. They grant you some promotion through search engines for the privilege but Bapa doesn’t need the world to be able to see his photo album. To my “Open source guy” brain the immediate solution would be to create the site and then setup something like coppermine or gallery2 but both of those solutions require me to teach Bapa how to post to a photo web site. Picasa and Flickr have the same issue.

Fortunately for me, Bapa has a Mac. The Mac has a set of wonderfully integrated tools for doing exactly this sort of thing. I decided that the easiest thing to do would be to Apache and mod_dav to grant access to some web space. And then use apache to publish a site from within the web space. The Apache config is actually pretty simple. You use two virtual hosts. One points to the backend and one points the actual site. Here’s the apache2 config for the backend:

<VirtualHost *:80>
    ServerName      backend.example.com
    ServerAlias     backend

    ServerAdmin     webmaster@example.com

    DocumentRoot    /home/www/sites/backend.example.com/
    DAVLockDB       /var/www/DavLockDb

    <Directory "/home/www/sites/backend.example.com/Dav/">
        Dav On
        AuthName    "Photo DAV Fileshare"
        AuthType    Basic
        AuthLDAPURL ldap://ldap-slave.example.com/ou=people,dc=example,dc=com?uid
        <LimitExcept GET HEAD OPTIONS PROPFIND>
            require valid-user
        </LimitExcept>
    </Directory>

    ErrorLog        /home/www/sites/backend.example.com/log/error_log
    CustomLog       /home/www/sites/backend.example.com/log/access_log common
</VirtualHost>

The goal here is to provide DAV access to the web sites storage so the Macintosh toolkit sees it as just another place to store files. The Directory setting tell Apache to provide the Dav directory and everything below it as a shared file system using the DAV protocol. In this case authentication is provided via LDAP but that could easily be changed to .htaccess files.

The actual web sites virtual host config is here.The trick is in setting DocumentRoot to be a subdirectory of the Dav provided above.

<VirtualHost *:80>
    ServerName      photos.example.com
    ServerAlias     photos

    ServerAdmin     bapa@example.com
    DocumentRoot    /home/www/sites/backend.example.com/Dav/photos

    ErrorLog        /home/www/sites/backend.example.com/log/error_log
    CustomLog       /home/www/sites/backend.example.com/log/access_log common
</VirtualHost>

The result is that Bapa can attach the file structure that contains his photo share as a DAV imported file system from his Mac (Finder: Go -> Connect to Server – http://backend.example.com/Dav/photos. Then tell iWeb to publish his website into that space et voilá: his pages are magically published to the web under photos.example.com.

This is about 90% of your setup. You will want to secure things to make sure that they aren’t easily broken. Apache accesses the Dav as user: www so it’s pretty important to make sure that the DAV directory is protected from tampering by having it owned by root:

# mkdir -p /home/www/sites/backend.example.com/Dav/photos
# chown root:root /home/www/sites/backend.example.com/Dav
# chmod 775 /home/www/sites/backend.example.com/Dav

# chown root:www /home/www/sites/backend.example.com/Dav/photos
# chmod 775 /home/www/sites/backend.example.com/Dav/photos

These permissions setup the Dav share so that an object stored in the root of the Dav may only be deleted or removed by its owner. The DocumentRoot of the photos site can be written into by the www user. This isn’t meant as absolution security as much as a means to keep down support calls.

Caveats

In this example I’m doing nothing to protect Bapa’s password from interlopers on the net. In reality you would want the DAV to be provided over https to protect the password. A VPN connection is another possibility.

I wrote earlier about SASL and postfix. One side affect of my setup has been that I get these spurious warnings in my logs.

Apr 4 10:22:19 corellia postfix/smtpd[69626]: auxpropfunc error invalid parameter supplied

I’ve been meaning to throw some time at this problem for a while now but everything works so I haven’t. Upgrading my infrastructure to the latest Open and FreeBSD’s has me using newer packet filtering code with more capabilities so what was once a non-problem has become a pain in the neck. This problem is tied to another feature of cyrus sasl that if find annoying. The configuration for postfix and cyrus is handled through a file called smtpd.conf. This file is stored in /usr/local/lib/sasl2/smtpd.conf. This is annoying for one because under Unix configuration files like this belong in /etc. But for two because the file is poorly documented at best. Reading the source for postfix shows that this is handled by the smtpd_sasl_path. It’s already well documented that this variable isn’t a path, it’s the base file name for the configuration file. This is fixed in postfix 2.5. The warning comes from the initialization of the ldapdb component of sasl. Even though I’m not using it I have to specify the parameter ldapdb_uri.

A while back I found xkcd. I found it through a mailing list but this post grabbed my attention. Here’s a recent comic which made me think about the way that popular web applications use SQL databases. If you don’t get it the
Mom in the comic executed a classic SQL injection attack against her son’s school. (BTW I didn’t want to spoil the joke. You can see the previous sentence by highlighting it with your mouse.) In any case this is a common attack method against many current web applications and it shows just how naively many of the programmers are of SQL in general. There are two practical ways to defend against this attack. The most obvious is to validate your SQL before you pass it to the database engine. One that requires a little more thought would be to disallow the web database user from being able to DROP TABLES in the first place. Any real web application should expect a database with at least two users, root, or dba and webuser, or www. Root should be allowed to do anything to the database but his credentials need to be protected. If your web application has grown to the point where you’ve split your database server from your webserver for performance purposes. Allowing the root or dba level of access from localhost only is a good start. Webuser should be able to SELECT on your applications tables. He should be able to INSERT, UPDATE, and DELETE on a limited subset of tables as your database will allow. He may need to be able to CREATE a temporary table and possible DROP the same but that’s a job that’s really better done by a stored procedure. E.g. create a stored procedure that does the needed manipulation and then allow the webuser the privilege to call the stored. Obviously what you can do here depends on your database. I know that Postgresql can grant these very fine grained security settings. If I recall correctly MySQL is a little more course but is still workable.