mirror of
https://github.com/NishiOwO/ircservices5.git
synced 2025-04-21 08:44:38 +00:00
1169 lines
53 KiB
HTML
1169 lines
53 KiB
HTML
<?xml version="1.0" encoding="ISO-8859-1"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11-strict.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
|
|
<head>
|
|
<meta http-equiv="Content-Style-Type" content="text/css"/>
|
|
<style type="text/css">@import "style.css";</style>
|
|
<title>IRC Services Technical Reference Manual - 9. The database conversion tool</title>
|
|
</head>
|
|
|
|
<body>
|
|
<h1 class="title" id="top">IRC Services Technical Reference Manual</h1>
|
|
|
|
<h2 class="section-title">9. The database conversion tool</h2>
|
|
|
|
<p class="section-toc">
|
|
9-1. <a href="#s1">Purpose and usage</a>
|
|
<br/>9-2. <a href="#s2">Structure</a>
|
|
<br/> 9-2-1. <a href="#s2-1">The main program</a>
|
|
<br/> 9-2-2. <a href="#s2-2">Format handlers</a>
|
|
<br/>9-2. <a href="#s2">Supported database formats</a>
|
|
<br/> 9-3-1. <a href="#s3-1"><tt>convert-cygnus.c</tt> (Cygnus)</a>
|
|
<br/> 9-3-2. <a href="#s3-2"><tt>convert-epona.c</tt> (Epona, Anope)</a>
|
|
<br/> 9-3-3. <a href="#s3-3"><tt>convert-hybserv.c</tt> (HybServ)</a>
|
|
<br/> 9-3-4. <a href="#s3-4"><tt>convert-magick.c</tt> (Magick, Wrecked)</a>
|
|
<br/> 9-3-5. <a href="#s3-5"><tt>convert-ptlink.c</tt> (PTlink)</a>
|
|
<br/> 9-3-6. <a href="#s3-6"><tt>convert-sirv.c</tt> (Sirv, Auspice, Bolivia)</a>
|
|
<br/> 9-3-7. <a href="#s3-7"><tt>convert-trircd.c</tt> (trircd)</a>
|
|
<br/> 9-3-8. <a href="#s3-8"><tt>convert-ver8.c</tt> (Daylight, IRCS)</a>
|
|
</p>
|
|
|
|
<p class="backlink"><a href="8.html">Previous section: Other modules</a> |
|
|
<a href="index.html">Table of Contents</a> |
|
|
<a href="10.html">Next section: Compilation</a></p>
|
|
|
|
<!------------------------------------------------------------------------>
|
|
<hr/>
|
|
|
|
<h3 class="subsection-title" id="s1">9-1. Purpose and usage</h3>
|
|
|
|
<p>The database conversion tool <tt>convert-db</tt> is designed to allow
|
|
users of other Services-like programs to migrate data stored with the other
|
|
program into Services. This program serves as an adjunct to the main
|
|
<tt>ircservices</tt> executable, reading in database files produced by
|
|
foreign programs and writing out an XML file that can then be imported into
|
|
Services with the <tt>misc/xml-import</tt> module (see
|
|
<a href="8.html#s4-2">section 8-4-2</a>).</p>
|
|
|
|
<p>More information (from a user's point of view) can be found in
|
|
<a href="../5.html#3">section 5-3 of the user's manual</a>.</p>
|
|
|
|
<p>As a historical note, this tool was introduced in version 4.1 of
|
|
Services as <tt>import-db</tt>, and overwrote the existing Services
|
|
databases with the imported data. This behavior was changed for version
|
|
5.0, both to dissociate the tool from the particular database format used
|
|
by Services (which was still limited to the old binary format at the time,
|
|
though implementation of a new format was planned) and to allow merging of
|
|
data rather than simple overwriting. The tool's name was also changed to
|
|
<tt>convert-db</tt> at this time to reflect the fact that it no longer
|
|
performed the actual importing.</p>
|
|
|
|
<p class="backlink"><a href="#top">Back to top</a></p>
|
|
|
|
<!------------------------------------------------------------------------>
|
|
<hr/>
|
|
|
|
<h3 class="subsection-title" id="s2">9-2. Structure</h3>
|
|
|
|
<p>The <tt>convert-db</tt> tool can be divided into two main parts: the
|
|
<i>main program</i>, which calls out to individual formats' probe and load
|
|
routines, sanity-checks the loaded data, and writes out the XML data; and
|
|
the <i>format handlers</i>, which process data produced by particular
|
|
programs.</p>
|
|
|
|
<p>All source code for <tt>convert-db</tt>, with the exception of code
|
|
borrowed from the main program, is located in the <tt>tools</tt>
|
|
directory.</p>
|
|
|
|
<p class="backlink"><a href="#top">Back to top</a></p>
|
|
|
|
|
|
<h4 class="subsubsection-title" id="s2-1">9-2-1. The main program</h4>
|
|
|
|
<p>The overall database conversion processing is performed in the
|
|
<tt>convert-db.c</tt> source file. The <tt>main()</tt> routine performs
|
|
the following functions:</p>
|
|
|
|
<ul>
|
|
|
|
<li class="spaced">Initializes variables and processes command-line
|
|
parameters.</li>
|
|
|
|
<li class="spaced">Checks that the database file directory given on the
|
|
command line is accessible, and expands the pathname to an absolute path if
|
|
the specified path is relative.</li>
|
|
|
|
<li class="spaced">If no database type was given on the command line, calls
|
|
each format handler's <tt>check()</tt> function, which determines whether
|
|
the files contained in the specified directory are of that particular
|
|
format. The first format found is used (if no format is found, the program
|
|
aborts).</li>
|
|
|
|
<li class="spaced">Calls the selected format's <tt>load()</tt> function to
|
|
load the databases.</li>
|
|
|
|
<li class="spaced">Performs sanity checks on the loaded data (via the
|
|
<tt>sanity_checks()</tt> function), to ensure that erroneous data is not
|
|
output.</li>
|
|
|
|
<li class="spaced">Calls <tt>xml_export()</tt> (from the
|
|
<tt>misc/xml-export</tt> module, linked into the final program) to write
|
|
the XML data to standard output.</li>
|
|
|
|
</ul>
|
|
|
|
<p><tt>convert-db.c</tt> also links in <tt>compat.c</tt> and <tt>misc.c</tt>
|
|
from the core code, making all of their functions available to format
|
|
handlers, and implements several other utility functions, including simple
|
|
versions of some core functions:</p>
|
|
|
|
<ul>
|
|
<li class="spaced"><tt>smalloc()</tt>, <tt>scalloc()</tt>,
|
|
<tt>srealloc()</tt>, and <tt>sstrdup()</tt> from
|
|
<tt>memory.c</tt>;</li>
|
|
<li class="spaced"><tt>init_password()</tt> and <tt>clear_password()</tt>
|
|
from <tt>encrypt.c</tt>;</li>
|
|
<li class="spaced"><tt>makenick()</tt> from NickServ and <tt>makechan()</tt>
|
|
from ChanServ to initialize and add nicknames and channels to the
|
|
database;</li>
|
|
<li class="spaced"><tt>open_db_ver()</tt> to open an old-Services-style
|
|
database file and check its version number;</li>
|
|
<li class="spaced"><tt>get_nickgroupinfo_by_nick()</tt> to retrieve a
|
|
<tt>NickGroupInfo</tt> structure directly from a nickname;</li>
|
|
<li class="spaced"><tt>set_os_priv()</tt> to set the <tt>os_priv</tt>
|
|
nickname group field for a nickname without having to first
|
|
retrieve the <tt>NickGroupInfo</tt>; and</li>
|
|
<li class="spaced"><tt>convert_acclev()</tt>, to convert pre-Services 5.0
|
|
channel access levels to levels used by the current version.</li>
|
|
</ul>
|
|
|
|
<p>The nickname, channel, and other databases themselves are implemented as
|
|
simple linked lists, since efficiency is not seen to be a significant
|
|
concern for <tt>convert-db</tt>. Also, since the program exits immediately
|
|
after writing out the converted data, no special effort is made to keep
|
|
track of or free allocated memory; it is assumed that the operating system
|
|
or library cleanup code will take care of freeing resources.</p>
|
|
|
|
<p class="backlink"><a href="#top">Back to top</a></p>
|
|
|
|
|
|
<h4 class="subsubsection-title" id="s2-2">9-2-2. Format handlers</h4>
|
|
|
|
<p>Format handlers perform the bulk of the conversion work. Each format is
|
|
defined by a <tt>DBTypeInfo</tt> structure containing an identifying string
|
|
for the format (used to match against the <tt>+<i>program-name</i></tt>
|
|
command-line option), a <tt>check()</tt> routine which determines whether
|
|
a given directory contains databases in the format, and a <tt>load()</tt>
|
|
routine which loads databases from a given directory. The list of
|
|
available formats is hard-coded as a list of external structure variable
|
|
names in <tt>convert-db.h</tt>, which is used in <tt>convert-db.c</tt> to
|
|
initialize an array of formats. The structures and routine implementations
|
|
themselves are stored in separate source files (see <a href="#s3">section
|
|
9-3</a> below).</p>
|
|
|
|
<p>The <tt>check()</tt> routine takes a single parameters, <tt>const char
|
|
*<i>dir</i></tt>, the path to the directory to be checked. The routine
|
|
should check to see if a database in a recognized format is contained in
|
|
that directory; if so, the routine should return a string describing the
|
|
database format (usually the name, and version if known, of the program
|
|
that created it), which will then be displayed to the user. If no
|
|
recognized database is found, the routine should return <tt>NULL</tt>.</p>
|
|
|
|
<p style="margin-bottom: 0">The <tt>load()</tt> routine takes four
|
|
parameters:</p>
|
|
|
|
<ul style="margin-top: 0">
|
|
<li><tt>const char *<i>dir</i></tt>: The directory to load data from.</li>
|
|
<li><tt>int <i>verbose</i></tt>: Whether the <tt>-v</tt> (verbose) flag
|
|
was passed to <tt>convert-db</tt>.</li>
|
|
<li><tt>int <i>ac</i>, char **<i>av</i></tt>: Any unrecognized
|
|
command-line options. <tt>ac</tt> is the number of options, and
|
|
<tt>av[]</tt> is an array of pointers to the option strings, with
|
|
<tt>av[0]</tt> pointing to the program name as for
|
|
<tt>main()</tt>.</li>
|
|
</ul>
|
|
|
|
<p>The command-line option array is passed in addition to the source
|
|
directory and verbosity flag to allow individual database loaders to
|
|
implement their own options. For example, the Cygnus database takes
|
|
advantage of this to add options for timezone handling.</p>
|
|
|
|
<p>The <tt>load()</tt> routine is assumed to succeed; if an error occurs
|
|
that prevents the data from being loaded properly, the routine should
|
|
simply call <tt>exit(1)</tt> to abort the program.</p>
|
|
|
|
<p>Additionally, the file read/write utilities from
|
|
<tt>modules/database/fileutil.c</tt> (see <a href="6.html#s5-1">section
|
|
6-5-1</a>) are linked into <tt>convert-db</tt> and can be used by the
|
|
<tt>check()</tt> and <tt>load()</tt> routines.</p>
|
|
|
|
<p class="backlink"><a href="#top">Back to top</a></p>
|
|
|
|
<!------------------------------------------------------------------------>
|
|
<hr/>
|
|
|
|
<h3 class="subsection-title" id="s3">9-3. Supported database formats</h3>
|
|
|
|
<p><tt>convert-db</tt> supports loading data from a total of 13 different
|
|
programs. The data loading code is in the various <tt>convert-*.c</tt>
|
|
files, one file for each distinct format (several programs use similar
|
|
database formats and therefore share code). Each of these files is
|
|
discussed below.</p>
|
|
|
|
<p>In general, each format's <tt>load()</tt> routine is implemented as a
|
|
function which calls subfunctions for each file to be loaded. Since most
|
|
of the programs are based on old versions of Services, the contents of the
|
|
files correspond fairly well with Services itself.</p>
|
|
|
|
<p>Where binary database files include fixed-length buffers, the lengths of
|
|
those buffers are assumed to be the same as those in the distributed source
|
|
code, with no changes to any configuration settings. For example, most
|
|
IRC service programs default to a nickname buffer size of 32 bytes, and
|
|
<tt>convert-db</tt> assumes that that value has not been changed by the
|
|
user.</p>
|
|
|
|
<p class="backlink"><a href="#top">Back to top</a></p>
|
|
|
|
|
|
<h4 class="subsubsection-title" id="s3-1">9-3-1. <tt>convert-cygnus.c</tt> (Cygnus)</h4>
|
|
|
|
<p>Cygnus is an IRC service program based on an old version of Services;
|
|
development seems to have stopped as of the writing of this manual. Unlike
|
|
the other programs supported by <tt>convert-db</tt>, Cygnus stores its
|
|
databases in plain text files, with each line containing a two-character
|
|
field identifier and one or more values, all separated by spaces. As such,
|
|
the data processing is somewhat more complex than for other databse
|
|
formats, particularly for numeric values, which must be checked for
|
|
syntactic validity as well as range. The following utility routines and
|
|
macros are used by the various loading functions:</p>
|
|
|
|
<ul>
|
|
|
|
<li class="spaced"><b><tt>cyg_strtok_remaining()</tt></b> returns the
|
|
remainder of the string currently being processed by <tt>strtok()</tt> with
|
|
any leading whitespace removed, like <tt>strtok_remaining()</tt> from
|
|
<tt>misc.c</tt> in the core code; in addition, any trailing newline (CR or
|
|
LF) is removed.</li>
|
|
|
|
<li class="spaced"><b><tt>CVT_TIME(<i>var</i>, <i>str</i>, <i>errfmt</i>,
|
|
...)</tt></b> attempts to convert the string in <tt><i>str</i></tt> to a
|
|
<tt>time_t</tt> value. If the conversion succeeds, the value is stored in
|
|
<tt><i>var</i></tt>, which must be an lvalue; if it fails (because the
|
|
string does not represent a valid integer—range checks are not
|
|
performed), <tt><i>var</i></tt> is set to the current time, and the error
|
|
message in <tt><i>errfmt</i></tt>, along with any additional parameters,
|
|
are printed to standard error.</li>
|
|
|
|
<li class="spaced"><b><tt>CVT_TIME_0(<i>var</i>, <i>str</i>, <i>errfmt</i>,
|
|
...)</tt></b> does the same thing as <tt>CVT_TIME()</tt>, but defaults to
|
|
zero rather than the current time when the string is invalid.</li>
|
|
|
|
</ul>
|
|
|
|
<p>Cygnus also supports storing time zone information with each nickname,
|
|
like NickServ <tt>SET TIMEZONE</tt> in Services; however, rather than
|
|
storing the actual time offset, Cygnus stores an index into a table whose
|
|
contents are controlled by a configuration file. The default list of
|
|
time zone offsets is included in the <tt>default_timezones[]</tt> array,
|
|
but since users may have modified the time zone configuration, the
|
|
command-line option <tt>-tzfile=<i>filename</i></tt> is checked for by the
|
|
<tt>load()</tt> function, allowing the user to specify their configuration
|
|
file, which is then loaded and used in place of the default list;
|
|
<tt>-no-timezones</tt> (which causes all time zone data to be discarded) is
|
|
also supported as a fallback in case time zone importing results in
|
|
incorrect data.</p>
|
|
|
|
<p>Cygnus does not have a "default" value, like <tt>MEMOMAX_DEFAULT</tt> in
|
|
Services, for the memo limit field, but instead stores the actual value of
|
|
the default limit at the time the nickname is registered. As a result,
|
|
these values will remain constant in Services even if the
|
|
<tt>MSMaxMemos</tt> configuration setting is changed. To work around this,
|
|
the <tt>-reset-memo-limits</tt> command-line option is checked for, and if
|
|
present, all memo limits are reset to <tt>MEMOMAX_DEFAULT</tt>.</p>
|
|
|
|
<p>The data files are as follows:</p>
|
|
|
|
<ul>
|
|
|
|
<li class="spaced"><b><tt>nickserv.db</tt>:</b> Nickname database. The
|
|
file contains three file-level fields:
|
|
<dl>
|
|
<dt class="cygnus">NV <i>version</i></dt>
|
|
<dd>File version. This field is always the first line in the file.
|
|
The version number is 3 in Cygnus 0.2.0.</dd>
|
|
<dt class="cygnus">SS <i>stamp</i></dt>
|
|
<dd>Previous servicestamp value. Cygnus stores this value in the
|
|
database, allowing it to ensure (assuming the database is not
|
|
modified) that servicestamp values are not reused even if the
|
|
program is restarted. Services does not save this value, so it is
|
|
ignored.</dd>
|
|
<dt class="cygnus">DE <i>nick-count</i> <i>link-count</i> <i>memo-count</i></dt>
|
|
<dd>"Database end". Included as the last line in the file, and
|
|
contains counts of nicknames, links, and memos stored in the
|
|
database. These can be used to double-check that all data was
|
|
loaded correctly.</dd>
|
|
</dl>
|
|
|
|
<p>All other fields are subfields of a nickname record (a nickname group
|
|
record, in Services terminology):</p>
|
|
|
|
<dl>
|
|
<dt class="cygnus">NI <i>nickname</i> <i>password</i>
|
|
<i>time-registered</i> <i>last-seen</i> <i>last-timestamp</i>
|
|
<i>last-servicestamp</i> <i>flags</i> <i>memo-limit</i>
|
|
<i>timezone-index</i> <i>key</i> <i>last-usermask</i>
|
|
<i>last-realname</i></dt>
|
|
<dd>Begins a nickname record; all subsequent fields until the next
|
|
<tt>NI</tt> or the end of the file correspond to this nickname.
|
|
Most of the fields are self-explanatory, with times recorded as
|
|
integers using ordinary Unix <tt>time()</tt> values. If the
|
|
<tt><i>nickname</i></tt> too long to fit in a
|
|
<tt>NICKMAX</tt>-character buffer, it is truncated with a warning.
|
|
The <tt><i>last-timestamp</i></tt> field is not saved by Services,
|
|
and is thus ignored; the <tt><i>last-servicestamp</i></tt> field
|
|
will not have any relevance to servicestamps assigned by Services,
|
|
and is likewise discarded. <tt><i>timezone-index</i></tt> is an
|
|
index into a table of time zone offset values (see the discussion
|
|
of time zones above). The <tt><i>key</i></tt> is the equivalent of
|
|
the authentication code used by the <tt>nickserv/mail-auth</tt>
|
|
module, and is used to set the nickgroup's <tt>authcode</tt> field,
|
|
so that authentication codes stored with nicknames will continue to
|
|
be valid; the code is assumed to be for a new registration, unless
|
|
we find out otherwise later on. If the <tt>NI</tt> line does not
|
|
match the above format or the nickname already exists, the entire
|
|
nickname record is discarded.</dd>
|
|
|
|
<dt class="cygnus">AC <i>mask</i></dt>
|
|
<dd>An access mask for the current nickname.</dd>
|
|
|
|
<dt class="cygnus">LN <i>nickname-1</i> <i>nickname-2</i>...</dt>
|
|
<dd>The list of subnicks (linked nicks) for the current nickname.
|
|
These are added to the current nickname group's nick list, with a
|
|
new <tt>NickInfo</tt> structure created for each subnick. As width
|
|
<tt>NI</tt> processing, nicknames that do not fit in a
|
|
<tt>NICKMAX</tt>-character buffer are truncated with a warning, and
|
|
nicknames that collide with already-existing nicks are discarded.
|
|
In theory, any number of nicknames can be included in a single
|
|
<tt>LN</tt> line, but Cygnus (version 0.2.0, at least) uses a
|
|
2048-byte line buffer when writing the databases; this routine uses
|
|
a 4096-byte buffer, so there should be no truncation problems.</dd>
|
|
|
|
<dt class="cygnus">MO <i>num</i> <i>flags</i> <i>time</i>
|
|
<i>sender</i> <i>text</i></dt>
|
|
<dd>A memo for the current nickname. The <tt><i>text</i></tt>
|
|
parameter may include spaces.</dd>
|
|
|
|
<dt class="cygnus">FW <i>nickname</i></dt>
|
|
<dd>The nickname to which memos to this nick should be forwarded.
|
|
Services does not support forwarding memos to another nickname, so
|
|
this field is ignored.</dd>
|
|
|
|
<dt class="cygnus">FR <i>reason</i></dt>
|
|
<dd>Freeze (suspension) reason for the nickname.</dd>
|
|
|
|
<dt class="cygnus">EM <i>address</i></dt>
|
|
<dd>E-mail address for the nickname.</dd>
|
|
|
|
<dt class="cygnus">TE <i>address</i></dt>
|
|
<dd>An E-mail address which has been set with <tt>SET EMAIL</tt>
|
|
but not yet authenticated. If this field is found, then the
|
|
nickname's authentication reason is set to
|
|
<tt>NICKAUTH_SET_EMAIL</tt>, and a new authentication code is
|
|
generated if one does not already exist (perhaps because of a
|
|
corrupt database file). The E-mail address given in the
|
|
<tt>EM</tt> field is moved to <tt>NickGroupInfo.last_email</tt>
|
|
as well.</dd>
|
|
|
|
<dt class="cygnus">UR <i>address</i></dt>
|
|
<dd>URL for the nickname.</dd>
|
|
|
|
<dt class="cygnus">UN <i>address</i></dt>
|
|
<dd>User information field for the nickname (instant messenger
|
|
UIN); ignored.</dd>
|
|
|
|
<dt class="cygnus">NA <i>address</i></dt>
|
|
<dd>User information field for the nickname (real name);
|
|
ignored.</dd>
|
|
|
|
<dt class="cygnus">AG <i>address</i></dt>
|
|
<dd>User information field for the nickname (age); ignored.</dd>
|
|
|
|
<dt class="cygnus">SX <i>address</i></dt>
|
|
<dd>User information field for the nickname (sex); ignored.</dd>
|
|
|
|
<dt class="cygnus">LO <i>address</i></dt>
|
|
<dd>User information field for the nickname (location);
|
|
ignored.</dd>
|
|
</dl>
|
|
</li>
|
|
|
|
<li class="spaced"><b><tt>chanserv.db</tt>:</b> Channel database. As with
|
|
<tt>nickserv.db</tt>, the file begins with a version field (<tt>CV</tt> in
|
|
this case; the supported version is 3) and ends with a <tt>DE</tt> field
|
|
containing a channel count. There is also a <tt>VF</tt> field (taking two
|
|
parameters, a channel name and time value) listing channels which have been
|
|
registered but not verified, but since Services does not implement such a
|
|
verification system, these records are ignored. Channel records are stored
|
|
on multiple lines:
|
|
|
|
<dl>
|
|
<dt class="cygnus">CI <i>channel</i> <i>founder</i> <i>password</i>
|
|
<i>time-registered</i> <i>last-used</i> <i>flags</i>
|
|
<i>mlock-on</i> <i>mlock-off</i> <i>topic-lock</i>
|
|
<i>memo-level</i> <i>key</i></dt>
|
|
<dd>Begins a channel record. The channel name is truncated to fit
|
|
in a <tt>CHANMAX</tt>-character buffer, if necessary. The channel
|
|
is discarded if the <tt>CI</tt> line is invalid, if another channel
|
|
with the same name already exists, or if the founder is not a
|
|
registered nickname. The mode lock parameters
|
|
<tt><i>mlock-on</i></tt> and <tt><i>mlock-off</i></tt> are mode
|
|
bitmasks, which are converted to mode strings based on the Cygnus
|
|
mode flag constants. The <tt><i>topiclock</i></tt> and
|
|
<tt><i>memolevel</i></tt> parameters are access levels required
|
|
for setting the topic and receiving channel memos, respectively,
|
|
using the same system as channel access entries (see below), with
|
|
zero indicating that the feature is disabled. In Services,
|
|
topic-lock is an on/off setting, so the <tt>TOPICLOCK</tt> channel
|
|
flag is set if <tt><i>topiclock</i></tt> is nonzero; the
|
|
<tt><i>memolevel</i></tt> value is translated directly to the
|
|
<tt>CA_MEMO</tt> privilege level. Services does not require
|
|
authentication for channels, so the <tt><i>key</i></tt> parameter
|
|
is ignored.</dd>
|
|
|
|
<dt class="cygnus">CA <i>nick-or-mask</i> <i>level</i></dt>
|
|
<dd>Channel access entry. Cygnus, like versions of Services before
|
|
3.0.0, allows both nicknames and usermasks on channel access lists;
|
|
any access entry that does not correspond to a registered nickname
|
|
is therefore discarded. Cygnus uses a simple XOP-based access
|
|
system, with five levels:
|
|
<ul>
|
|
<li>1: VOP</li>
|
|
<li>2: HOP</li>
|
|
<li>3: AOP</li>
|
|
<li>4: SOP</li>
|
|
<li>5: Founder</li>
|
|
</ul>
|
|
These values are translated to the corresponding <tt>ACCLEV_*</tt>
|
|
constants.</dd>
|
|
|
|
<dt class="cygnus">AK <i>mask</i> <i>setter</i> <i>time</i>
|
|
<i>reason</i></dt>
|
|
<dd>Channel autokick entry. The setter nickname is truncated
|
|
(silently) if necessary.</dd>
|
|
|
|
<dt class="cygnus">SU <i>nickname</i></dt>
|
|
<dd>Channel successor. Ignored if the nickname is not registered
|
|
or is in the same nickname group as the founder.</dd>
|
|
|
|
<dt class="cygnus">GR <i>text</i></dt>
|
|
<dd>Channel greeting (entry message). <tt><i>text</i></tt> may
|
|
contain spaced.</dd>
|
|
|
|
<dt class="cygnus">UR <i>url</i></dt>
|
|
<dd>Channel URL.</dd>
|
|
|
|
<dt class="cygnus">CT <i>setter</i> <i>time</i> <i>topic</i></dt>
|
|
<dd>Channel topic, along with the nickname of the topic setter and
|
|
the time the topic was set.</dd>
|
|
|
|
<dt class="cygnus">KY <i>key</i></dt>
|
|
<dd>Channel key locked with <tt>MLOCK</tt>. Ignored if mode
|
|
<tt>+k</tt> is not locked on.</dd>
|
|
|
|
<dt class="cygnus">LM <i>limit</i></dt>
|
|
<dd>Channel limit locked with <tt>MLOCK</tt>. Ignored if not a
|
|
valid limit value, or if mode <tt>+l</tt> is not locked on.</dd>
|
|
|
|
<dt class="cygnus">FL <i>value</i></dt>
|
|
<dd>Channel flood setting locked with <tt>MLOCK</tt>. Ignored if
|
|
mode <tt>+f</tt> is not locked on.</dd>
|
|
|
|
<dt class="cygnus">LK <i>link</i></dt>
|
|
<dd>Channel link locked with <tt>MLOCK</tt>. Ignored if mode
|
|
<tt>+L</tt> is not locked on.</dd>
|
|
</dl>
|
|
</li>
|
|
|
|
<li><b><tt>rootserv.db</tt>:</b> Contains global data, analogous to the
|
|
OperServ and related databases in Services. Data is stored with one full
|
|
record per line, as follows:
|
|
|
|
<dl>
|
|
<dt class="cygnus">AK <i>mask</i> <i>setter</i> <i>is-realname</i>
|
|
<i>set-at</i> <i>expires</i> <i>reason</i></dt>
|
|
<dd>An autokill or SGline record; the numeric field
|
|
<tt><i>is-realname</i></tt> determines the record type (nonzero for
|
|
an SGline, zero for an autokill). <tt><i>reason</i></tt> may
|
|
contain spaces.</dd>
|
|
|
|
<dt class="cygnus">TR <i>mask</i> <i>limit</i></dt>
|
|
<dd>A session exception with a defined user limit (a "trigger" in
|
|
Cygnus terminology).</dd>
|
|
|
|
<dt class="cygnus">EX <i>mask</i></dt>
|
|
<dd>A session exception with no user limit.</dd>
|
|
|
|
<dt class="cygnus">NW <i>time</i></dt>
|
|
<dd>The last time the <tt>RESETNEWS</tt> command was called.
|
|
Cygnus implements news as a simple text file, shown to users only
|
|
if the user's last read-news time is earlier than this timestamp.
|
|
Ignored.</dd>
|
|
|
|
<dt class="cygnus">RS <i>max-uptime</i></dt>
|
|
<dd>The longest amount of time Cygnus has remained running, in
|
|
seconds. Services does not store this information, so this field
|
|
is ignored.</dd>
|
|
</dl>
|
|
</li>
|
|
|
|
<li class="spaced"><b><tt>web.db</tt>:</b> Contains a summary of all data,
|
|
intended for use by external programs. Apparently serves a purpose similar
|
|
to the XML export functionality in Services. This file is ignored.</li>
|
|
|
|
</ul>
|
|
|
|
<p class="backlink"><a href="#top">Back to top</a></p>
|
|
|
|
|
|
<h4 class="subsubsection-title" id="s3-2">9-3-2. <tt>convert-epona.c</tt> (Epona, Anope)</h4>
|
|
|
|
<p>Epona IRC Services is an IRC service program based on Services 4.3.3;
|
|
development has been intermittent since the release of Epona 1.4 in 2001.
|
|
Anope Services was forked from Epona 1.4.14, and has been developed more
|
|
actively. Both use a database format similar to the Services 4.3 format;
|
|
however, rather than a single format version number for all files,
|
|
individual version numbers are used for each file. (As noted in the user
|
|
manual, versions of Anope since 1.7.11 also support storing databases in a
|
|
MySQL database; access to such databases is not supported by the
|
|
<tt>convert-db</tt> tool.)</p>
|
|
|
|
<p>Epona and Anope use a "nick core plus nick aliases" concept for
|
|
registered nicknames, in which most nickname data is stored with a single
|
|
"core" nick and other nicknames can "aliased" to the same settings (the
|
|
redesigned nickname linking system in Services 5.0 was based on this
|
|
concept). Other data is structured similarly to Services, and conversion
|
|
is fairly straightforward.</p>
|
|
|
|
<p>Anope supports a number of IRC servers; unfortunately, the flag values
|
|
used in the channel mode lock fields stored in the database vary between
|
|
IRC servers (though given the vast range of channel modes present in
|
|
various servers, this is probably unavoidable). In order to interpret the
|
|
mode flags correctly, the converter allows a "<tt>-ircd=</tt>" option to
|
|
be passed on the command line. The parameter to this option selects the
|
|
IRC server type to be used for interpreting channel modes. If no
|
|
<tt>-ircd</tt> option is given, the converter only converts the eight basic
|
|
channel modes (<tt>i</tt>, <tt>k</tt>, <tt>l</tt>, <tt>m</tt>, <tt>n</tt>,
|
|
<tt>p</tt>, <tt>s</tt>, <tt>t</tt>), which share the same flag values
|
|
across all IRC server types.</p>
|
|
|
|
<p>Since Anope 1.7.18, administrators can select one of several encryption
|
|
modules, similar to how encryption was handled in Services 5.0. This
|
|
method shares the same shortcoming present in Services 5.0, however, which
|
|
is that a particular password's encryption status cannot be determined from
|
|
the data itself. To work around this problem, the converter accepts a
|
|
command-line option "<tt>-encryption=</tt>" to select the type of
|
|
encryption used for passwords in the databases. If this option is given,
|
|
the "encrypted" flag on nickname cores and channels is ignored, and all
|
|
passwords are assumed to use the given encryption type; otherwise, the
|
|
"encrypted" flag selects between MD5 encryption and no encryption. (For
|
|
forward compatilibity, <tt>sha1</tt> is accepted to indicate SHA-1
|
|
encryption, but Services will not be able to check such passwords without a
|
|
third-party module implementing the SHA-1 hash.)</p>
|
|
|
|
<p>The Epona/Anope database files are:</p>
|
|
|
|
<ul>
|
|
|
|
<li class="spaced"><b><tt>nick.db</tt>:</b> Contains nickname data.
|
|
Nickname cores are stored in a format similar to that in Services 4.x,
|
|
followed by nickname aliases in a condensed format. Unlike Services, Epona
|
|
and Anope store nicknames and passwords as strings rather than buffers
|
|
(with the exception of the memo sender field, which is stored as a buffer
|
|
of default size 32 bytes); there seems to have been a bug in some versions
|
|
of Epona that could result in a <tt>NULL</tt> string being saved in the
|
|
password field, and this is checked for by the load routine. Additional
|
|
fields stored with nickname cores include:
|
|
<ul>
|
|
<li><tt>greet</tt>: A greeting message sent from NickServ to the
|
|
user upon logon. Ignored.</li>
|
|
<li><tt>icq</tt>: The user's ICQ number. Ignored.</li>
|
|
</ul>
|
|
Nickname aliases include the same fields as are stored in the
|
|
<tt>NickInfo</tt> structure. Since nickname cores are stored using the
|
|
"display name" (main nickname) rather than a separate ID value,
|
|
<tt>convert-db</tt> first looks up the nickname read from the database,
|
|
and only creates a new <tt>NickInfo</tt> if the nickname does not already
|
|
exist.
|
|
</li>
|
|
|
|
<li class="spaced"><b><tt>chan.db</tt>:</b> Contains channel data.
|
|
Additional fields stored with channels include:
|
|
<ul>
|
|
<li><tt>forbidby</tt>: The nickname of the user who forbade the
|
|
channel. Ignored.</li>
|
|
<li><tt>forbidreason</tt>: The reason given for the channel
|
|
forbid. Ignored.</li>
|
|
<li><tt>bantype</tt>: Selects among different method of creating a
|
|
ban mask when banning a user from a channel. Ignored.</li>
|
|
<li>Several BotServ-related fields, all ignored.</li>
|
|
</ul>
|
|
The major difficulty in importing Epona/Anope channel data is that the
|
|
meaning of the bitmask values used in the channel mode lock varies
|
|
depending on the particular IRC server being used. Since this information
|
|
is not stored in the databases, <tt>convert-db</tt> defaults to only
|
|
importing the eight basic channel modes, which have consistent flag values
|
|
across all IRC server types: <tt>+i</tt>, <tt>+k</tt>, <tt>+l</tt>,
|
|
<tt>+m</tt>, <tt>+n</tt>, <tt>+p</tt>, <tt>+s</tt>, and <tt>+t</tt>. To
|
|
import other modes, the user must specify the appropriate
|
|
<tt>-ircd=<i>type</i></tt> option on the <tt>convert-db</tt> command line;
|
|
the argument to this option is used to look up an IRC server type (the
|
|
<tt>IRCD_*</tt> enum defined at the top of the file), which is then used as
|
|
an index into the <tt>epona_cmode_index[]</tt> array of arrays to process
|
|
nonstandard mode flag values. Note that there is not a one-to-one
|
|
correspondence between IRC server type names (taken from the Anope 1.7
|
|
protocol module names) and <tt>IRCD_*</tt> constants; protocols using the
|
|
same mode flag values are combined into a single flag list. (In hindsight,
|
|
this is probably an unnecessary optimization.)
|
|
</li>
|
|
|
|
<li class="spaced"><b><tt>oper.db</tt>:</b> Contains OperServ-related data,
|
|
both basic data such as maximum user count and lists of autokills and
|
|
S-lines. Some versions of Epona and Anope also store information about
|
|
detected proxy hosts, but this data was removed during the development of
|
|
Anope 1.7 without changing the file version number.</li>
|
|
|
|
<li class="spaced"><b><tt>exception.db</tt>:</b> Contains session exception
|
|
data.</li>
|
|
|
|
<li class="spaced"><b><tt>news.db</tt>:</b> Contains news item data.</li>
|
|
|
|
<li class="spaced"><b><tt>autoop.db</tt>:</b> Contains nickname auto-op
|
|
settings. Ignored.</li>
|
|
|
|
<li class="spaced"><b><tt>bot.db</tt>:</b> Contains data for the
|
|
Epona/Anope BotServ pseudoclient. Ignored.</li>
|
|
|
|
<li class="spaced"><b><tt>hosts.db</tt>:</b> Contains data for the
|
|
Anope 1.5+ HostServ pseudoclient. Ignored.</li>
|
|
|
|
<li class="spaced"><b><tt>hs_request.db</tt>:</b> Contains data for the
|
|
Anope 1.5+ HostServ pseudoclient. Ignored.</li>
|
|
|
|
<li class="spaced"><b><tt>os_info.db</tt>:</b> Contains IRC operator
|
|
information strings for nicknames and channels (Anope 1.7.9+ only).
|
|
Ignored.</li>
|
|
|
|
<li class="spaced"><b><tt>prenick.db</tt>:</b> Contains data on requested
|
|
but not yet confirmed nicknames in Anope's two-step registration process
|
|
(Anope 1.5+ only). Since Anope uses an alphanumeric code that cannot be
|
|
stored in the <tt>NickGroupInfo.authcode</tt> numeric field, this data is
|
|
currently ignored.</li>
|
|
|
|
</ul>
|
|
|
|
<p class="backlink"><a href="#top">Back to top</a></p>
|
|
|
|
|
|
<h4 class="subsubsection-title" id="s3-3">9-3-3. <tt>convert-hybserv.c</tt> (HybServ)</h4>
|
|
|
|
<p>HybServ is an IRC service program designed from scratch for networks
|
|
using the IRCD-Hybrid IRC server. After version 1.6, development changed
|
|
hands and the program was renamed HybServ2, but as they share a common
|
|
codebase, "HybServ" is used to refer to both in this documentation.
|
|
Several modified versions of HybServ have also been seen.</p>
|
|
|
|
<p>Like Cygnus, HybServ writes its databases to text files. The format is
|
|
similar to IRC commands, with a record or field identifier followed by an
|
|
arbitrary number of space-separated parameters, and with a leading colon
|
|
indicating a parameter that continues to the end of the line (including
|
|
spaces). The first line of each file begins with "<tt>; Hybserv</tt>",
|
|
which is used by the <tt>check()</tt> routine to check for the existence of
|
|
HybServ databases.</p>
|
|
|
|
<p>HybServ allows passwords to be encrypted, using the Unix
|
|
<tt>crypt()</tt> function; however, encryption status is not stored in the
|
|
databases themselves, so the command-line option <tt>-crypt</tt> must be
|
|
given to <tt>convert-db</tt> to make it treat passwords as encrypted.</p>
|
|
|
|
<ul>
|
|
|
|
<li class="spaced"><b><tt>nick.db</tt>:</b> Contains nickname data.
|
|
Each nickname record begins with a line that has the nickname itself as the
|
|
first token on the line; subsequent fields for that record begin with the
|
|
two characters "<tt>-></tt>" followed by a field name. The fields are:
|
|
<dl>
|
|
<dt><tt><i>nickname</i> <i>flags</i> <i>time-registered</i>
|
|
<i>last-seen</i></tt></dt>
|
|
<dd>Begins a new nickname record.</dd>
|
|
<dt><tt>->PASS <i>password</i></tt></dt>
|
|
<dd>The nickname's password.</dd>
|
|
<dt><tt>->PERMPASS <i>password</i></tt></dt>
|
|
<dd>A "permanent password" for the nickname (only present in some
|
|
modified versions of HybServ); ignored.</dd>
|
|
<dt><tt>->FORBIDBY <i>nickname</i></tt></dt>
|
|
<dd>The nickname of the user who forbade this nick; ignored.</dd>
|
|
<dt><tt>->FORBIDREASON <i>reason</i></tt></dt>
|
|
<dd>The reason for the nickname forbid; ignored. (This field is
|
|
called <tt>FREASON</tt> in some modified versions of HybServ.)</dd>
|
|
<dt><tt>->FTIME <i>time</i></tt></dt>
|
|
<dd>The time at which the nickname was forbidden (only present in
|
|
some modified versions of HybServ); ignored.</dd>
|
|
<dt><tt>->EMAIL <i>address</i></tt></dt>
|
|
<dd>E-mail address for the nickname.</dd>
|
|
<dt><tt>->URL <i>url</i></tt></dt>
|
|
<dd>URL for the nickname.</dd>
|
|
<dt><tt>->GSM <i>string</i></tt>
|
|
<br/><tt>->PHONE <i>string</i></tt>
|
|
<br/><tt>->UIN <i>string</i></tt>
|
|
<br/><tt>->ICQ <i>string</i></tt></dt>
|
|
<dd>Various user information fields for the nickname; ignored.
|
|
(<tt>ICQ</tt> is only present in some modified versions of
|
|
HybServ.)</dd>
|
|
<dt><tt>->LANG <i>language</i></tt></dt>
|
|
<dd>Believed to identify the language selected by the user (only
|
|
present in some modified versions of HybServ); ignored due to a
|
|
lack of data to correlate values with languages.</dd>
|
|
<dt><tt>->LASTUH <i>user</i> <i>host</i></tt></dt>
|
|
<dd>The last-seen usermask for the nickname, with user and hostname
|
|
as separate tokens.</dd>
|
|
<dt><tt>->LASTQMSG <i>message</i></tt></dt>
|
|
<dd>The last quit message used by the nickname.</dd>
|
|
<dt><tt>->HOST <i>usermask</i></tt></dt>
|
|
<dd>A hostmask (access) entry for the nickname.</dd>
|
|
<dt><tt>->LINK <i>master-nick</i></tt></dt>
|
|
<dd>Indicates that this nickname is linked to another, and gives
|
|
the parent (master) nickname. Master nicknames are always written
|
|
before the nicknames that link to them.</dd>
|
|
</dl>
|
|
</li>
|
|
|
|
<li class="spaced"><b><tt>chan.db</tt>:</b> Contains channel data.
|
|
<dl>
|
|
<dt><tt><i>channel</i> <i>flags</i> <i>time-registered</i>
|
|
<i>last-used</i></tt></dt>
|
|
<dd>Begins a new channel record.</dd>
|
|
<dt><tt>->FNDR <i>nickname</i></tt></dt>
|
|
<dd>The channel founder's nickname.</dd>
|
|
<dt><tt>->SUCCESSOR <i>nickname</i></tt></dt>
|
|
<dd>The channel successor's nickname.</dd>
|
|
<dt><tt>->PASS <i>password</i></tt></dt>
|
|
<dd>The channel's founder password.</dd>
|
|
<dt><tt>->PERMPASS <i>password</i></tt></dt>
|
|
<dd>A "permanent password" for the channel (only present in some
|
|
modified versions of HybServ); ignored.</dd>
|
|
<dt><tt>->ACCESS <i>nickname</i> <i>level</i></tt></dt>
|
|
<dd>An access entry for the channel. Levels are adjusted so that
|
|
users have close to the same privileges as they did in HybServ
|
|
(assuming default HybServ privilege settings), but as there is not
|
|
a one-to-one match between levels and privileges, some users will
|
|
end up with more or less privileges than they had previously (see
|
|
under HybServ in <a href="../5.html#3">section 5-3</a> of the
|
|
user's manual).</dd>
|
|
<dt><tt>->AKICK <i>mask</i> <i>reason</i></tt></dt>
|
|
<dd>An autokick entry for the channel.</dd>
|
|
<dt><tt>->ALVL <i>level...</i></tt></dt>
|
|
<dd>Privilege access levels for the channel (all on one line);
|
|
ignored.</dd>
|
|
<dt><tt>->TOPIC <i>topic</i></tt></dt>
|
|
<dd>Saved topic for the channel. Since the topic setter and time
|
|
are not saved, they are set to "<tt><unknown></tt>" and the
|
|
current time, respectively, in the XML output.</dd>
|
|
<dt><tt>->MON <i>mode-mask</i></tt></dt>
|
|
<dd>Modes locked on for the channel, as a combination of numeric
|
|
flags.</dd>
|
|
<dt><tt>->MOFF <i>mode-mask</i></tt></dt>
|
|
<dd>Modes locked off for the channel, as a combination of numeric
|
|
flags.</dd>
|
|
<dt><tt>->KEY <i>key</i></tt></dt>
|
|
<dd>Locked key for the channel.</dd>
|
|
<dt><tt>->LIMIT <i>limit</i></tt></dt>
|
|
<dd>Locked limit for the channel.</dd>
|
|
<dt><tt>->FORWARD <i>string</i></tt></dt>
|
|
<dd>Presumed to be a forwarding channel for when the channel
|
|
reaches its user limit (<tt>+l</tt>), and stored as the channel
|
|
link parameter accordingly, but as the IRC server with which this
|
|
is used (Dancer IRCd) appears to be defunct, I am not certain of
|
|
this interpretation.</dd>
|
|
<dt><tt>->ENTRYMSG <i>message</i></tt></dt>
|
|
<dd>Entry message for the channel.</dd>
|
|
<dt><tt>->EMAIL <i>address</i></tt></dt>
|
|
<dd>E-mail address for the channel.</dd>
|
|
<dt><tt>->URL <i>url</i></tt></dt>
|
|
<dd>URL for the channel.</dd>
|
|
</dl>
|
|
</li>
|
|
|
|
<li class="spaced"><b><tt>memo.db</tt>:</b> Contains memo data. The data
|
|
is organized by nickname, with each memo on a single line:
|
|
<dl>
|
|
<dt><tt><i>nickname</i></tt></dt>
|
|
<dd>Begins a group of memos, and identifies the nickname to which
|
|
the memos belong.</dd>
|
|
<dt><tt>->TEXT <i>sender</i> <i>time</i> <i>flags</i>
|
|
<i>text</i></tt></dt>
|
|
<dd>Data for a single memo.</dd>
|
|
</dl>
|
|
</li>
|
|
|
|
<li class="spaced"><b><tt>stat.db</tt>:</b> Contains the following
|
|
network-wide statistics:
|
|
<dl>
|
|
<dt><tt>->USERS <i>maxusers</i> <i>maxusers-time</i></tt></dt>
|
|
<dd>The maximum number of users seen on the network, and the time
|
|
at which the maximum was reached. Used to set the corresponding
|
|
OperServ data.</dd>
|
|
<dt><tt>->OPERS <i>maxopers</i> <i>maxopers-time</i></tt></dt>
|
|
<dd>The maximum number of IRC oprators seen on the network, and the
|
|
time at which the maximum was reached. Ignored.</dd>
|
|
<dt><tt>->OPERS <i>maxopers</i> <i>maxopers-time</i></tt></dt>
|
|
<dd>The maximum number of IRC oprators seen on the network, and the
|
|
time at which the maximum was reached. Ignored.</dd>
|
|
<dt><tt>->OPERS <i>maxopers</i> <i>maxopers-time</i></tt></dt>
|
|
<dd>The maximum number of IRC oprators seen on the network, and the
|
|
time at which the maximum was reached. Ignored.</dd>
|
|
</dl>
|
|
</li>
|
|
|
|
<li class="spaced"><b><tt>oper.db</tt>:</b> Seems to contain a list of
|
|
current user modes set on online users. Ignored.</li>
|
|
|
|
<li class="spaced"><b><tt>ignore.db</tt>:</b> Contains OperServ ignore
|
|
data. Services does not store this data to disk, so this file is ignored.</li>
|
|
|
|
<li class="spaced"><b><tt>seen.db</tt>:</b> Data for SeenServ; ignored.</li>
|
|
|
|
</ul>
|
|
|
|
<p class="backlink"><a href="#top">Back to top</a></p>
|
|
|
|
|
|
<h4 class="subsubsection-title" id="s3-4">9-3-4. <tt>convert-magick.c</tt> (Magick, Wrecked)</h4>
|
|
|
|
<p>Magick IRC Services is an IRC service program based on a very old
|
|
version of Services, and WreckedNet IRC Services is a modified version of
|
|
Magick; both seem to be defunct as of the writing of this manual.</p>
|
|
|
|
<p>The databases used by these programs are similar to the format used by
|
|
Services before machine-independence was introduced in version 4.0: rather
|
|
than writing each variable in a consistent way, they simply dump the
|
|
structures to disk as is. As such, <tt>convert-db</tt> assumes that the
|
|
databases are being loaded on the same machine that produced them;
|
|
attempting to read the databases on a different architecture (and in some
|
|
cases, on the same architecture using a different compiler) will likely
|
|
fail.</p>
|
|
|
|
<p>Magick and Wrecked support nickname and channel suspensions via flags,
|
|
but do not record any other suspension information, so default values are
|
|
filled in. These programs also support a hierarchical system of nickname
|
|
links, and these are resolved into nickname groups after all nicknames are
|
|
read in.</p>
|
|
|
|
<p>The data files used by Magick and Wrecked are as follows:</p>
|
|
|
|
<ul>
|
|
<li class="spaced"><b><tt>nick.db</tt></b>: Contains nickname data.</li>
|
|
<li class="spaced"><b><tt>chan.db</tt></b>: Contains channel data.</li>
|
|
<li class="spaced"><b><tt>memo.db</tt></b>: Contains memo data.</li>
|
|
<li class="spaced"><b><tt>news.db</tt></b>: Contains channel news data;
|
|
ignored.</li>
|
|
<li class="spaced"><b><tt>sop.db</tt></b>: Contains the Services
|
|
operator list (Services operators in Magick and Wrecked are
|
|
equivalent to Services administrators in Services, and are imported
|
|
as such).</li>
|
|
<li class="spaced"><b><tt>akill.db</tt></b>: Contains autokill data.</li>
|
|
<li class="spaced"><b><tt>clone.db</tt></b>: Contains session exception
|
|
data.</li>
|
|
<li class="spaced"><b><tt>message.db</tt></b>: Contains network message
|
|
data (imported as news items).</li>
|
|
</ul>
|
|
|
|
<p class="backlink"><a href="#top">Back to top</a></p>
|
|
|
|
|
|
<h4 class="subsubsection-title" id="s3-5">9-3-5. <tt>convert-ptlink.c</tt> (PTlink)</h4>
|
|
|
|
<p>PTlink Services is an IRC service program designed specifically for the
|
|
PTlink IRC server. It appears to be based on a fairly old version of
|
|
Services, and uses a similar data file format. (Another, apparently
|
|
separately developed, program called PTlink IRC Services has recently
|
|
appeared; it uses MySQL for database storage, and is not supported by
|
|
<tt>convert-db</tt>.)</p>
|
|
|
|
<p>PTlink stores the encryption method used for passwords with the
|
|
corresponding nickname or channel, a significant improvement over Services'
|
|
method (at the time) of using a single method for the entire database.
|
|
<tt>convert-db</tt> reads the encryption method and includes it in the XML
|
|
output; however, the "JP2" method used in PTlink is not available in
|
|
Services, and any passwords encrypted with this method, or with an unknown
|
|
method, are reset to the corresponding nick or channel name with no
|
|
encryption (a warning is printed in this case).</p>
|
|
|
|
<p>PTlink also stores record counts in the nickname and channel databases,
|
|
similar to Cygnus, for the purpose of ensuring that the data is loaded
|
|
correctly; however, there have apparently been bugs in some versions of
|
|
PTlink that caused valid databases to have a mismatch between this value
|
|
and the number of records actually recorded. <tt>convert-db</tt> still
|
|
checks the value, but the warning message on mismatch includes a note about
|
|
this issue.</p>
|
|
|
|
<p>The following data files are used by PTlink (some only by more recent
|
|
versions):</p>
|
|
|
|
<ul>
|
|
|
|
<li class="spaced"><b><tt>nick.db</tt></b>: Contains nickname and memo
|
|
data. Suspension status is stored as a flag, without setter, time, or
|
|
expiration. PTlink stores the following additional data, currently
|
|
ignored:
|
|
<ul>
|
|
<li><tt>icq_number</tt>: ICQ user number, as a string.</li>
|
|
<li><tt>location</tt>: User's location. </li>
|
|
<li><tt>last_identify</tt>: Last time the nickname was identified
|
|
for. PTlink updates the "last seen" time regardless of
|
|
authentication status, and uses this field instead to record use
|
|
by an authenticated user. To maintain user-interface
|
|
compatibility, we keep the old last-seen time, even though we treat
|
|
it differently, rather than use this time.</li>
|
|
<li><tt>last_email_request</tt>: Last time the <tt>SET EMAIL</tt>
|
|
command was used. Services only records this in memory, not on
|
|
disk.</li>
|
|
<li><tt>birth_date</tt>: Presumably intended to allow the user to
|
|
record their birth date (stored as a numeric time value), but this
|
|
field appears to be unused in recent versions of PTlink.</li>
|
|
<li><tt>news_mask</tt>: NewsServ-related options.</li>
|
|
<li><tt>news_status</tt>: Presumably NewsServ-related, but appears
|
|
to be unused in recent versions of PTlink.</li>
|
|
<li><tt>notes</tt>: These seem to be a sort of memo-to-self
|
|
feature; they could potentially be imported as memos.</li>
|
|
</ul>
|
|
As of data file version 10, PTlink did away with the legacy zero byte
|
|
used to terminate a record chain for a single hash table entry, simply
|
|
storing a sequence of records.
|
|
</li>
|
|
|
|
<li class="spaced"><b><tt>chan.db</tt></b>: Contains channel data. This
|
|
file does not have a version 10, and the hash chain terminator bytes are
|
|
always present; the hash table size was increased from 256 to 65536 in
|
|
data file version 9. PTlink stores the following additional data,
|
|
currently ignored:
|
|
<ul>
|
|
<li><tt>maxusers</tt>: Maximum number of users seen on the
|
|
channel.</li>
|
|
<li><tt>maxtime</tt>: Time when the maximum number of users on the
|
|
channel was reached.</li>
|
|
<li><tt>drop_time</tt>: Time when the channel was dropped with a
|
|
DROP command. Only present if the 0x1000 (<tt>CI_DROPPED</tt>)
|
|
flag is set. Used by the PTlink "delayed drop" system.</li>
|
|
<li><tt>memos</tt>: PTlink supports channel memos (like old
|
|
versions of Services), which are discarded.</li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li class="spaced"><b><tt>oper.db</tt></b>: Contains the list of Services
|
|
administrators and operators, and the network-wide maximum user count and
|
|
time of maximum.</li>
|
|
|
|
<li class="spaced"><b><tt>akill.db</tt></b>: Contains autokill data.</li>
|
|
|
|
<li class="spaced"><b><tt>sqline.db</tt></b>: Contains SQline data.</li>
|
|
|
|
<li class="spaced"><b><tt>sxline.db</tt></b>: Contains SXline data (what
|
|
Services calls SGlines).</li>
|
|
|
|
<li class="spaced"><b><tt>news.db</tt></b>: Contains news data.</li>
|
|
|
|
<li class="spaced"><b><tt>newsserv.db</tt></b>: Contains NewsServ data;
|
|
ignored.</li>
|
|
|
|
<li class="spaced"><b><tt>bots.db</tt></b>: Contains bot data; ignored.</li>
|
|
|
|
<li class="spaced"><b><tt>vline.db</tt></b>: Contains SVline data (S-lines
|
|
for blocking certain DCC filenames); ignored.</li>
|
|
|
|
<li class="spaced"><b><tt>vlink.db</tt></b>: Contains VLINK data (a feature
|
|
in recent versions of the PTlink IRC server); ignored.</li>
|
|
|
|
</ul>
|
|
|
|
<p class="backlink"><a href="#top">Back to top</a></p>
|
|
|
|
|
|
<h4 class="subsubsection-title" id="s3-6">9-3-6. <tt>convert-sirv.c</tt> (Sirv, Auspice, Bolivia)</h4>
|
|
|
|
<p>SirvNET Services is an IRC service program designed for use on SirvNET.
|
|
Earlier versions were based on an old version of Services; version 3.0.0
|
|
was a complete rewrite, and development is actively continuing. Since
|
|
version 3.0.0, Sirv requires a MySQL database to operate, and apparently
|
|
has no way to export its data to ordinary files; thus, Sirv databases are
|
|
only supported through version 2.9.0.</p>
|
|
|
|
<p>Auspice is an IRC service program that appears to have been based on an
|
|
old version of Sirv, and was designed for UnrealIRCd networks. Development
|
|
status is unclear.</p>
|
|
|
|
<p>Bolivia IRC Services is an IRC service program that also appears to have
|
|
been based on Sirv, and developed for a particular network. The program
|
|
appears to be defunct as of the writing of this manual.</p>
|
|
|
|
<p>All three of these programs share the same overall file format, so they
|
|
have been grouped in the same file despite fairly significant differences
|
|
in the details to avoid code repetition. The base format seems to be that
|
|
from Services 3.x, before machine-independence was introduced.</p>
|
|
|
|
<p>The database files are as follows:</p>
|
|
|
|
<ul>
|
|
|
|
<li class="spaced"><b><tt>nick.db</tt>:</b> Nickname data. All three
|
|
programs share a common base nickname data structure (the <tt>oldni</tt>
|
|
variable), and each has its own additions to the structure. (As a side
|
|
note, Bolivia's extra data structure, consisting entirely of padding, is
|
|
not written to disk due to a missing comment terminator in the structure
|
|
definition.) The common load routine then loads string data for the
|
|
appropriate database type and initializes NickInfo and NickGroupInfo
|
|
structures for the loaded data. Bolivia has a flag for nickname
|
|
suspensions, and if it is set, dummy suspension data is created for the
|
|
nickname group. Auspice has a nick linking system, similar to the
|
|
hierarchical system introduced in Services 4.0, indicated by a nickname
|
|
flag; if the flag is set, the <tt>last_usermask</tt> field contains the
|
|
parent nickname. These links are resolved into nickname groups after all
|
|
nicknames have been loaded.</li>
|
|
|
|
<li class="spaced"><b><tt>chan.db</tt>:</b> Channel data. As with the
|
|
nickname database, all three programs share a common base structure—with
|
|
the exception of mode lock data, which is stored as <tt>short</tt> numeric
|
|
values in Sirv and Bolivia but 64-byte string buffers in Auspice. The
|
|
routine first reads the initial part of the common structure
|
|
(<tt>oldci</tt>), then reads either two shorts or two 64-byte buffers for
|
|
the mode lock data, then reads the latter part of the common structure
|
|
(<tt>oldci2</tt>). This can theoretically cause alignment problems due to
|
|
the mode lock variables not being part of the structure, but no such
|
|
problems have yet been reported. The Sirv and Bolivia formats are similar,
|
|
but Auspice also includes:
|
|
<ul>
|
|
<li>Channel successors.</li>
|
|
<li>A record of who added a channel access entry (also present in
|
|
recent versions of Sirv).</li>
|
|
<li><tt>TIMEOP</tt> entries on the access list: users who only get
|
|
channel operator privileges at certain times. These are
|
|
discarded.</li>
|
|
<li>Channel news data.</li>
|
|
<li>Channel "bad word" data.</li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li class="spaced"><b><tt>memo.db</tt>:</b> Memo data. All three programs
|
|
use the same format here, with the exception that Auspice has a flag for
|
|
marking memos to be saved; this flag is used (inverted) to set the "may
|
|
expire" flag in imported memos.</li>
|
|
|
|
<li class="spaced"><b><tt>os_sop.db</tt> (Sirv only):</b> Services operator
|
|
list. Consists of a count followed by a list of strings.</li>
|
|
|
|
<li class="spaced"><b><tt>os_sa.db</tt> (Sirv only):</b> Services
|
|
administrator list. Consists of a count followed by a list of strings.</li>
|
|
|
|
<li class="spaced"><b><tt>admin.db</tt> (Auspice only):</b> Services
|
|
administrator/operator list. Stored like the nickname and channel
|
|
databases, with a series of entries each preceded by a nonzero byte,
|
|
followed by a zero byte, for each hash table entry. Auspice keeps a fair
|
|
amount of information for each record in this table, but since Services
|
|
does not record such information, only the status flag is used to set the
|
|
nickname's OperServ privilege level (<tt>ngi->os_priv</tt>).</li>
|
|
|
|
<li class="spaced"><b><tt>akill.db</tt>:</b> Autokill list. All three
|
|
programs share the same straightforward format.</li>
|
|
|
|
<li class="spaced"><b><tt>trigger.db</tt>:</b> Trigger (session exception)
|
|
list. All three programs share the same straightforward format.</li>
|
|
|
|
<li class="spaced"><b><tt>gline.db</tt>, <tt>qline.db</tt>,
|
|
<tt>zline.db</tt> (Bolivia only):</b> S-line data. These files use simple
|
|
arrays of strings preceded by a count.</li>
|
|
|
|
</ul>
|
|
|
|
<p class="backlink"><a href="#top">Back to top</a></p>
|
|
|
|
|
|
<h4 class="subsubsection-title" id="s3-7">9-3-7. <tt>convert-trircd.c</tt> (trircd)</h4>
|
|
|
|
<p>trircd IRC Services is a fork of Services 4.5.36 developed for the
|
|
tr-ircd IRC server, and has been discontinued since support for tr-ircd was
|
|
added to Services. The data files are essentially the same as those in
|
|
Services 4.5.36, with the addition of the following data files:</p>
|
|
|
|
<ul>
|
|
|
|
<li class="spaced"><b><tt>ajoin.db</tt>:</b> Nickname-related extension
|
|
data for each registered nickname, including:
|
|
<ul>
|
|
<li>Autojoin list.</li>
|
|
<li>Forbidder nickname and reason for forbidden nicknames.</li>
|
|
<li>E-mail address authentication status.</li>
|
|
<li>Memo ignore list.</li>
|
|
<li>Nickname information string.</li>
|
|
<li>Memo expiration data (ignored).</li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li class="spaced"><b><tt>cforbid.db</tt>:</b> Channel-related extension
|
|
data for each registered channel, including:
|
|
<ul>
|
|
<li>Forbidder nickname and reason for forbidden channels.</li>
|
|
<li>Time added, last used time, and expiration time for autokick
|
|
entries (expiration times are not supported for autokicks and are
|
|
ignored).</li>
|
|
<li>Last used time for access entries (ignored).</li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li class="spaced"><b><tt>exclude.db</tt>:</b> Autokill exclusion data,
|
|
stored in the same format as autokill data.</li>
|
|
|
|
<li class="spaced"><b><tt>sgline.db</tt>, <tt>sqline.db</tt>,
|
|
<tt>szline.db</tt>:</b> S-line data, stored in the same format as autokill
|
|
data.</li>
|
|
|
|
</ul>
|
|
|
|
<p class="backlink"><a href="#top">Back to top</a></p>
|
|
|
|
|
|
<h4 class="subsubsection-title" id="s3-8">9-3-8. <tt>convert-ver8.c</tt> (Daylight, IRCS)</h4>
|
|
|
|
<p>Daylight is a fork of Services 4.3.3 developed for the UnrealIRCd IRC
|
|
server, and has been discontinued since support for Unreal was added to
|
|
Services. IRCS is a fork of Services 4.0.5 developed for Undernet (ircu)
|
|
IRC servers, and appears to be defunct as of the writing of this manual.
|
|
Both use a data format essentially unchanged from that in the original
|
|
Services versions; the data file format at that time was version 8, hence
|
|
the source file name "<tt>convert-ver8.c</tt>".</p>
|
|
|
|
<p>The Daylight database format is almost completely unchanged from the
|
|
original version 8, with the exception of an extra channel flag
|
|
<tt>CI_XMANAGEMENT</tt> which is ignored.</p>
|
|
|
|
<p>The IRCS database format uses a channel name buffer size of 204 bytes
|
|
and a password size of 16 bytes. Services defaults to a maximum channel
|
|
name buffer size of 64 bytes, and will truncate (with a warning) any
|
|
channel name that is too long to fit in the buffer. IRCS also uses five
|
|
OperServ privilege levels instead of two, and users on the extra lists
|
|
("senior", "junior", and "helper") are moved onto either the admin or the
|
|
oper list depending on appropriate privileges.</p>
|
|
|
|
<p>IRCS adds one data file to the base Services set: <tt>gline.db</tt>,
|
|
containing "G-line" (autokill) data.</p>
|
|
|
|
<p class="backlink"><a href="#top">Back to top</a></p>
|
|
|
|
<!------------------------------------------------------------------------>
|
|
<hr/>
|
|
|
|
<p class="backlink"><a href="8.html">Previous section: Other modules</a> |
|
|
<a href="index.html">Table of Contents</a> |
|
|
<a href="10.html">Next section: Compilation</a></p>
|
|
|
|
</body>
|
|
</html>
|