[Spacewalk-list] error jabber after upgrade 0.5 => 0.6
Michiel van Es
Michiele at info.nl
Thu Sep 10 21:03:22 UTC 2009
Here is my file s2s.xml:
<!-- s2s configuration -->
<s2s>
<!-- Our ID on the network (default: s2s) -->
<id>s2s</id>
<!-- The process ID file. Comment this out if you don't need to know
the process ID from outside the process (eg for control
scripts) -->
<pidfile>/var/lib/jabberd/pid/s2s.pid</pidfile>
<!-- Router connection configuration -->
<router>
<!-- IP/port the router is waiting for connections on -->
<ip>127.0.0.1</ip> <!-- default: 127.0.0.1 -->
<port>5347</port> <!-- default: 5347 -->
<!-- Username/password to authenticate as -->
<user>jabberd</user> <!-- default: jabberd -->
<pass>*mypass*</pass> <!-- default: secret -->
<!-- The router will only allow one component to be the default
route (ie the component that receives packets destined for
unknown hosts). If you want to run more than one s2s instance,
you need to uncomment this so that s2s does not try to become
the default route. Note that all outgoing s2s communication
will go to the component that is the default route. -->
<!--
<non-default/>
-->
<!-- File containing an SSL certificate and private key to use when
setting up an encrypted channel with the router. From
SSL_CTX_use_certificate_chain_file(3): "The certificates
must be
in PEM format and must be sorted starting with the subject's
certificate (actual client or server certificate), followed
by intermediate CA certificates if applicable, and ending
at the highest level (root) CA" (the latter one being
optional).
If this is commented out, or the file can't be read, no
attempt
will be made to establish an encrypted channel with the
router. -->
<!--
<pemfile>/etc/jabberd/server.pem</pemfile>
-->
<!-- Router connection retry -->
<retry>
<!-- If the connection to the router can't be established at
startup, we should try again this many times before exiting.
Use -1 to retry indefinitely. [default: 3] -->
<init>3</init>
<!-- If we lost the connection to the router during normal
operation (ie we've successfully connected to the router in
the past), we should try to reconnect this many times before
exiting. Use -1 to retry indefinitely. [default: 3] -->
<lost>3</lost>
<!-- Sleep for this many seconds before trying attempting a
reconnect. [default: 2] -->
<sleep>2</sleep>
</retry>
</router>
<!-- Log configuration - type is "syslog", "file" or "stdout" -->
<log type='syslog'>
<!-- If logging to syslog, this is the log ident -->
<ident>jabberd/s2s</ident>
<!-- If logging to syslog, this is the log facility
(local0 - local7) [default: local3] -->
<facility>local3</facility>
<!-- if logging to file, this is the filename of the logfile -->
<!--
<file>/var/lib/jabberd/log/s2s.log</file>
-->
</log>
<!-- Local network configuration -->
<local>
<!-- IP and port to listen for incoming s2s connections on
(default: 0.0.0.0, 5269) -->
<ip>0.0.0.0</ip>
<port>5269</port>
<!-- Multihomed machines (with more than one interface and IP
address)
need to specify outgoing S2S connections interface/address.
If not set, the <ip> section address above is used. -->
<!--
<origin>1.2.3.4</origin>
-->
<!-- Secret used to generate dialback keys. If you have more than
one s2s instance configured, make sure that this is the same
on
all of them. If this is commented out, a random one will be
generated. -->
<!--
<secret>secret</secret>
-->
<!-- File containing an SSL certificate and private key to use
when setting
up encrypted s2s connections with other servers (STARTTLS +
Dialback).
From SSL_CTX_use_certificate_chain_file(3): "The
certificates must be
in PEM format and must be sorted starting with the subject's
certificate (actual client or server certificate), followed
by intermediate CA certificates if applicable, and ending
at the highest level (root) CA" (the latter one being
optional).
If this is commented out, or the file can't be read, no
attempt will be
made to establish encrypted connections with other servers.
-->
<!--
<pemfile>/etc/jabberd/server.pem</pemfile>
-->
<!-- SSL verify mode - see SSL_CTX_set_verify(3), mode parameter
-->
<!--
<verify-mode>7</verify-mode>
-->
<!-- File containing an optional SSL certificate chain file for SSL
connections. -->
<!--
<cachain>/etc/jabberd/cachain.pem</cachain>
-->
</local>
<!-- input/output settings -->
<io>
<!-- Maximum number of file descriptors. Note that the number of
possible connections will be slightly less than this, because
s2s itself can use some on its own. If the supply of file
descriptors is exhausted, new incoming connections will be
denied.
These connections are mainly consumed when we make a
connection to an external jabber server, or an external jabber
server connects to us. If you don't have a lot of users then
there's probably no need for s2s to establish connections to
external jabber servers and the default value here is probably
fine. On the other hand, if you have lots of users with lots
of remote buddies in their buddylist then s2s will need to
have
lots of open connections with other jabber servers and you may
need to increase this value.
Note that this value only affects how many file descriptors
jabberd is able to handle internally. You may also need to
tell your operating system to allow jabberd to use more file
descriptors. On Linux this can be done using ulimit -n or by
changing the value of /proc/sys/fd/file-max.
(default: 1024) -->
<max_fds>1024</max_fds>
<!-- Rate limiting -->
<limits>
<!-- Maximum stanza size - if more than given number of bytes
are read in one incoming stanza, the stream is closed
with policy-violation error.
Set to 0 to disable.
Values less than 16384 might not work. -->
<stanzasize>0</stanzasize>
</limits>
</io>
<!-- Timed checks -->
<check>
<!-- Interval between checks.
Checks will be run every n seconds.
0 disables all checks except DNS expiry. (default: 60) -->
<interval>60</interval>
<!-- Queue expiry and connection timeout.
While a connection is being established and dialback is in
progress, packets are queued. If a valid connection has not
been established within this many seconds, the connection
process will be aborted and the queued packets will be
bounced. Timeout checks are made for three phases of
setting up a route authenticated through dialback:
1. Connection establishment to exchange of stream headers
2. Initiating dialback (incoming connections)
3. Completing dialback (incoming and outgoing)
If stage 1 connection establishment fails and there are
alternative hosts for this route that have not failed
recently, they will be tried too before finally giving up.
0 disables queue expiry. (default: 60) -->
<queue>60</queue>
<!-- Queue retry timeout.
If the queue is older than this timeout, the connection
will not be retried even if there are alternative hosts
that have not failed recently.
0 disables retry expiry. (default: 300) -->
<retry>300</retry>
<!-- Idle connection checks.
Connections that have not sent data for longer than this many
seconds will be dropped.
0 disables idle timeouts. (default: 86400) -->
<idle>86400</idle>
<!-- Keepalives.
Outgoing connections that have not been used for longer than
this many seconds will have a single whitespace character sent
to them. This will force the TCP connection to be closed if
they have disconnected without us knowing about it.
0 disables keepalives. (default: 0) -->
<keepalive>0</keepalive>
<!-- Interval between DNS result/bad host expiry.
0 disables expiry checks. (default: 300) -->
<dnscache>300</dnscache>
</check>
<!-- Statistics -->
<stats>
<!-- file containing count of packets that went through -->
<!--
<packet>/var/lib/jabberd/stats/s2s.packets</packet>
-->
</stats>
<lookup>
<!-- SRV TCP services will be resolved in the following order.
The first
one that returns something will be used (ie dereferenced
via an
A/AAAA lookup). If no SRV records are found, resolver will
fallback to a straight A/AAAA lookup. -->
<!-- xmpp-server is mandated by the XMPP spec -->
<srv>xmpp-server</srv>
<!-- traditionally, jabber has been used -->
<srv>jabber</srv>
<!-- If this is enabled, the resolver will look up AAAA records
as well
as A records. This is needed if you want s2s to use IPv6.
Connection attempts will be made to all IPv6 hosts before
trying
IPv4 (see bad host timeout below). -->
<!--
<resolve-ipv6/>
-->
<!-- Minimum time that DNS lookup results are cached (overrides
max below). -->
<min-ttl>30</min-ttl>
<!-- Maximum time that DNS lookup results are cached. -->
<max-ttl>86400</max-ttl>
<!-- Time /etc/hosts lookup results are cached for (default:
86400). -->
<etc-hosts-ttl>86400</etc-hosts-ttl>
<!-- Minimum time to wait before using hosts that we have failed to
establish a connection to (unless there are no alternatives).
Do not set this too low - it is required to detect permanent
problems like broken IPv6 connectivity in order to attempt
IPv4.
0 disables bad host caching. (default: 3600) -->
<bad-host-timeout>3600</bad-host-timeout>
<!-- Disable the DNS cache (negative caching will still be done).
This is likely to negatively impact performance while saving
a small amount of memory since multiple DNS requests must
then be made for every re-connection. -->
<!--
<no-cache/>
-->
</lookup>
<!-- If this is enabled, domains which share the same host will re-
use
existing outgoing connections. This is a potential security risk
as the SSL connection from the first domain will be re-used
too. -->
<out-reuse-conn/>
</s2s>
<!--
vim: syntax=xml
-->
If you want I can send the other config files too ? or send them to
you personally as a tar.gz file?
Kind Regards,
Michiel
On Sep 10, 2009, at 10:15 PM, Michiel van Es wrote:
>
>
>
> On Sep 10, 2009, at 9:45 PM, Joshua Roys wrote:
>
>> On 09/10/2009 03:30 PM, Michiel van Es wrote:
>>> [root at devmx01 ~]# sm -D
>>> Thu Sep 10 21:22:51 2009 [notice] starting up
>>> Thu Sep 10 21:22:51 2009 [notice] id: devmx01.buro.info.nl
>>> Thu Sep 10 21:22:51 2009 [info] process id is 15647, written to
>>> /var/lib/jabberd/pid/sm.pid
>>> Thu Sep 10 21:22:51 2009 storage.c:94 adding arbitrary types to
>>> driver 'db'
>>> Thu Sep 10 21:22:51 2009 storage.c:117 driver not loaded, trying to
>>> init
>>> Thu Sep 10 21:22:51 2009 [info] loading 'db' storage module
>>> Thu Sep 10 21:22:51 2009 storage.c:139 preloaded module 'db' (not
>>> initialized yet)
>>> Thu Sep 10 21:22:51 2009 storage.c:158 calling driver initializer
>>>
>>> [root at devmx01 ~]# c2s -D
>>> Thu Sep 10 21:23:03 2009 [notice] starting up
>>> Thu Sep 10 21:23:03 2009 [info] process id is 15701, written to
>>> /var/lib/jabberd/pid/c2s.pid
>>> Thu Sep 10 21:23:03 2009 [notice] modules search path: /usr/lib/
>>> jabberd/
>>> Thu Sep 10 21:23:03 2009 [info] loading 'db' authreg module
>>> Thu Sep 10 21:23:03 2009 authreg.c:73 preloaded module 'db' (not
>>> initialized yet)
>>>
>>
>> Michiel,
>>
>> What version of jabberd do you have?
>> - should be 2.2.8 or better
>
> root at devmx01 ~]# rpm -qa | grep jabber
> jabberd-selinux-1.4.6-1.el5
> jabberd-2.2.8-2.el5
>
>
>> Are you x86 or x86_64?
>
> i386
>
>> - if you're x86_64, module search path needs to be /usr/lib64/jabberd
>> -- c2s.xml, <authreg> <path> ... </path>
>> -- sm.xml, <storage> <path> ... </path>
>
>> Do c2s or sm give any other output? It looks like they are crashing?
>> Are they still running after the above?
>
> Nope but can run them again :)
>
>> Can they read/write the db location specified in their configs?
>> - mine is /var/lib/jabberd/db
>> - try: sudo -u jabber stat /var/lib/jabberd/db/*
>> -- c2s.xml, <db> <path> ... </path>
>> -- sm.xml, <db> <path> ... </path>
>
> runs without error :)
>>
>> Good luck,
>>
>> Joshua Roys
>
> Michiel van Es
>>
>> _______________________________________________
>> Spacewalk-list mailing list
>> Spacewalk-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
More information about the Spacewalk-list
mailing list