📄 x3381.htm
字号:
<HTML
><HEAD
><TITLE
>Server Constellations</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="Managing the Configuration"
HREF="x3305.htm"><LINK
REL="NEXT"
TITLE="Putting Jabber's Concepts to Work"
HREF="p3608.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="x3305.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="p3608.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.5"
>Server Constellations</A
></H1
><P
>Throughout the discussion of components in this chapter,
and how they're arranged to form a 'complete' Jabber server, we've only
really considered a monolithic server, running in a single process.
<A
NAME="JABTDG-CH-4-FOOTNOTE-22"
HREF="#FTN.JABTDG-CH-4-FOOTNOTE-22"
>[1]</A
> </P
><P
>However, there may be good reasons (performance, administration and
manageability) to run the Jabber server in different configurations, or
'constellations'.
<A
NAME="JABTDG-CH-4-FOOTNOTE-23"
HREF="#FTN.JABTDG-CH-4-FOOTNOTE-23"
>[2]</A
> </P
><P
>In this concluding section of Chapter 4 we take a look at some of the
possible constellations, and how they're constructed. </P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="JABTDG-CH-4-SECT-4.5.1"
>Multiple Servers on one Host</A
></H2
><P
>Although it's unlikely that this constellation would be of much use,
it is possible to run more than one Jabber server on one host simply
by creating multiple installations, maintaining each server's
<TT
CLASS="FILENAME"
>jabber.xml</TT
> configuration file separately, and starting
them up to listen on different ports to each other. Note that some Jabber
clients don't support connections to anything other than port 5222, however.</P
><P
>As we have seen from examining the instance configuration for
the <I
CLASS="EMPHASIS"
>Client (to Server) Connections</I
> and the
<I
CLASS="EMPHASIS"
>Server (to Server) Connections</I
> components,
the 'standard' Jabber
ports for client and server connectivity are 5222 and 5269 respectively.
To run a second Jabber server on the same host, just ensure that its
<I
CLASS="EMPHASIS"
>Connections</I
> component instances are configured to
listen on different ports.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="JABTDG-CH-4-SECT-4.5.2"
>'Real' Virtual Jabber Servers</A
></H2
><P
>While looking at <A
HREF="x1740.htm#JABTDG-CH-4-SECT-4.3.1.2"
>the section called <I
>Host filter</I
></A
>
we saw how to use multiple <TT
CLASS="LITERAL"
><host/></TT
>
tags to allow connection to the Jabber server under multiple hostnames.
Although this simple feature might be useful in some circumstances,
a better distinction of <I
CLASS="EMPHASIS"
>Session Management</I
> functionality
might be more appropriate. </P
><P
>Taking our <TT
CLASS="FILENAME"
>a-domain.com</TT
> and
<TT
CLASS="FILENAME"
>b-domain.com</TT
> hostname examples again, we might want
to offer different 'welcome' messages to new users; we may want to limit
the authentication possibilities for the <TT
CLASS="FILENAME"
>b-domain.com</TT
>
host to zero-knowledge only; and disable the message filtering service for
the <TT
CLASS="FILENAME"
>a-domain.com</TT
> host;
furthermore it's likely that we'd want to
offer - in the <TT
CLASS="LITERAL"
><browse/></TT
>
list - a different set of services for each of the hosts. </P
><P
>Let's have a look how this can be done. Using the
<TT
CLASS="LITERAL"
><jabberd:include/></TT
>
tag to organise our configuration XML by component instance definitions, we
might have a <TT
CLASS="FILENAME"
>jabber.xml</TT
> configuration file that
looks like <A
HREF="x3381.htm#JABTDG-CH-4-EX-20"
>Example 4-24</A
>.</P
><DIV
CLASS="EXAMPLE"
><A
NAME="JABTDG-CH-4-EX-20"
></A
><P
><B
>Example 4-24. Virtual server <TT
CLASS="FILENAME"
>jabber.xml</TT
> configuration</B
></P
><P
><PRE
CLASS="SCREEN"
><jabber>
<!-- Common components -->
<jabberd:include>./config/common/xdb.xml</jabberd:include>
<jabberd:include>./config/common/c2s.xml</jabberd:include>
<jabberd:include>./config/common/elogger.xml</jabberd:include>
<jabberd:include>./config/common/rlogger.xml</jabberd:include>
<jabberd:include>./config/common/dnsrv.xml</jabberd:include>
<jabberd:include>./config/common/s2s.xml</jabberd:include>
<!-- a-domain.com -->
<jabberd:include>./config/a-domain/sessions.xml</jabberd:include>
<jabberd:include>./config/a-domain/conference.xml</jabberd:include>
<!-- b-domain.com -->
<jabberd:include>./config/b-domain/sessions.xml</jabberd:include>
<jabberd:include>./config/b-domain/conference.xml</jabberd:include>
<jabberd:include>./config/b-domain/jud.xml</jabberd:include>
<!-- IO, PIDfile -->
<jabberd:include>./config/common/io.xml</jabberd:include>
<jabberd:include>./config/common/pidfile.xml</jabberd:include>
</jabber></PRE
></P
></DIV
><P
>What can we see here?</P
><P
>First, a-domain.com and b-domain.com Jabber
users will share the common facilities such as
<I
CLASS="EMPHASIS"
>Data Storage</I
>, remembering that data will be stored
by hostname within the spool area (and while you're remembering, remember
also that you <I
CLASS="EMPHASIS"
>can</I
> use two xdb component instances,
specifying a different host filter in each, to store data in separate
places - see <A
HREF="x1740.htm#JABTDG-CH-4-SECT-4.3.2"
>the section called <I
>Component instance: <I
CLASS="EMPHASIS"
>xdb</I
></I
></A
>
earlier in this Chapter),
<I
CLASS="EMPHASIS"
>Client (to Server) Connections</I
>,
<I
CLASS="EMPHASIS"
>Logging</I
> and so on.
They also share the same IO settings and PIDfile definition - after all,
there is still only one Jabber server that is hosting these two virtual
servers, so we only need one PIDfile. </P
><P
>But we also see that there are two <TT
CLASS="FILENAME"
>sessions.xml</TT
>
files included - one for the <TT
CLASS="FILENAME"
>a-domain.com</TT
> host and
another for the <TT
CLASS="FILENAME"
>b-domain.com</TT
> host. And with each of
the <TT
CLASS="FILENAME"
>sessions.xml</TT
> files included, we have one or two
other components - for <I
CLASS="EMPHASIS"
>Conferencing</I
> and JUD services.</P
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="JABTDG-CH-4-SECT-4.5.2.1"
>Configuration for a-domain.com</A
></H3
><P
>The layout in the <TT
CLASS="FILENAME"
>jabber.xml</TT
> file indicates that there
are separate definitions for each of the two hosts. Let's examine the
contents of <TT
CLASS="FILENAME"
>./config/a-domain/sessions.xml</TT
>:</P
><P
><PRE
CLASS="SCREEN"
><service id="sessions.a-domain">
<host>a-domain.com</host>
<jsm xmlns="jabber:config:jsm">
<!-- no filter config necessary -->
<vCard>
<FN>a-domain.com Jabber Services</FN>
<DESC>Jabber 1.4.1 on a-domain.com</DESC>
<URL>http://www.a-domain.com</URL>
</vCard>
<browse>
<conference type="public" jid="conference.a-domain.com"
name="a-domain Conferencing"/>
</browse>
<!--
a-domain.com not open for self-service new user accounts
<register notify="yes">
<instructions/>
<name/>
<email/>
</register>
-->
<welcome>
<subject>Welcome!</subject>
<body>Welcome to the Jabber server at a-domain.com</body>
</welcome>
<admin>
<write>admin@a-domain.com</write>
<reply>
<subject>Auto Reply</subject>
<body>This is a special administrative address.</body>
</reply>
</admin>
</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>
<!-- No filter service for a-domain.com
<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
><P
>We can see that this
configuration file contains the definition of a jsm component instance.
The instance is identified with the name <TT
CLASS="LITERAL"
>sessions.a-domain</TT
> and the host <TT
CLASS="FILENAME"
>a-domain.com</TT
> has
been registered as what the jsm listens for - its 'external identification'.</P
><P
>We can also see that the literal texts in the descriptions and welcome
message are specific to a-domain.com, the administration section in
the configuration describes a local user at a-domain.com as the
administrator, the new user registration facility
has been disabled, and that the <TT
CLASS="FILENAME"
>mod_filter</TT
>
service has been commented out from the list of loaded modules in the component
connection definition. </P
><P
>There is one service listed in
the browse section - the <I
CLASS="EMPHASIS"
>Conferencing</I
> service,
with the JID <TT
CLASS="FILENAME"
>conference.a-domain.com</TT
>;
this is the service that's defined in the file
<TT
CLASS="FILENAME"
>./config/a-domain/conference.xml</TT
>, which itself
is specified in a
<TT
CLASS="LITERAL"
><jabberd:include/></TT
>
tag in the main <TT
CLASS="FILENAME"
>jabber.xml</TT
> alongside this
<TT
CLASS="FILENAME"
>sessions.xml</TT
> file.</P
><P
>Taking a look at this <I
CLASS="EMPHASIS"
>Conferencing</I
> service
definition for a-domain.com in the
<TT
CLASS="FILENAME"
>./config/a-domain/conference.xml</TT
> file, we see:</P
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -