eJabberD TLS driver error - connection
I'm trying to get an ejabberd server running to use as a real time chat in an android application.
I have installed the server using a 32bit binary and configured it to a point that I can log in using the web interface. I have issues connecting to it with a client though. The error returned by the server is an {open_error,-10}, which is supposed to be an error when trying to read the tls_drv.so file.
Some searches on the web revealed that there are people with the same issue as me but I can't seem to find a concrete solution.
This thread here http://www.ejabberd.im/node/4200 mentions the exact same problems as I'm having and the OP seemed to have fixed them using a newer version of the drivers. I don't know how or where to get those drivers though.
Can anyone here please help me fix this? Thank you.
Thanks a lot for that ldd command! It solved my issue :-D
Here's the thing: apparently tls_drv.so is looking for libssl.so.0.9.8 and libcrypto.so.0.9.8, and ejabberd includes 0.9.7. I happened to have installed libssl.so.0.9.8e and libcrypto.so.0.9.8e, which tls_drv.so couldn't find (because of the 'e'?).
What I did was creating a symbolic link to 0.9.8e, named 0.9.8. And voilĂ ! It worked!
Here's some more info:
Centos 5.5, 32 bit
ejabberd 2.1.8
I downloaded the binary installer directly from www.process-one.net (www.ejabberd.im)
I still have the default configuration, except for the hostname and the admin user, which are required by the installer.
The connection from a jabber client seems to work fine without TLS. The problem came when I configured my client to encrypt connection when available.
Here's the erlang log complaining before the fix:
=CRASH REPORT==== 12-Sep-2011::22:48:56 ===
crasher:
pid: <0.372.0>
registered_name: []
exception exit: {{case_clause,{error,{open_error,-10}}},
[{tls,tcp_to_tls,2},
{ejabberd_socket,starttls,3},
{ejabberd_c2s,wait_for_feature_request,2},
{p1_fsm,handle_msg,10},
{proc_lib,init_p,5}]}
in function p1_fsm:terminate/7
initial call: gen:init_it(p1_fsm,<0.258.0>,<0.258.0>,ejabberd_c2s,
[{ejabberd_socket,
{socket_state,gen_tcp,#Port<0.406>,
<0.371.0>}},
[inet,
{certfile,
"/opt/ejabberd-2.1.8/conf/server.pem"},
starttls,
{access,c2s},
{shaper,c2s_shaper},
{max_stanza_size,65536},
{ip,{0,0,0,0}}]],
[])
ancestors: [ejabberd_c2s_sup,ejabberd_sup,<0.36.0>]
messages: []
links: [<0.258.0>]
dictionary: [{'$internal_queue_len',0}]
trap_exit: false
status: running
heap_size: 987
stack_size: 23
reductions: 3258
neighbours:
=SUPERVISOR REPORT==== 12-Sep-2011::22:48:56 ===
Supervisor: {local,ejabberd_c2s_sup}
Context: child_terminated
Reason: {{case_clause,{error,{open_error,-10}}},
[{tls,tcp_to_tls,2},
{ejabberd_socket,starttls,3},
{ejabberd_c2s,wait_for_feature_request,2},
{p1_fsm,handle_msg,10},
{proc_lib,init_p,5}]}
Offender: [{pid,<0.372.0>},
{name,undefined},
{mfa,
{ejabberd_c2s,start_link,
[{ejabberd_socket,
{socket_state,gen_tcp,#Port<0.406>,<0.371.0>}},
[inet,
{certfile,"/opt/ejabberd-2.1.8/conf/server.pem"},
starttls,
{access,c2s},
{shaper,c2s_shaper},
{max_stanza_size,65536},
{ip,{0,0,0,0}}]]}},
{restart_type,temporary},
{shutdown,brutal_kill},
{child_type,worker}]
Here's the process to fix it:
root#mail [/opt/ejabberd-2.1.8]# find . -name tls_drv.so
./lib/ejabberd-2.1.8/priv/linux-x86/lib/tls_drv.so
root#mail [/opt/ejabberd-2.1.8]# cd lib/ejabberd-2.1.8/priv/linux-x86/lib/
root#mail [/opt/ejabberd-2.1.8/lib/ejabberd-2.1.8/priv/linux-x86/lib]# ldd tls_drv.so
linux-gate.so.1 => (0x00f9c000)
libssl.so.0.9.8 => not found
libcrypto.so.0.9.8 => not found
libc.so.6 => /lib/libc.so.6 (0x00d9c000)
/lib/ld-linux.so.2 (0x00943000)
root#mail [/lib]# cd /lib
root#mail [/lib]# ll libcrypto.so.* libssl.so.*
-rwxr-xr-x 1 root root 1296964 Mar 6 2011 libcrypto.so.0.9.8e*
lrwxrwxrwx 1 root root 14 Nov 24 2009 libcrypto.so.4 -> libcrypto.so.6*
lrwxrwxrwx 1 root root 19 Apr 26 11:06 libcrypto.so.6 -> libcrypto.so.0.9.8e*
-rwxr-xr-x 1 root root 293044 Mar 6 2011 libssl.so.0.9.8e*
lrwxrwxrwx 1 root root 11 Nov 24 2009 libssl.so.4 -> libssl.so.6*
lrwxrwxrwx 1 root root 16 Apr 26 11:06 libssl.so.6 -> libssl.so.0.9.8e*
root#mail [/lib]# ln -s libcrypto.so.0.9.8e libcrypto.so.0.9.8
root#mail [/lib]# ln -s libssl.so.0.9.8e libssl.so.0.9.8
root#mail [/lib]# cd -
/opt/ejabberd-2.1.8/lib/ejabberd-2.1.8/priv/linux-x86/lib
root#mail [/opt/ejabberd-2.1.8/lib/ejabberd-2.1.8/priv/linux-x86/lib]# ldd tls_drv.so
./tls_drv.so: /lib/libcrypto.so.0.9.8: no version information available (required by ./tls_drv.so)
./tls_drv.so: /lib/libssl.so.0.9.8: no version information available (required by ./tls_drv.so)
linux-gate.so.1 => (0x0088c000)
libssl.so.0.9.8 => /lib/libssl.so.0.9.8 (0x00110000)
libcrypto.so.0.9.8 => /lib/libcrypto.so.0.9.8 (0x00ebf000)
libc.so.6 => /lib/libc.so.6 (0x00252000)
libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x008ef000)
libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00ae0000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0x0077c000)
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00527000)
libresolv.so.2 => /lib/libresolv.so.2 (0x00158000)
libdl.so.2 => /lib/libdl.so.2 (0x0016c000)
libz.so.1 => /usr/lib/libz.so.1 (0x00a67000)
/lib/ld-linux.so.2 (0x00943000)
libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x00df3000)
libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x00e2a000)
libselinux.so.1 => /lib/libselinux.so.1 (0x008cc000)
libsepol.so.1 => /lib/libsepol.so.1 (0x00171000)
root#mail [/opt/ejabberd-2.1.8/lib/ejabberd-2.1.8/priv/linux-x86/lib]#
I restarted ejabberd, and that was it!
I really hope it helps someone else, since googling made me find a lot of people with the same issue, but not a single solution.
Regards!
maganap
Latest installer will solve this dependancy on ejabberd.
Thank you for reporting it !
Related
symfony 5.3 logfile could not be opened in append mode: Failed to open stream (docker)
I have a rotating Logfile configured with monolog, which worked like a charm and suddenly I get error messages stating that the file cannot be created, when the frontend is calling my symfony backend, which runs in a alpine docker container. Creating logfiles while running my phpunit tests is causing no trouble at all. This is my monolog configuration, which didn't change: monolog: handlers: frontend: type: rotating_file path: "%kernel.logs_dir%/%kernel.environment%.frontend.log" level: error channels: [ frontend ] max_files: 3 main: type: rotating_file path: "%kernel.logs_dir%/%kernel.environment%.log" level: debug channels: [ "!event", "!frontend", "!deprecation" ] max_files: 3 console: type: console process_psr_3_messages: false channels: [ "!event", "!doctrine", "!console", "!frontend", "!deprecation" ] What I did was disabling sessions, which should have no influence on whether the system is able to create a file for writing. Why can my server no longer write logfiles? My permissions for my log folder are increased to 777 and the server runs as "root" in it's container: e9dffe459185:/var/www/var# ll total 8 drwxrwxr-x 6 root root 192 Jul 22 15:07 ./ drwxr-xr-x 51 root root 1632 Jul 23 10:16 ../ drwxrwxr-x 4 root root 128 Jul 23 11:01 cache/ drwxrwxrwx 3 root root 96 Jul 23 11:02 log/
Looks like the problem was fixed with an update of monolog: Updating dependencies Lock file operations: 0 installs, 1 update, 0 removals - Upgrading monolog/monolog (2.3.1 => 2.3.2) Writing lock file Installing dependencies from lock file (including require-dev) Package operations: 0 installs, 1 update, 0 removals - Downloading monolog/monolog (2.3.2) - Upgrading monolog/monolog (2.3.1 => 2.3.2): Extracting archive Looks like version 2.3.1 was buggy. Since the upgrade I don't have further problems.
Run Rails with Passenger on Apache with Plesk
I have everything installed as per this tutorial: https://www.digitalocean.com/community/tutorials/how-to-setup-a-rails-4-app-with-apache-and-passenger-on-centos-6 But when I go to the website, I get an error, and in the error log it shows this: [ 2015-02-26 16:17:47.3041 28207/7f7326058780 agents/Watchdog/Main.cpp:728 ]: All Phusion Passenger agents started! [Thu Feb 26 16:17:47.305819 2015] [mpm_prefork:notice] [pid 28184] AH00163: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips mod_fcgid/2.3.9 Phusion_Passenger/4.0.59 mod_perl/2.0.9-dev Perl/v5.16.3 configured -- resuming normal operations [Thu Feb 26 16:17:47.305844 2015] [core:notice] [pid 28184] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND' [ 2015-02-26 16:22:04.7157 28225/7f2c65840840 apache2/Hooks.cpp:151 ]: A filesystem exception occured. Message: Cannot stat '/var/www/vhosts/blah.blah/httpdocs/config.ru Backtrace: in 'void Passenger::DirectoryMapper::autoDetect()' (DirectoryMapper.h:144) in 'bool Hooks::prepareRequest(request_rec*, Passenger::DirConfig*, const char*, bool)' (Hooks.cpp:374) Can anyone help? The config.ru file was auto generated by rails, and it has these lines: # This file is used by Rack-based servers to start the application. require ::File.expand_path('../config/environment', __FILE__) run BlahBlah::Application
Your problem can be related to the following things: config.ru file is not exists by the specified path Try to execute command for check this: ls -la /var/www/vhosts/blah.blah/httpdocs/config.ru Passenger doesn't have permissions to read this file Try to execute command for check this: namei -lm /var/www/vhosts/blah.blah/httpdocs/config.ru P.S. I noticed you are using shared hosting. Don't use them if you want to avoid a lot of different problems. Use VPS servers instead. Like Digital Ocean or Linode for Rails applications.
Webistrano stuck on deploy:update_code
I've been trying to set up webistrano on one of our servers. Everything went well, until I tried deploying my set up. Webistrano is currenlty set up to live on the test server, so I want it to deploy to 127.0.0.1 The configuration contains valid user, webistrano, that should have access to /home/webistrano/.subversion/servers the password for that user is correct. Could someone shed some light as to what might be going wrong with it? *** SSH options: setting ssh_port to: 22 *** LOCAL SCM ERROR: svn: warning: Can't open file '/home/webistrano/.subversion/servers': Permission denied * executing `deploy' * executing `deploy:update' ** transaction: start * executing `deploy:update_code' * executing "svn checkout -q --username webistrano --password XXXXXXXX --no-auth-cache -r27687 http://server.com/repos/server/clients/site/trunk /var/www/vhosts/server.com/releases/20121001183038 && (echo 27687 > /var/www/vhosts/server.com/releases/20121001183038/REVISION)" servers: ["127.0.0.1"] *** [deploy:update_code] rolling back * executing "rm -rf /var/www/vhosts/server.com/releases/20121001183038; true" servers: ["127.0.0.1"] ** [deploy:update_code] exception while rolling back: Capistrano::ConnectionError, connection failed for: 127.0.0.1 (Errno::EACCES: Permission denied - connect(2)) *** connection failed for: 127.0.0.1 (Errno::EACCES: Permission denied - connect(2)) debugging with puts system('id') in deployer.rb returns uid=500(webistrano) gid=500(webistrano) groups=500(webistrano) context=unconfined_u:system_r:httpd_t:s0 and ls -all /home/webistrano returns: drwxrwxr-x. 3 webistrano webistrano 4096 Sep 27 16:59 .subversion ls -all /home/webistrano/.subversion returns: drwxrwxr-x. 3 webistrano webistrano 4096 Oct 1 20:02 . drwx------. 4 webistrano webistrano 4096 Oct 1 22:14 .. drwx------. 6 webistrano webistrano 4096 Sep 27 16:59 auth -rw-rw-r--. 1 webistrano webistrano 6866 Sep 27 16:59 config -rw-rw-r--. 1 webistrano webistrano 4276 Sep 27 16:59 README.txt -rw-rw-r--. 1 webistrano webistrano 7674 Oct 1 20:02 servers Which shows that servers should be fully readable by everyone? What's going on?
It turns out this was an issue with Passenger. Phusion Passenger is supposed to run as the user who owns conf/environment.conf (which in my case was webistrano). Displaying the user id also showed webistrano, but if I changed it to run as nobody, the svn error stopped appearing. I was unable to svn export the code though, probably because nobody does not have a home directory. I ended up running webistrano through mongrel, and starting it by doing: $ su - webistrano to make sure that the correct home environment is loaded and all the permissions are correct. It works perfect now . Hope this helps somebody
Leopard => Snow Leopard architecture woes with nokogiri / rails
I'm confused. It's a regular state of affairs for me but specifically in this case I felt I could reach out to fellow stackoverflowers (that is, stackoverflow-ers, not stackover-flowers). uname -a Darwin macbookpro 10.3.0 Darwin Kernel Version 10.3.0: Fri Feb 26 11:58:09 PST 2010; root:xnu-1504.3.12~1/RELEASE_I386 i386 set bash-3.2$ set ... HOSTTYPE=x86_64 ... MACHTYPE=x86_64-apple-darwin10.0 ... I'm having a nightmare rebuilding some native ruby gems and I'm wondering whether this is part of the problem -- part of this machine says its 64 bit but another part 32 ... as far as I can tell? Under 'About this Mac' it says 'Intel Core 2 Duo' which Apple says is 64 bit. So why, after doing sudo gem pristine --all am I still getting this kind of error? dlopen(/Applications/Rails/ruby/lib/ruby/gems/1.8/gems/nokogiri-1.4.2/lib/nokogiri/nokogiri.bundle, 9): no suitable image found. Did find: /Applications/Rails/ruby/lib/ruby/gems/1.8/gems/nokogiri-1.4.2/lib/nokogiri/nokogiri.bundle: mach-o, but wrong architecture - /Applications/Rails/ruby/lib/ruby/gems/1.8/gems/nokogiri-1.4.2/lib/nokogiri/nokogiri.bundle Specifically I had removed nokogiri and reinstalled it. No errors in output. bash-3.2$ sudo gem install nokogiri Building native extensions. This could take a while... Successfully installed nokogiri-1.4.2 1 gem installed thanks for any thoughts! UPDATE I've found a useful post by Chris Noos on a similar problem. This is where I am: cd /usr/local/lib/ruby/gems/1.8/gems/nokogiri-1.4.2/ then made a file called wem_extconf.rb: require 'mkmf' find_library('xml2', 'xmlParseDoc') dir_config('any-string-here', '/opt/local/include', '/opt/local/lib') find_library('xml2', 'xmlParseDoc') Running sudo web_extconf.rb produces checking for xmlParseDoc() in -lxml2... no checking for xmlParseDoc() in -lxml2... no ???? But hang on, it is there: $ port installed | grep libxml2.*active libxml2 #2.7.7_0+universal (active) $ ls -l /opt/local/lib | grep libxml2 -rwxr-xr-x 2 root admin 2623276 31 May 20:09 libxml2.2.dylib -rw-r--r-- 2 root admin 3643928 31 May 20:09 libxml2.a lrwxr-xr-x 1 root admin 15 31 May 20:09 libxml2.dylib -> libxml2.2.dylib -rwxr-xr-x 2 root admin 975 31 May 20:09 libxml2.la And it does appear I have several copies of the thing -- but not sure which one port installed is using (I'm assuming given it's macports, it's /opt?) $ ls -l /usr/lib | grep libxml2 lrwxr-xr-x 1 root wheel 15 23 May 16:07 libxml2.2.7.3.dylib -> libxml2.2.dylib -rwxr-xr-x 1 root wheel 3758272 22 Sep 2009 libxml2.2.dylib lrwxr-xr-x 1 root wheel 15 23 May 16:07 libxml2.dylib -> libxml2.2.dylib $ ls -l /usr/local/lib | grep libxml2 -rwxr-xr-x 1 root admin 1456292 30 Oct 2009 libxml2.2.dylib -rw-r--r-- 1 root admin 4812456 30 Oct 2009 libxml2.a -rwxr-xr-x 1 root admin 1456292 30 Oct 2009 libxml2.dylib -rwxr-xr-x 1 root admin 951 30 Oct 2009 libxml2.la
On Snow Leopard, gcc has a misleading behavior; even if you are running a i386 kernel, gcc will produce 64 bits binaries by default. Have you looked at the GEM documentation to see how to specify the targeted architecture ?
Have you installed the XCode Development tools?
Passenger/mod_rails fails to initialize in Fedora 12 when starting Apache
I am in the process of setting up a server to run a Ruby on Rails application on Fedora 12, using Passenger. I am at the stage where I've installed Passenger, set it up as prescribed, but get the following errors when I restart Apache: [Wed Jan 13 15:41:38 2010] [notice] caught SIGTERM, shutting down [Wed Jan 13 15:41:40 2010] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0 [Wed Jan 13 15:41:40 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Wed Jan 13 15:41:40 2010] [error] *** Passenger could not be initialized because of this error: Cannot create FIFO file /tmp/passenger.25235/.guard: Permission denied (13) [Wed Jan 13 15:41:40 2010] [notice] Digest: generating secret for digest authentication ... [Wed Jan 13 15:41:40 2010] [notice] Digest: done [Wed Jan 13 15:41:40 2010] [error] *** Passenger could not be initialized because of this error: Cannot create FIFO file /tmp/passenger.25235/.guard: Permission denied (13) [Wed Jan 13 15:41:40 2010] [error] python_init: Python version mismatch, expected '2.6', found '2.6.2'. [Wed Jan 13 15:41:40 2010] [error] python_init: Python executable found '/usr/bin/python'. [Wed Jan 13 15:41:40 2010] [error] python_init: Python path being used '/usr/lib/python26.zip:/usr/lib/python2.6/:/usr/lib/python2.6/plat-linux2:/usr/lib/python2.6/lib-tk:/usr/lib/python2.6/lib-old:/usr/lib/python2.6/lib-dynload'. [Wed Jan 13 15:41:40 2010] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads. [Wed Jan 13 15:41:40 2010] [notice] mod_python: using mutex_directory /tmp [Wed Jan 13 15:41:40 2010] [notice] Apache/2.2.14 (Unix) DAV/2 Phusion_Passenger/2.2.9 PHP/5.3.0 mod_python/3.3.1 Python/2.6.2 mod_ssl/2.2.14 OpenSSL/1.0.0-fips-beta3 mod_perl/2.0.4 Perl/v5.10.0 configured -- resuming normal operations As you can see, there is a permissions problem when Passenger is trying to initialize: [Wed Jan 13 15:41:40 2010] [error] *** Passenger could not be initialized because of this error: Cannot create FIFO file /tmp/passenger.25235/.guard: Permission denied (13) When Apache is starts, it does create a file in /tmp: d-ws--x--x. 2 root root 4096 2010-01-13 16:04 passenger.26117 If instead I run the app by firing up mongrel directly with mongrel_rails start -e production, I see the following: ActiveRecord::StatementInvalid (Mysql::Error: Can't create/write to file '/tmp/#sql_5d3_0.MYI' (Errcode: 13): SHOW FIELDS FROM `users`): Again the error points to permission issues with the /tmp directory. I am at a loss as to what the solution is. I'm not sure if it is related to simply directory permissions or Fedora's SELinux security. Any help would be appreciated. Thanks.
I did the same as Fred, except that instead of doing it one error at a time: Go into permissive mode by running setenforce 0 Restart apache, and hit your site and use it for a while as normal Run grep httpd /var/log/audit/audit.log | audit2allow -M passenger semodule -i passenger.pp Go back to enforcing mode by running setenforce 1 Restart apache and test your site - hopefully it should all be working as before! Note that this is basically a specific example of the procedure on the Centos SELinux help - check it out.
I'm having the same issue in CentOS 5.4, SELinux getting in the way of Passenger. Setting PassengerTempDir to /var/run/passenger simply gives you the same permission errors in the new directory instead of /tmp : [Mon Feb 22 11:42:40 2010] [error] *** Passenger could not be initialized because of this error: Cannot create directory '/var/run/passenger/passenger.3686' I can then change the security context of /var/run/passenger to get past this error: chcon -R -h -t httpd_sys_content_t /var/run/passenger/ ...and that lets Passenger create the temp directory, but not files within that directory: [Mon Feb 22 12:07:06 2010] [error] *** Passenger could not be initialized because of this error: Cannot create FIFO file /var/run/passenger/passenger.3686/.guard: Permission denied (13) Oddly, re-running the recursive chcon again doesn't get past this error, it keeps dying at this point, and this is where my SELinux knowledge gets murky. The Phusion Passenger guide sections 6.3.5 and 6.3.7 have some useful thoughts, but they don't seem to completely resolve the problem.
You need more than just the httpd_sys_content_t permission. I use the following technique to get things started: start a tail on the audit log: tail -f /var/log/audit/audit.log reload apache: apachectl restart Go to the /tmp/directory: cd /tmp If just 1 line is added use the command: tail -1 /var/log/audit/audit.log | audit2allow -M httpdfifo Note that the name 'httpdfifo' is just a name chosen to reflect the kind of error that has been observed. This will create a file named 'httpdfifo.pp'. To allow apache to create a FIFO from here on after you have to issue the command: semodule -i httpdfifo.pp Continue to do this until all audit errors have been resolved (It took 4 different kind of permissions on my system running Centos 5.4)
Running setenforce 0 before starting will let you test if it's SELinux. Don't forget to run setenforce 1 afterwards.
I tried what Dan Sketcher and Fred Appleman suggested, i.e. repeat the following: yum install setroubleshoot echo > /var/log/audit/audit.log # clear irrelevant errors cd ~ service httpd restart # try booting passenger -- audit.log now shows the relevant permission errors tail -f /var/log/httpd/error_log # check that passenger is still failing due to permission errors sealert -a /var/log/audit/audit.log > selinux-diag.txt # translate the permission errors # read and check that you are happy with selinux-diag.txt # and either follow its specific advice, or if it just wants you to grep into audit2allow, then: cat /var/log/audit/audit.log | audit2allow -M mypol # grant everything just denied semodule -i mypol.p # commit new permissions But after doing this 5 or 6 times, I kept coming up against new errors, and some of the same errors came up even after I had tried to permit them with "audit2allow". In the end I just turned off SELinux, with: echo 0 >/selinux/enforce