I just had the occasion to install Ikonboard
(
http://www.ikonboard.com/) a piece of message board software written
in Perl. It was an enlightening experience, and one I'd like to share.
There's been some discussion previously about the problem with
installing OpenGuides being that the build process installs both the
modules and the site. I think the Ikonboard guys have hit the nail on
the head with their install process, so here's a breakdown of how it
works.
* You untar the install package and move the contents of the cgi-bin
directory to wherever your CGIs live. There's a perl_test.cgi and an
installer.cgi which you chmod +x.
* Running perl_test.cgi from your browser checks whether you have
prerequisite modules (CGI, DBI_File at least, or optimally various DBI
drivers) installed, and prints out both a bunch of $ENV and the
contents of your @INC for you to keep around for debugging purposes
should you need it.
* If you have everything, next you run installer.cgi from your
browser. You're presented with a screen that lists various files (such
as the ikonboard.conf file) and directories and whether they have
their permissions set correctly for the install to proceed. If they're
not, you set them appropriately and re-run the script. Presuming
everything is correct, it presents you with a button to proceed.
* Next you get a screen with various fields where you set paths to the
various directories - skins, static HTML, uploads, and so on.
* The next screen checks permissions on all these places as being writable.
* Next, the installer untars a bunch of tarballs that were included in
the installation directory, and moves their contents to the
directories you specified. One screen appears per untar; if
successful, it reloads the script with an incremented CGI argument to
move on to the next file. Very smooth to watch. Presumably if anything
fails it presents an error screen. (Note: this whole step is optional;
you can choose to skip it if you've already manually placed various
files in their destinations.)
* Next you get a screen to choose your admin user name and password,
set the name of the site and board to be displayed, and so on, and
asks you what kind of DB you want.
* The next step sets up the database and displays a confirmation of
the stuff that just happened.
* Finally, it redirects you to the board login screen - but the board
script refuses to run until you've gotten rid of installer.cgi, as
that would be a security hole. After you've ditched it, you can log
in.
Overall, it's an excellent install experience. Hopefully you can see
how well it maps onto the site-related part of our own install
mechanism. I can see our existing Build.PL being hacked into two parts
- the first part, which remains Build.PL, installs the libraries. The
second part would become our installer.cgi. I see their reason for
keeping perl_test.cgi separate, as well: if a user is having problems,
they can run it to produce an instant system report to diagnose
issues. As a minor note, I think having the various templates and so
on as tar files within the tar file may be slight overkill - copying
from one dir to another works for me.
If people like the sound of this (perhaps even try downloading and
running the thing yourself; it only takes a moment and you can throw
away the result), would you be interested in me having a go at
producing something like it for us?
My only slight reservation about this is that I don't know how Dom's
packaging for Debian works, and if this would be completely
incompatible with it. Dom?
Cheers,
Earle.
--
Earle Martin
http://downlode.org/
http://purl.org/net/earlemartin/