How shall I install PmWiki into our web application’s directory structure? I have source code, third-party library, and (user generated) data sub-directories. A wiki spans all three: it should be installed in the library area, the generated wiki pages should go into data, and pages that are to be kept long-term must be backed up. I don’t want a separate backup procedure, thus I wish to place the wiki content under Subversion source code control.

Wiki packages seem to prefer their default directory scheme, so I decided against trying to force PmWiki into my structure and instead will create a new top-level directory just for it. The plan is that only this pmwiki directory and the wiki.d and local sub-directories will be under subversion control. All other files and directories will be unversioned.

Initial installation of the PmWiki software:

1. mkdir -p pmwiki/{wiki.d,local}
2. svn add pmwiki
3. ln -s pmwiki{,-2.1.27} # symbolic link so that the versioned tar file is extracted into the controlled directory.
4. tar -xzf pmwiki.tgz
5. rm pmwiki-2.1.27
6. Edit local/config.php
7. Add the “rename” action to cookbook area, config.php (and optionally to Site/ EditForm).
8. Modify the logo and skins/themes.

Both developers and eventually end-users will be editing Help and Manual pages using the Wiki interface. This editing may occur on the development web server or the public system. I want to capture “approved” changes into subversion, which I believe can be done by committing the wiki.d directory periodically.

Once end-users start editing the public site, developers must either: a) make our edits on the public site also, or b) update our development server to match the public site, make our edits, commit the update, and re-publish to the public site. Option b must be done quickly or by disabling editing on the public site during the update.

Suppose we arrive at a point where there are numerous desired updates made by the user community, a few vandalized pages, plus other edits which we don’t want to adopt into the official documentation. Here’s a procedure:

1. Clone the public site’s wiki.d onto the development server.
2. On the development machine, restore or svn revert the vandalized pages.
3. Restore, modify, or svn revert the updates we wish to discard.
4. svn commit the wiki.d directory.
5. Check-out and publish the updated configuration to the public site.

I’ve always used smbmount (or mount.smbfs) when I need to mount a shared Windows folder, but when I tried it today, no luck:

mount: unknown filesystem type ‘smbfs’

Figured I just needed to install the package, but YaST came up empty. Searching on the web, I find that SMB file system support is not compiled into openSUSE 10.2 and that people are using cifs (Common Internet Filesystem) instead. I tried it and it worked, but some people aren’t happy about the removal of smbfs.

mount -t cifs -o username=uuu,password=ppp //winHost/Shared\ Docs /mnt

The mount seems to work just like the smbfs mount. A cursory search turned up no reason why smbfs support was removed by openSUSE. Anyone know the reason?

Update: Upon receiving Nick’s comment (thanks, Nick), I searched for more details and discovered the Linux CIFS Client Guide on the Samba web site. It describes the differences between the Linux smbfs and cifs file system drivers, and continues with an in-depth discussion of cifs driver usage and optimization.

How do small groups do shared document development these days? We had a SharePoint site; it requires heavyweight applications (MS Office) on each client machine. We have Subversion for source code and are also using it for shared scheduling with GNU Project. I had a Writely account; it is a pure Web Service Application, but I sort of lost track of the account after Google bought them.

We are writing a browser-based app, so should be eating our own dogfood when possible during development. That says an HTML-based browser application such as Writely or a Wiki. Well, I decided to go with a Wiki, so now I need to select a Wiki Engine.

When I went searching, I found a Top Ten Wiki Engines page and the WikiMatrix. I put some criteria into the Matrix’s Choice Wizard and then compared its output to the Top Ten list. Here are my finalists:

• MediaWiki – Wikipedia’s engine. It’s the only wiki engine that openSUSE 10.2 includes in the distribution. I was about to go with it by default, but then saw that it is targeted for high-traffic sites.
• PhpWiki – “a WikiWikiWeb clone written in PHP. PhpWiki works right out of the box with zero configuration,” says the Matrix. Things were in some disarray at its SourceForge sites, however.
• TWiki – “a flexible, powerful, and easy to use enterprise collaboration platform. It is a Structured Wiki, typically used to run a project development space, a document management system, or any other groupware tool,” says the Matrix. I was impressed with their web site. TWiki is a high-traffic, high-powered system.
• PmWiki – another engine written in PHP. Their web page also looks nice and lists lots of current users which gives a good idea of what its capabilities are. Many of the sites are small installations.

