/usr/share/doc/refdb/refdb-manual/ch04s09.html is in refdb-doc 1.0.2-3ubuntu1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 | <?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Testing your installation</title><link rel="stylesheet" type="text/css" href="manual.css" /><meta name="generator" content="DocBook XSL Stylesheets V1.79.1" /><link rel="home" href="index.html" title="RefDB handbook" /><link rel="up" href="ch04.html" title="Chapter 4. Installation" /><link rel="prev" href="ch04s08.html" title="Finishing the RefDB installation" /><link rel="next" href="ch04s10.html" title="SRU support" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Testing your installation</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04s08.html">Prev</a> </td><th width="60%" align="center">Chapter 4. Installation</th><td width="20%" align="right"> <a accesskey="n" href="ch04s10.html">Next</a></td></tr></table><hr /></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp65218448"></a>Testing your installation</h2></div></div></div><p>Now that you got this far, you surely want to see whether your setup actually works. To this end, you may want to run the following tests and see what happens. For your convenience you should perform this test in a graphical environment running at least two console windows.</p><div class="procedure"><ol class="procedure" type="1"><li class="step"><p>For our first tests it is desirable to have debug information directly available. Therefore you should start refdbd from the root account with some special parameters. Before going ahead you should make sure that you do not have a refdbd process already running, e.g. because you've setup your system to start that daemon at system startup. The following command will kill any refdbd processes. It will do no harm if no such process is running.</p><pre class="screen">
<code class="prompt">#~ </code>
<strong class="userinput"><code>refdbctl stop</code></strong>
</pre><p>If you see an error message saying <span class="quote">“<span class="quote">refdbctl: command not found</span>”</span> then your installation failed or your <code class="envar">PATH</code> environment variable is not set properly.</p></li><li class="step"><p>Now that we know that there is no other refdbd process around, we'll start a fresh one with special properties: We'll run it in a separate xterm as a standalone application and have it write debug information to stderr. This way, RefDB will be slow, but we directly see what's going on.</p><pre class="screen">
<code class="prompt">#~ </code>
<strong class="userinput"><code>refdbd -s -e 0 -l 7</code></strong>
</pre><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>If you try to access refdbd from a different box, you should also use the <code class="option">-I</code> switch to allow remote connections.</p></div><p>refdbd should print some diagnostic information about its startup process and then wait for clients to connect. You may experience problems at this point if the access rights do not allow refdbd to create its PID file. This is why we run the test process as root, but if you plan to set up RefDB for use with a different account, this is a good time to check and try out these access rights. You may use the <code class="option">-P</code> option to provide the path to a PID file that you have write access to in order to run refdbd from an unprivileged account.</p><p>refdbd checks the availability of libdbi database drivers during the startup procedure. The following messages indicate a problem with libdbi:</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">error while loading shared libraries: libdbi.so.0: cannot open shared object file: no such file or directory</span></dt><dd><p>This is a common problem if you build your system from packages, but have to build some libraries (like libdbi, as shown here) from the sources. libdbi and most other autotools-based programs are installed into <code class="filename">/usr/local</code> by default. On some systems (like Debian, Ubuntu) the linker does not peek into <code class="filename">/usr/local/lib</code> for shared objects. To fix this, please add <code class="filename">/usr/local/lib</code> to <code class="filename">/etc/ld.so.conf</code> and run <span class="command"><strong>ldconfig</strong></span>(8), or configure the libraries to install into <code class="filename">/usr/lib</code> instead. See <span class="command"><strong>./configure --help</strong></span> for further instructions.</p></dd><dt><span class="term">Unable to initialize libdbi! Make sure you specified a valid driver directory</span></dt><dd><p>You should see a few lines before this message which libdbi driver directory refdbd attempted to use. Either the default directory is not where the drivers are, or you specified an incorrect driver directory.</p></dd><dt><span class="term">Initialized libdbi, but no drivers were found!</span></dt><dd><p>The libdbi library was not able to locate or properly load at least one database driver. Please check the libdbi installation and make sure you've installed at least one database driver. Remember that on most systems the libdbi-drivers package is distributed separately from the libdbi package which contains only the framework, but no drivers. This error also occurs if you install driver versions which are too old for the libdbi framework.</p></dd></dl></div><p>If refdbd successfully loads libdbi, it will list the available database drivers. Make sure the driver for the database engine you use is listed.</p></li><li class="step"><p>Now switch to a different xterm and start the refdba client. The client can basically run from any user account, but the username and password settings have to be those of a database administrator. We're talking about that username and password that you would provide to the command line client of your database server (<span class="command"><strong>mysql</strong></span> or <span class="command"><strong>psql</strong></span> for MySQL and PostgeSQL, respectively) for administrative tasks. The username and password settings are either provided by the corresponding configuration file <code class="filename">~/.refdbarc</code>, or by using the command line options <code class="option">-u <dbadmin></code> <code class="option">-p <dbadmin-password></code>. In the first case, that is if you set up your configuration file properly, you can just say:</p><pre class="screen">
<code class="prompt">#~ </code>
<strong class="userinput"><code>refdba</code></strong>
</pre><p>In the second case you have to use this instead:</p><pre class="screen">
<code class="prompt">#~ </code>
<strong class="userinput"><code>refdba -u <dbadmin> -w <dbadmin-passwd></code></strong>
</pre><p>In both cases the client should start up and wait for your commands with a friendly prompt.</p></li><li class="step"><p>At first you might try and see whether the RefDB programs read their configuration files properly. To this end, first run the following refdba command:</p><pre class="screen">
<code class="prompt">refdba: </code>
<strong class="userinput"><code>set</code></strong>
</pre><p>This will list the current settings of all configuration variables. Make sure these values are what you want. The most important variables are: username and passwd (you won't see the value of the latter for security reasons, though), as well as the host name or IP address of the box that runs refdbd. As we currently run both the server and the client on the same box, please make sure that the value of serverip is "127.0.0.1".</p></li><li class="step"><p>Now try to send a command to the server. We use a command that does not require database access, but it will tell us whether we can connect to the server properly:</p><pre class="screen">
<code class="prompt">refdba: </code>
<strong class="userinput"><code>viewstat</code></strong>
</pre><p>Several things can happen. If you get several lines of output, telling you about the database server used and about a few refdbd variables, you're fine. This output may look like the following:</p><pre class="programlisting">You are served by: RefDB 0.9.4
Client IP: 127.0.0.1
Connected via pgsql driver (dbd_pgsql v0.7.1)
to: PostgreSQL 7.2.1 on i386-portbld-freebsd4.3, compiled by GCC 2.95.3
serverip: localhost
timeout: 180
dbs_port: 5432
logfile: /home/markus/prog/refdb/pseudotest/log/refdbd.log
logdest: 0
loglevel: 7
remoteadmin: off
pidfile: /home/markus/refdbd.pid</pre><p>If you get the following message instead: <span class="quote">“<span class="quote">could not establish server connection</span>”</span>, check that refdbd is still running and that the serverip setting in refdba is correct. If you try to access refdbd from a remote box, make sure the server was started with the <code class="option">-I</code> option. The error may also result from the fact that you failed to create the common database <code class="filename">refdb</code> or that you did not use the appropriate database server administrator username and password when starting refdba. Finally, your system may lack the runtime client library of the database server.</p><p>The error message <span class="quote">“<span class="quote">failed to connect to database server</span>”</span> shows that your client can talk to refdbd, but that in turn can't talk to the database server. This may be due to incorrect username/password settings or incorrect permissions with the database servers that support user authentication. If you use SQLite as the database engine, you may have specified an incorrect database directory.</p><p>A third possible outcome of this test is the message "main database too old or corrupt". Sometimes this is just what it says, e.g. if you upgraded to a newer version without re-creating the main database although the <code class="filename">UPGRADING</code> file told you to do so. However, the most likely reason is an incorrect setting in the <code class="filename">refdbdrc</code> config file. Please check that the <code class="varname">dbserver</code> variable matches the database engine that you created the main database for. The default is sqlite.</p></li></ol></div><p>This is all it takes to test the basic functionality of your setup. Everything beyond this is either site-specific setup or mere usage of the tools. Please peruse the manual, especially the hints about getting your <a class="link" href="ch05s07.html#sect-database-server-access-control" title="Database server access control">database access rights</a> correct.</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch04s08.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch04.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch04s10.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Finishing the RefDB installation </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> SRU support</td></tr></table></div></body></html>
|