Description of problem: yum upgrade breaks on having incorrect version of libsecure and libssl. Version-Release number of selected component (if applicable): ejabberd.i386-1.1.4-1.fc8 How reproducible: 100% Steps to Reproduce: 1. yum upgrade 2. 3. Actual results: breaks on couple of packages being broken -- ejabberd is one of them. Expected results: it should just work Additional info:
http://koji.fedoraproject.org/koji/taskinfo?taskID=288240
Actually, although the recompile works well (with patch I'got from the upstream bug tracking database, because otherwise ejabberd doesn't compile with the newest erlang we have in Rawhide; apparently, according to folks on ejabberd.ru we are pretty wild using pretty unstable Erlang; I have to explain them that in Rawhide it is expected to have everything broken ;-)) However, when restarting compiled program ejabberd crashes: [root@hubmaier ~]# service ejabberd stop Shutting down ejabberd: [ OK ] [root@hubmaier ~]# service ejabberd start Spouštím ejabberd: [ OK ] [root@hubmaier ~]# service ejabberd status Node ejabberd@hubmaier is started. Status: started ejabberd is not running [root@hubmaier ~]# ejabberdctl ejabberd@localhost RPC failed on the node ejabberd@localhost: nodedown =ERROR REPORT==== 15-Dec-2007::00:01:29 === Error in process <0.33.0> on node 'ejabberdctl@hubmaier' with exit value: {badarg,[{erlang,list_to_existing_atom,["ejabberd@hubmaier"]},{dist_util,recv_challenge,1},{dist_util,handshake_we_started,1}]} [root@hubmaier ~]#
Created attachment 289611 [details] erl_crash.dump
Created attachment 289621 [details] sasl.log
/var/log/ejabberd/ejabberd.log is zero length
Upsteram bug https://support.process-one.net/browse/EJAB-459
from ejabberd.ru: [01:57:24] mcepl: https://support.process-one.net/browse/EJAB-459 [11:20:29] badlop: mcepl: in your logs: exception exit: {bad_return,{{ejabberd_app,start,[normal,[]]}, {'EXIT',"permission denied"}}} [11:20:39] badlop: did you investigate this? [12:42:58] mcepl: badlop: well, the question is permission to what are denied? [12:44:12] badlop: to strinpret.so or other .so files installed by ejabberd? [12:44:58] mcepl: OK, I will investigate that. [...] [17:21:34] mcepl: badlop: ping (is it enough that all files in ejabberd package are readable/executable by ejabberd user)? [17:22:41] mcepl: what is bean.smp? I guess it was broken by selinux [17:23:33] badlop: i think yes [17:23:50] badlop: beam.smp might be a beam version with support for SMP [17:24:25] badlop: beam: binary erlang architecture machine [17:24:32] badlop: or something like that [17:26:10] badlop: A is for abstract [17:26:12] mcepl: but I have permissive selinux so it shouldn't break anything [17:26:21] mcepl: oh well -- selinux is weird these days in Rawhide
Created attachment 289691 [details] correct version of erl_crash.dump
(In reply to comment #2) > Actually, although the recompile works well (with patch I'got from the upstream > bug tracking database, because otherwise ejabberd doesn't compile with the > newest erlang we have in Rawhide; apparently, according to folks on > ejabberd.ru we are pretty wild using pretty unstable Erlang; Erlang R12-0 has many advantages over last version so we'd better stay with latest one :). BTW odbc may be hardly broken too (R12-0 has some differences in odbc-realisation). Returning to subj - the main problem is selinux-related, as I understand.
I am not sure about that -- I have Selinux in permissive mode, so it shouldn't be a factor (although the current history of hal in Rawhide suggest otherwise).
note to myself -- check permissions on /etc/ejabberd/*
(In reply to comment #9) > Returning to subj - the main problem is selinux-related, as I understand. my comment 10 shouldn't mean that there is no problem with SELinux (it may just mercilessly covered by the permissive mode) and the reason why beam.smp is denied execmem is interesting one.
to comment 11: yes, permissions in /etc/ejabberd/* were helpful -- when fixed ownership to ejabberd:ejabberd to all files there and chmod to 640 the server runs and I can connect to it. to comment 9: yes, it is SELinux -- when testing with binary install from ejabberd site, everything works smoothly, but with Fedora packaged ejabberd I get: type=AVC msg=audit(1197926176.301:431): avc: denied { execmem } for pid=13101 comm="beam.smp" scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:system _r:initrc_t:s0 tclass=process type=SYSCALL msg=audit(1197926176.301:431): arch=c000003e syscall=9 per=400000 success=yes exit=1073741824 a0=0 a1=a01000 a2=7 a3=62 items=0 ppid=13100 pid=13101 auid=500 uid=498 gid=497 euid=498 suid=498 fsuid=498 egid=497 sgid=497 fsgid=497 tty=(none) comm="beam.smp" exe="/usr/lib64/erlang/erts-5.6/bin/beam.smp" subj=system_u:system_r:initrc_t:s0 key=(null) (full /var/log/audit/audit.log is going to be attached for Dan's enjoyment)
sorry, it's too late and I forgot the most important stuff -- the problems presents itself as me being not able to send a message anywhere and not able to connect to any MUC.
Is ejabberd a java application? Where is it installed? If it is a java app can you set the context to java_exec_t and does the AVC go away. chcon -t java_exec_t PATHTOAP
(In reply to comment #16) > Is ejabberd a java application? Ejabberd is in no way related to Java. It is a pure erlang-application.
Ok, I have no idea what erlang is, But it is asking for execmem privledge which is considered a potential security risk. http://people.redhat.com/~drepper/selinux-mem.html Certain languages require the ability to execute writeable memory java, mono. So we allow those apps to work, but a lot of time programs don't need it and are poorly coded. You can label the executable unconfined_execmem_exec_t and then it should work in enforcing mode. chcon -t unconfined_execmem_exec_t /usr/lib64/erlang/erts-5.6/bin/beam.smp The best solution would be to write an SELinux policy for jabberd.
(In reply to comment #16) > Is ejabberd a java application? http://en.wikipedia.org/wiki/Erlang_%28programming_language%29 [root@hubmaier ~]# rpm -qi erlang Name : erlang Relocations: (not relocatable) Version : R12B Vendor: Fedora Project Release : 0.1.fc9 Build Date: So 8. prosinec 2007, 13:05:27 CET Install Date: Út 11. prosinec 2007, 01:20:02 CET Build Host: xenbuilder1.fedora.redhat.com Group : Development/Languages Source RPM: erlang-R12B-0.1.fc9.src.rpm Size : 93239652 License: Erlang Public License Signature : (none) Packager : Fedora Project URL : http://www.erlang.org Summary : General-purpose programming language and runtime environment Description : Erlang is a general-purpose programming language and runtime environment. Erlang has built-in support for concurrency, distribution and fault tolerance. Erlang is used in several large telecommunication systems from Ericsson. [root@hubmaier ~]#
The upstream bug is now https://support.process-one.net/browse/EJAB-431 (my bug was duplicate of this one), and they blame some linking problems, which seems irrelevant to our situation. One more development -- when playing with the upstream binary installer, I managed to get our packaged ejabberd to the same state as the upstream one. So I can confirm the first half of my comment 13 -- fixing ownership of /etc/ejabberd/* makes it working. Moreover, when I limit ejabberd to using non-secure (i.e., no SSL, no TLS) connection to server, it works. So, Dan, I think you are out of the loop on this bug, but we will probably really need to work through some SELinux policy for Erlang -- if what makes Java, Mono, et al. special for SELinux is that these are interpreted languages, then Erlang is definitively in the same ballpark. Moreover, IIRC, it is language which is specifically developed for writing huge server applications, so it better be confined by SELinux. And one last nitpicking note -- jabberd (C application) is not the same as ejabberd (Erlang application), and they are not the same as jabberd2 (fork of the jabberd C application).
One more data point -- the problem goes away when 2.0.0-beta1 is used. Which means that I have two news for you -- one good and the other bad. The bad is that I am not reproduce it anymore, so this should be closed as INSUFFICIENT_DATA. The good news is that there is a package of ejabberd 2.0.0-beta1 build on Rawhide http://koji.fedoraproject.org/koji/taskinfo?taskID=310599 and it seems to work for me. Of course, I don't know when the 2.0.0 will be actually released, so I don't have any idea, whether we want to push beta version into Fedora.
Dan, this is not good -- it's OK to remove you from the bug and remove SELinux keyword if you don't want to be bothered by this (but, yes, I have still those same AVC denials, but apparently ejabberd works happily with them in Permissive mode), but I think ejabberd maintainers should decide whether to upgrade to 2.0.0 in Rawhide or not. I would love to see them to decide. Reopening.
And yes sorry my comment 21 was not clear enough about SELinux. The problem is still there, it is the same execmem, I was just so happy that it works for me that I forgot about SELinux issue (no, I am not crazy enough to run Rawhide with Enforcing mode ;-)).
ejabberd-2.0.0-0.3.rc1.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update ejabberd'. You can provide feedback for this update here: http://admin.fedoraproject.org/F8/FEDORA-2008-1042
ejabberd-2.0.0-0.3.rc1.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
ejabberd-2.0.0-0.3.rc1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.