Topic: Preinstall Assumptions
Topic type:
What assumptions does the installation guide make about our set up before it outlines its steps.
Originally written by Walter McGinnis, Kete Project Lead for Katipo Communications, Ltd.
Part of the Installation Guide
All Platforms:
I won't be covering all the security measures you should be taking or the initial installation and configuration of your operating system. Security, besides common practices, is beyond the scope of this guide. I also won't be covering things related to mail or DNS, I assume you have a handle on both.
Speaking of DNS, if you are developing or demoing a site and aren't ready to have a dedicated host entry in DNS, you might be interested in this optional step; Add Your Kete Application to /etc/hosts or "ghost".
How to use this guide:
There are few conventions that most people will be able to guess, but I'll spell them out so there is no confusion.
When a step requires you to specify something that varies for each person's installation, we try to name it something self-explanatory and prefix it with "your_" with underscores between words. Such as...
When you create a Kete application, as it is with all Ruby on Rails applications, you have to choose a name for it. This is then the basis for how to name other things that your application depends on.
The database settings are a good example. If you chose "kete_net", as we have for the old.kete.net.nz site, your production database would be called "kete_net_production" and the database user would be named "kete_net".
Pay careful attention for anything with "your_" prefix in the steps or things like provided configuration file templates. It means you need to replace it with something specific to your installation.
When we are indicating running commands from a terminal session (a shell) as a normal user (but with sudo privileges) it will look like so:
$ some_command
The "$" is our shorthand for the shell prompt. You only need to type what is after the $ sign, i.e. "some_command" above.
Your shell prompt may vary. For example, in my current session on Mac OS X 10.5 it is "bash-3.2$", whereas in a Debian Etch session it looks like "walter@some_host:~/path/to/where/i/am$".
When we switch to being logged in as the root user via a "sudo -s" command, we'll note it like this:
root@host: # some_command
You only need to type what is after the # sign (the first one, sometimes we'll include shell comments at the end of commands, too.
I sometimes use ellipsis, as you would guess, to indicate "other stuff before here" or "other stuff after here", as well as "a response from your last command before the prompt".
We may also note when you are inside a particular program's shell client by listing it's prompt as well as the command. It should be fairly obvious.
Just a reminder: like most big installation processes, it's a good idea to have a complete backup of your system BEFORE you start the Kete installation process.
Debian Lenny:
You will need a host with fresh and up-to-date installation of the Debian Lenny operating system running with its network connection configured, ssh access enabled, and that you have a user account with full sudo privileges.
Mac OS X:
You will need a host with fresh and up-to-date installation of Mac OS X 10.6 (Snow Leopard 10.6.6 or greater) operating system running with its network connection configured, ssh access enabled, and that you have a user account with full sudo privileges.
We'll be using Homebrew (a software package manager) for it's speed and convenience.
Next step for:
Debian | openSUSE | Mac OS X | Solaris 10
Walter McGinnis
said YAZ and Zebra Version
Update: the below comment is no longer relevant. You may use the latest versions of YAZ and Zebra. The comment is left in place to reflect the history of the project.
------
For the time being, you must use the YAZ and Zebra versions that are specified in the required software installation topic for your platform.
This is because there was a change in the configuration file formats at some point in their development that breaks Kete's included Zebra configuration files. There may also be issues around handling of the OAI-PMH records that we pass to Zebra since their has been some change in Zebra's parsing of records. I haven't had the time yet to track down the problem and since I know these versions work... I haven't made it a top priority.
If someone would like to volunteer to work on the Kete Zebra configuration files to make them work with newer versions YAZ and Zebra it would be hugely appreciated.
Cheers,
Walter
Tags: Kete, Installation, YAZ, Zebra