Commit 8000a83d authored by Per Cederqvist's avatar Per Cederqvist
Browse files

Initial revision

parent f6296e16
Administrating a LysKOM site
============================
This document is a short description of how to administrate a LysKOM
database on your site.
The first thing you will have to do is to follow the instructions in
the file INSTALL. This will set up the LysKOM system with a database
containing a few necessary conferences and one person - the
administrator.
Once the LysKOM system is running, there is not much you will have
to do to keep it that way. One thing to remember is that the current
release of the server (0.32) has an incomplete handling of garbage
collection of the database. The database is split into two files, the
information file and the text file. Newly written texts are
concatenated to the text file and old texts are never removed. The
information file contains information about conferences, users and
where in the text file the texts are. This file is properly garbage
collected, but not the text file.
There is a program called dbck (Data Base Check) which is used to
check the consistency of the LysKOM database. This program can also
be used to shrink the text file. To do this, just type `dbck -g' in
the database directory, or give additional switches to dbck to use the
correct directory. See further the manual page for dbck. When dbck
is to be run on the database, the LysKOM server *must* be stopped, or
unrepairable damage may result. See below for a description on how to
stop the server.
There is a shell script called updateLysKOM which is used to insure
continuous operation. This script is run with certain intervals and
if the LysKOM server has died for some reason, updateLysKOM restarts
it. If the server is still running properly, updateLysKOM sends a
signal (SIGUSR1) to it, which causes the server to write call
statistics to a file named etc/lyskomd-log in the lyskom directory.
Taking the server down cleanly can be done in two ways: through the
use of the LysKOM protocol on a socket, preferably through the use of
a suitable client, or to send the signal SIGHUP to it. This will
cause the server to save the database and close all client
connections. It will also create a file named etc/memory-usage in
which the memory usage of the server is reported. There is currently
a small memory leak in the server. We know about it, so there is no
need to send bug reports to us about that (unless you have found where
the leak is).
Administrating a LysKOM site
============================
This document is a short description of how to administrate a LysKOM
database on your site.
The first thing you will have to do is to follow the instructions in
the file INSTALL. This will set up the LysKOM system with a database
containing a few necessary conferences and one person - the
administrator.
Once the LysKOM system is running, there is not much you will have
to do to keep it that way. One thing to remember is that the current
release of the server (0.32) has an incomplete handling of garbage
collection of the database. The database is split into two files, the
information file and the text file. Newly written texts are
concatenated to the text file and old texts are never removed. The
information file contains information about conferences, users and
where in the text file the texts are. This file is properly garbage
collected, but not the text file.
There is a program called dbck (Data Base Check) which is used to
check the consistency of the LysKOM database. This program can also
be used to shrink the text file. To do this, just type `dbck -g' in
the database directory, or give additional switches to dbck to use the
correct directory. See further the manual page for dbck. When dbck
is to be run on the database, the LysKOM server *must* be stopped, or
unrepairable damage may result. See below for a description on how to
stop the server.
There is a shell script called updateLysKOM which is used to insure
continuous operation. This script is run with certain intervals and
if the LysKOM server has died for some reason, updateLysKOM restarts
it. If the server is still running properly, updateLysKOM sends a
signal (SIGUSR1) to it, which causes the server to write call
statistics to a file named etc/lyskomd-log in the lyskom directory.
Taking the server down cleanly can be done in two ways: through the
use of the LysKOM protocol on a socket, preferably through the use of
a suitable client, or to send the signal SIGHUP to it. This will
cause the server to save the database and close all client
connections. It will also create a file named etc/memory-usage in
which the memory usage of the server is reported. There is currently
a small memory leak in the server. We know about it, so there is no
need to send bug reports to us about that (unless you have found where
the leak is).
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment