ejabberd

Re: dynamicaly set loglevel on running ejabberd

Mailing list - Thu, 2015-11-19 07:56
* Gerhard Schmidt <schmidt< at >ze.tum.de> [2015-11-19 07:58]: You can now use the 'ejabberd_logger' module, instead: ejabberd_logger:set(3). With 15.09 and newer there's also an ejabberdctl command: ejabberdctl set_loglevel 3 Holger
Categories: ejabberd

dynamicaly set loglevel on running ejabberd

Mailing list - Thu, 2015-11-19 05:58
Hi, I'm upgraded my ejabber server from 2.x to 15.07. on my old server i could change loglevel without restarting th ejabberd with ejabberdctl debug Erlang/OTP 18 [erts-7.1] [source] [64-bit] [smp:8:8] [async-threads:10] [kernel-poll:true] Eshell V7.1 (abort with ^G) (ejabberd< at >delphi.ze.tum.de)1> ejabberd_loglevel:set(3). But since the update to 15.07 i get the following errormessage. ** exception error: undefined function ejabberd_loglevel:set/1 I found a mail that states that i have to load the ejabberd_loglevel module. How do I do this. Regards Estartu
Categories: ejabberd

Re: STUN/TURN server - receiving error messages

Mailing list - Tue, 2015-11-17 10:49
Tue, 17 Nov 2015 20:24:37 +0900 Mark Brown <markb< at >lowsnr.net> wrote: I think the problem is that 'stun' command is outdated and doesn't support RFC 5389, because 'ChangeRequest' is only defined in RFC 3489 (which is obsoleted and doesn't support TURN).
Categories: ejabberd

STUN/TURN server - receiving error messages

Mailing list - Tue, 2015-11-17 10:24
I'm attempting to configure the ejabberd TURN server over TCP (TURNS). For testing, I'm using the 'stun' client on Linux. However, when I carry out a test, I get an error message: Bad length string 15 problem parsing ServerName The log is as follows: $ stun xmpp.lowsnr.net -v STUN client version 0.96 Opened port 22719 with fd 3 Opened port 22720 with fd 4 Encoding stun message: Encoding ChangeRequest: 0 About to send msg of len 28 to 183.181.58.166:3478 Encoding stun message: Encoding ChangeRequest: 4 About to send msg of len 28 to 183.181.58.166:3478 Encoding stun message: Encoding ChangeRequest: 2 About to send msg of len 28 to 183.181.58.166:3478 Received stun message: 76 bytes Bad length string 15 problem parsing ServerName Received message of type 273 id=1 Encoding stun message: Encoding ChangeRequest: 4 About to send msg of len 28 to 183.181.58.166:3478 Encoding stun message: Encoding ChangeRequest: 2 About to send msg of len 28 to 183.181.58.166:3478 Received stun message: 76 bytes Bad length string 15 problem parsing ServerName Received message of type 273 id=2 Received stun message: 76 bytes Bad length string 15 problem parsing ServerName Received message of type 273 id=3 Received stun message: 76 bytes Bad length string 15 problem parsing ServerName Received message of type 273 id=2 Received stun message: 76 bytes Bad length string 15 problem parsing ServerName Received message of type 273 id=3 test I = 1 test II = 1 test III = 1 test I(2) = 0 is nat = 0 mapped IP same = 1 hairpin = 0 preserver port = 0 Primary: Open Return value is 0x000010 _______________________________________________ ejabberd mailing list ejabberd< at >jabber.ru http://lists.jabber.ru/mailman/listinfo/ejabberd
Categories: ejabberd

Re: Stun authentication with ejabberd and ldap

Mailing list - Mon, 2015-11-16 20:51
Hi, Well, Jitsi supports it. But then again, Jitsi development (the real Jitsi) is in maintenance mode and Jitsi is not a reference for a decent client anymore. Another "solution" I came up with for the meantime would involve netfilter and conntrack on the server. Given that the XMPP server closes connections after a timeout if they don't authenticate, one could use anonymous auth in the turn module and have the firewall only allow UDP on the TURN port range for clients that happen to have an alive XMPP connection as well. One would have to make up something to make the return path work, but maybe conntrack could also track where the TURN server sends data to and allow that host back in. That is very unclean, but should help against most abuse cases, while keeping compatibility high. Disclaimer: If someone proposed this solution to me, I'd honestly tell them to go away ;). -nik
Categories: ejabberd

Re: Stun authentication with ejabberd and ldap

Mailing list - Mon, 2015-11-16 19:55
* Hoshpak <mailinglist< at >pozimski.eu> [2015-11-16 18:48]: There's no other established NAT traversal mechanism. Jitsi might be using another server for STUN, but I'm not aware of public TURN servers. Plain STUN will do the trick for some NAT environments, but in other cases, it won't work without TURN relaying. I guess there's no client support so far, though? Holger
Categories: ejabberd

Re: Stun authentication with ejabberd and ldap

Mailing list - Mon, 2015-11-16 16:48
Am 15.11.2015 um 23:42 schrieb Holger Weiß: Thanks for the explanation. Since I want to avoid having clear text passwords on the server at any time, I'm going to disable STUN/TURN for now and gain some experience without it. At least jitsi seems to do fine without it, it probably uses some other NAT traversal mechanism or another server instead. It would be nice if someone could add a few words about the authentication mechanism support for STUN/TURN to the ejabberd documentation some time. It seems that there might be another way to deal with the issue as described in XEP-0215 which seems to gain support in prosody as mod_extdisco and mod_turncredentials but not available in the free version of ejabberd (yet). If it becomes available in some future version, I'd certainly like to try it. Helmut
Categories: ejabberd

Re: Stun authentication with ejabberd and ldap

Mailing list - Mon, 2015-11-16 11:25
Hi, ah, OK, sorry! I thought it'd cache a password read in cleartext from a backend. -nik
Categories: ejabberd

Re: Stun authentication with ejabberd and ldap

Mailing list - Mon, 2015-11-16 10:59
* Dominik George <nik< at >naturalnet.de> [2015-11-16 12:48]: Yes, that's pretty much what I suggested above. The "extauth_cache" feature provides such a plain text cache, the problem is that it can currently only be used with "auth_method: external". Holger
Categories: ejabberd

Re: Stun authentication with ejabberd and ldap

Mailing list - Mon, 2015-11-16 10:48
Hi, THinking of it… This could be a solution for having hashed passwords in LDAP and still having working STUN authentication. What if ejabberd stored the cleartext password the client sends on XMPP authentication in memory (in a more or less secure manner), and mod_stun used this cache as source for plaintext passwords? This way, the first XMPP login could use secure SSHA passwords in LDAP, and all modules needing auth afterwards would have a plaintext copy, provided jsut by the fact the client sent it once and it was validated. Cheers, Nik
Categories: ejabberd

Re: Stun authentication with ejabberd and ldap

Mailing list - Sun, 2015-11-15 21:55
Just for the record: * Holger Weiß <holger< at >zedat.fu-berlin.de> [2015-11-15 23:42]: SQL or Riak authentication will do the trick as well (if plain text passwords are stored), of course. Holger
Categories: ejabberd

Re: Stun authentication with ejabberd and ldap

Mailing list - Sun, 2015-11-15 21:42
* Hoshpak <mailinglist< at >pozimski.eu> [2015-11-14 12:49]: Unrelated to your question, but you probably also wanted to set tls: true for this last listener. Right. There's currently two ways to support STUN authentication: Either with "auth_method: internal" and "auth_password_format: plain", or with "auth_method: external" and the "extauth_cache" feature. So you *could* use an external script for LDAP authentication¹ and have ejabberd cache the passwords, they will then be used for STUN authentication. A nicer solution would be to teach the built-in LDAP code (and other authentication backends) to optionally cache plain text passwords, but the current code doesn't support this. Holger ¹ E.g., <https://www.ejabberd.im/check_pass_ldap_perl>.
Categories: ejabberd

Stun authentication with ejabberd and ldap

Mailing list - Sat, 2015-11-14 10:49
Hi everyone, currently I am using ejabberd 14.07 (from the Debian repository) on Debian jessie and configured it to use LDAP as the authentication method. This generally works great, except for stun/turn which I tried to configure to offer NAT traversal for connected clients. The relevant part of my configuration currently looks as follows: - port: 3478 transport: udp use_turn: true turn_ip: "$IP" auth_realm: "$REALM" module: ejabberd_stun - port: 3478 transport: tcp use_turn: true turn_ip: "$IP" auth_realm: "$REALM" module: ejabberd_stun - port: 5349 module: ejabberd_stun transport: tcp use_turn: true turn_ip: "$IP" auth_realm: "$REALM" certfile: "/etc/ejabberd/ejabberd.pem" The "auth_realm" is set to the same as the main and only vhost configured which uses the LDAP authentication. If someone tries to access the STUN service, I get the following error message in my log file: 2015-11-10 18:24:43.805 [info] <0.440.0> failed long-term STUN authentication for $USER< at >$DOMAIN from $IP:$PORT. The only hit I got for this error message is the following post in the ejabberd forums: https://www.ejabberd.im/node/24717 If I understand the post right, the issue with STUN authentication is that it requires building a hashed version of the password and sending it to the server. The server would then have to hash the password itself to compare it with the received hash. That of course would require the clear text password to be saved somewhere on the server which is not the case since my LDAP back end stores the passwords hashed and salted. Does anyone here have experience with STUN authentication using a LDAP server? Is there any way to make this work without requiring clear text passwords to be stored on the server? Greetings Helmut
Categories: ejabberd

Re: ejabberd 15.10: mod_http_upload not found

Mailing list - Fri, 2015-11-13 18:23
That is logged every time you start ejabberd? It appears that it was logged when you uninstalled the module. So it shouldn't appear anymore, and is unrelated to the problem. Let's play with your config and logs: First: If you attempt to start a module that does not exist, like this: mod_http_uploadddddd: {} then do you get an error like this? 20:17:38.569 [critical] Problem starting the module mod_http_uploadddddd for host <<"localhost">> options: [] error: undef [{mod_http_uploadddddd,start,[<<"localhost">>,[]],[]}, {gen_mod,start_module,3,[{file,"src/gen_mod.erl"},{line,98}]}, {lists,foreach,2,[{file,"lists.erl"},{line,1336}]}, {ejabberd_app,start,2,[{file,"src/ejabberd_app.erl"},{line,74}]}, {application_master,start_it_old,4, [{file,"application_master.erl"},{line,272}]}] 20:17:38.569 [critical] ejabberd initialization was aborted because a module start failed. Crash dump was written to: //var/log/ejabberd/erl_crash_20151113-201732.dump Problem starting the module mod_http_uploadddddd for host <<"localhost">> options: [] error: undef [{mod_http_uploadddddd,start,[<<"localhost">>,[]],[]}, {gen_mod,start_module,3,[{file,"src/gen_m Second: If you enable the module with proper name, and accept default options, like this: mod_http_upload: {} then does it show in the service discovery? Third: Does it appear in the list of running modules in WebAdmin -> Hosts -> your host -> Nodes -> your node -> Modules ? --- Badlop ProcessOne
Categories: ejabberd

ejabberd 15.10: mod_http_upload not found

Mailing list - Fri, 2015-11-13 12:13
Hi everyone, I updated from ejabberd 15.09 to ejabberd 15.10 because I saw that the module supporting XEP-0363 (mod_http_upload) is now bundled with ejabberd itself[1]. Previously it was only available via the community repository[2]. So I chcked out the latest version of ejabberd from Git, removed my previous installation except for the etc and lib directories and recompiled and reinstalled the new version on my Debian Jessie system. I then started ejabberd and remove the mod_http_upload community module by executing $ ejabberdctl module_uninstall mod_http_upload ok which correctly removed ~/.ejabberd-modules/mod_http_upload. Since this was my only contribution module in use, I then commented out the `allow_contrib_modules` option in my ejabberd.yml file and restarted ejabberd. However, if I now want to start ejabberd it logs this: -------------------- 2015-11-13 12:28:58.081 [error] <0.606.0>< at >gen_mod:stop_module_keep_config:136 {{badmatch,{error,not_found}},[{mod_http_upload,stop,1,[{file,"src/mod_http_upload.erl"},{line,144}]},{gen_mod,stop_module_keep_config,2,[{file,"src/gen_mod.erl"},{line,135}]},{gen_mod,stop_module,2,[{file,"src/gen_mod.erl"},{line,127}]},{ext_mod,'-uninstall/1-lc$^0/1-0-',2,[{file,"src/ext_mod.erl"},{line,186}]},{ext_mod,uninstall,1,[{file,"src/ext_mod.erl"},{line,186}]},{ejabberd_commands,execute_command2,2,[{file,"src/ejabberd_commands.erl"},{line,378}]},{ejabberd_ctl,call_command,3,[{file,"src/ejabberd_ctl.erl"},{line,292}]},{ejabberd_ctl,try_call_command,3,[{file,"src/ejabberd_ctl.erl"},{line,268}]}]} -------------------- Neither it announces the service in the service discovery anymore, at least according to my XMPP client (Gajim). The module is there: -------------------- $ find lib -iname '*http_upload*' lib/ejabberd/ebin/mod_http_upload_quota.beam lib/ejabberd/ebin/mod_http_upload.beam -------------------- Here’s the relevant part of my ejabberd.yml: -------------------- # ... listen: # ... - port: 5444 module: ejabberd_http request_handlers: "": mod_http_upload # Enable HTTPS tls: true tls_compression: false protocol_options: - "no_sslv2" - "no_sslv3" # - "no_tlsv1" dhfile: "/usr/local/etc/ejabberd/dh2048.pem" certfile: "/tmp/phtest/ph.all.pem" ciphers: "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA" # ... access: # ... soft_upload_quota: all: 80 hard_upload_quota: all: 100 # ... modules: # ... mod_http_upload: host: "upload.< at >HOST< at >" docroot: "/home/ejabberd/uploads" access: local # Maximum file size 8 MiB max_size: 8388608 secret_length: 40 file_mode: "0644" dir_mode: "0755" put_url: "https://upload.mydomain.local:5444" mod_http_upload_quota: max_days: 14 access_hard_quota: hard_upload_quota access_soft_quota: soft_upload_quota -------------------- Probably I overlooked something obvious, but I’m fairly new to ejabberd still, so please bear with me :-). Any hints are appreciated. Greetings Marvin [1]: http://lists.jabber.ru/pipermail/ejabberd/2015-October/008848.html [2]: https://github.com/processone/ejabberd-contrib/tree/master/mod_http_upload _______________________________________________ ejabberd mailing list ejabberd< at >jabber.ru http://lists.jabber.ru/mailman/listinfo/ejabberd
Categories: ejabberd
Syndicate content