Ejabberd 3.0.0-alpha-2 fails to start

Operating System: Fedora 14 2.6.35.12-88.fc14.x86_64

Ejabberd Versions: ejabberd-3.0.0-alpha-2_linux-amd64

Installation method: gzipped binary (ejabberd-3.0.0-alpha-2_linux-amd64.bin.gz)

erlang.log shows:
=CRASH REPORT==== 20-Apr-2011::17:25:53 ===
crasher:
initial call: application_master:init/4
pid: <0.35.0>
registered_name: []
exception exit: {bad_return,
{{ejabberd_app,start,[normal,[]]},
{'EXIT',
{undef,
[{crypto,start,[]},
{sha,start,0},
{ejabberd_app,start,2},
{application_master,start_it_old,4}]}}}}
in function application_master:init/4
ancestors: [<0.34.0>]
messages: [{'EXIT',<0.36.0>,normal}]
links: [<0.34.0>,<0.6.0>]
dictionary: []
trap_exit: true
status: running
heap_size: 610
stack_size: 24
reductions: 96
neighbours:

Checked /lib/crypto-2.0.2/ebin

Any advice or help is appreciated.

kailesmith wrote: Checked

kailesmith wrote:

Checked installation path/lib/crypto-2.0.2/ebin

Does that dir contain crypto.beam?

Try that:
1. ./bin/ejabberdctl live
2. Then type: crypto:start().

Hardcode OpenSSL library version?

1. Yes, it does contain crypto.beam

2. ./bin/ejabberdctl live gives the following error:
Eshell V5.8.2 (abort with ^G)
(ejabberd@localhost)1>
=ERROR REPORT==== 1-May-2011::08:44:54 ===
Failed to load driver "exmpp_tls_openssl": libssl.so.0.9.8: cannot open shared object file: No such file or directory
....

3. OpenSSL is installed but is version openssl-1.0.0d-1.fc14.x86_64. I am suspecting that this is hard coded in crypto.so. Is that the case? (Don't have the source for it)

Install also 0.9.8

Probably the compiler links it to 0.9.8.

I have both libssl 0.9.8 and 1.0.0 installed in my Debian.

Openssl hardcoded to 0.9.8 in 3.0.0-alpha2

strings priv/lib/crypto.so | grep 0.9.8
libcrypto.so.0.9.8
OPENSSL_0.9.8

shows definitely that it is linked to 0.9.8. It would be hard to downgrade without impacting every other application on the system. Other choice is to install 0.9.8 also. I was wondering if the source for crpto.so is anywhere so I can rebuilt that as it will be a lot easier.

two paths

crypto.so is part of erlang/otp, specifically its library 'crypto'. See for example in debian: http://packages.debian.org/sid/i386/erlang-crypto/filelist
You can download the tar.gz from erlang.org or git from https://github.com/erlang/otp

Alternative 2: install all the erlang packages provided by your fedora. Then download ejabberd 3.0.0-alpha2 source code, and compile it.
The reason: it's easier and faster to compile ejabberd than all (or part of) Erlang/OTP.

The problem is that the

The problem is that the prebuilt binary at the site packages a crypto as part of ejabberd 3.0.0-alpha2 that is hardcoded to 0.9.8. I thought I would be smart and copy the crytp.so from crypto-R14B-02.1.fc14.x86_64 to the local install, but now I have a version clash...:(

I have downloaded 3.0.0-alpha2 source and have it compiled. Can you give me a link or any hints on how to configure and run it from the source tree? Sorry for the all the bother, but being new to both erlang and ejabberd the learning experience is steeper than usual.

Re

kailesmith wrote:

The problem is that the prebuilt binary at the site packages a crypto as part of ejabberd 3.0.0-alpha2 that is hardcoded to 0.9.8. I thought I would be smart and copy the crytp.so from crypto-R14B-02.1.fc14.x86_64 to the local install, but now I have a version clash...:(

Maybe you can copy that specific SO file into the ejabberd installed dir, with other ejabberd SO files.

kailesmith wrote:

I have downloaded 3.0.0-alpha2 source and have it compiled. Can you give me a link or any hints on how to configure and run it from the source tree? Sorry for the all the bother, but being new to both erlang and ejabberd the learning experience is steeper than usual.

Check the ejabberd Guide html or pdf, section "Compile".

An optimistic admin can do:
cd src
./configure --prefix=/tmp/ejabberd-test
make
make install
cd /tmp/ejabberd-test/sbin/ejabberdctl live

That worked like a

That worked like a charm....:) Thanks.

One other quick question. I have a 2.x module that I want to test against 3.x and the question is with regards to the new exmpp library XML elements. Should I switch to #xmlel or continue using #xmlelement or it does not matter?

Quite probably you have to

Quite probably you have to change to #xmlel.

Syndicate content