TWiki and MediaWiki are high-horsepower systems for big sites and PhpWiki and PmWiki are more appropriate for small sites. I want minimal overhead and maintenance at this point, so I’ll start small and move up later.

I selected PhpWiki for my first attempt, swayed by the “runs out of the box” promise. It installed out-of-the-box, as I didn’t have to modify my Apache configuration files or install any other rpm packages. However it didn’t run out-of-the-box, and the configuration was rather tedious. It has a configurator, but it is apparently newer than that installation doc that I read. After a couple of hours playing with it, I decided thumbs-down on the out-of-the-box claim.

Next up, PmWiki. It did run out-of-the-tarball and essentially met all of my initial expectations. Installation configuration is straightforward, well documented, and confined to one file. All of the user-created pages go into the wiki.d sub-directory. Based on the painless installation and quick learning curve, PmWiki is my choice for our wiki engine.

The Amazon Web Services Simple Storage Service (AWS S3) agreement makes it clear that you the user are completely liable for any unauthorized use of your secret key. However, their PHP, Python, and Ruby code examples usually start off with “$secretKey = <insert your key here>” followed by a caution to “only use this example code on a secure server.”

I want to host a PHP application on a shared, remote server where I have only ftp access. I have to assume such a server is not secure, since any sysadmin at the hosting service can browse at will. I’m surely not the first person to host an S3 application on a remote server, yet there are only unanswered threads in the AWS forums regarding best security practices. So I’m guessing that some users are uploading the AWS secret keys and hoping for the best.

Here are the ways I’ve considered for using S3 from a Shared, Remote Web server:

1. Upload Secret Key – either in plain text or nominally concealed by an XOR hash or hex encoding. It would be concealment only, not encryption, since PHP is not compiled.
2. Encrypt and Upload – use another language (Java) or extension (Zend engine) that provides some security. AWS has some sample Java code that does this.
3. Use Public Buckets – from a secure machine, create a public_read_write bucket on S3. The PHP application on the shared server can then use anonymous access to read and write objects without requiring the secret key.
4. User Grantee – the AWS documentation states that access can be granted to anyone who has an account on amazon.com, even those without an AWS account. Obviously, such a person would not have a secret key. So the shared server application could use an amazon account to access a bucket with such a grant. However, the documentation does not explain how to sign a request with a canonical account name without a secret key.

I rejected options 2 & 4 as having too many unknowns at this stage of development. Adding a new language just to encrypt a key is a big hit in complexity. Similarly, with no cookbook example and the rather hastily assembled user documentation, I expect lots of trial and error for option 4. But once documented, option 4 would be my clear first choice.

Options 1 & 3 shift risk between a particular bucket and one’s secret key. With option 3, anyone who discovers the publicly read/writable bucket can use it immediately without even needing to find my PHP source code. But since they don’t have my secret key, I still have control over the bucket and can turn it off (delete it or make it private).

Option 1 exposes no public buckets on the web. But the worst case (someone gaining access to the remote server and stealing the secret key) has a big exposure. Only Amazon customer service can turn off a secret key, and they’re available only by email and only during business hours. If they take a week to shut off the key, I’d be liable for all of the charges.

My choice is option 3. I’m more comfortable with the risk profile being concentrated onto one bucket. Also, option 4 is a straighforward upgrade once more documentation becomes available. One unknown: is there any easy way for hackers to scan AWS S3 searching for public buckets? Let’s hope not.

I’ve been investigating the following code bundles to help me to get underway with the Amazon Web Services Simple Storage Service (AWS S3):

• Test Utility for Amazon S3 in PHP – from the AWS Developer Connection, it provides s3-test-utility-php.zip which contains: s3.php, index.php, and readme.html. Using the browser GUI provided by index.php to control s3.php, I was able to create a bucket and upload an object. Code is documented and lists the derivation history of the code (see Storage3 and Mission Data Blog below).
• Amazon S3 Sample in PHP – an alternative s3.php that has some common heritage with the Test Utility s3.php.
• Storage3 Project – the predecessor of the AWS Test Utility package, provides file Storage3.php plus the required PEAR modules (making it easy to install on a remote server where PEAR can’t be invoked).
• Mission Data Blog – presents the original putObjectStream() method that has now been modified to use a file in the AWS Test Utility.

I want to stream data directly to S3 (without first saving to a file) thus the current form of the AWS Test Utility package won’t work directly. I can either use the Storage3 project or substitute the Mission Data putObjectStream() method back into the AWS Test Utility s3 class.