Greenstone Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.



====== Administration ======

An “administrative” facility is included with every Greenstone installation.To access this facility, click the appropriate link on the front page.

The entry page, shown in Figure <imgref figure_greenstone_administration_facility>, gives information about each of the collections offered by the system. Note that //all// collections are included—for there may be “private” ones that do not appear on the Greenstone home page. With each is given its short name, full name, whether it is publicly displayed, and whether or not it is running. Clicking a particular collection's abbreviation (the first column of links in Figure <imgref figure_greenstone_administration_facility>) brings up information about that collection, gathered from its collection configuration file and from other internal structures created for that collection. If the collection is both public and running, clicking the collection's full name (the second link) takes you to the collection itself.

A collection named //wohiex//, for //Women's History Excerpt//, is visible near the bottom of Figure <imgref figure_greenstone_administration_facility>. Figure <imgref figure_information_about_the_womens_history_excerpt_collection> shows the information that is displayed when this link is clicked. The first section gives some information from the configuration file, and the size of the collection (about 1000 documents, about a million words, over 6 Mb). The next sections contain internal information related to the communication protocol through which collections are accessed. For example, the filter options for “QueryFilter” show the options and possible values that can be used when querying the collection.

The administrative facility also presents configuration information about the installation and allows it to be modified. It facilitates examination of the error logs that record internal errors, and the user logs that record usage. It enables a specified user (or users) to authorize others to build collections and add new material to existing ones. All these facilities are accessed interactively from the menu items at the left-hand side of Figure <imgref figure_greenstone_administration_facility>.

<imgcaption figure_greenstone_administration_facility|%!-- id:586 --%Greenstone Administration facility ></imgcaption>
{{..:images:user_fig_17.png?335x699&direct}}

<imgcaption figure_information_about_the_womens_history_excerpt_collection|%!-- id:587 --%Information about the //Women's History Excerpt// collection ></imgcaption>
{{..:images:user_fig_18.png?331x699&direct}}

===== Configuration files =====

There are two configuration files that control Greenstone's operation, the site configuration file //gsdlsite.cfg// and the main configuration file //main.cfg//.

The //gsdlsite.cfg// file is used to configure the Greenstone software for the site where it is installed. It is designed for keeping configuration options that are particular to a given site. Examples include the name of the directory where the Greenstone software is kept, the http address of the Greenstone system, and whether the //fastcgi// facility is being used.The entries in this file are described in the //Greenstone Digital Library Installation Guide//.

The //main.cfg// file contains information that is common to the interface of all collections served by a Greenstone site. It includes the E-mail address of the system maintainer, whether the status and collector pages are enabled, whether logs of user activity are kept, and whether Internet “cookies” are used to identify users.

===== Logs =====

Three kinds of logs can be examined: usage logs, error logs and initialization logs. The last two are only really of interest to people maintaining the software.

All user activity—every page that each user visits—can be recorded by the Greenstone software, though no personal names are included in the logs. Logging, disabled by default, is enabled by including the lines

<code>
logcgiargs true
usecookies true
</code>

in the main system configuration file. Both options are false by default, so that no logging is done unless they are set. It is the //logcgiargs// line that actually turns logging on and off. By activating //usecookies// a unique identification code is assigned to each user, which enables individual user's interactions to be traced through the log file.

Each line in the user log records a page visited—even the pages generated to inspect the log files! It contains (a) the IP address of the user's computer, (b) a timestamp in square brackets, (c) the CGI arguments in parentheses, and (d) the name of the user's browser (Netscape is called “Mozilla”). Here is a sample line, split and annotated for ease of reading:

<code>
/fast-cgi-bin/niupepalibrary
(a) its-www1.massey.ac.nz
(b) [ Thu Dec07 23:47:00 NZDT2000]
(c) (a=p, b=0, bcp=, beu=, c=niupepa, cc=, ccp=0, ccs=0, cl=, cm=, cq2=, d=, e=, er=, f=0, fc=1, gc=0, gg=text, gt=0, h=, h2=, hl=1, hp=, il=l, j=, j2=, k=1, ky=, l=en, m=50, n=, n2=, o=20, p=home, pw=, q=, q2=, r=1, s=0, sp=frameset, t=1, ua=, uan=, ug=, uma=listusers, umc=, umnpw1=, umnpw2=, umpw=, umug=, umun=, umus=, un=, us=invalid, v=0, w=w, x=0, z=130.123.128.4-950647871)
(d) “Mozilla/4.08 [en] (Win95; I ;Nav)”
</code>

The last CGI argument, “z”, is an identification code or “cookie” generated by the user's browser: it comprises the user's IP number followed by the timestamp when they first accessed the digital library.

The log file //usage.txt// is placed in the //etc// directoryin the Greenstone file structure (see the //Greenstone Digital Library Developer's Guide//).When logging is enabled, every action by every user is logged. However, only the last 100 entries in the log file are displayed by the //usage log// link in Figure <imgref figure_greenstone_administration_facility>.

===== User management =====

Greenstone incorporates an authentication scheme which can be used to control access to certain facilities. At the moment this is only used to restrict the people who are allowed to enter the Collectorand certain administration functions. If, for a particular collection, it were necessary to authenticate users before returning information to them, this is possible too—for example, documents could be protected on an individual basis so that they can only be accessed by registered users on presentation of a password. However, no current collections use this facility). Authentication is done by requesting a user name and password, as illustrated in Figure <imgref figure_using_the_collector_to_build_a_new_collection>.

From the administration page users can be listed, new ones added, and old ones deleted. The ability to do this is of course also protected: only users who have administrative privileges can add new users. It is also possible for each user to belong to different “groups”. At present, the only extant groups are “administrator” and “colbuilder”. Members of the first group can add and remove users, and change their groups. Members of the second can access the facilities described above to build new collections and alter (and delete) existing ones.

When Greenstone is installed, there is one user called //admin// who belongs to both groups. The password for this user is set during the installation process. This user can create new names and passwords for users who belong just to the //colbuilder// group, which is the recommended way of giving other users the ability to build collections. User information is recorded in two databases that are placed in the Greenstone file structure (see the //Greenstone Digital Library Developer's Guide//).

===== Technical information =====

The links under the //Technical information// heading show further information on the installation.The //general// link gives access to technical information, including the directories where things are stored.The //protocols// menu item gives, for each possible protocol type, information about each of the collections supported by that protocol.

Finally, user interface code (called the “receptionist”) uses //actions// to communicate the wishes of the user. These actions correspond to the CGI argument labeled //a//. For example, if //a=status// the receptionist invokes the //status// action (which displays the status page). A menu item gives access to lists of all actions supported by the system, and another leads to the arguments that these actions take.