[Spacewalk-list] error jabber after upgrade 0.5 => 0.6
Michiel van Es
michiele at info.nl
Fri Sep 11 12:28:45 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
And (hopefully) my latest update:
The database files in /var/lib/jabberd/db where 1 , 2 days old but not
auto created when I restart jabberd.
When I moved and recreated the folder wit hthe right permissions, all
worked well :)
Thanks for any help :)
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/11/2009 1:15 PM
> 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/
iQEcBAEBAgAGBQJKqkJ8AAoJEKmnTNucqQlOwfwH/2FFM/x56D27KHcxFdHXVHUB
Rv48UHCU84fQjgHvne9z5fTvUOy832/fcCVKZHgJDZwk+x9mLhsItNa+W2NvhKuy
MQy0S/3/VFuVnwmChCvVeygGlQ0QFm5+NFeQI5nuJ/J59T3hK/WcHCGkuP1NBBFW
C3JjhYrO36Uks1AJRpS8usBOHKiigPp2ds60BauGniBA4hl4r8J7CQ67QBcklEEl
5Z82ABCZ51QIaxWu+42t6T29x9edCuzT6EpN3t21uSaU6YkDWM92xDbJ8t3VRztf
5LjWFbah4cyKvRiE5EGg9AC5JgZ6a89ke9aEkfIJrl3o/ATbACFisfTBn2ZxiUw=
=Q7Cz
-----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/155f318f/attachment.bin>
-------------- 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/155f318f/attachment-0001.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/155f318f/attachment.obj>
-------------- 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/155f318f/attachment-0001.obj>
More information about the Spacewalk-list
mailing list