Date: Tue Mar 5 19:18:38 CET 2002
User: Dan Kalowsky
Directory: srmdoc/admin
Log Message:
[3.02]
- Working on updates to the admin section documentation
# The compiling.xml is nothing new, don't read it yet...
Modified files:
srmdoc/admin/installation.xml (version: 1.4)
srmdoc/admin/intro.xml (version: 1.3)
srmdoc/admin/settings.xml (version: 1.5)
Added files:
srmdoc/admin/compiling.xml (new version: 1.1)
[FILE: /srmdoc/admin/compiling.xml]
<?xml version="1.0" encoding="iso-8859-1"?>
<!-- $Revision: 1.85 $ -->
<chapter id="admin.installation">
<title>Installation</title>
<para>
This section of the manual is designed to help you with installing
Vulcan-Logic SRM. To show better examples, the configuration used in this
installation chapter is not identical to the default SRM configuration.
There will be a note where there is a deviation from the default
configuration. While using this document it is assumed that you have
compiled PHP and Apache before, and tha this is not your first installation
of a software program on a Unix/Linux system.
</para>
<section id="admin.files">
<title>Files</title>
<para>
This example uses a very basic install of PHP and SRM, requiring only the
two files distributed from the <ulink
url="http://www.vl-srm.net/download.php">download site</ulink> and the
latest <ulink url="http://www.php.net/anoncvs.php">CVS version of
PHP</ulink> (after March 1st, 2002).
</para>
<para>
After you downloaded the latest CVS version of PHP (we asume you did this
in <literal>/home/user/install</literal>) you need to dowload the following
files from the SRM download site:
<itemizedlist>
<listitem>
<para>srm-0.6.0.tar.gz</para>
</listitem>
<listitem>
<para>srm-php-0.6.0.tar.gz</para>
</listitem>
</itemizedlist>
At this moment the directory listing of
<literal>/home/user/install</literal> looks like this:
</para>
<para>
<programlisting role="shell">
$ ls
php4/
srm-0.6.0.tar.gz
srm-php-0.6.0.tar.gz
</programlisting>
</para>
<para>
The tar.gz files need to be extracted in the following way:
</para>
<para>
<programlisting role="shell">
$ tar -xzf srm-0.6.0.tar.gz
$ mv srm-php-0.6.0.tar.gz php4
$ cd php4
$ tar -xzf srm-php-0.6.0.tar.gz
$ cd ..
</programlisting>
</para>
<para>
Now all files are unpacked you are ready to begin to configure and compile
SRM and PHP.
</para>
</section>
<section id="admin.compile">
<title>Compiling</title>
<para>
This section discusses all the steps needed to <link
linkend='admin.compile.srm'>compile SRM</link>, and PHP as a
running machine. You need to compile PHP twice to have a fully working
system. You need both an <link linkend='admin.compile.srmmodule'>SRM
module</link> and <link linkend='admin.compile.apache'>Apache</link> (or
other webserver) module which uses the SRM extension.
</para>
<section id="admin.compile.srm">
<title>Compiling SRM</title>
<para>
First change to the SRM source directory (in our example: <literal>cd
/home/user/install/srm</literal>), then select the configure
options you want to compile. The full list with options to
<literal>configure</literal> can be found <link
linkend="admin.configure">here</link>.
In this example we use the following configure line:
</para>
<para>
<programlisting role="shell">
./configure --prefix=/opt/srm --enable-auth
</programlisting>
</para>
<para>
Please remember that <literal>/opt/srm</literal> is not the default path
for SRM, the default path is <literal>/usr/local/srm</literal>.
</para>
<para>
After you ran configure, it is posisble to make and install SRM by doing:
</para>
<para>
<programlisting role="shell">
make
make install
</programlisting>
</para>
<para>
After SRM is compiled and installed, you need to copy
<literal>srm.ini</literal> to the <literal>/etc</literal> directory and
adjust the paths in this file to reflect the different install path
(<literal>/opt/srm</literal> in our example). For information on how to
configure SRM, see the section in this manual on <link
linkend="admin.ini-settings">configuring SRM</link>.
</para>
<para>
If you want to testdrive SRM at this point, comment the
<literal>php4</literal>
module out. You will re-enable this module later if you want to use
<classname>Bananas</classname>.
</para>
</section>
<section id="admin.compile.php">
<title>Compiling the PHP module for SRM</title>
<para>
First you should recreate the PHP configure file. Change into
the <literal>php4</literal> directory, remove the existing configure
script, and run buildconf:
</para>
<para>
<programlisting role="shell">
cd php4; rm -f configure; ./buildconf
</programlisting>
</para>
<para>
It is now possible configure PHP with a clean configure script. To
find out what options are needed for compiling with SRM, type:
</para>
<para>
<programlisting role="shell">
./configure --help | grep srm
</programlisting>
</para>
<para>
If the lines below are shown everything is fine, otherwise have a look
at the <link linkend="admin.trouble">troubleshooting</link>
section of this file.
</para>
<para>
<programlisting role="shell">
--with-srm-sapi[=DIR] Include SRM-SAPI support
--with-srm[=DIR] Include SRM: Script Running Magic
(http://www.vl-srm.net/) support
</programlisting>
</para>
<section id="admin.compile.srmmodule">
<title>Compiling the PHP module for SRM</title>
<para>
First change to the PHP source directory (you should be already here),
and configure PHP as necessary. This example uses just the essentials
srm needs to run:
</para>
<para>
<programlisting role="shell">
./configure --with-srm-sapi=/srm --with-srm=/srm
</programlisting>
</para>
<para>
You also might want to add <literal>--disable-cli</literal> to your
configure line, because compiling a CLI version with the module does not
make much sense.
</para>
<para>
Now the PHP module for SRM is ready to be compiled. The following lines
will compile the PHP module for SRM and place the module in the
<literal>/opt/srm/lib</literal> directory, or in the
<literal>/lib</literal> directory of the install prefix that you
specified (with <literal>/usr/local/srm/lib</literal> being the default).
</para>
<para>
<programlisting role="shell">
make
make install
</programlisting>
</para>
<para>
After the <literal>make install</literal> is completed, the PHP module
for SRM should be in the proper place. Now you may start the SRM Daemon by
running the command <literal>/opt/srm/sbin/srmd</literal> (see the
section on <link linkend="admin.commandline">command line</link> options.
</para>
</section>
<section id="admin.compile.apache">
<title>Compiling the apache module with the SRM extension</title>
<para>
Compiling PHP with SRM extension is not any more difficult. Just use your
normal configure options to PHP, but add the
<literal>--with-srm[=DIR]</literal> option. Replace [DIR] with the path
to which the prefix was set in the configure options to SRM. In our
example this is <literal>--with-srm=/opt/srm</literal>.
</para>
</section>
</section>
<section id="admin.configure">
<title>Configure options for SRM</title>
<para>
This section lists all available options to <literal>configure</literal>.
</para>
<section id="admin.configure.general">
<title>General configure options</title>
<para>
<variablelist>
<varlistentry id="admin.compile.configure-prefix">
<term>
<parameter>--prefix</parameter>
</term>
<listitem>
<para>
The install path of SRM. This defaults to
<literal>/usr/local/srm</literal>.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
</section>
<section id="admin.configure.modules">
<title>Configure options for modules</title>
<para>
<variablelist>
<varlistentry id="admin.compile.configure-enable-auth">
<term>
<parameter>--enable-auth</parameter>
</term>
<listitem>
<para>
This enables the <link linkend="user.module.auth">auth</link> module
which makes it possible to authenticate a session with a password
file.
</para>
</listitem>
</varlistentry>
<varlistentry id="admin.compile.configure-enable-http">
<term>
<parameter>--enable-http</parameter>
</term>
<listitem>
<para>
The <link linkend="user.module.http">http module</link> can be used to
view statistical data about the Daemon and in the future to tune
specific options. At this moment the <link
linkend="user.module.http">http module</link> is experimental and not
available in release. If you want to test the http module you need a
CVS version of SRM. which makes it possible to authenticate a session
with a password
file.
</para>
</listitem>
</varlistentry>
<varlistentry id="admin.compile.configure-enable-mhttp">
<term>
<parameter>--enable-mhttp</parameter>
</term>
<listitem>
<para>
The <link linkend="user.module.mhttp">mhttp module</link> implements
a simple multi threaded http server which is able to access data
stored in application level variables. At this moment the <link
linkend="user.module.mhttp">mhttp module</link> is experimental and
not available in release. If you want to test the http module you need
a CVS version of SRM. which makes it possible to authenticate a
session with a password file.
</para>
</listitem>
</varlistentry>
<varlistentry id="admin.compile.configure-enable-smxs">
<term>
<parameter>--enable-smxs</parameter>
</term>
<listitem>
<para>
If you want to use challenge-response based authentication you need
the <link linkend="user.module.smxs">Secure Media XS module</link>.
This module will be merged into the <link
linkend="user.module.auth">auth module</link> and is currently not
available from either releases or CVS.
</para>
</listitem>
</varlistentry>
<varlistentry id="admin.compile.configure-with-ssl-dir">
<term>
<parameter>--with-ssl-dir[=DIR]</parameter>
</term>
<listitem>
<para>
This parameter points the configure script to the base location of
your OpenSSL installation. This parameter should be used in
combination with the <link
linkend="admin.compile.configure-enable-auth">auth</link> or <link
linkend="admin.compile.configure-enable-smxs">smxs</link> modules. It
defaults to <literal>/usr/local</literal>.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
</section>
<section id="admin.configure.debug">
<title>Debugging related options</title>
<para>
<variablelist>
<varlistentry id="admin.compile.configure-enable-debug">
<term>
<parameter>--enable-debug</parameter>
</term>
<listitem>
<para>
The <literal>--enable-debug</literal> configuration parameter compiles
SRM in debug mode. In debug mode some <link
linkend="admin.commandline">command line</link> parameters behave
differently and the logging is for more extensive.
</para>
</listitem>
</varlistentry>
<varlistentry id="admin.compile.configure-enable-dmalloc">
<term>
<parameter>--enable-dmalloc</parameter>
</term>
<listitem>
<para>
This module makes the SRM Daemon link with the dmalloc memory
allocation library for easier debugging of memory leaks.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
</section>
</section>
</section>
</chapter>
<!-- keep this comment at the end of the file
vim600: syn=xml fen fdm=syntax fdl=4 si
vim: et tw=78 syn=sgml
vi: ts=1 sw=1
-->
[FILE: /srmdoc/admin/installation.xml]
--- srmdoc/admin/installation.xml:1.3 Sun Mar 03 15:38:44 2002 GMT
+++ srmdoc/admin/installation.xml Tue Mar 05 17:18:37 2002 GMT
@@ -3,354 +3,117 @@
<chapter id="admin.installation">
<title>Installation</title>
<para>
- This section of the manual is designed to help you with installing
- Vulcan-Logic SRM. To show better examples, the configuration used in this
- installation chapter is not identical to the default SRM configuration.
- There will be a note where there is a deviation from the default
- configuration. While using this document it is assumed that you have
- compiled PHP and Apache before, and tha this is not your first installation
- of a software program on a Unix/Linux system.
+ The process for installing the Vulcan-Logic SRM system has three major parts
+ to it:
+ <itemizedlist>
+ <listitem>
+ <para>The copying of the binary to desired permanent location.</para>
+ </listitem>
+ <listitem>
+ <para>The copying of the srm.ini file to the user-defined compiled
+ location.</para>
+ </listitem>
+ <listitem>
+ <para>The modification of the system to automatically begin the SRM
+ daemon at bootstrap.</para>
+ </listitem>
+ </itemizedlist>
</para>
- <section id="admin.files">
- <title>Files</title>
- <para>
- This example uses a very basic install of PHP and SRM, requiring only the
- two files distributed from the <ulink
- url="http://www.vl-srm.net/download.php">download site</ulink> and the
- latest <ulink url="http://www.php.net/anoncvs.php">CVS version of
- PHP</ulink> (after March 1st, 2002).
- </para>
- <para>
- After you downloaded the latest CVS version of PHP (we asume you did this
- in <literal>/home/user/install</literal>) you need to dowload the following
- files from the SRM download site:
- <itemizedlist>
- <listitem>
- <para>srm-0.6.0.tar.gz</para>
- </listitem>
- <listitem>
- <para>srm-php-0.6.0.tar.gz</para>
- </listitem>
- </itemizedlist>
- At this moment the directory listing of
- <literal>/home/user/install</literal> looks like this:
- </para>
- <para>
- <programlisting role="shell">
- $ ls
- php4/
- srm-0.6.0.tar.gz
- srm-php-0.6.0.tar.gz
- </programlisting>
- </para>
- <para>
- The tar.gz files need to be extracted in the following way:
- </para>
+ <section id="admin.srm-binary">
+ <title>Binary Home On The Range</title>
<para>
+ Under the UNIX environment, the configure script ran at the beginning of
+ this process defines the final location of the binaries for the Makefiles.
+ Unless overridden by the user at configure time, the default location is
+ /usr/local/srm/bin. To make life easier for the enduser, these Makefiles
+ have an "install" option. Typing in
<programlisting role="shell">
- $ tar -xzf srm-0.6.0.tar.gz
- $ mv srm-php-0.6.0.tar.gz php4
- $ cd php4
- $ tar -xzf srm-php-0.6.0.tar.gz
- $ cd ..
- </programlisting>
- </para>
- <para>
- Now all files are unpacked you are ready to begin to configure and compile
- SRM and PHP.
+ $ sudo make install
+ </programlisting>
+ from the srm source directory, will cause the make system to copy the
+ freshly built binary files to the appropriate locations. This process will
+ <b>NOT</b> copy the srm.ini though.
</para>
</section>
- <section id="admin.compile">
- <title>Compiling</title>
- <para>
- This section discusses all the steps needed to <link
- linkend='admin.compile.srm'>compile SRM</link>, and PHP as a
- running machine. You need to compile PHP twice to have a fully working
- system. You need both an <link linkend='admin.compile.srmmodule'>SRM
- module</link> and <link linkend='admin.compile.apache'>Apache</link> (or
- other webserver) module which uses the SRM extension.
- </para>
-
- <section id="admin.compile.srm">
- <title>Compiling SRM</title>
- <para>
- First change to the SRM source directory (in our example: <literal>cd
- /home/user/install/srm</literal>), then select the configure
- options you want to compile. The full list with options to
- <literal>configure</literal> can be found <link
- linkend="admin.configure">here</link>.
- In this example we use the following configure line:
- </para>
- <para>
- <programlisting role="shell">
- ./configure --prefix=/opt/srm --enable-auth
- </programlisting>
- </para>
- <para>
- Please remember that <literal>/opt/srm</literal> is not the default path
- for SRM, the default path is <literal>/usr/local/srm</literal>.
- </para>
- <para>
- After you ran configure, it is posisble to make and install SRM by doing:
- </para>
- <para>
- <programlisting role="shell">
- make
- make install
- </programlisting>
- </para>
- <para>
- After SRM is compiled and installed, you need to copy
- <literal>srm.ini</literal> to the <literal>/etc</literal> directory and
- adjust the paths in this file to reflect the different install path
- (<literal>/opt/srm</literal> in our example). For information on how to
- configure SRM, see the section in this manual on <link
- linkend="admin.ini-settings">configuring SRM</link>.
- </para>
- <para>
- If you want to testdrive SRM at this point, comment the
- <literal>php4</literal>
- module out. You will re-enable this module later if you want to use
- <classname>Bananas</classname>.
- </para>
- </section>
-
- <section id="admin.compile.php">
- <title>Compiling the PHP module for SRM</title>
- <para>
- First you should recreate the PHP configure file. Change into
- the <literal>php4</literal> directory, remove the existing configure
- script, and run buildconf:
- </para>
- <para>
- <programlisting role="shell">
- cd php4; rm -f configure; ./buildconf
- </programlisting>
- </para>
- <para>
- It is now possible configure PHP with a clean configure script. To
- find out what options are needed for compiling with SRM, type:
- </para>
- <para>
- <programlisting role="shell">
- ./configure --help | grep srm
- </programlisting>
- </para>
- <para>
- If the lines below are shown everything is fine, otherwise have a look
- at the <link linkend="admin.trouble">troubleshooting</link>
- section of this file.
- </para>
- <para>
- <programlisting role="shell">
- --with-srm-sapi[=DIR] Include SRM-SAPI support
- --with-srm[=DIR] Include SRM: Script Running Magic
- (http://www.vl-srm.net/) support
- </programlisting>
- </para>
-
- <section id="admin.compile.srmmodule">
- <title>Compiling the PHP module for SRM</title>
- <para>
- First change to the PHP source directory (you should be already here),
- and configure PHP as necessary. This example uses just the essentials
- srm needs to run:
- </para>
- <para>
- <programlisting role="shell">
- ./configure --with-srm-sapi=/srm --with-srm=/srm
- </programlisting>
- </para>
- <para>
- You also might want to add <literal>--disable-cli</literal> to your
- configure line, because compiling a CLI version with the module does not
- make much sense.
- </para>
+ <section id="admin.srm-ini">
+ <title>The srm.ini</title>
<para>
- Now the PHP module for SRM is ready to be compiled. The following lines
- will compile the PHP module for SRM and place the module in the
- <literal>/opt/srm/lib</literal> directory, or in the
- <literal>/lib</literal> directory of the install prefix that you
- specified (with <literal>/usr/local/srm/lib</literal> being the default).
+ The <literal>srm.ini</literal> is the file used by the SRM system, to
+ allow configuration changes to the daemon. For example, you can use it to
+ turn on or turn off the auth module. A more detailed explination of the
+ srm.ini file can be found in the <link
+ linkend="admin.ini-settings">ini-settings</link> section of the manual.
</para>
<para>
- <programlisting role="shell">
- make
- make install
- </programlisting>
+ At this point in the installation process, copying the srm.ini from the
+ srm source directory to /etc will be sufficent. If at configure time, the
+ user defined a custom <literal>--prefix</literal> option, the srm.ini
+ will need to be modifed to reflect the new paths.
</para>
- <para>
- After the <literal>make install</literal> is completed, the PHP module
- for SRM should be in the proper place. Now you may start the SRM Daemon by
- running the command <literal>/opt/srm/sbin/srmd</literal> (see the
- section on <link linkend="admin.commandline">command line</link> options.
- </para>
- </section>
-
- <section id="admin.compile.apache">
- <title>Compiling the apache module with the SRM extension</title>
- <para>
- Compiling PHP with SRM extension is not any more difficult. Just use your
- normal configure options to PHP, but add the
- <literal>--with-srm[=DIR]</literal> option. Replace [DIR] with the path
- to which the prefix was set in the configure options to SRM. In our
- example this is <literal>--with-srm=/opt/srm</literal>.
- </para>
- </section>
-
</section>
- <section id="admin.configure">
- <title>Configure options for SRM</title>
- <para>
- This section lists all available options to <literal>configure</literal>.
- </para>
-
- <section id="admin.configure.general">
- <title>General configure options</title>
- <para>
- <variablelist>
- <varlistentry id="admin.compile.configure-prefix">
- <term>
- <parameter>--prefix</parameter>
- </term>
- <listitem>
- <para>
- The install path of SRM. This defaults to
- <literal>/usr/local/srm</literal>.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- </para>
- </section>
-
- <section id="admin.configure.modules">
- <title>Configure options for modules</title>
+ <section id="admin.bootstrap">
+ <title>Ground Control To Major Tom</title>
<para>
- <variablelist>
- <varlistentry id="admin.compile.configure-enable-auth">
- <term>
- <parameter>--enable-auth</parameter>
- </term>
- <listitem>
- <para>
- This enables the <link linkend="user.module.auth">auth</link> module
- which makes it possible to authenticate a session with a password
- file.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="admin.compile.configure-enable-http">
- <term>
- <parameter>--enable-http</parameter>
- </term>
- <listitem>
- <para>
- The <link linkend="user.module.http">http module</link> can be used to
- view statistical data about the Daemon and in the future to tune
- specific options. At this moment the <link
- linkend="user.module.http">http module</link> is experimental and not
- available in release. If you want to test the http module you need a
- CVS version of SRM. which makes it possible to authenticate a session
- with a password
- file.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="admin.compile.configure-enable-mhttp">
- <term>
- <parameter>--enable-mhttp</parameter>
- </term>
- <listitem>
- <para>
- The <link linkend="user.module.mhttp">mhttp module</link> implements
- a simple multi threaded http server which is able to access data
- stored in application level variables. At this moment the <link
- linkend="user.module.mhttp">mhttp module</link> is experimental and
- not available in release. If you want to test the http module you need
- a CVS version of SRM. which makes it possible to authenticate a
- session with a password file.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="admin.compile.configure-enable-smxs">
- <term>
- <parameter>--enable-smxs</parameter>
- </term>
- <listitem>
- <para>
- If you want to use challenge-response based authentication you need
- the <link linkend="user.module.smxs">Secure Media XS module</link>.
- This module will be merged into the <link
- linkend="user.module.auth">auth module</link> and is currently not
- available from either releases or CVS.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="admin.compile.configure-with-ssl-dir">
- <term>
- <parameter>--with-ssl-dir[=DIR]</parameter>
- </term>
- <listitem>
- <para>
- This parameter points the configure script to the base location of
- your OpenSSL installation. This parameter should be used in
- combination with the <link
- linkend="admin.compile.configure-enable-auth">auth</link> or <link
- linkend="admin.compile.configure-enable-smxs">smxs</link> modules. It
- defaults to <literal>/usr/local</literal>.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- </para>
- </section>
-
- <section id="admin.configure.debug">
- <title>Debugging related options</title>
- <para>
- <variablelist>
- <varlistentry id="admin.compile.configure-enable-debug">
- <term>
- <parameter>--enable-debug</parameter>
- </term>
- <listitem>
- <para>
- The <literal>--enable-debug</literal> configuration parameter compiles
- SRM in debug mode. In debug mode some <link
- linkend="admin.commandline">command line</link> parameters behave
- differently and the logging is for more extensive.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry id="admin.compile.configure-enable-dmalloc">
- <term>
- <parameter>--enable-dmalloc</parameter>
- </term>
- <listitem>
- <para>
- This module makes the SRM Daemon link with the dmalloc memory
- allocation library for easier debugging of memory leaks.
- </para>
- </listitem>
- </varlistentry>
-
- </variablelist>
-
- </para>
- </section>
+ The process of having the SRM daemon run at bootstrap is dependent upon
+ the host machines operating system. The daemon is able to take a
+ minimal number of arguements at runtime. The arguements include:
+ <itemizedlist>
+ <listitem>
+ <para><literal>-L</literal> This arguement will cause the daemon to
+ output all messages to the logfile rather than to the screen.</para>
+ </listitem>
+ <listitem>
+ <para><literal>-h</literal> This arguement will cause the daemon to
+ display a short description and list of all the arguements it is
+ capable of using. The daemon will cease execution once it has finished
+ displaying this information.</para>
+ </listitem>
+ <listitem>
+ <para><literal>-S</literal> This arguement will cause the daemon to
+ ignore any signals sent EXCEPT the SIGKILL signal.</para>
+ </listitem>
+ <listitem>
+ <para><literal>-V</literal> This arguement will cause the daemon to
+ display it's version number and information to the screen. The daemon
+ will cease execution once it has finished displaying this
+ information.</para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ Note that the paths may be different on a local installation. Please
+ update any path related information to reflect that which was defined
+ at the configure time. These examples all follow the defaults provided
+ by the configure script.
+ </para>
+
+ <para title="BSD based UNIX">
+ Under a BSD based UNIX, editing the /etc/rc file will be sufficent (some
+ BSD unicies prefer /etc/rc.local). Adding the following lines to end of
+ the appropriate rc file will begin the SRM daemon at the next boot:
+
+ <programlisting role="shell">
+ if [ -d /usr/local/srm/bin/srmd ] && [ -f /etc/srm.ini ]; then
+ echo -n ' srmd' ; /usr/local/srm/bin/srmd -L
+ fi
+ </programlisting>
+
+ This small snippet checks for both the binary and the srm.ini file,
+ echos to the console that srmd is starting, and runs the SRM daemon.
+ </para>
+
+ <para title="SysV based UNIX">
+ Why in the hell would you want to be running this style unix anyways?
+ </para>
+
+ <para title="Windows based PCs">
+ At this time the Windows port is not yet complete.
+ </para>
</section>
-
- </section>
-
</chapter>
<!-- keep this comment at the end of the file
vim600: syn=xml fen fdm=syntax fdl=4 si
[FILE: /srmdoc/admin/intro.xml]
--- srmdoc/admin/intro.xml:1.2 Tue Feb 05 09:34:38 2002 GMT
+++ srmdoc/admin/intro.xml Tue Mar 05 17:18:37 2002 GMT
@@ -1,5 +1,15 @@
-<partintro>
+<?xml version="1.0" encoding="iso-8859-1"?>
+<!-- $Revision: $ -->
+ <title>Administrative Introduction</title>
<para>
- This is a dummy document for the introduction to the vlsrm platform appendix
+ This section of the manual is dedicated to the adminstrative tasks required
+ for using the Vulcan-Logic SRM system. These typically include, compling,
+ configuring, and installing the system. Each section will be explained in
+ detail.
</para>
-</partintro>
+</chapter>
+<!-- keep this comment at the end of the file
+vim600: syn=xml fen fdm=syntax fdl=4 si
+vim: et tw=78 syn=sgml
+vi: ts=1 sw=1
+-->
[FILE: /srmdoc/admin/settings.xml]
--- srmdoc/admin/settings.xml:1.4 Thu Feb 21 02:26:16 2002 GMT
+++ srmdoc/admin/settings.xml Tue Mar 05 17:18:37 2002 GMT
@@ -1,18 +1,12 @@
<appendix id="admin.ini-settings">
<title>Configuration settings</title>
<para>
- In this appendix we list all possible settings for the different parts of
+ This appendix lists all the possible settings for the different portions of
<acronym>SRM</acronym>.
</para>
<para>
- The configuration file is read by a Lex/Yacc based parser. It will build a
- tree with settings into hashtables. Every section, or subsection gets its
- own hash table, and each setting will be an entry in this hashtable.
- </para>
- <para>
- Every value gets converted to the correct type. When an error occurs during
- parsing, srm will stop loading and give a parse error on the coresponding
- line:
+ If an error occurs during parsing, srmd will stop loading and give a parse
+ error on the coresponding line, like so:
</para>
<para>
<screen>
@@ -24,24 +18,37 @@
<title>Global settings</title>
<para>
The first section of the configuration file is the
- <emphasis>module</emphasis> settings.
+ <emphasis>module</emphasis> settings. This portion of the configuration
+ file informs the srmd system where to find modules and which modules to load.
</para>
<para>
<programlisting>
modules {
- path = "/opt/srm/lib/";
+ path = "/usr/local/srm/lib/";
load "auth";
load "php4";
}
</programlisting>
</para>
+
<para>
This <literal>path</literal> directive specifies where the SRM modules can
- be found on the filesystem. The <literal>load</literal> keyword, which is
- only valid in the <literal>modules</literal> section makes SRM try to load
- the specified module into the Daemon. If the module could not be loaded, an
- error is displayed in the log file.
+ be found on the filesystem.
+ </para>
+
+ <para>
+ The <literal>load</literal> keyword tells SRM to attempt to load the
+ specified module into the daemon. If the module cannot be loaded, a
+ message is displayed to either screen or logfile. This keyword is only
+ valid in the module section of the ini file.
</para>
+
+ <para>
+ The second section of the ini file is <emphasis>srm</emphasis> specific
+ settings. This controls various settings for the SRM daemon, like which tcp
+ port to use and where the logfile is located.
+ </para>
+
<para>
<programlisting>
srm {
@@ -53,21 +60,22 @@
}
</programlisting>
</para>
+
<para>
- The <literal>srm</literal> section of the srm.ini configuration file
- controls settings to the deamon. The <literal>port</literal> directive is
- the TCP/IP portnumber on which SRM will listen for connections. SRM will
- also always listen for connections on an AF_UNIX socket, which is
- configurable with the <literal>sockname</literal> directive and defaults to
- <literal>/tmp/srm.socket</literal>.
+ The <literal>port</literal> directive is the TCP portnumber on which SRM
+ will listen for connections. SRM will also always listen for connections on
+ an AF_UNIX socket.
+ </para>
+
+ <para>The socket is configurable with the <literal>sockname</literal>
+ directive and defaults to <literal>/tmp/srm.socket</literal>.
</para>
<para>
- The <literal>log_level</literal> directive controls what types or notices,
- warnings and errors must be dumped to the error log. The location of the
- logfile can be specified with the <literal>log_file</literal> directive.
- The value for the logging level is a number between 0 and 100. The higher
- the number, the more message are shown. The default and recommended level
- is 30. The <literal>log_level</literal> values are shown here:
+ The <literal>log_level</literal> directive controls what types of notices,
+ warnings and errors must be dumped to the error log. The value for the
+ logging level is a number between 0 and 100. The higher the number, the
+ more message are shown. The default and recommended level is 30. The
+ <literal>log_level</literal> values are shown here:
<table>
<title>Logging levels</title>
@@ -139,6 +147,15 @@
</table>
</para>
<para>
+ The location of the logfile can be specified with the
+ <literal>log_file</literal> directive.
+ </para>
+
+ <para>
+ The third section is the store section, which is used to define the size of
+ various internal memory structures for SRM. Typically there should be no
+ reason to change these values, as they are optimized for upto 5,000
+ different application variables.
<programlisting>
store {
applications_items = 2048;
@@ -151,14 +168,10 @@
</programlisting>
</para>
<para>
- The store section is used for control of the application, session and
- locking hashes in SRM. The values specify the size of the hashses. There
- should be no reason to changes these values if you don't use more than
- 50000 different application variables. The
- <literal>session_save_path</literal> directive is used to specify where
- SRM should dump the contents of the application variables hashes when it is
- shut down. On start up the data is read again, so no data will be lost if
- you should take SRM down for some reason.
+ The <literal>session_save_path</literal> directive is used to specify where
+ SRM should dump the contents of the application variables when it is
+ shut down. On startup the data is read again, so no data will be lost if
+ SRM needs to be shutdown.
</para>
<para>
<programlisting>
@@ -193,7 +206,7 @@
</para>
<para>
Although the current HTTP module is totally useless, you can configure the
- port it listens to for HTTP connections with the <literal>port</literal>
+ port it listens on for HTTP connections with the <literal>port</literal>
directive.
</para>
</section>
@@ -201,6 +214,9 @@
<section id="admin.ini-settings.smxs">
<title>SMXS Module</title>
<para>
+ The SMXS module contains some configuration settings to control the
+ authentication of users.
+
<programlisting>
smxs {
userfile = "/etc/cryptousers";
@@ -210,15 +226,17 @@
</programlisting>
</para>
<para>
- The SMXS module has some configuration settings to control the
- authentication of users. With the <literal>userfile</literal> directive
- you can point the SMXS module to the correct userfile. The
- <literal>login_timeout</literal> values is the time in seconds after which
- responses to a challenge, handed out earlier, will not be accepted
- anymore. After this timeout a new challenge should be requested. The
- <literal>idle_timeout</literal> directive specifies the time after which a
- user will implicitly be logged out without showing any activity regarding
- the login.
+ The <literal>userfile</literal> directive points the SMXS module to the
+ correct userfile.
+ </para>
+ <para>
+ The <literal>login_timeout</literal> value sets the amount of time, in
+ seconds, for which responses to a challenge will not be accepted. After
+ this timeout a new challenge must be requested.
+ </para>
+ <para>
+ The <literal>idle_timeout</literal> directive specifies the time, in
+ seconds, after which an inactive user will be implicitly logged out.
</para>
</section>
</section>
Received on Tue Mar 5 19:20:09 2002
This archive was generated by hypermail 2.1.8 : Tue Jan 06 2009 - 12:00:02 CET