📄 x1740.htm
字号:
<HTML
><HEAD
><TITLE
>A Tour of jabber.xml</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.64
"><LINK
REL="HOME"
TITLE="Programming Jabber"
HREF="book1.htm"><LINK
REL="UP"
TITLE="Server Architecture and Configuration"
HREF="c1223.htm"><LINK
REL="PREVIOUS"
TITLE="Server Configuration"
HREF="x1581.htm"><LINK
REL="NEXT"
TITLE="Managing the Configuration"
HREF="x3305.htm"></HEAD
><BODY
CLASS="SECT1"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Programming Jabber</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="x1581.htm"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 4. Server Architecture and Configuration</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="x3305.htm"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="JABTDG-CH-4-SECT-4.3"
>A Tour of <TT
CLASS="FILENAME"
>jabber.xml</TT
></A
></H1
><P
>Now we know what patterns to look out for, we're well prepared to dive
into a <TT
CLASS="FILENAME"
>jabber.xml</TT
> configuration file. As an example,
we'll take one that's very similar to the default
<TT
CLASS="FILENAME"
>jabber.xml</TT
> installed with
version 1.4.1 of
Jabber, but we'll plug in some extra components: the
Conferencing component and a local JUD component. </P
><P
>The entire configuration content, with comment lines dividing up
each section, can be found in <A
HREF="a10211.htm"
>Appendix A</A
>.
It's definitely worth turning briefly to have a look at the XML
before continuing, to get a feel for how the configuration is
laid out.</P
><P
>In order to deal with it without going crazy, let's break down the
XML into manageable chunks.
We'll build configuration diagrams for each of the top-level tags
that are children of the root tag
<TT
CLASS="LITERAL"
><jabber/></TT
>.
The opening tags for each of these chunks are as follows:</P
><P
></P
><UL
><LI
><P
><TT
CLASS="LITERAL"
><service id="sessions"></TT
></P
></LI
><LI
><P
><TT
CLASS="LITERAL"
><xdb id="xdb"></TT
></P
></LI
><LI
><P
><TT
CLASS="LITERAL"
><service id="c2s"></TT
></P
></LI
><LI
><P
><TT
CLASS="LITERAL"
><log id="elogger"></TT
></P
></LI
><LI
><P
><TT
CLASS="LITERAL"
><log id="rlogger"></TT
></P
></LI
><LI
><P
><TT
CLASS="LITERAL"
><service id="dnsrv"></TT
></P
></LI
><LI
><P
><TT
CLASS="LITERAL"
><service id="s2s"></TT
></P
></LI
><LI
><P
><TT
CLASS="LITERAL"
><service id="conf"></TT
></P
></LI
><LI
><P
><TT
CLASS="LITERAL"
><io></TT
></P
></LI
><LI
><P
><TT
CLASS="LITERAL"
><pidfile></TT
></P
></LI
></UL
><P
>Most of these should be recognisable by now, but there are two chunks that
we haven't come across yet:
<TT
CLASS="LITERAL"
><io></TT
> and
<TT
CLASS="LITERAL"
><pidfile></TT
>.
These aren't components but nevertheless are part of the configuration
for <B
CLASS="COMMAND"
>jabberd</B
>; there are also the two
<I
CLASS="EMPHASIS"
>Logging</I
> component instances that we have not paid
much attention to until now.</P
><P
><A
HREF="x1740.htm#JABTDG-CH-4-FIG-4.4"
>Figure 4-4</A
> provides an overview of how the
Jabber server is configured. It represents the contents of the
<TT
CLASS="FILENAME"
>jabber.xml</TT
> configuration file in
<A
HREF="a10211.htm"
>Appendix A</A
> in diagram form. </P
><DIV
CLASS="FIGURE"
><A
NAME="JABTDG-CH-4-FIG-4.4"
></A
><P
><B
>Figure 4-4. Configuration file in diagram form</B
></P
><PRE
CLASS="SCREEN"
> +----------+ +-----+
| sessions | | xdb |
+----------+-------------------+ +-----+------------------------+
| service | | xdb |
|--> host yak | |--> host * |
|--> load jsm.so | |--> load xdb_file.so |
|--> config filter, vCard, | |--> config spool |
| register, welcome | +------------------------------+
| ... |
+------------------------------+ +---------+
| elogger |
+-----+ +---------+--------------------+
| c2s | | log |
+-----+------------------------+ |--> host * |
| service | |--> logtype * |
|--> host (c2s) | |--> format ... |
|--> load pth_client.so | |--> file ... |
|--> config authtime, ip, | |--> stderr |
| karma | +------------------------------+
+------------------------------+
+---------+
+-------+ | rlogger |
| dnsrv | +---------+--------------------+
+-------+----------------------+ | log |
| service | |--> host * |
|--> host * | |--> logtype record |
|--> load dnsrv.so | |--> format ... |
|--> config resend | |--> file ... |
+------------------------------+ +------------------------------+
+------+ +-----+
| conf | | s2s |
+------+-----------------------+ +-----+------------------------+
| service | | service |
|--> host conference.yak | |--> host (s2s) |
|--> load conference.so | |--> load dialback.so |
|--> config public, vCard, | |--> config legacy, ip, karma |
| history, notice | +------------------------------+
| room |
+------------------------------+ +----+
| io |
+-----+ +----+--------------+
| jud | |--> rate ... |
+-----+------------------------+ |--> karma ... |
| service | |--> ssl ... |
|--> host jud.yak | |--> allow ... |
|--> load jud.so | |--> deny ... |
|--> config vCard | +-------------------+
+------------------------------+
+---------+
| pidfile |
+---------+---------+
|--> jabber.pid |
+-------------------+
</PRE
></DIV
><P
>We can see that the bulk of the Jabber server functionality described
here is in the form of components. Let's take each of these components
one by one and have a closer look.</P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="JABTDG-CH-4-SECT-4.3.1"
>Component instance: <I
CLASS="EMPHASIS"
>sessions</I
></A
></H2
><P
>The <I
CLASS="EMPHASIS"
>sessions</I
> component, described by the configuration
XML shown in <A
HREF="x1740.htm#JABTDG-CH-4-EX-8"
>Example 4-8</A
> and shown in diagram form
in <A
HREF="x1740.htm#JABTDG-CH-4-FIG-4.5"
>Figure 4-5</A
>, provides Session Management
features for users (the word "users" is employed in the widest possible
sense—a user could be a person or a script) connecting with Jabber
clients - through XML streams identified
with the <TT
CLASS="LITERAL"
>jabber:client</TT
> stream namespace.</P
><DIV
CLASS="FIGURE"
><A
NAME="JABTDG-CH-4-FIG-4.5"
></A
><P
><B
>Figure 4-5. Diagram view of <I
CLASS="EMPHASIS"
>sessions</I
> component instance</B
></P
><PRE
CLASS="SCREEN"
>+----------+
| sessions |
+----------+-------------------+
| service |
|--> host yak |
|--> load jsm.so |
|--> config filter, vCard, |
| register, welcome |
| ... |
+------------------------------+ </PRE
></DIV
><P
>It also provides the services that give Jabber its IM capabilities—
services such as roster management, message filtering, store-and-forward
("offline") message handling, and so on. These IM services are loaded
individually as part of the component connection phase.</P
><DIV
CLASS="EXAMPLE"
><A
NAME="JABTDG-CH-4-EX-8"
></A
><P
><B
>Example 4-8. <TT
CLASS="FILENAME"
>jabber.xml</TT
> configuration for the <I
CLASS="EMPHASIS"
>sessions</I
> component instance</B
></P
><P
><PRE
CLASS="SCREEN"
><service id="sessions">
<host><jabberd:cmdline flag="h">yak</jabberd:cmdline></host>
<jsm xmlns="jabber:config:jsm">
<filter>
<default/>
<max_size>100</max_size>
<allow>
<conditions>
<ns/>
<unavailable/>
<from/>
<resource/>
<subject/>
<body/>
<show/>
<type/>
<roster/>
<group/>
</conditions>
<actions>
<error/>
<offline/>
<forward/>
<reply/>
<continue/>
<settype/>
</actions>
</allow>
</filter>
<vCard>
<FN>Jabber Server on yak</FN>
<DESC>A Jabber Server!</DESC>
<URL>http://yak/</URL>
</vCard>
<register notify="yes">
<instructions>Choose a userid and password to register.</instructions>
<name/>
<email/>
</register>
<welcome>
<subject>Welcome!</subject>
<body>Welcome to the Jabber server on yak</body>
</welcome>
<!--
<admin>
<read>support@yak</read>
<write>admin@yak</write>
<reply>
<subject>Auto Reply</subject>
<body>This is a special administrative address.</body>
</reply>
</admin>
-->
<update><jabberd:cmdline flag="h">yak</jabberd:cmdline></update>
<vcard2jud/>
<browse>
<service type="jud" jid="jud.yak" name="yak User Directory">
<ns>jabber:iq:search</ns>
<ns>jabber:iq:register</ns>
</service>
<conference type="public" jid="conference.yak" name="yak Conferencing"/>
</browse>
</jsm>
<load main="jsm">
<jsm>./jsm/jsm.so</jsm>
<mod_echo>./jsm/jsm.so</mod_echo>
<mod_roster>./jsm/jsm.so</mod_roster>
<mod_time>./jsm/jsm.so</mod_time>
<mod_vcard>./jsm/jsm.so</mod_vcard>
<mod_last>./jsm/jsm.so</mod_last>
<mod_version>./jsm/jsm.so</mod_version>
<mod_announce>./jsm/jsm.so</mod_announce>
<mod_agents>./jsm/jsm.so</mod_agents>
<mod_browse>./jsm/jsm.so</mod_browse>
<mod_admin>./jsm/jsm.so</mod_admin>
<mod_filter>./jsm/jsm.so</mod_filter>
<mod_offline>./jsm/jsm.so</mod_offline>
<mod_presence>./jsm/jsm.so</mod_presence>
<mod_auth_plain>./jsm/jsm.so</mod_auth_plain>
<mod_auth_digest>./jsm/jsm.so</mod_auth_digest>
<mod_auth_0k>./jsm/jsm.so</mod_auth_0k>
<mod_log>./jsm/jsm.so</mod_log>
<mod_register>./jsm/jsm.so</mod_register>
<mod_xml>./jsm/jsm.so</mod_xml>
</load>
</service></PRE
></P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="JABTDG-CH-4-SECT-4.3.1.1"
>Component type and identification</A
></H3
><P
>The opening tag:</P
><P
><PRE
CLASS="SCREEN"
><service id="sessions"></PRE
></P
><P
>identifies this component instance to the backbone as a service type
component and gives it a name ("sessions") that can be used for
internal addressing
and to distinguish it from other component instances. </P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="JABTDG-CH-4-SECT-4.3.1.2"
>Host filter</A
></H3
><P
>Assuming that our hostname isn't "sessions," it's just as well that
we have a
<TT
CLASS="LITERAL"
><host/></TT
>
specification in this component instance description:</P
><P
><PRE
CLASS="SCREEN"
><host><jabberd:cmdline flag="h">yak</jabberd:cmdline></host></PRE
></P
><P
>which means that this session management component instance will
handle packets addressed to the host "yak."
<A
NAME="JABTDG-CH-4-FOOTNOTE-7"
HREF="#FTN.JABTDG-CH-4-FOOTNOTE-7"
>[1]</A
>
The
<TT
CLASS="LITERAL"
><jabberd:cmdline flag="h"> ... </jabberd:cmdline></TT
>
wrapper around the hostname means that this value ("yak") can be overridden
by specifying a switch <TT
CLASS="OPTION"
>-h <hostname></TT
> when
<B
CLASS="COMMAND"
>jabberd</B
>
is invoked, as is described in <A
HREF="c813.htm"
>Chapter 3</A
>.
If you're sure you'll never want
to override the hostname setting here, this
<TT
CLASS="LITERAL"
><jabberd:cmdline/></TT
> wrapper can
safely be removed from the configuration, to leave:</P
><P
><PRE
CLASS="SCREEN"
><host>yak</host></PRE
></P
><P
>As described earlier, you can specify more than one hostname - use a
<TT
CLASS="LITERAL"
><host>...</host></TT
>
pair for each one. This will effectively give you a virtual server effect
where Jabber will respond to different hostnames. This is useful in situations
such as deployment in an ISP where a single host serves multiple domains.
The client data stored on the server (such as rosters, offline messages,
and so on) is stored by the xdb component by hostname, so that a separate
directory in the spool area will be used for each specified hostname. </P
><P
>For example, if you specified the two hosts:</P
><P
><PRE
CLASS="SCREEN"
><host>a-domain.com</host>
<host>b-domain.com</host></PRE
></P
><P
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -