You are here

Wikis

Wikis, ./configure, and make

When installing packages from source on *nix servers, I find I need to compile the software identically across several machines. (I do realize that this would be easier if I built a single package and then installed that using the OS/distribution package management tools but that's for another day.) Or sometimes I need to upgrade a package and keep the configuration information the same.

On my personal webserver (which runs this site), I have a directory that contains scripts that include the ./configure command (or the equivalent for the package) and the options for that command. Whenever I need to rebuild a package that has such a script, I just need to run the script.

However, there are some packages that lack such scripts. In these cases, I have to go to the old source directory, check config.log to find how I built it last and then use the same options in the new directory. (Or the same directory if I am reconfiguring the same version of the package.) I find that due to a feature of config.log and either screen or my SSH client that I have to retype parts of the ./configure command-line because it has wrapped around and the wrapping isn't being honored.

The latter is clearly non-optimal. The former is better but is limited to a single machine. If I need to build a package in a like manner on a different machine, I either have to copy the script or recreate it on the new one. Either way, this process is somewhat cumbersome.

An improvement I am trying is documenting the build process used for all software on a wiki. This provides a central (and version controlled) repository for the information that I can refer to independently of the SSH session. It does require a browser but this is not an issue in today's world of large screens and the movement towards using multiple monitors. (If screen real-estate is at a premium or you're not at a workstation, most wikis render well in lynx. If using ikiwiki, you could even check out the repository and view it with less.) Also, if multiple machines have the same software installed but require slightly different configurations, you can make the note in the wiki entry so you can easily see the differences. Further, since wikis implement revisions, you can see how the options have changed over time.

The challenge is making sure that all packages get documented correctly. However, once in the habit of documenting the process, it should become easier to make sure that future packages are documented as well.

Implementing A Distributed Wiki

In my last post, I mentioned wanting to set up a personal wiki. I thought about it more this morning and realized a standard, centralized wiki would not work as well as I had originally thought. In order to properly use a wiki, I need to have access to it offline on my laptop.

Doing a Google search for "distributed wiki" returned this post which mentioned ikiwiki. ikiwiki can use a version control system as its backend for articles. Using its support for git provides for a distributed wiki (in the same sense of "distributed" as git is a "distributed" version control system). There are even instructions on how to do this.

I have ikiwiki set up on the webserver now. I encountered some issues with the web update functionality because I do not allow setuid scripts to run on the partition with the websites. This has resulted in some non-optimal permissions but I hope to fix this in the near future. (Or, at the least, when I rebuild my webserver.)

The one thing I don't like about ikiwiki is needing to rerun the setup script every time I want to change something. However, this shouldn't be a problem once I'm done tinkering with the configuration. I suppose I'm just spoiled from using a lot of PHP web applications (like Drupal and phpBB), and perhaps interpreted languages in general, that having to run a command to "make" the application seems cumbersome.

I'm still working out the logistics of the laptop-side of this. I'm tempted to run the laptop's copy of the wiki repository on a USB flash drive so that way I can even access the files on other machines entirely. (Running git might be hard but text editing should still work.) The issues with this are finding a format that all OS X, Windows, and Linux like that is not FAT32. With the appropriate software, ext3fs may be the winner but this is another topic for another day.

Edit, 03 March 2009: After some thought, I am concerned that the title is misleading. So if you've come here looking for quick instructions on how to set up a distributed wiki:

  1. Download ikiwiki.
  2. Install ikiwiki.
  3. Setup ikiwiki.
  4. Set up a git repository with ikiwiki-makerepo. (There are directions on how to do this near the end of the "by hand" setup instructions.)
  5. Configure ikiwiki to use the git repository.
  6. Test ikiwiki.
  7. Repeat the above for all other machines you may want to run the wiki on. Note that there may be special configuration needed on machines that may be offline, e.g. laptops.
  8. Enjoy your new wiki.
Subscribe to RSS - Wikis