?? x1740.htm
字號:
><email/></TT
>
<I
CLASS="EMPHASIS"
>and</I
>
<TT
CLASS="LITERAL"
><username/></TT
>
and
<TT
CLASS="LITERAL"
><password/></TT
>
will be sent in the reply. The text inside the
<TT
CLASS="LITERAL"
><instructions/></TT
>
tag is intended for display by the client if it supports such a dynamic
process. Typically the client would request the registration requirements and
build a screen asking the user to enter values for the required fields,
while displaying the instructions received. </P
><P
>The <TT
CLASS="LITERAL"
>notify="yes"</TT
> attribute of the
<TT
CLASS="LITERAL"
><register/></TT
>
tag will cause a message to be automatically created and sent to the
server administrator address(es) for every new account created. See
<A
HREF="x1740.htm#JABTDG-CH-4-SECT-4.3.1.3.5"
>the section called <I
>Administration</I
></A
>
for details about specifying administration addresses.</P
><P
>If you want to prevent registration of new accounts on your Jabber server,
comment out this
<TT
CLASS="LITERAL"
><register/></TT
>
section.
<TT
CLASS="LITERAL"
>mod_register</TT
>, the only standard module that
handles <TT
CLASS="LITERAL"
><iq/></TT
> packets in
the <TT
CLASS="LITERAL"
>jabber:iq:register</TT
> namespace, will
refuse to handle register requests if there is no
<TT
CLASS="LITERAL"
><register/></TT
> section in
the configuration, and so a "Not Implemented" reply will be sent to the
registration details request. </P
></DIV
><DIV
CLASS="SECT4"
><H4
CLASS="SECT4"
><A
NAME="JABTDG-CH-4-SECT-4.3.1.3.4"
>Welcome Message</A
></H4
><P
>The welcome message defined here:</P
><P
><PRE
CLASS="SCREEN"
><welcome>
<subject>Welcome!</subject>
<body>Welcome to the Jabber server on yak</body>
</welcome></PRE
></P
><P
>will be sent to all new users the first time they log on. The
<TT
CLASS="LITERAL"
><subject/></TT
>
and
<TT
CLASS="LITERAL"
><body/></TT
>
contents are simply placed in a normal
<TT
CLASS="LITERAL"
><message/></TT
>
and sent off to the new Jabber ID (JID).</P
></DIV
><DIV
CLASS="SECT4"
><H4
CLASS="SECT4"
><A
NAME="JABTDG-CH-4-SECT-4.3.1.3.5"
>Administration</A
></H4
><P
>While the Unix user acts as the overall administrator for the Jabber
server (for starting and stopping <B
CLASS="COMMAND"
>jabberd</B
>, for example)
it is possible to specify administration rights for certain Jabber users
that are local to the server. 'Local' means users that are defined as
belonging to the host (or hosts) specified in the
<TT
CLASS="LITERAL"
><host/></TT
>
tag within the same jsm component instance definition - if the host
tag is </P
><P
><PRE
CLASS="SCREEN"
><host>server.com</host></PRE
></P
><P
>then the JIDs
<TT
CLASS="LITERAL"
>dj@server.com</TT
> and
<TT
CLASS="LITERAL"
>admin@server.com</TT
> are local, but
<TT
CLASS="LITERAL"
>admin@anotherserver.com</TT
> is not.</P
><P
>The only difference between an administration JID and a 'normal' JID
is that the former is specified in tags in this section and the latter
isn't. When a JID is specified between either the
<TT
CLASS="LITERAL"
><read/></TT
>
or
<TT
CLASS="LITERAL"
><write/></TT
>
tags, then it can be used to perform 'administrative' tasks.</P
><P
>The
<TT
CLASS="LITERAL"
><admin/></TT
>
section as delivered in the standard <TT
CLASS="FILENAME"
>jabber.xml</TT
>
that comes with version 1.4.1 (see <A
HREF="a10211.htm"
>Appendix A</A
>)
is commented
out. Make sure that you remove the comment lines to activate the section
if you want to make use of the administrative features:</P
><P
><PRE
CLASS="SCREEN"
><admin>
<read>support@yak</read>
<write>admin@yak</write>
<reply>
<subject>Auto Reply</subject>
<body>This is a special administrative address.</body>
</reply>
</admin></PRE
></P
><P
>If you want to specify more than one JID with administrative
rights, simply repeat the tags, like this:</P
><P
><PRE
CLASS="SCREEN"
><read>admin1@yak</read>
<read>admin2@yak</read>
<read>admin3@yak</read></PRE
></P
><P
>Placing a JID inside of a <TT
CLASS="LITERAL"
><write/></TT
>
tag implies that that JID also has
<TT
CLASS="LITERAL"
><read/></TT
> administration rights.
So there's not much point in doing something like this:</P
><P
><PRE
CLASS="SCREEN"
><read>admin@yak</read>
<write>admin@yak</write></PRE
></P
><P
>So what are the administrative features available to JIDs placed inside
the <TT
CLASS="LITERAL"
><read/></TT
>
and <TT
CLASS="LITERAL"
><write/></TT
> tags?</P
><P
><I
CLASS="EMPHASIS"
>Administrative Features for
<TT
CLASS="LITERAL"
><read/></TT
>
JIDs</I
></P
><P
>For JIDs appearing in a
<TT
CLASS="LITERAL"
><read/></TT
>
tag in the
<TT
CLASS="LITERAL"
><admin/></TT
>
section, these are the features available:</P
><P
></P
><UL
><LI
><P
><I
CLASS="EMPHASIS"
>Retrieve list of users currently online</I
></P
><P
>By sending one of two possible types of query to the server, a JID can retrieve
a list of users that currently have a session on the (local) Jabber server.
The results come in one of two forms, depending on the query type. The first
query version is of the 'legacy' <TT
CLASS="LITERAL"
>iq:admin</TT
> type
and the second is of the newer <TT
CLASS="LITERAL"
>iq:browse</TT
> type.</P
><P
>The list of users in both sorts of results contain the user JID, for how long
the user has been logged on (measured in seconds), how many packets have been
sent from the user's session, and how many packets have been send to the
user's session. The first query version also contains presence information for
each user in the list.</P
></LI
><LI
><P
><I
CLASS="EMPHASIS"
>Receipt of 'administrative queries'</I
></P
><P
>Users normally send messages to other users - to other JIDs, where a JID
is composed of a username and a hostname (a Jabber servername). The Jabber
server itself is also a valid recipient, and the 'JID' in this case is
just the servername itself - no username and no
<TT
CLASS="LITERAL"
>@</TT
> sign.
<A
NAME="JABTDG-CH-4-FOOTNOTE-9"
HREF="#FTN.JABTDG-CH-4-FOOTNOTE-9"
>[2]</A
></P
><P
>If a user sends a message to the server, it will be forwarded to the
JIDs listed in the
<TT
CLASS="LITERAL"
><read/></TT
>
(and <TT
CLASS="LITERAL"
><write/></TT
>)
tags in this
<TT
CLASS="LITERAL"
><admin/></TT
>
section, and the reply defined in the
<TT
CLASS="LITERAL"
><reply/></TT
>
tag will be sent back to the user as an automated response.</P
></LI
></UL
><P
>For JIDs appearing in a
<TT
CLASS="LITERAL"
><write/></TT
>
tag in the
<TT
CLASS="LITERAL"
><admin/></TT
>
section, these are the features available:</P
><P
></P
><UL
><LI
><P
><I
CLASS="EMPHASIS"
>Same as <TT
CLASS="LITERAL"
><read/></TT
></I
></P
><P
>JIDs listed in <TT
CLASS="LITERAL"
><write/></TT
>
tags automatically have access to the same features as those JIDs listed
in <TT
CLASS="LITERAL"
><read/></TT
> tags.</P
></LI
><LI
><P
><I
CLASS="EMPHASIS"
>Configuration retrieval</I
></P
><P
>In a similar way to how a list of online users can be requested by
sending a query of the <TT
CLASS="LITERAL"
>iq:admin</TT
>
variety, a copy of the jsm configuration can be requested by sending
an <TT
CLASS="LITERAL"
>iq:admin</TT
> query to the server. The
difference is that in the former user list request, a request tag
<TT
CLASS="LITERAL"
><who/></TT
> is sent inside the
query, and in this configuration request, a
<TT
CLASS="LITERAL"
><config/></TT
> tag is sent. </P
><P
>The configuration XML, as it is defined in the jsm component instance
section of the Jabber server being queried, is returned as a result.</P
></LI
><LI
><P
><I
CLASS="EMPHASIS"
>Sending administrative messages</I
></P
><P
>Two types of administrative messages can be sent - an announcement to
all online users, and a 'message of the day' (MOTD). The announcement
goes out to all users currently online. Similarly, the MOTD goes out
to all users, but not only those online - when someone logs on and starts
a session the MOTD will be sent to them too, unlike the announcement,
which will 'expire' as soon as it is sent. The MOTD will not expire,
unless explicitly made to do so. The MOTD can also be updated - those that
had already received the MOTD won't receive the updated copy during their
current session, but anyone
logging on after the update will receive the new version of the message.</P
></LI
></UL
></DIV
><DIV
CLASS="SECT4"
><H4
CLASS="SECT4"
><A
NAME="JABTDG-CH-4-SECT-4.3.1.3.6"
>Update Info Request</A
></H4
><P
>The <TT
CLASS="FILENAME"
>mod_version</TT
> module provides a simple service
that, at server startup, queries a central repository of Jabber software
version information at <TT
CLASS="FILENAME"
>update.jabber.org</TT
>.
The <TT
CLASS="LITERAL"
><update/></TT
>
configuration tag:</P
><P
><PRE
CLASS="SCREEN"
><update><jabberd:cmdline flag="h">yak</jabberd:cmdline></update></PRE
></P
><P
>is used to control this query. </P
><P
>If the <TT
CLASS="LITERAL"
><update/></TT
>
tag is present, the query is sent. If the update tag is not present,
the query is not sent.</P
><P
>If you do intend leaving the
<TT
CLASS="LITERAL"
><update/></TT
>
tag in, you need to make sure </P
><P
></P
><OL
TYPE="1"
><LI
><P
>the hostname specified as the value in the tag is resolvable and
reachable as this is your Jabber server address to which the central
repository will try to send back information (if there happens
to be a newer version of the server software - specifically
the jsm component - available)</P
></LI
><LI
><P
>your Jabber server is connected to the Internet to be able to reach
<TT
CLASS="FILENAME"
>update.jabber.org</TT
>. You also need to be running
instances of the <I
CLASS="EMPHASIS"
>Hostname Resolution</I
> and
<I
CLASS="EMPHASIS"
>Server (to Server) Connections</I
> components so
that your Jabber server can resolve the <TT
CLASS="FILENAME"
>update.jabber.org</TT
>
host and send the query out. </P
></LI
></OL
><P
>The jsm component version releases are fortunately not so frequent that
you require an automated mechanism to keep up with what's new; also you
may wish to run an internal Jabber server with no connection to the
outside world. So it is not uncommon for this section to be commented out.
The jsm will still function without this piece of configuration.</P
><P
>It is worth noting here, however, that Jabber clients also use the
central repository to find out about newer versions of themselves.
As all Jabber client communication goes through the server
you need to realise that commenting out the
<TT
CLASS="LITERAL"
><update/></TT
>
tag will not stop clients sending their queries.
<A
NAME="JABTDG-CH-4-FOOTNOTE-10"
HREF="#FTN.JABTDG-CH-4-FOOTNOTE-10"
>[3]</A
> </P
></DIV
><DIV
CLASS="SECT4"
><H4
CLASS="SECT4"
><A
NAME="JABTDG-CH-4-SECT-4.3.1.3.7"
>Auto-Update of JUD</A
></H4
><P
>The Jabber User Directory (JUD) is a service that provides a directory service
of user names and addresses. The service comes in the form of a component
- we'll be looking at the component instance definition of a JUD later in
this chapter. If a Jabber server is running a JUD service, then you can
connect to it with your Jabber client and enter your name and address details
and query it as you would any directory service to find details of other
people. </P
><P
>At the same time, each user has the possibility of maintaining his own
vCard - we discussed vCards earlier
in <A
HREF="x1740.htm#JABTDG-CH-4-SECT-4.3.1.3.2"
>the section called <I
>Server vCard</I
></A
>. In the
same way that the server's vCard can be requested and retrieved, you can
request a user's vCard, and the user whose vCard is requested does not have
to be connected at that moment for the request to be fulfilled - the vCards
are stored server-side and the Jabber server handles the request (not the
user's client). </P
><P
>So in many ways it makes sense to align the data in the user vCard with
data stored in a JUD. The </P
><P
><PRE
CLASS="SCREEN"
><vcard2jud/></PRE
></P
><P
>configuration
tag allows this alignment to happen automagically; if it appears in the
configuration, it will cause any vCard updates (that would be typically
performed by users changing their personal information via their Jabber
clients) to be not only stored server-side in the vCard but also to be
passed on to a JUD. </P
><P
>Which JUD? Well, the first one that's defined in the
<TT
CLASS="LITERAL"
><browse/></TT
> section of the
configuration, which is described next. Effectively it means that if
you run a local JUD but also connect to the JUD running on
<TT
CLASS="FILENAME"
>jabber.org</TT
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -