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
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 https://github.com/erlang/otp
You can download the tar.gz from erlang.org or git from
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
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.
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.