[Spacewalk-list] error jabber after upgrade 0.5 => 0.6
Michiel van Es
michiele at info.nl
Fri Sep 11 11:15:41 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Some more information I found on the internet:
>>> The problem looks strange to me as the server does not report any
>>> errors.
>>>
>>> I have tried various settings, different backends, over 15
>>> compilations... and no result. Port 5347 is opened and processes seem
>>> to talk to each other, but 5222 remains closed...
>>
>> This is a problem known to me.
>> I could only guess that the c2s login to router fails. On the router
>> side, but c2s does not know about it and waits for router reply. Only
>> after successful login to router, c2s starts listening on its port (it
>> logs this event in syslog).
>>
>> Unfortunately I cannot manage to reproduce this bug, so I can't fix it.
>> (Router should report the login failure)
>>
>>
>>
>> The cause I think is borked SASL layer. Are you using GnuSASL or Cyrus?
How can I check that the used router login used by the c2s.xml file is
correct?
And can it be a corrupt SASL thing?
Kind regards,
Michiel
- -------- Original Message --------
Subject: [Spacewalk-list] error jabber after upgrade 0.5 => 0.6
From: Michiel van Es <michiele at info.nl>
To: spacewalk-list at redhat.com <spacewalk-list at redhat.com>
Date: 9/11/2009 12:01 PM
> Hi,
>
> A small update: I don't see anything wrong in /var/log/messages:
>
>
> Sep 11 11:57:00 devmx01 syslogd 1.4.1: restart.
> Sep 11 11:57:00 devmx01 kernel: klogd 1.4.1, log source = /proc/kmsg
> started.
> Sep 11 11:57:09 devmx01 jabberd/router[9912]: shutting down
> Sep 11 11:57:24 devmx01 jabberd/router[16262]: starting up
> Sep 11 11:57:24 devmx01 jabberd/router[16262]: process id is 16262,
> written to /var/lib/jabberd/pid/router.pid
> Sep 11 11:57:24 devmx01 jabberd/router[16262]: loaded user table (1 users)
> Sep 11 11:57:24 devmx01 jabberd/router[16262]: loaded filters (0 rules)
> Sep 11 11:57:24 devmx01 jabberd/router[16262]: [0.0.0.0, port=5347]
> listening for incoming connections
> Sep 11 11:57:24 devmx01 jabberd/sm[16286]: starting up
> Sep 11 11:57:24 devmx01 jabberd/sm[16286]: id: devmx01.buro.info.nl
> Sep 11 11:57:24 devmx01 jabberd/sm[16286]: process id is 16286, written
> to /var/lib/jabberd/pid/sm.pid
> Sep 11 11:57:24 devmx01 jabberd/sm[16286]: loading 'db' storage module
> Sep 11 11:57:24 devmx01 jabberd/c2s[16310]: starting up
> Sep 11 11:57:24 devmx01 jabberd/c2s[16310]: process id is 16310, written
> to /var/lib/jabberd/pid/c2s.pid
> Sep 11 11:57:24 devmx01 jabberd/c2s[16310]: modules search path:
> /usr/lib/jabberd/
> Sep 11 11:57:24 devmx01 jabberd/c2s[16310]: loading 'db' authreg module
> Sep 11 11:57:24 devmx01 jabberd/s2s[16334]: starting up (interval=60,
> queue=60, keepalive=0, idle=86400)
> Sep 11 11:57:24 devmx01 jabberd/s2s[16334]: process id is 16334, written
> to /var/lib/jabberd/pid/s2s.pid
> Sep 11 11:57:24 devmx01 jabberd/s2s[16334]: attempting connection to
> router at 127.0.0.1, port=5347
> Sep 11 11:57:24 devmx01 jabberd/router[16262]: [127.0.0.1, port=48181]
> connect
> Sep 11 11:57:24 devmx01 jabberd/router[16262]: [127.0.0.1, port=48181]
> authenticated as jabberd at jabberd-router
> Sep 11 11:57:24 devmx01 jabberd/s2s[16334]: connection to router established
> Sep 11 11:57:24 devmx01 jabberd/router[16262]: [s2s] set as default route
> Sep 11 11:57:24 devmx01 jabberd/router[16262]: [s2s] online (bound to
> 127.0.0.1, port 48181)
> Sep 11 11:57:24 devmx01 jabberd/s2s[16334]: [0.0.0.0, port=5269]
> listening for connections
> Sep 11 11:57:24 devmx01 jabberd/s2s[16334]: ready for connections
>
>
> But nothing is listening on 5222 of 5223.
> Also when I start the modules seperatly with the -D option, I still
> don't see anything going wrong?
>
> What could be the problem or what is starting up at tcp port 5222 and is
> failing?
>
> Kind Regards,
>
> Michiel
>
> -------- Original Message --------
> Subject: Re: [Spacewalk-list] error jabber after upgrade 0.5 => 0.6
> From: Michiel van Es <Michiele at info.nl>
> To: spacewalk-list at redhat.com <spacewalk-list at redhat.com>
> Date: 9/10/2009 11:03 PM
>
>> 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
>
>> _______________________________________________
>> Spacewalk-list mailing list
>> Spacewalk-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJKqjFcAAoJEKmnTNucqQlOVQkH/j5d9n7xqjj1Lum4LYoyw0lq
k6vgg/9lt5ZDqrPvNxUMtfmi5LPjF6DtSxMU/+EuIYazYkkIt7kLj65eOQ5LzfpZ
S1rufQDbcU23lIDiP45SC2wE5o/VLOlmLx0gQybzSmNxHjej/spjqimhp4i0fWFy
beNvjWUcr9Mq4JWLzmIJj8mg5aHYP8vcu195NAR63v5r5MWIdBKpTqYwK+zpxMpG
3aPtgyAeb85e6V0vIlJEZPJDiOzS9dDz6h2Ztqz16g27TpTKEZmzqgFLbafEuF5r
l7myyKb/dNB2qN+xOvZfbQNS/d59TO3bW+vUw6+pRXva10g6l4GBjW7yJs4dZVA=
=WL6G
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x9CA9094E.asc
Type: application/pgp-keys
Size: 1728 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20090911/a57d3faf/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x9CA9094E.asc.sig
Type: application/octet-stream
Size: 287 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20090911/a57d3faf/attachment.obj>
More information about the Spacewalk-list
mailing list