[prosody-dev] [ANN] Prosody 0.9.2 released!
We are pleased to announce Prosody 0.9.2, the latest release of our stable 0.9 branch. The main focus of this release is on a couple of security improvements. A summary of changes in this release: * Debian/Ubuntu packages fixed to always generate per-system certs * TLS: Improved cipher string, and use Prosody's preferred ciphers * MUC: Fix for Spark clients not displaying room lists More information can be found in the release announcement on our blog: http://blog.prosody.im/prosody-0-9-2-released/ Download information can be found at https://prosody.im/download Happy Jabbering! The Prosody Team -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/groups/opt_out.
Re: [prosody-dev] [ANN] Prosody 0.9.2 released!
Hi Lonnie, On 7 January 2014 18:51, Lonnie Abelbeck wrote: > Hi Matthew, > > I built 0.9.2 and see the certs get generated. Of course we remove them > anyway. > > Question, what is your reason for generating certs vs. let developers/users > handle that outside of prosody ? Aren't you still setting-up the risk of > private keys getting distributed ? Hmm, right - it's possible that packages could still generate certificates at build time, and distribute binary packages containing these certificates. The correct thing for packages to do is to pass --no-example-certs to ./configure now (I've just documented this at https://prosody.im/doc/packagers#section09 ). There is a balance to strike, and it's a tough one. I can't immediately see a way to automatically prevent packagers from making this mistake, except by removing all forms of automatic cert generation, which would inconvenience users building from source. Perhaps now we have prosodyctl able to generate certificates, this isn't terrible. More thought required. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/groups/opt_out.
Re: [prosody-dev] Manipulating Messages Sent to Server
Hi Victor, On 22 January 2014 14:49, Victor wrote: > Hello all, > > I am looking for the option to route messages send to server, like this: > > from='northumberl...@shakespeare.lit' > to='royalty.england.lit'> > My lord, dispatch; read o'er these articles. > If you are writing a module this is very easy. You simply have to catch the event "message/host". You can see an example module at: http://prosody.im/doc/developers/modules (just change "message/bare" to "message/host"). You can read more about events at https://prosody.im/doc/developers/events Hope this helps! Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/groups/opt_out.
Re: [prosody-dev] mod_smacks leaking plaintext messages to log
Hi Nik, On 29 January 2014 10:02, Dominik George wrote: > Hi, > > mod_smacks leaks all stanzas that remain unacked after the timeout to > Prosody's log file by emitting them with loglevel warn. Heh, yes. This is debugging code left over from the original version of mod_smacks. Though I still wouldn't consider mod_smacks quite production-ready yet, I'd say we're probably past needing this code here. I've removed it and pushed to prosody-modules. Thanks for bringing it to my attention! Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/groups/opt_out.
Re: [prosody-dev] conference.prosody.im down?
On 13 March 2014 08:14, Twattle.net wrote: > Hi guys, > > is conference.prosody.im down? > > I cannot connect from twattle.net and the webchat does not work either. Your message was marked as spam and held for moderation for a while, sorry. Are you still having trouble connecting? The server is up, but you may have had some connectivity problems over the past week as we have been dealing with a DoS attack against our site. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Error when using with OpenSSL without ECDH
Hi Artur,
Sorry for the delay in replying, I've only just realised I've had this
draft open for nearly 4 days already.
On 16 March 2014 20:31, Artur Bekasov wrote:
> Hello prosody developers,
>
> I've faced a slight problem when trying to use Prosody with SSL.
>
> I have following in the global part of my prosody.cfg.lua:
>
> ssl = {
> key = ".../ssl.key";
> certificate = ".../ssl.crt";
> }
>
>
> When I try to start the server, it gives a few lines of this:
>
> SSL/TLS: Error initialising for ...: OpenSSL does not support ECDH
>
> Of course, I could just enable ECDH, but unfortunately it is not a trivial
> task on my distribution (it's EC2 Amazon Linux) - you need to build it from
> sources with some flag set, which sounds like a potential source of even
> more problems.
Right, RedHat and derived distributions have it disabled in OpenSSL
over patent fears: https://bugzilla.redhat.com/show_bug.cgi?id=319901
> I've tried installing the current master of prosody and got the same
> results.
I don't see an easy way for us to detect whether OpenSSL supports it
or not (but we've been discussing for a while the need for LuaSec to
be able to report capabilities to us).
> So what do you think about it, guys? Am I doing something wrong, or this
> should be fixed? I'll be more than happy to fix it myself and pull-request,
> if we agree on how this should be dealt with. I am not very good with all
> that SSL terminology, but is it required to have curve set to something even
> if we don't intend to use ECDH?
I'm not sure yet what the best solution is, though I lean towards it
being taken care of by packagers. It could for example be allowing you
to set curve = false to remove a dependency on ECDH. This doesn't
currently work, but arguably it should.
Later on we could make it automatic if LuaSec adds an API for detecting this.
Regards,
Matthew
--
You received this message because you are subscribed to the Google Groups
"prosody-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to prosody-dev+unsubscr...@googlegroups.com.
To post to this group, send email to prosody-dev@googlegroups.com.
Visit this group at http://groups.google.com/group/prosody-dev.
For more options, visit https://groups.google.com/d/optout.
[prosody-dev] [ANN] Prosody 0.9.4 released
Hi folks, We're pleased to present Prosody 0.9.4, the latest release from our stable 0.9 branch. This release fixes a security (denial of service) issue. If you are using mod_compression then we strongly recommended that you upgrade as soon as possible or disable compression (it is disabled by default) to prevent potential resource consumption by untrusted users. A summary of changes in this release: - Compression: Disallow compression on unauthenticated streams - Core: Limit default read size and maximum stanza size - Core: Enable SASL EXTERNAL by default for component s2s - S2S: Warn if `s2s_secure_auth` and `s2s_require_encryption` have been set in conflicting ways - S2S: Warn if no local network addresses were found, preventing successful s2s - MUC: Fix traceback when a non-occupant tried to change an occupant's role - MUC: API: Fire an event when temporary rooms are destroyed after the last person leaves - Telnet: Fixed traceback when listing users - Telnet: Apply normalization to JIDs in user management commands - HTTP: Fix directory detection in file server on Windows - Plugins: Fix paths on Windows - MOTD: Don't strip blank lines from the message provided in the config - prosodyctl: Better error reporting when generating certificates - Makefile: Improve FreeBSD compatibility - Multiple fixes to our migration tools, and support for importing MUCs from ejabberd Download instructions for all platforms can be found on our download page: https://prosody.im/download If you have any questions, comments or other issues with this release, let us know - https://prosody.im/discuss Happy Jabbering, The Prosody Team -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Help with setting up Prosody
Hi Michael, On 3 April 2014 18:36, Michael Cabus wrote: > I setup Prosody, and have a local connection manager setup through Prosody: > It never connects; however, if I swap out the local connection manager with > an external one, it connects with jabber accounts. > > If I could prosody to work with converse.js, life would be great. > > Any clues why this might not be working? The easiest way to debug is using the browser's debugging tool's 'Network' tab. Check to see that all requests are successful (200 OK), and if they are, look at the contents of the response of the last couple of requests. Usually they will tell you what the error was. Hope this helps. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
[prosody-dev] Security notice: the OpenSSL 'heartbleed' bug
Today a serious security vulnerability in the popular encryption library OpenSSL was publicly announced. This issue affects all software using OpenSSL, including Prosody. The bug allows external attackers to read the memory of any process using OpenSSL, by connecting to it and sending specially crafted packets. In Prosody's case this puts at risk lots of data, including (but not limited to) passwords, messages, and your certificate's key file used to protect SSL/TLS traffic. Our advice is to upgrade OpenSSL immediately, Debian, Ubuntu and many other distributions already have fixes available. On Debian/Ubuntu run: sudo apt-get update sudo apt-get upgrade sudo service prosody restart Don't forget to restart any other services you have as well that use OpenSSL, such as your web server or mail server. Alternatively you may simply reboot to ensure all services are restarted. More generic information on the issue can be found at http://heartbleed.com/ I'll try and finish off with some good news: - if your client used the more advanced SCRAM-SHA-1 mechanism to authenticate to Prosody and you use hashed password storage, your password is probably safe (it would take considerable targeted effort to recover) - if you used OTR or some other end-to-end encryption mechanism with your contacts, your message contents are probably safe - if you used TLS ciphers with forward secrecy then generally your encrypted traffic could not easily be decrypted even if your certificate's key file was compromised (though individual connections active around the time of an attack could still be compromised) - the flaw in OpenSSL has existed for around two years, but we cannot know for sure that it has actually been exploited by anyone Further reading: Information and FAQ: http://heartbleed.com/ OpenSSL advisory: http://www.openssl.org/news/secadv_20140407.txt Debian advisory: http://www.debian.org/security/2014/dsa-2896 Ubuntu advisory: http://www.ubuntu.com/usn/usn-2165-1/ -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Re: mod_bosh crashing with latest compile from mercurial
Hi Peter, On 10 May 2014 18:58, Peter Villeneuve wrote: > Any idea when the MUC issues will be resolved and pushed to trunk? I just pushed a fix, it should be in the next nightly build (ready about 6am UTC). Sorry for the delay and thanks for the report. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Re: mod_bosh crashing with latest compile from mercurial
On 11 May 2014 15:36, Peter Villeneuve wrote: > Hi Matthew, > > Is it available yet? I can't seem to find it. Really sorry Peter, for some unknown reason the commit hadn't successfully pushed. I've done so now, and the builds should be done in a few hours. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Re: mod_bosh crashing with latest compile from mercurial
On 12 May 2014 13:19, Peter Villeneuve wrote: > No worries. Thanks for your effort. > By the way, it seems that prosody.im is down. Yes, sorry - system crash, it should be back shortly (within in an hour). Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Re: mod_bosh crashing with latest compile from mercurial
On 12 May 2014 13:28, Peter Villeneuve wrote: > No problem. By the way, I noticed the other days that recent builds weren't > available for Wheezy but only Jessie and others. > Is this latest one available for Wheezy amd64 too? It should be available for all unless the builds fail for some reason. I'll check when the server comes back up. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] BOSH returns 404
Hi,
On 5 July 2014 00:26, Hugo Osvaldo Barrera wrote:
> Hi,
>
> I'm trying to set bosh without success.
Thanks for the details. One key bit of info missing: what version of
Prosody are you using?
> bosh_ports = { 5280 }
Probably best to drop this line. 5280 is the default, and bosh_ports
has been removed from 0.9+.
> When testing this locally:
>
> # curl -I localhost:5280/http-bind
> HTTP/1.1 404 Not Found
> Connection: Keep-Alive
> Content-Length: 369
> Date: Fri, 04 Jul 2014 23:06:25 GMT
> # curl localhost:5280/http-bind
>
> It works! Now point your BOSH client to this URL to connect to
> Prosody.
> For more information see href="http://prosody.im/doc/setting_up_bosh";>Prosody: Setting up BOSH.
>
> # curl xmpp.barrera.io/http-bind
>
>
> charset="utf-8">body{margin-top:14%;text-align:center;background-color:#F8F8F8;font-family:sans-serif;}h1{font-size:xx-large;}p{font-size:x-large;}p+p
> { font-size: large; font-family: courier }
>
> 404 Not FoundWhatever you were looking for is not here.
> It's behind you.Unknown host: xmpp.barrera.io
>
>
> My nginx config is LITERALLY a copy-paste from
> https://prosody.im/doc/setting_up_bosh
>
> Looking at pidgin's log, it gets the same 404 message I via curl
> xmpp.barrera.io/http-bind.
> I've also tried setting xmpp.barrera.io.
Sounds like you're using Prosody 0.9. Prosody 0.8 totally ignored the
HTTP host, which simplified setup but led to some unintuitive
behaviour and limitations. In Prosody 0.9 you need to make sure to
tell Prosody about what HTTP host you will be using (if it isn't the
same as an XMPP host in your config).
I'm going to guess that your XMPP host is "barrera.io", and Prosody is
running at "xmpp.barrera.io". This is a common setup, and the fix is
easy. Under your "barrera.io" host in Prosody's config, just tell it
what HTTP host to expect:
VirtualHost "barrera.io"
...options here
http_host = "xmpp.barrera.io" -- HTTP requests will be addressed to here
> After looking at the error a bit, I tried some guessing and changed and
> changed nginx to:
>
> location / {
> proxy_passhttp://localhost:5280/http-bind;
> proxy_set_header Host "localhost";
> proxy_buffering off;
> tcp_nodelay on;
> }
>
> (notice the change in Host). Why did I need this? Has anyone else had similar
> experiences?
This worked because you probably have "localhost" as a VirtualHost in
your config. This would also have worked (and be more correct):
proxy_set_header Host "barrera.io";
If you prefer you can do this *instead* of setting http_host in
Prosody's config. The only advantage to configuring it in Prosody is
that you can then easily serve multiple HTTP hosts (which may or may
not be useful to you).
> After this change, curl http://xmpp.barrera.io/ works as expected. Pidgin
> manages to connect but with absolutely no encryption. If I enable HTTPS,
> it fails. If I require encryption on the client or server side (or both),
> it fails too.
https://xmpp.barrera.io/ seems to work for me (in my browser), so I
don't know what the problem might be here. Check Pidgin's debug logs
perhaps (Help->Debug).
Regards,
Matthew
--
You received this message because you are subscribed to the Google Groups
"prosody-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to prosody-dev+unsubscr...@googlegroups.com.
To post to this group, send email to prosody-dev@googlegroups.com.
Visit this group at http://groups.google.com/group/prosody-dev.
For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Problems using libevent on FreeBSD
Hi Theo, On 9 September 2014 07:45, Theodor-Iulian Ciobanu wrote: > Hello, > > I've recently moved from CentOS to FreeBSD and am having issues > starting prosody with use_libevent=true. I'm using luajit-2.0.3 (same > behavior with lua5.1 though), libevent2-2.0.21_2 and master of luaevent > (there isn't a port for it, so I thought of going with the latest if > I'm compiling it anyway). I know of an issue with FreeBSD + libevent that occurs when Prosody is set to daemonize itself, however I thought that issue manifested itself differently. Could you try daemonize = false in (the global section of) your config file, and see if this is that same issue? Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Problems using libevent on FreeBSD
On 9 September 2014 23:04, Theodor-Iulian Ciobanu wrote: > On Tue, 9 Sep 2014 08:18:01 +0100 > Matthew Wild wrote: > >> Hi Theo, >> >> On 9 September 2014 07:45, Theodor-Iulian Ciobanu >> wrote: >> > Hello, >> > >> > I've recently moved from CentOS to FreeBSD and am having issues >> > starting prosody with use_libevent=true. I'm using luajit-2.0.3 >> > (same behavior with lua5.1 though), libevent2-2.0.21_2 and master >> > of luaevent (there isn't a port for it, so I thought of going with >> > the latest if I'm compiling it anyway). >> >> I know of an issue with FreeBSD + libevent that occurs when Prosody is >> set to daemonize itself, however I thought that issue manifested >> itself differently. Could you try daemonize = false in (the global >> section of) your config file, and see if this is that same issue? > > As almost always the case in such events, as soon as I hit Send on my > previous mail I found this workaround as well: > > http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2014-April/275346.html > > And by setting daemonize=false and having the rc script take care of it > instead I was able to start prosody. Ok, thanks for the confirmation! > My next question would be if this is an issue with lib/luaevent on fbsd > (though I was able to run the luaevent client+server test successfully) or > with prosody itself, because I'd be more than happy to help debug and fix > this if the latter case. I tried adding more debug info to server_event.lua > to check if there was a silent failure when registering events, but that > didn't seem the case; and it's also where my knowledge of libevent sort of > stops, so I don't know where to go to next. It's a problem with kqueue and the way Prosody starts. Prosody initializes its networking before it loads any modules. The code that daemonizes is in mod_posix, so it runs after networking has been initialized. Unfortunately when daemonizing, kqueue doesn't carry its state across to the new process. The workaround for this on the Prosody side would be to daemonize before doing absolutely anything else. It sort of makes sense, even if we lose a bit of flexibility, so I'm considering this for a future version. I don't know if there is anything that can be done in libevent to work around this, I haven't checked since originally investigating the issue. Other backends (e.g. epoll) work fine. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] [ANN] Prosody 0.9.5 released!
On 9 October 2014 20:40, Lonnie Abelbeck wrote: > > On Oct 9, 2014, at 7:32 AM, Kim Alvefur wrote: > >> Hi everyone, >> >> We are pleased to announce Prosody 0.9.5, the latest release of our >> stable 0.9 branch. This release brings a bunch of fixes and smaller >> improvements. > > I'm having a problem with 0.9.5 and loading 's2s' and 'adhoc'. The paths are > not correct... > > I'm seeing errors: > -- > Oct 09 14:15:52 modulemanager error Unable to load module 's2s': > /usr/lib/prosody/modules/mod_s2s.lua: No such file or directory > Oct 09 14:15:52 modulemanager error Unable to load module 'adhoc': > /usr/lib/prosody/modules/mod_adhoc.lua: No such file or directory > -- > which are not the correct installed paths for adhoc/ and mod_s2s/ : > -- > drwxr-xr--1 root root80 Oct 9 08:43 adhoc > -rw-r--r--1 root root 31524 Oct 9 08:43 mod_admin_adhoc.lua > --snip-- > -rw-r--r--1 root root 5789 Oct 9 08:43 mod_roster.lua > drwxr-xr--1 root root80 Oct 9 08:43 mod_s2s > -rw-r--r--1 root root 10636 Oct 9 08:43 mod_saslauth.lua > -- Strange. After downgrading to 0.9.4, are these permissions still the same? Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
[prosody-dev] [ANN] Prosody 0.9.6 released!
Hi folks, We are pleased to announce Prosody 0.9.6, the latest release of our stable 0.9 branch. This is mainly a bug fix release, with security and interoperability implications. Note: This release disables SSLv3 by default, which has been shown to be insecure when used by clients. Clients that only support SSLv3 will no longer be able to connect. There are not many of these nowadays, but they exist. A summary of changes in this release: * certmanager, net.http: Disable SSLv3 by default * net.http.parser: Support status code 101 and allow handling of the received data by plugins * util.filters: Ignore filters being added twice (fixes issues on removal, i.e. when some plugins are reloaded/unloaded) * mod_s2s: Close offending s2s streams missing an 'id' attribute with a stream error instead of throwing an unhandled error * Networking API: Add 'ondetach' callback for listener objects, to prevent leaks when connections have their listener changed * core.stanza_router: Stricter validation of stanzas * mod_admin_adhoc: Mark 'accountjids' field as required in 'end user sessions' command (thanks Lloyd) * mod_admin_adhoc: Add required to field in user deletion form too * net.dns: Avoid duplicate cache entries * util.stanza: Escape newlines and tabs (\r\n\t) when serializing stanzas. * util/dataforms: Make sure we iterate over field tags only * mod_s2s: Capitalize log message * mod_pubsub: Fix error type of 'forbidden' (change from 'cancel' to 'auth') More information can be found in the release notes: https://prosody.im/doc/release/0.9.6 Download information can be found at https://prosody.im/download -- Happy Jabbering, The Prosody Team -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
[prosody-dev] [ANN] Prosody 0.9.7 released
Hello everyone, We are pleased to announce a new minor release from our stable branch. This release has just a couple of changes for you: * Fix server-to-server interoperability issue with Isode M-Link (since 0.9.6) * Fix traceback in 'prosodyctl about' command with LuaRocks 2.2.0+ installed Also, this is our first release with an official Docker image. More on that soon! # Download As usual, download instructions for many platforms can be found on our download page: https://prosody.im/download If you have any questions, comments or other issues with this release, let us know! https://prosody.im/discuss -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Re: managing groups in mysql
On 16 January 2015 at 18:24, justin chaise wrote: > this is an old post, but still i will comment. I ran into this myself and a > quick answer would have been nice. > > mysql sees the field named key as a reserved word. At the mysql commandline > i enclosed the field name key with backticks `key`. > I was then able to add my users via the command line. Ah, thanks Justin! I ran into a very similar issue myself yesterday because 'user' is a reserved word in PostgreSQL. There you have to use double quotes around the field names instead. SQL is such fun :) Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] message archiving & requesting message history
On 19 January 2015 at 04:07, wrote: > Thanks for the reply! > > Using the latest stanza.io (with urn:xmpp:mam:0) and prosody nightly: > > server:version() > | OK: 0.10 nightly build 104 (2015-01-16, 3426e903c48d) > > when I query history (or history prefs, same results): > > from='1...@myhost.com/e116abea-a672-49cb-81ae-2138d647b9cc'> queryid='31fc3501-da34-4936-addb-0f47c587d624' xmlns='urn:xmpp:mam:0'> xmlns='jabber:x:data' type='submit'> var='FORM_TYPE'>urn:xmpp:mam:0 > > I keep getting unhandled stanza in the logs: > > Unhandled c2s stanza: iq; xmlns=urn:xmpp:mam:0 Puzzling. After some thought I think the most likely explanation is that you have an older version of mod_mam, make sure you update your prosody-modules repo to the latest code. If that isn't the cause, maybe post some more debug logs or pop into the chatroom to dig into the issue further. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
[prosody-dev] FOSDEM
Hi folks, Just a quick note for anyone at FOSDEM who wants to meet up - I'll be in the "Realtime Lounge" all afternoon today. It's on the second floor of the K building, tucked in a corner at the top of the stairs. Look out for the XMPP-controlled lights :) Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Character Set Issue with MySQL and Prosody (other than cyrilic)
Hi, On 12 February 2015 at 14:35, TSM wrote: > Hey All, > > this issue is similar to > https://code.google.com/p/lxmppd/issues/detail?id=268, only it happens with > Hebrew, This is the same as issue 268. It will be fixed in 0.10. Note that the data is actually stored correctly, it just looks wrong when viewed by any application other than Prosody. As long as only Prosody writes to the database, there is no invalid data and everything will still function fine. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Key/value table defined in configuration
Hi Nicolás,
On 20 February 2015 at 06:59, Nicolás wrote:
> Hi,
>
> I'm trying to define a key/value table in the configuration file, like this:
>
> a = {
>["key"] = "value"
> }
>
> However, seems that inside the plugin function, at retrieve time via
> module:get_option_set('a', '{}') it retrieves an empty table. However, if I
> just define a value instead of key/value, the table is retrieved correctly.
You should use just module:get_option() for that kind of table.
module:get_option_set() is for lists of unique values.
Also, in the config you do not need to use the ["key"] syntax unless
you have special characters in the key name. For example, this is the
same as your example:
a = {
key = "value"
}
Hope this helps!
Regards,
Matthew
--
You received this message because you are subscribed to the Google Groups
"prosody-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to prosody-dev+unsubscr...@googlegroups.com.
To post to this group, send email to prosody-dev@googlegroups.com.
Visit this group at http://groups.google.com/group/prosody-dev.
For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Problems adding vCard to support for email forwarding on v.10
On 20 March 2015 at 00:56, Simon Hill wrote:
> I promise to get better at Lua and Prosody - currently I am a noob and ask a
> lot of stupid questions. Here's my question:
>
> I am trying to add vCard support to mod_offline_email. Zash kindly
> suggested:
>
>> local vcards = module:open_store("vcard");
>> -- in a hook
>> local vcard = vcards:get(username);
>
>
>>
>> local email = vcards:get_child_text("EMAIL");
This should be vcard:get_child_text() - vcards is the data store,
vcard is the user's vcard.
You might also need to deserialize the stanza object before you can
use it though. Run it through st.deserialize():
local vcard = st.deserialize(vcards:get(username));
Finally, although what you are doing seems like an obvious feature to
add, and quite simple, I have always refrained from adding it to
mod_offline_email. This is because the user's email address in the
vcard is not verified, they could put anybody's address there. This
would allow your server to be used as an open XMPP->email relay. It's
fine if your vcards are locked down to verified details and can't be
modified directly by the user though.
Regards,
Matthew
--
You received this message because you are subscribed to the Google Groups
"prosody-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to prosody-dev+unsubscr...@googlegroups.com.
To post to this group, send email to prosody-dev@googlegroups.com.
Visit this group at http://groups.google.com/group/prosody-dev.
For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] prosody v.0.10 docker does not log to logspout
On 20 March 2015 at 21:25, Simon Hill wrote: > I'm trying to use https://github.com/gliderlabs/logspout to siphon remote > prosody docker logs to Paper Trail. I have the config > > "*console"; -- Log to the console, useful for debugging with daemonize=false > > > For some unknown reason, logspout doesn't pick this up. I have a couple of > other containers running on this device, which capture fine. so I think it > has something to do with prosody. > > Is there anything I can do to fix that? Try setting the environment variable __FLUSH_LOG=1 before Prosody starts. Does it help? Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] User-level sharding
Hi Rob, On 20 March 2015 at 05:54, Robert Norris wrote: > What I want to do is distribute users for a single domain across multiple > Prosody instances while having them look like a single server on the > outside. The reasons for this are partly to do with load - I'm preparing for > a time where there are thousands of users online - but also to fit neatly > into our existing infrastructure, where we spread email users across > multiple servers. I like the idea of mirroring our email architecture and > doing redundancy the same way. Makes sense. > Note that I'm expressly not talking about real live clustering, where a > server can fail and the user remains connected. A Prosody instance (or its > underlying machine) can fail and the sessions will be disconnected. That's > totally fine with me - most clients will quietly reconnect without issue. Agreed. I should note that for our initial clustering implementation we're not aiming for live migration of users between nodes either, I don't think many people need this feature compared to the number of people who just want availability and load balancing. > It seems that all that's necessary to make this happen is to hook into the > stanza delivery code. If we have a session for a user on the current server, > we deliver it to them. If not, we do a lookup (via an external daemon) to > see where the "home" server for the user is. If we find one, we pass the > stanza over to that server and let it deliver it. If not, we continue as > normal. Yes, this is the right approach. > So I have a very rough prototype in this three plugins: > > https://github.com/robn/prosody/blob/shard/plugins/mod_shard.lua > https://github.com/robn/prosody/blob/shard/plugins/mod_shard_client.lua > https://github.com/robn/prosody/blob/shard/plugins/mod_shard_server.lua I understand the code is rough, so I haven't really "reviewed" it - but you're definitely going in the right direction. Comments below... > I'm assuming a very controlled environment here - secure networks (no auth > required between shards), a user->shard lookup daemon, common storage and > auth and a proxy that can get incoming user connections to the right shard > (in my case that's nginx-xmpp). I'm expecting s2s to be covered by a par of > Prosody instances that accept stanzas and pass them to the right shard. I > should be able to run multiple of those because they're basically stateless. Right, what we can and can't assume drastically affects the complexity of clustering, so this is where things get interesting. Auth between nodes: easily done, but fine if you don't need it. The shard lookup daemon. This would be a problem with the current design. XMPP requires in-order processing and delivery of stanzas. If you have to delay a stanza based on a call to an out-of-process third-party, you're going to lose this unless you block the whole session until you receive the result. There isn't currently a way to do this in Prosody 0.9 (but there is in 0.10, with the async work). Alternatively you could assign users to shards based on a hash or some other means that can be determined immediately without an external lookup. If you wanted to get fancy you could use "consistent hashing" to minimize disruption when adding/removing nodes to the cluster. For the s2s nodes, make sure you set dialback_secret to some secret static string (the same on both nodes). > So that's the whole description. Hopefully it all made sense! What I'm > looking for is some feedback on whether the way I've implemented this makes > sense (half-arsed prototype code notwithstanding) and any thoughts about > what user-visible differences in XMPP it might present (stanza delivery > order comes to mind). And any other thoughts you might have! Hopefully the above is a good start. There are some other things to consider if you haven't already. For example, off the top of my head... what shard will be responsible for offline users? Various things happen with offline users, including handling roster state changes (e.g. in response to subscription authorization) and the storage of offline messages. If every user has a fixed "home" shard, this is easy enough to handle. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
[prosody-dev] [ANN] Prosody 0.9.8 released
Hello everyone, We're happy to announce a new minor release from our stable branch, 0.9.8. This release contains mainly bug fixes, including an important security fix. A summary of changes in this release: High: * Ensure only valid UTF-8 is passed to libidn. It was found (CVE-2015-2059: http://seclists.org/oss-sec/2015/q1/672) that libidn can read beyond the boundaries of the provided buffer when an input string contains invalid UTF-8 sequences. Systems where Prosody is compiled to use libICU are not affected by this issue. Medium: * DNS: Fix traceback caused when DNS server IP is unroutable (issue 473: https://prosody.im/bugs/473) * HTTP client: More robust handling of chunked encoding across packet boundaries * Stanza router: Fix handling of 'error' 's with multiple children Minor: * c2s: Fix error reply when clients try to bind multiple resources on the same stream (issue 484: https://prosody.im/bugs/484) * s2s: Ensure to/from attributes are always present on stream headers, even if empty (issue 468: https://prosody.im/bugs/468) * Build scripts: Add --libdir option to ./configure to simplify building on some platforms * Fix traceback in datamanager when used outside of Prosody (e.g. in some migration tools) * mod_admin_telnet: Fix potential traceback in server:memory() command (issue 471: https://prosody.im/bugs/471) * HTTP server: Improved debug logging # Download As usual, download instructions for many platforms can be found on our download page: https://prosody.im/download If you have any questions, comments or other issues with this release, let us know! https://prosody.im/discuss -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Prosody 0.10 nightly build 118 - no changes?
Hi, On 27 March 2015 at 17:56, deoren wrote: > Hi, > > I noticed that there is a new build for Prosody 0.10, but the "Changes since > previous build" section is empty. I pulled down the tarball for each release > and found a prosody.release file inside noting which revision the tarball > was based off of. Summary: I made a mess of merging the branches the other day, so build 117 had some regressions. Zash attempted to fix it with a couple of new merges, which resulted in build 118 - but the nightly page doesn't list merge commits (because they're not supposed to actually make any changes). It's still not right though, so I'm going to re-do the merges now and they'll land in build 119. Sorry for the confusion! > I pulled down the 0.10 branch and ran a diff against the two revisions like > so: > > user@testbox:/tmp/prosody-0.10$ hg diff -r 03a43bf3ecd2:61b6a4fc65f1 > > and got back this output: > [...] > I'm a complete newbie at Mercurial, so I could have gotten myself mixed up. > Is that the proper way to determine what changed between two nightlies? Yes, it is. Maybe we could add this output and a diffstat to the build nightly build page too :) Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] how to add new modules
On 28 March 2015 at 14:47, zinwa lin wrote: > If i dev new modules or get third-party module, how to add them to prosody? > does it need to rebuild prosody? No, see https://prosody.im/doc/installing_modules Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Prosody 0.10 nightly build 118 - no changes?
On 28 March 2015 at 19:33, deoren wrote: > On 3/27/2015 3:23 PM, Matthew Wild wrote: >> Summary: I made a mess of merging the branches the other day, so build >> 117 had some regressions. Zash attempted to fix it with a couple of >> new merges, which resulted in build 118 - but the nightly page doesn't >> list merge commits (because they're not supposed to actually make any >> changes). >> >> It's still not right though, so I'm going to re-do the merges now and >> they'll land in build 119. Sorry for the confusion! > > Thanks for explaining that. However when you say: > >> because they're not supposed to actually make any changes > > Are you saying that individual commits which change something are > reported as changes for a build, but if you were to report merge commits > you would end up reporting the same change twice (once when it was > actually made and then again when merging into a branch)? > > I think I get what you're saying. I took a look at the "branch" docs for > Mercurial and I see that it's a lot more complex than I thought (SVN > background). I also came from an SVN background, and Mercurial made perfect sense to me when it 'clicked'. Git though still hasn't clicked for me unfortunately (though that might be more of a difference in the UI layer... the underlying models are very similar). Anyway, the point of a merge is that user A made commit A, and user B made commit B at the same time. So you have to introduce a third commit, C, which is the correct combination of both commits. Sometimes the system can't automatically merge the two commits because they 'conflict' - i.e. they made different changes to the same part of the code. This can happen when we have revamped some code in a newer branch, but then make a change in the old branch. When we try to merge the two (which we do to keep bug fixes in sync across all branches), Mercurial can't apply the change to the new code automatically - hence the need for a manual merge. But the merge commit is supposed to be a combination of A + B, it's not supposed to be an actual change in itself. That's why we don't list them in the list of changes. Merge commits with no other changes don't usually happen - it only happened here because we got the manual merge wrong a couple of times :) Some links: - http://hginit.com/00.html - http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Hope this helps! Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Scaling Prosody
Hi Simon, On 9 April 2015 at 00:27, Simon Hill wrote: > Hi guys, > > What's the overview on scaling prosody? Lua is fast, prosody is lightweight, > and you guys are awesome, but apart from that I know little about what to > expect as more concurrent users get added. I'm expecting to have to support > hundreds of simultaneous connections and tens of thousands of JIDs. For those numbers there's really not much to do. The most important thing is just make sure you're using libevent ( https://prosody.im/doc/libevent ). You can confirm by Prosody's log message at startup, which should say "Prosody is using the epoll backend for connection handling" (on Linux). For public servers it's also a good idea to enable mod_limits (from prosody-modules), make sure mod_privacy and mod_compression are disabled (they are disabled by default), and enable mod_muc_limits too if you have public chatrooms. But there's no trick to it, Prosody will easily serve hundreds (and well into the thousands) on any reasonable server without you having to pay much attention to it. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Submitting new third party modules
Hi Rob, On 29 April 2015 at 02:48, Rob Hoelz wrote: > Hi everyone, > > With the pending shutdown of Google Code, I have noticed that > prosody-modules has moved to hg.prosody.im. What is the way for developers > to submit new modules for Prosody going forward? Will some developers be > granted push access to hg.prosody.im, or should we go with the "create a > clone and send a mail with a link" model? For now, please continue to push to Google Code as before. The shutdown is some months away yet, and we'll announce the plan for moving forward soon. The prosody-modules on hg.prosody.im is a read-only mirror, and we've had that for a long time (before the announcement from Google). If you want to clone the repository to a server, it's fine to use this (and then you won't have to change it later). > Assuming the latter for now, I have created a copy of the prosody-modules > repository at https://bitbucket.org/hoelzro/prosody-modules, with a small > module I wrote for setting Prosody's process name (mod_proctitle), if anyone > is interested in such a module. Oh, that's really nice. We've had an open issue about that for a looong time: https://prosody.im/bugs/89 Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] introduction and commit access
Hi Michael, Sorry for the delay in processing your message, it got held up in the mailing list moderation queue. On 29 April 2015 at 15:45, Michael Hendricks wrote: > I'd like to request commit access to the prosody-modules repository. I have > a new module (for sending webhooks based on XMPP messages) and some patches > to existing modules that I'd like to share. Added. Sounds like an interesting module :) Take a moment to read the developer guidelines at https://code.google.com/p/prosody-modules/ and let us know if you have any issues/questions. > By the way, thanks for Prosody. It's really been great to work with and has > been a good introduction to Lua for me too. Thanks! I'm glad :) Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] error in loggingmanager.lua
On 5 May 2015 at 07:34, Chris Tian wrote: > I'm using prosody trunk from 2015-04-26 and the following error in the logs: > > May 05 08:30:45 c2s208e290 info Authenticated as u...@domain.de > May 05 08:30:46 May 05 08:30:46 c2s150aad0 error Traceback[c2s]: > ...art/.toast/armed/lib/prosody/core/loggingmanager.lua:262: bad argument #3 > to 'format' (string expected, got nil) > stack traceback: > [C]: in function 'format' > ...art/.toast/armed/lib/prosody/core/loggingmanager.lua:262: in function '?' > ...art/.toast/armed/lib/prosody/util/logger.lua:48: in function > <...art/.toast/armed/lib/prosody/util/logger.lua:46> > (tail call): ? > (tail call): ? > ...cept_subscriptions/mod_auto_accept_subscriptions.lua:10: in function > 'handle_inbound_subscription_request' Thanks. It's an issue in mod_auto_accept_subscriptions. However I'm a bit suspicious about what caused it. Are you trying to add yourself to your contact list or something? I've pushed a fix for this error, let me know if any more come up. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] error in loggingmanager.lua
On 6 May 2015 at 16:13, Chris Tian wrote: > Thanks a lot. This fix solved that problem. Yes, you're right. I've added > myself to my roster for testing some things. Great to hear. About adding yourself to your roster - this is not actually possible. You automatically receive your own presence anyway, so it does not really help with anything (except maybe client UI issues...). Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Scaling Prosody
Hi, On 25 May 2015 at 22:11, shail.narayan wrote: > Hi Matthew > > one quick question, I read in another thread that there was some work going > on in the scaling part. > so if we really need to load balance across multiple servers, is it possible > with Prosody as of now. > Any tutorial/doc you can point me to will be great too. This is correct. It's possible, but the thread you were reading is probably the most documentation on the approach. This is because the best way to scale depends very much on your application, its design and requirements. > another option I read was that we can shard the users over multiple servers > each server handling a sub-domain. > considering I have control over the client completely, can we easily have > one user on on server talking to another > user on another server easily and hence achieve horizontal scaling? Yes, this is exactly what I mean by that approach. > Pardon me english and knowledge of Prosody as I am quite new to it (just > started looking at it a month ago) No worries. Welcome :) Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] prosody-modules migration to github
Hi Guilhem, On 28 May 2015 at 15:52, Guilhem Lettron wrote: > Hi everyone, > > As you should know, code.google.com shutdown pretty soon. > I begin to work on a migration to github. > I also use this migration to split all modules in their own repository. > > You can find the resulting work here https://github.com/prosody-modules > I manage to keep all history for all modules. I see you put some effort into this, and if it helps someone, that's great! However I just want to make it clear that this move is not an official move of the project. I set up prosody-modules as a place for people to collaborate openly, experiment with cool ideas, - an open playground. So I have always tried to have minimal "control" over it, aside from allowing new contributors access when they asked (I have never said no). Also we have never made promises to review code in prosody-modules, nor allow expectations of code quality, support, etc. for all the modules in it, as it is not "official" code. However I intend, for now, to continue having one single repository where people can easily pull all modules from. This does not mean people cannot develop and host modules on Github (or elsewhere), it is just an issue of discovery for users (there are currently a few nice Prosody modules on Github that not many people know about, because of this issue). In the long term, we are working on a new section of the site where all core and community modules and their documentation can be found, regardless of where they are hosted or distributed. But until that is ready, I am not clear what advantages having these modules on Github brings. Google Code is still working fine, and my contributions will continue there right now. Just my thoughts. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] prosody-modules migration to github
On 29 May 2015 at 04:38, Hugo Osvaldo Barrera wrote: > On 2015-05-28 14:52, Guilhem Lettron wrote: >> Hi everyone, >> >> As you should know, code.google.com shutdown pretty soon. >> I begin to work on a migration to github. >> I also use this migration to split all modules in their own repository. >> >> You can find the resulting work here https://github.com/prosody-modules >> I manage to keep all history for all modules. >> >> I'm open to any suggestion and don't hesitate to ping me for being able to >> push on it :) >> >> Thanks, >> >> Guilhem Lettron >> > > I'm getting a strange deja-vú that I've already posted this, but there's no > evidence supporting this, so: > > I just wanted to chime in and mention GitLab. It's a very mature open source > GitHub clone. Seeing as how prosody is FLOSS, I'm assuming that the author(s) > (and many users) care about this sort of thing. We do, thanks. However the issue still remains that we don't use git. Is the expectation for the Prosody core team to move the project to a VCS system that none of them like? I fail to see how that will help us feel happier or to be more productive. > For open source projects, there's free hosting[1], or you can host it yourself > (I don't think there's interest in this for prosody). There's also some > companies that set up a private instance for those interested, but I don't > think that makes any sense here. We currently host (almost) everything ourselves, and intend to continue doing so. The only things we don't host ourselves is 1) our issue tracker, because Google Code's is one of the best I've ever used, and 2) prosody-modules... because I wanted that to be clearly separated from the main project, and have more of a community playground aspect to it. And please let's *not* start debating what the best issue tracker is :) We've done our homework, believe me. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] prosody-modules migration to github
On 29 May 2015 at 09:52, Victor Seva wrote: > On 05/29/2015 10:04 AM, Goffi wrote: >> G'day, >> >> As a recent modules developer, I just want to say that I'm totally >> against a github move: I have no account there and will not have. > > You don't need a github account to contribute. It is easier if you have, > but you can always send patches by email > and amend them easily wit git. > >> Of course project manage its code the way it wants, but please let the >> ability for people to contribute without github account, the way as it >> is possible today without google account. > > A will point a thread about github on Debian devel mailing list [0] > >> Oh, and I'm really happy with hg... > > Glad to hear but lets face it git is more widely use. I'm not picking on you, it's just your post was the most recent one to bring up the popularity of git. I'm not interested in spending our time and resources moving the project to whatever VCS and hosting platform is currently trending. Back when Prosody started, Github was less than 6 months old, and most people would have had no clue what it was. Git was not especially popular back then either. The package 'git' on Debian didn't even install the VCS, but some unrelated GNU utility. I've been developing software long enough to know that things rise and fall. Today it's Github, tomorrow... something else. We're going to stay working with what we're happy and comfortable with. If there are firm technical reasons to move, fine, but there aren't. I know some projects that have moved VCS three times in three years, and that's nothing but disruptive. Finally, on the issue of contributions. Firstly I know of projects that have moved to Github and had almost no extra contributions. It's not a magic wand. Secondly, I think if someone is actually serious about contributing, our choice of VCS will not stop them. So called "drive-by" contributions are not the kind of thing I'm interested in for our core project. I appreciate everyone putting their thoughts forward here, but the graveyards of the internet are littered with this kind of thread. Everyone has their personal preferences, and sadly we can't satisfy all of them all of the time. I personally don't have anything more to say on the matter, so unless someone has something substantially new to contribute I'd recommend we just let this thread go. If you still feel like you need to change our minds about something, or if you have any questions, we're always available to email directly at develop...@prosody.im without having to drag hundreds of other people into the debate. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] [prosody-users] Anyone run into issues with Prosody after libssl update for Ubuntu 14.04?
On 3 June 2015 at 19:40, deoren wrote: > On 6/3/2015 1:39 PM, deoren wrote: >> >> I installed these packages (previous, new): >> >> libssl-dev:amd64 (1.0.1f-1ubuntu2.11, 1.0.1f-1ubuntu2.12) >> libssl-doc:amd64 (1.0.1f-1ubuntu2.11, 1.0.1f-1ubuntu2.12) >> libssl1.0.0:amd64 (1.0.1f-1ubuntu2.11, 1.0.1f-1ubuntu2.12) >> openssl:amd64 (1.0.1f-1ubuntu2.11, 1.0.1f-1ubuntu2.12) > > > >> Sample log messages for a connection attempt: >> >> Jun 2 18:52:12 grunt prosody[1243]: c2se8fbb0: Client connected >> Jun 2 18:52:12 grunt prosody[1243]: c2se8fbb0: Stream encrypted (TLSv1.2 >> with ECDHE-RSA-AES256-SHA) >> Jun 2 18:52:12 grunt prosody[1243]: c2se8fbb0: No SASL mechanisms to >> offer >> Jun 2 18:52:12 grunt prosody[1243]: c2se8fbb0: Client disconnected: >> closed >> >> I've not modified any of the default encryption settings for Prosody. To >> work around this I downgraded the package (thankfully I had an older copy of >> the package on another server that had not yet been upgraded) and restarted >> Prosody. > > > >> These are the ciphers which were disabled via the OpenSSL library update: >> >> EXP-DES-CBC-SHA >> EXP-EDH-DSS-DES-CBC-SHA >> EXP-EDH-RSA-DES-CBC-SHA >> EXP-RC2-CBC-MD5 >> EXP-RC4-MD5 >> >> If nobody else is having trouble I suspect that I'm doing something odd. >> > > One thing I thought of is that perhaps Dovecot (I'm using the auth module > for it) could be the problem here. I'll look into that and report back. Ah, worth chasing. Your issue is pretty strange. TLS is working at the XMPP level, it's just authentication failing. But I doubt it's a problem with the communication between Prosody and Dovecot, as it either uses unix sockets or plain TCP, SSL is not involved. Debug logs might help. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Seeking your assistance - Prosody-0.9.8 not starting.
Hi Susheel, The problem is simple... Prosody requires Lua version 5.1. Lua 5.2 and 5.3 introduce major changes that Prosody 0.9.x is not compatible with. Regards, Matthew On 12 June 2015 at 21:57, Susheel Jalali wrote: > Dear Prosody Developers, > > Our installation of Prosody-0.9.8 is not starting. We compiled it from > source in the following environment. When we type prosodyctl start, it > gives the error. What are we missing? > > · Any dependencies? > > · Or ordering of modules in events.lua? > > > > Error > > /usr/local/lua-5.3.0/bin/lua: > /usr/local/lib/prosody-0.9.8/prosody/util/events.lua:16: attempt to call a > nil value (global 'module') > > stack traceback: > >/usr/local/lib/prosody-0.9.8/prosody/util/events.lua:16: in main > chunk > >[C]: in function 'require' > >/usr/local/bin/prosodyctl:49: in main chunk > > [C]: in ? > > > > > > Environment: CentOS 7, Lua 5.3 (compiled from source) > > Dependencies installed: (installed from EPEL) > > lua-socket 3.0.0 > > lua-sec 0.5.4 > > lua-expat 1.3.0 > > lua-filesystem 1.6.2 > > lua-dbi 0.5.11 > > Lua-devel 5.1.4 > libevent-2.0.21 and its -devel. > > > > -- > > Regards, > > Susheel Jalali > > Customer Operations Leader, > > Coscend Communications Solutions > > susheel.jal...@coscendcommunications.com > > Web site: www.CoscendCommunications.com > > -- > > CONFIDENTIALITY NOTICE: See 'Confidentiality Notice Regarding E-mail > Messages from Coscend Communications Solutions' posted at: > http://www.CoscendCommunications.com/Terms_and_Conditions.html > > > > -- > You received this message because you are subscribed to the Google Groups > "prosody-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to prosody-dev+unsubscr...@googlegroups.com. > To post to this group, send email to prosody-dev@googlegroups.com. > Visit this group at http://groups.google.com/group/prosody-dev. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] is it lua 5.1 really required for Prosody .9.8?
Hi Ben, Lua 5.2 has major changes that are not backwards-compatible with Lua 5.1. In particular for example, the module() function was removed which Prosody uses in almost every file in the project :) We're working on 5.2 support for future releases, but the 0.9.x series will remain compatible with 5.1 only. This also keeps us compatible with LuaJIT, which is primarily 5.1-based and doesn't support some of Lua 5.2's features (yet?). Regards, Matthew On 13 August 2015 at 23:16, wrote: > I working through installing Prosody and I really like it so far. I have a > set-up that seems to be installed but when I try launch prosody I receive > the message that I have lua 5.2 installed and lua 5.1 is required. > My question is can I just the ./confiugre to use 5.2 and see what happens? > > The system is already running a pre-reales os x 10.11 and Xcode-beta so I'm > not risking stability. > > Thanks, > > Ben > > -- > You received this message because you are subscribed to the Google Groups > "prosody-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to prosody-dev+unsubscr...@googlegroups.com. > To post to this group, send email to prosody-dev@googlegroups.com. > Visit this group at http://groups.google.com/group/prosody-dev. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] is it lua 5.1 really required for Prosody .9.8?
On 14 August 2015 at 12:39, wrote: > > > > On Friday, August 14, 2015 at 6:32:49 AM UTC-4, Matthew Wild wrote: >> >> Hi Ben, >> >> Lua 5.2 has major changes that are not backwards-compatible with Lua >> 5.1. In particular for example, the module() function was removed >> which Prosody uses in almost every file in the project :) >> >> We're working on 5.2 support for future releases, but the 0.9.x series >> will remain compatible with 5.1 only. > > > Is there a branch available that is compatible ? > > Currently build repeatability is a higher priority then stability. Only our 'timber' branch, which is definitely not stable, as it is a playground for various experiments: https://hg.prosody.im/timber And by unstable I don't mean it's likely to crash, though you might experience errors or even incorrect behaviour (messages being routed incorrectly). But if you use it and find any issues, please let us know! >> This also keeps us compatible >> with LuaJIT, which is primarily 5.1-based and doesn't support some of > > > The LuaJit in macports is version 2.0.4 is that what I should be targeting? Any current version of LuaJIT should work with 0.9.x, as they are all 5.1-compatible. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] is it lua 5.1 really required for Prosody .9.8?
On 14 August 2015 at 16:57, wrote: > I have downloaded the timber trunk and I'm working through getting it build. > currently it's failing with this linker error. Which I isolated to util-src > Makefile. > > slim# pwd > /Users/Shared/prosody/timber-trunk/util-src > slim# make > MACOSX_DEPLOYMENT_TARGET="10.3"; export MACOSX_DEPLOYMENT_TARGET; > gcc -o encodings.so encodings.o -bundle -undefined dynamic_lookup -lidn > ld: library not found for -lidn > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > make: *** [encodings.so] Error 1 > > I have been using the paths of my macports lua installation with the intent > that I will turn the manual installation into a macports portfile for at > least my own local use. > Any ideas appreciated. I'm not an OS X user, but this error indicates that you do not have (or the linker cannot find) the libidn library, which is one of Prosody's build dependencies: https://prosody.im/doc/installing_from_source#dependencies Hope this helps a bit. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] is it lua 5.1 really required for Prosody .9.8?
On 14 August 2015 at 20:02, wrote: > My question is now focused on what configure args should I use to get timber > to use lua version 5.2. ./configure --runwith=lua5.2 Change 'lua5.2' to whatever the path is to your Lua 5.2 interpreter. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] is it lua 5.1 really required for Prosody .9.8?
Hi Ben, On 14 August 2015 at 21:35, wrote: > > > On Friday, August 14, 2015 at 4:07:25 PM UTC-4, Matthew Wild wrote: >> >> On 14 August 2015 at 20:02, wrote: >> > My question is now focused on what configure args should I use to get >> > timber >> > to use lua version 5.2. >> >> ./configure --runwith=lua5.2 >> >> Change 'lua5.2' to whatever the path is to your Lua 5.2 interpreter. >> > > I have tried it a few ways but below is a transcript starting from the > removal of prosody timber until the launching of the fresh binary that > displays the message. > > > Thanks for your help. > > Ben > > > slim# rm /opt/local/bin/prosody > slim# ./configure --ostype=macosx --with-lua=/opt/local/bin/lua > -n Checking Lua includes... > lua.h found in /opt/local/include/lua.h > Writing configuration... > > Installation prefix: /opt/local > Prosody configuration directory: /opt/local/etc/prosody > Using Lua from: /opt/local/bin/lua > > Done. You can now run 'make' to build. > > slim# make > sed "1s| lua$| lua|; \ > s|^CFG_SOURCEDIR=.*;$|CFG_SOURCEDIR='/opt/local/lib/prosody';|; \ > s|^CFG_CONFIGDIR=.*;$|CFG_CONFIGDIR='/opt/local/etc/prosody';|; \ > s|^CFG_DATADIR=.*;$|CFG_DATADIR='/opt/local/var/lib/prosody';|; \ > s|^CFG_PLUGINDIR=.*;$|CFG_PLUGINDIR='/opt/local/lib/prosody/modules/';|;" < > prosody > prosody.install > sed "1s| lua$| lua|; \ > s|^CFG_SOURCEDIR=.*;$|CFG_SOURCEDIR='/opt/local/lib/prosody';|; \ > s|^CFG_CONFIGDIR=.*;$|CFG_CONFIGDIR='/opt/local/etc/prosody';|; \ > s|^CFG_DATADIR=.*;$|CFG_DATADIR='/opt/local/var/lib/prosody';|; \ > s|^CFG_PLUGINDIR=.*;$|CFG_PLUGINDIR='/opt/local/lib/prosody/modules/';|;" < > prosodyctl > prosodyctl.install > sed 's|certs/|/opt/local/etc/prosody/certs/|' prosody.cfg.lua.dist > > prosody.cfg.lua.install > test -e .hg/dirstate && \ > hexdump -n6 -e'6/1 "%02x"' .hg/dirstate > prosody.version || true > test -f prosody.release && \ > cp prosody.release prosody.version || true > /Applications/Xcode-beta.app/Contents/Developer/usr/bin/make -C util-src > install > gcc -fPIC -Wall -ggdb -I/opt/local/include -c -o encodings.o encodings.c > MACOSX_DEPLOYMENT_TARGET="10.3"; export MACOSX_DEPLOYMENT_TARGET; > gcc -o encodings.so encodings.o -bundle -undefined dynamic_lookup > gcc -fPIC -Wall -ggdb -I/opt/local/include -c -o hashes.o hashes.c > MACOSX_DEPLOYMENT_TARGET="10.3"; export MACOSX_DEPLOYMENT_TARGET; > gcc -o hashes.so hashes.o -bundle -undefined dynamic_lookup -lcrypto > gcc -fPIC -Wall -ggdb -I/opt/local/include -c -o net.o net.c > MACOSX_DEPLOYMENT_TARGET="10.3"; export MACOSX_DEPLOYMENT_TARGET; > gcc -o net.so net.o -bundle -undefined dynamic_lookup > gcc -fPIC -Wall -ggdb -I/opt/local/include -c -o pposix.o pposix.c > MACOSX_DEPLOYMENT_TARGET="10.3"; export MACOSX_DEPLOYMENT_TARGET; > gcc -o pposix.so pposix.o -bundle -undefined dynamic_lookup > gcc -fPIC -Wall -ggdb -I/opt/local/include -c -o signal.o signal.c > MACOSX_DEPLOYMENT_TARGET="10.3"; export MACOSX_DEPLOYMENT_TARGET; > gcc -o signal.so signal.o -bundle -undefined dynamic_lookup > gcc -fPIC -Wall -ggdb -I/opt/local/include -c -o table.o table.c > MACOSX_DEPLOYMENT_TARGET="10.3"; export MACOSX_DEPLOYMENT_TARGET; > gcc -o table.so table.o -bundle -undefined dynamic_lookup > install *.so ../util/ > rm table.o net.o pposix.o signal.o > /Applications/Xcode-beta.app/Contents/Developer/usr/bin/make -C certs > localhost.crt example.com.crt || true > make[1]: `localhost.crt' is up to date. > make[1]: `example.com.crt' is up to date. > slim# make install > install -d /opt/local/bin /opt/local/etc/prosody > /opt/local/lib/prosody/modules /opt/local/lib/prosody > install -m750 -d /opt/local/var/lib/prosody > install -d /opt/local/share/man/man1 > install -d /opt/local/etc/prosody/certs > install -d /opt/local/lib/prosody/core /opt/local/lib/prosody/net > /opt/local/lib/prosody/util > install -m755 ./prosody.install /opt/local/bin/prosody > install -m755 ./prosodyctl.install /opt/local/bin/prosodyctl > install -m644 core/* /opt/local/lib/prosody/core > install -m644 net/*.lua /opt/local/lib/prosody/net > install -d /opt/local/lib/prosody/net/http > /opt/local/lib/prosody/net/websocket > install -m644 net/http/*.lua /opt/local/lib/prosody/net/http > install -m644 net/websocket/*.lua /opt/local/lib/prosody/net/websocket > install -m644 util/*.lua /opt/local/lib/prosody/util > install -m644 util/*.so /opt/local/lib/prosody/util > install -d /op
Re: [prosody-dev] is it lua 5.1 really required for Prosody .9.8?
On 15 August 2015 at 12:30, wrote: > > > On Saturday, August 15, 2015 at 6:26:17 AM UTC-4, Matthew Wild wrote: >> >> Hi Ben, >> >> I think you are building or running the wrong code, as timber would >> not display this message for Lua 5.2. > > > could be here is my mercurial line that I'm using to get timber > > slim# hg clone https://hg.prosody.im/trunk timber-trunk This is incorrect. Just clone the URL I gave you earlier: hg clone https://hg.prosody.im/timber Then you should be good :) Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] is it lua 5.1 really required for Prosody .9.8?
On 15 August 2015 at 12:50, wrote: > > > On Saturday, August 15, 2015 at 7:30:52 AM UTC-4, b...@cogs.com wrote: >> >> >> >> On Saturday, August 15, 2015 at 6:26:17 AM UTC-4, Matthew Wild wrote: >>> >>> Hi Ben, >>> >>> I think you are building or running the wrong code, as timber would >>> not display this message for Lua 5.2. >> >> >> could be here is my mercurial line that I'm using to get timber >> >> slim# hg clone https://hg.prosody.im/trunk timber-trunk >> requesting all changes >> adding changesets >> adding manifests >> adding file changes >> added 6771 changesets with 7712 changes to 314 files >> updating to branch default >> 231 files updated, 0 files merged, 0 files removed, 0 files unresolved >> >>> Try running '/opt/local/bin/prosody' instead of just 'prosody'. Also >>> as a quick check, you can run: grep "if _VERSION" >>> util/dependencies.lua >>> >> >> grep "if _VERSION" util/dependencies.lua >> if _VERSION ~= "Lua 5.1" then >> >> >> That is true for the source I have been using and a fresh folder using the >> mercurial clone command used above. >> >> Thank you for your help I think we are getting very close. >> >> Ben >> >> >>> >>> If you have timber, the grep will show: if _VERSION < "Lua 5.1". > > > I changed my timber-trunk util/dependencies.lua and prosody launched. > Prosody is now prompting it is unable to fine luafilesystem, LuaSec and > util.encodings. Great. But just so you know, changing the version check is not all that is required to make Prosody work with 5.2 :) If you have the wrong version of the code (trunk) then remember it still won't work until you switch to timber. We have no branch called "timber-trunk". The dependency warnings you see now are for the C libraries that Prosody needs, they need to be compiled for Lua 5.2 also (and in Lua 5.2's search paths). Once you have those, you'll have passed all the dependency checks. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] is it lua 5.1 really required for Prosody .9.8?
On 15 August 2015 at 13:11, wrote: > > > On Saturday, August 15, 2015 at 7:33:42 AM UTC-4, Matthew Wild wrote: >> >> On 15 August 2015 at 12:30, wrote: >> > >> > >> > On Saturday, August 15, 2015 at 6:26:17 AM UTC-4, Matthew Wild wrote: >> >> >> >> Hi Ben, >> >> >> >> I think you are building or running the wrong code, as timber would >> >> not display this message for Lua 5.2. >> > >> > >> > could be here is my mercurial line that I'm using to get timber >> > >> > slim# hg clone https://hg.prosody.im/trunk timber-trunk >> >> This is incorrect. Just clone the URL I gave you earlier: hg clone >> https://hg.prosody.im/timber > > Ok I coned that directory and all I had to do was edit the > /util-src/Makefile I mentioned earlier. > > That built a running Prosody that is unable to find the luafilesystem, > LuaSec and util.encodings. Not finding util.encodings is a bit strange. Check what happens when you run: lua5.2 -l util.encodings (in the directory where you ran 'make') If you're around for a bit and want some realtime help, I'm around in the chatroom[1] right now and you're always welcome :) Regards, Matthew [1]: https://prosody.im/discuss#chatroom -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Re: Running Prosody on Android via Lua wrapper
Hi Chris, On 21 August 2015 at 00:18, Chris Ballinger wrote: > This is an open source project I am really looking to make happen in order > to democratize the ability to run your own server. If you are familiar > enough with Prosody, Android, and the NDK, to make this a reality please get > in touch! If it helps, I may be able to find you some funding to get this > off the ground. Running Prosody on Android is certainly possible, though I don't know of it being done in any open-source projects so far. I don't think any of the core developers currently have the time to dedicate to such a project (getting 0.10 finished and released is our priority), but we'd certainly be happy to help with advice wherever we can. > On Tue, Jul 14, 2015 at 4:00 PM, Chris Ballinger > wrote: >> >> All of the Java Lua wrappers aren't maintained but it seems that you can >> cross compile LuaJIT for the Android NDK which may be sufficient. Some of >> Prosody's Lua dependencies require C libraries as well, which may complicate >> the NDK build process. LuaJIT isn't necessary, building plain Lua for Android would be much easier and more portable. Our own C libraries are very simple, but your main problem will be dependencies. For example LuaSec needs OpenSSL, and our util.encodings needs libidn or libicu. >> Beyond that initial hurdle, it looks like overall the structure of Prosody >> would be compatible with running in the Android app sandbox given the proper >> configuration. >> >> Anything I'm missing here? No, it would work fine technically. I'm not completely sure I understand the greater purpose of such a project though. For example, I wouldn't generally recommend running a server on something with an intermittent internet connection, which is true of 99% of the devices that Android is installed on. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] FYI: expat: add security patch for CVE-2015-1283
Hi Lonnie, On 2 September 2015 at 00:40, Lonnie Abelbeck wrote: > Devs, > > Buildroot added a patch for expat: add security patch for CVE-2015-1283 > > http://git.buildroot.net/buildroot/commit/package?id=67d6276c1bd050b362b11658ae0c7b4da73e227e > > Since luaexpat uses expat and Prosody uses luaexpat and expat is old, this > may be of interest. Thanks! :) Just for the record, I don't believe this affects Prosody or LuaExpat. Also the patch is already in most mainstream Linux distributions, so anyone worried just needs to apply their distribution's security updates as usual. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Non-english characters makes sasl login fail
Hi Mathias, On 28 September 2015 at 17:14, Mathias Friman wrote: > Hi, > > I'm using Prosody for a Jitsi-Meet installation that is fairly detailed > here: https://github.com/jitsi/jicofo/issues/22#issuecomment-143686744 > > When enabling mod_auth_ldap module I can login using a XMPP client like > Jitsi, Empathy or Pidgin. However, when I try Jitsi-Meet, I get the > following error in prosody.log: > > Sep 28 10:03:46 > boshed479f56-6a3b-420c-b330-00c1b4ea4bc6 debug Received[c2s_unauthed]: mechanism='PLAIN' xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> > Sep 28 10:03:46 sasl debug Username or password violates SASLprep. > Sep 28 10:03:46 videokonf.domain.com:saslauth debug sasl reply: xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>Invalid > username or password. > > > I've narrowed it down to accounts with a password containing non-english > characters like swedish åäö or ÅÄÖ which is part of our alphabet. When > trying a user with a not-so-complex password, the login works fine. However, > I cannot rely on our users to choose a password not containing the letters > åäö or ÅÄÖ since they are a part of our alphabet. I have no idea as of now > if other characters are met with the same error message. > > I have two problems: > > 1. Why in name of [random deity] does a login failure like this only get > reported in debug mode? :) I've spent like three days on this before I > noticed the error message. :/ There is possibly an argument to bump the log level of this to "warn" (which we use for unexpected/incorrect behaviour from clients). However given that this is before authentication succeeds, it also opens up the possibility of abuse by random strangers (flooding the log by sending invalid data), so it's not a simple choice. Also I'll note that spending three days debugging something without enabling debug logs is almost always going to be a mistake :) > 2. I need this fixed in some way because these letters might be used by a > number of our users. So how can I do this? It seems to be this file: > https://github.com/bjc/prosody/blob/master/util/sasl/plain.lua that reports > the error. How to fix it however, I have no idea. If you've confirmed that the affected username can log in with normal Jitsi, Empathy and Pidgin, and only Jitsi-Meet has this problem, I rather suspect it is an issue with Jitsi-Meet or its configuration. Many people use Prosody daily with such characters in their usernames. If Jitsi-Meet is taking the username from a text input on a web page, it could quite possibly be an encoding issue, as everything needs to be in UTF-8. You would need to take this up with the Jitsi-Meet developers. If you find that other clients are also not working, please feel free to file a bug report ( https://prosody.im/issues/ ) along with debug logs from the client and the server, and we'll do our best to figure out the problem. Obviously this should only be done with accounts created for testing purposes :) Regards, Matthew P.S. Just in case, because you were looking through the source code for a fix - I really don't advise changing anything in Prosody's SASL code, especially without understanding what the root of this problem is. It would be quite easy to open up security holes that way. -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] proxy65: buffer size too small ?
Hi, On 11 November 2015 at 21:19, Goffi wrote: > G'day, > > I'm currently working on file transfer, and I realized that default minimum > buffer size for proxy65 is 4096 octets. If a client send a bigger one, it will > be disconnected. That's not intentional (obviously). Filling the buffer in mod_proxy65 is harmless and not an error. I suspect you may be encountering an unrelated known issue. Are you using libevent with Prosody? Does the client get disconnected, or does the connection freeze? Try setting the following in your config file (global section) and see if the issue goes away: network_default_read_size = "*a" If that doesn't fix it, please supply debug logs. > I haven't found documentation about a recommended buffer size, but 4Kio seems > really low to me, especially if going above disconnect the client. > 64 Kio seems more usual. In fact I have tried with Gajim, and it is > disconnected when sending a file through the proxy. > On my client I have set the size to 4Kio because of this, but I wonder if the > subject has already been discussed here (after all, I guess I'm not the first > one to send a file through prosody proxy with gajim). > So if you have any hint on why this limit has been choosed, and if I need to > report that to Gajim developers, i would appreciate. If Prosody is disconnecting the client here, it's most likely a bug on our side, not Gajim. And you're certainly not the first person to send a file through mod_proxy65, in the past I have stress-tested it, streaming many GB through at a good speed. The buffer is a part of that, and I think 4KB is fine for general use and public servers. It seems it's not configurable however, and we should probably fix that... Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Result packet not forwarded from BOSH to Smack client
On 17 November 2015 at 17:48, wrote: > The issue has been fixed in https://hg.prosody.im/0.10/rev/f755e0bdc60a > > Thank you Matthew Wild ! Thanks for your patience with this crazy bug, and to Damian for managing to reproduce it and get me access to his machine while it was actually occurring so I could track it down. Quite sure I wouldn't have been able to fix it otherwise :) Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] proxy65: buffer size too small ?
On 20 November 2015 at 23:15, Goffi wrote: > Hi Matthew, > > sorry for the late answer, I was quite busy. > > So it's not working neither with the network_default_read_size option you gave > me, and I'm not using libevent. What version of Prosody are you using? Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] proxy65: buffer size too small ?
On 20 November 2015 at 23:42, Goffi wrote: > Le vendredi 20 novembre 2015, 23:22:54 Matthew Wild a écrit : >> On 20 November 2015 at 23:15, Goffi wrote: > >> What version of Prosody are you using? > > current trunk tip (3c4799467dae) > > I have the feeling that with a 64Kio chunk size, I sending data too quickly > for gajim to read, and after a while the prosody buffer explode. Correct. The error that gets logged indicates that the receiving client was not receiving fast enough. However the proxy65 code is specifically designed so that can't happen. I'll see if I can reproduce it. If it's not much trouble, could you try with libevent and see if that changes anything? Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] prosody-modules migration to github
Hi Scott, On 8 December 2015 at 22:28, Scott White wrote: > Hello, > > I am a developer looking for a replacement chat server (we currently use > OpenFire). > Prosody looks promising and pretty powerful. > > I just wanted to offer my comments: > -Moving to a better supported source repo (Github or Bitbucket with Hg > support) would make the product *look* more viable > -Better documentation on a tool like readthedocs.org would help (alot) > (for example: I found a couple of mistakes following the documentation > that I would have done a pull request to fix if you used readthedocs and > either of the above repos) Thanks for the feedback. Please feel free to just report documentation issues to us, it would only take a couple of minutes to send us an email (mailto:develop...@prosody.im), or let us know what they are on this list, or join the chatroom, basically any of the means listed at https://prosody.im/discuss - we are constantly improving docs based on user feedback. I don't think a git repository or $documentation_hosting_of_the_month is a requirement for that, and neither, as I already explained earlier in this thread, do I think that chasing whichever third-party providers are currently the best use of developers' time. We're an open, active, and friendly project. Please don't discriminate against us based on the tools we choose to use. Enjoy our software instead :) Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at http://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Is it possible to use anonymous access of Prosody to implement live help?
On 21 December 2015 at 04:08, Ying LEE wrote: > As a demo, support-chat is the one I am looking for. But, I am wondering > there is some security problems. For the team MUC is known by client by > checking the source code, and team MUC is open to anonymous visitors. So it > is easy to use an XMPP client to access team MUC and get the private > messages (of course, not all) between other visitors and supporters. The MUC is used only for co-ordination and discovery of the (online) members of teams. The initial message/invitation is sent privately, so is not visible to other users in the room. The supporters then join the private room that the user created, and all discussion happens there. At the end of the day it is, like many other services on the internet, providing an anonymous chat service. So yes, it is wise to be aware of what is and isn't visble or accessible to anonymous users. A service would, for example, probably want to put some restrictions on submitting queries, but that would need to be enforced server-side, and not in the client code. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
[prosody-dev] [ANN] Prosody 0.9.9 security release available
Hi folks, This release contains important fixes for two security issues recently discovered in Prosody. It also contains various other fixes and improvements we have made since 0.9.8. We strongly recommend that you upgrade your server as soon as possible. Another important note is that for a number of reasons we have dropped Windows support with this release. If you are affected by this, please contact us directly via email at develop...@prosody.im. A summary of changes: Security fixes: - Fix path traversal vulnerability in mod_http_files (CVE-2016-1231) for more details see https://prosody.im/security/advisory_20160108-1/ - Fix use of weak PRNG in generation of dialback secrets (CVE-2016-1232) for more details see https://prosody.im/security/advisory_20160108-2/ Bugs: - Improve handling of CNAME records in DNS - Fix traceback when deleting a user in some configurations (issue #496) - MUC: restrict_room_creation could prevent users from joining rooms (issue #458) - MUC: fix occasional dropping of iq stanzas sent privately between occupants - Fix a potential memory leak in mod_pep Additions: - Add http:list() command to telnet to view active HTTP services - Simplify IPv4/v6 address selection code for outgoing s2s - Add support for importing SCRAM hashes from ejabberd # Download As usual, download instructions for many platforms can be found on our download page: https://prosody.im/download If you have any questions, comments or other issues with this release, let us know! https://prosody.im/discuss -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] events
On 20 January 2016 at 19:13, Harsha Bellur wrote: > Hi > > In situations where events (same event_name) are getting fired > (module:fire_event()) quicker than the handler function (defined in > module:hook()), is it safe to assume that the events are queued? There is no queue - module:fire_event() d -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] events
On 20 January 2016 at 20:24, Matthew Wild wrote: > On 20 January 2016 at 19:13, Harsha Bellur wrote: >> Hi >> >> In situations where events (same event_name) are getting fired >> (module:fire_event()) quicker than the handler function (defined in >> module:hook()), is it safe to assume that the events are queued? > > There is no queue - module:fire_event() d Sorry, hit send somehow too early. There is no queue - module:fire_event() does not return until the handler has finished. Handlers should never take long to execute, they should return instantly. If you're having trouble with slow handlers, they need fixing (we can help you figure out how, if you need). Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] events
On 21 January 2016 at 01:15, Harsha Bellur wrote: > Hi Mathew, > > Perhaps I should not be using fire_event(). > What I am attempting to do is capture all "muc_events" (such as join room, > leave room...) in a MUC room and send it via HTTP. > I have written a module that incorporates a handler which does a HTTP post > of the events received. This, in my opinion, must be an asynchronous > operation. Prosody's HTTP client API, net.http, provides an asynchronous HTTP post. Documentation is here: https://prosody.im/doc/developers/net/http Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
[prosody-dev] [ANN] Prosody 0.9.10 released
Hi folks, We are pleased to announce the release of Prosody 0.9.10. This release fixes another dialback security issue. We strongly encourage all Prosody servers to upgrade as soon as possible. Successful exploitation of the issue allows an attacker to impersonate your server on the XMPP network. A full security advisory can be found at https://prosody.im/security/advisory-20160127/ Many thanks to Thijs Alkemade for discovering and reporting the issue. We also have a number of other fixes and improvements made since 0.9.9. A summary of changes since the previous release: Security - mod_dialback: Adopt key generation algorithm from XEP-0185, to prevent impersonation attacks (CVE-2016-0756) Fixes and improvements - Startup: Open /dev/urandom read-only, to fix a failure to start on some systems (fixes #585) - Networking: Improve handling of 'select' network backend running out of file descriptors Minor changes - Networking: Increase default internal read size to prevent connections stalling with LuaEvent (see #583) - DNS: Discard queries that failed to send due to connection errors (fixes #598) - c2s, s2s: Lower priority of shutdown handler, so that modules such as MUC can always send shutdown notifications to (remote) users (fixes #601) # Download As usual, download instructions for many platforms can be found on our download page: https://prosody.im/download If you have any questions, comments or other issues with this release, let us know! https://prosody.im/discuss -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Re: BitOp not bundled with docker Prosody 0.10: websocket error
On 31 January 2016 at 19:19, Simon Hill wrote: > So I fixed this by adding to the dockerfile > > RUN apt-get install -y lua-bitop > Thanks Simon. Could you open an issue on prosody-docker Github? Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Re: Prosody not listening to any ports after restart
Hi Rainer, On 24 February 2016 at 13:17, Rainer Schuth wrote: > Hello, > > any ideas on this? > > I am using prosody-0.10_1nightly214-1~trusty on a Ubuntu 14.04 64bit. Really sorry for the delay on this. I was hoping to look into the issue, but I haven't had time this week. Could you please file a bug at https://prosody.im/issues? (include mod_auth_external in the title) Also be aware that we don't really recommend using mod_auth_external on production systems right now, it's experimental, has known bugs, and we are planning to remove support for the non-blocking mode from Prosody 0.10 anyway. If possible, it is better to translate your authentication requirements to a native Prosody plugin. If you have questions then let us know. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Prosody doesn't start after upgrade from nightly219 to nightly220
Hi Sebastian, On 28 February 2016 at 19:23, Sebastian Schweizer wrote: > Hi, > > I use Debian Jessie with systemd and the prosody-0.10 nightly package. > After this upgrade, prosody doesn't start anymore: > [UPGRADE] prosody-0.10:amd64 1nightly219-1~jessie -> 1nightly220-1~jessie Thanks for the report. The issue has already been fixed and will be in the next nightly build. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] prosody BOSH errors
Hi Aaron, On 22 March 2016 at 21:46, Aaron van Meerten wrote: > Hi Prosody People, > > I have prosody set up for bosh, and am forwarding requests to /http-bind in > nginx to prosody on 5280. When using this configuration with > prosody-0.10-nightly181, I have had no issues running the service. > > However, now I have been experiencing this strange issue on all builds of > prosody since prosody-0.10-1nightly181-1, up to and including prosody-trunk > build 645. Just to confirm, are you saying 0.10 build 181 works, and 182 does not? (for the record, that seems unlikely) or is the exact build that breaks unknown? > The issue is that upon reaching a certain condition (not clear if it’s load, > number of concurrent connections, or what), prosody stops responding to BOSH > requests in a timely fashion. The error I see in nginx is as follows: > > 2016/03/22 21:12:45 [error] 29130#0: *12378 upstream timed out (110: > Connection timed out) while reading response header from upstream, client: > 52.90.26.24, server: , request: "POST /http-bind/?room=ip1065189341 > HTTP/1.1", upstream: "http://127.0.0.1:5280/http-bind/?room=ip1065189341";, > host: "lonely.hipchat.me:443” > > There are no equivalent lines in the prosody logs. It’s as if prosody is > blocking and fails to respond to the request, closing the connection > silently within a few seconds of initiation. > > The errors only occur when enough clients are connected and communicating, > so I suspect it’s a resource management problem or some kind of locking > issue. When the load reduces again, BOSH connections work properly without > having to restart the prosody process so it does seem to be related to > ongoing connections. What authentication and storage backends is Prosody configured to use? These are the most likely candidates for this kind of behaviour. In particular, we have been making some changes to our SQL code in the 0.10 branch recently, so if you are using SQL then we might need to investigate some of our changes further. > All this is blocking me from upgrading to the latest prosody, so I am using > the last one that didn’t have this issue, prosody-0.10-1nightly181-1. > However, this doesn’t contain the support I need for token authentication, > and also requires me to check out separate repos of modules which have since > been integrated into the mainline. So I’d like to get to the bottom of this > and start using the latest prosody again. You mention using other modules (I guess the prosody-modules repo?) - which of these modules are you using, and any chance that it could be an issue in one of these rather than Prosody itself? > Does anyone have any ideas on what I could do to investigate further? Or > does anyone have any idea what might have changed in prosody to permit such > a failure mode? No particular change springs to mind (apart from SQL changes, as mentioned above). Prosody appearing to freeze momentarily will either be caused by something CPU intensive (e.g. a loop), or by some syscall that blocks. The former should be detectable with most standard monitoring tools. The latter could be caught with something like strace or sysdig. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] [PATCH] Do not rely on auto string-to-number coercion
Hi David, On 25 March 2016 at 14:49, David Favro wrote: > Hello, > > Here is a small patch to (partially, anyhow) remove prosody's > reliance on Lua's implicit string-to-number coercion 'feature'. > > Why do so? Since it was met with some disapproval in the > chatroom, let me try to justify it here: For what it's worth I'm not a fan of implicit coercion either, and I'd say that we already actively avoid it much of our code already. I wouldn't be sad to see automatic string->number coercion removed from Lua. > This is perhaps not the only place where the code relies on this > behavior, but it's the only one that I've found to date, and > rather than sit on a patched local version, I'd prefer to run a > vanilla codebase. I am unfamiliar with hg; this patch is > formatted such that the entire email can be fed to > "git am --scissors" to apply it, while ignoring the rest of the > email body; should you decide to use it, I don't know what is > the equivalent with hg or whether the format is appropriate. No worries, your contribution is appreciated in any format! Obviously hg makes life easier for us, but for the odd patch anything is fine (though I'm probably opening myself up to screenshots of code embedded in Word documents at this point). Ultimately, I didn't apply your patch as-is though. Reasoning follows: As well as adding tonumber() (the main reason for the patch) it subtly changed the major + minor calculation. While the new calculation produced the same result for current LuaSec version numbers (0.4, 0.5, 0.6), it wasn't quite the same calculation. Specifically the new one would treat "0.1" and "0.10" the same (returning 1 for both). Notably the current code actually has a similar issue (it's not perfect), but is good for up to 0.100 which is probably some time away yet... Therefore I simply changed the code to call tonumber() on both segments of the version number, and left the existing calculation code in place. See https://hg.prosody.im/0.10/rev/afa83f3ccaad Thanks! Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Corrected: [PATCH] Makefile: git-based version number
Hi David, Thanks for the patch. On 28 March 2016 at 21:52, David Favro wrote: > A little patch to give a reasonable version number when building > prosody, for those who work with git as their VCS front-end. Details > are in the commit message. I don't think this change really makes sense - we don't have an official git repository, so git commit hashes are not meaningful in identifying Prosody versions. Receiving bug reports from people who have 'git:X' as their Prosody version is not going to help us identify the version of Prosody they are using. We wouldn't even know what git repository the hash referred to, and even if we did then it would be a manual process to translate that into a hg revision - not fun :) Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Corrected: [PATCH] Makefile: git-based version number
On 28 March 2016 at 22:23, Matthew Wild wrote: > Hi David, > > Thanks for the patch. > > On 28 March 2016 at 21:52, David Favro wrote: >> A little patch to give a reasonable version number when building >> prosody, for those who work with git as their VCS front-end. Details >> are in the commit message. > > I don't think this change really makes sense - we don't have an > official git repository, so git commit hashes are not meaningful in > identifying Prosody versions. Receiving bug reports from people who > have 'git:X' as their Prosody version is not going to help us > identify the version of Prosody they are using. We wouldn't even know > what git repository the hash referred to, and even if we did then it > would be a manual process to translate that into a hg revision - not > fun :) Ha, I just noticed that you do append a hg version to it. Fun :) > Regards, > Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Some issues with mod_cloud_notify
Hi Chris,
On 25 May 2016 at 22:16, Chris Ballinger wrote:
> Not sure about the proper way to submit a pull request, but we have some
> proposed modifications to the existing module that I'd like some feedback on
> first.
I'm working on some 'contributing' docs :) But summary is - however
you want to send a pull request. For small changes, sending a patch
here is fine. For larger changes, either email a bundle (generated
with 'hg bundle') to develop...@prosody.im, or point us to a repo we
can pull from.
> 1. push_enabled is not persisted across server restarts (only reloads). This
> means that users won't receive pushes until they login again. Is there an
> easy way to accomplish this with the existing persistent storage API? I had
> trouble finding docs for the storage API.
You're right, I thought we had this documented.
First, open the store using module:open_store():
https://prosody.im/doc/developers/moduleapi#storage
Once you have the store, you can call store:get(username) and
store:set(username, data).
Example:
```
local prefs_store = module:open_store("cloud_notify_preferences");
prefs_store:set("myusername", { push_enabled = true });
local user_preferences = prefs_store:get("myusername");
if user_preferences and user_preferences.push_enabled then
-- Push
end
```
> 2. pushes are triggered for typing notifications (and possibly other
> extraneous stanzas as well). Would this be desired for some use cases and
> configurable (for instance to wake up the receiving client more quickly), or
> would it be better to just filter out all messages without a body?
I don't see any typical use cases for no-body messages being pushed.
If someone wants that, they are probably happy customizing the module
to pluck out the information they want to send, and it wouldn't be a
difficult change. I say discard messages that don't have a body right
now.
Regards,
Matthew
--
You received this message because you are subscribed to the Google Groups
"prosody-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to prosody-dev+unsubscr...@googlegroups.com.
To post to this group, send email to prosody-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/prosody-dev.
For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Some issues with mod_cloud_notify
On 26 May 2016 at 16:55, Kim Alvefur wrote: > On 2016-05-25 23:16, Chris Ballinger wrote: >> 2. pushes are triggered for typing notifications (and possibly other >> extraneous stanzas as well). Would this be desired for some use cases >> and configurable (for instance to wake up the receiving client more >> quickly), or would it be better to just filter out all messages without >> a body? > > and MattJ wrote: >> I don't see any typical use cases for no-body messages being pushed. > > It's not that simple, what about OMEMO, or other non-body message with > some alternative payload? And this problem also applies to Carbons, MAM > and possibly other things. How useful are encrypted push notifications, in the way that push notifications are actually implemented in devices? At that point I think it would probably be better to just send "You have new messages from XYZ" if they are determined "important" messages. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] bug: mod_saslauth sends incorrect auth success response
Hi Andrey, On 25 August 2016 at 18:19, Andrey Prokopenko wrote: > Hi fellow chatters. > Just discovered a rather nasty bug in mod_saslauth module, effectively > preventing Smack (or any other XMPP lib) to connect to the prosody. > In particular, function build_reply within SASL authentication module > mod_saslauth.lua adds "=" sign to empty response. Thus reply cannot be > decoded back from Base64 and processed with Smack library (or any other XMPP > library in fact )and fails with "invalid base" exception. This is from RFC 6120, section 6.4.2: http://xmpp.org/rfcs/rfc6120.html#sasl-process-neg-initiate and 6.4.6: http://xmpp.org/rfcs/rfc6120.html#sasl-process-neg-success In short, the '=' is used to differentiate "no data" and "empty data" within the SASL element. On receiving '=', you need to skip base64 decoding and just treat it as an empty string. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] number of hosts
Hi Stefan, On 3 November 2016 at 12:27, 'Stefan Sänger' via prosody-dev wrote: > Hi All, > > I am currently looking into some config and scaling options - the goal is to > integrate prosody into some hosting scenario. In the end there is a > webclient embedded into another application, and it is using BOSH to connect > to prosody (with nginx doing SSL offloading). > In one of my tests I tried to create a lot of VirtualHost configs - and to > my surprise there seems to be a limit. While everything was pretty smooth > for like 20 hosts, I really had problems with larger numbers. 500 hosts also > does not seem to be a problem, but with 1000 hosts it basically stopped > working. There is no hard limit, and Prosody has been successfully used in hosted scenarios with thousands of domains by others. Although there is no hard limit, some things will not perform that great out of the box. I'll share some tips. The first thing I'll mention is that you're using 0.10 - and we're not quite done with it yet, there are known performance issues, especially if you're using SQL for storage. If you are, that's probably the #1 source of your problems right now. We've done extensive tests in the past with Prosody serving thousands of hosts. They caused us to make some architectural changes some years ago to reduce per-host memory footprint and startup time. These are the two places you are going to encounter any bottlenecks. Starting with memory usage... the answer is simple. This depends on what modules and features you have enabled in your configuration. Really consider what you need and what you don't need to be loaded, and trim back anything you don't need. That way you'll be able to squeeze more hosts into your available RAM. The second is startup time. Prosody has the concept of "active" and "inactive" hosts, and when it activates a host there is some initialization done (loading modules, etc.) for that host. By default (because this is what most setups want) Prosody takes a very simple approach and automatically activates all the hosts in the config file at startup. If you have thousands of them, this is almost certainly *not* what you want. It can take quite a while (again, depending on your configuration - keep it minimal) before Prosody is ready to accept connections. We have made some utilities available for controlling this behaviour. For example, you can use this small script in your config to load hosts on-demand, instead of at startup: https://prosody.im/files/prosody_lazyhosts_09.lua Startup time with the above script will become instant again. When a host is first accessed (e.g. user tries to log in) then it is automatically activated. This spreads the load of activating hosts over time, and ensures that only hosts that you actually use get activated and use resources. You also likely will want to dynamically add/remove hosts while Prosody is running. For that you can take advantage of the fact that the config file allows you to run Lua snippets. Using this feature you can pull hosts dynamically from a file, database or external API (caution: this technique is blocking, so make it a fast operation). You can combine this with: https://modules.prosody.im/mod_auto_activate_hosts.html (this module is designed to be compatible with the lazyhosts script mentioned above). > I increased RAM and adjusted limits for file descriptors, but it looks like > even with 8G of RAM I am not able to connect anymore. I am currently trying > with prosody 0.10. Enable debug logs and figure out what's going on. If you can't figure it out, use strace. However it is very likely to be SQL-related, or the issues I described above. If none of this helps you though, get some more details on why you are unable to connect and we'll figure it out. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
[prosody-dev] [ANN] Prosody 0.9.11 released
Hi folks, We are pleased to announce a new minor release from our stable branch. This release contains a bunch of bug fixes, a brief summary of them follows: - HTTP parser: Improve buffering of incoming HTTP data and add size limits (#603) - sessionmanager: Fix for an issue which caused people to be kicked from conferences if mod_smacks was enabled (#648) - Dependencies: Workaround for compatibility with LuaSec 0.6 (#749) - MUC: Accept missing form as "instant room" request (#377) - C2S: Fix issues with destroying disconnected connections (#590), (#641) - mod_privacy: Fix selection of the top resource(s) #694 - mod_presence: Make sure both users get each others presence after adding each other (#673) - mod_http_files: Fix traceback when serving a non-wildcard path (#611) - mod_http_files: Preserve a trailing slash in paths (#639) - util.datamanager: Fix error handling (#632) - net.server_event: Fix internal socket API to allow writing from socket.ondrain callback (#661) - net.server_event: Fix timeout (commit 1909bde0e79f) - net.server_event: Fix traceback due to write during TLS handshake (commit c774622ad9db) - net.server_event: Fix buffer length check (commit 206f9b0485ad) # Download As usual, download instructions for many platforms can be found on our download page: https://prosody.im/download If you have any questions, comments or other issues with this release, let us know! https://prosody.im/discuss -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
[prosody-dev] [ANN] Prosody 0.9.12 released
Hi folks, We are pleased to announce our first release of 2017 - Prosody 0.9.12! This release fixes a few minor issues, and fixes valid certificates failing to verify correctly when Prosody 0.9.x is used with LuaSec 0.6. A summary of changes since the previous release: Minor changes - Dependencies: Fix certificate verification failures when using LuaSec 0.6 (fixes #781) - mod_s2s: Lower log message to 'warn' level, standard for remotely-triggered protocol issues - certs/Makefile: Remove -c flag from chmod call (a GNU extension) - Networking: Prevent writes after a handler is closed (fixes #783) # Download As usual, download instructions for many platforms can be found on our download page: https://prosody.im/download If you have any questions, comments or other issues with this release, let us know! https://prosody.im/discuss -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] mod_mam: support XEP-0313 v0.5 keeping compatibility with previous XEP-0313 v0.3
On 21 February 2017 at 14:06, deoren wrote: > Pardon my ignorance, but is there an easy way to tell whether I have the > community or built-in version of mod_mam enabled? I'm running the latest > 0.10 nightly and I also have Prosody configured to use the current hg > "working copy" (for the lack of the appropriate word) of the modules repo. > > When I ask Pidgin to list the loaded modules, it shows mam and mam_archive > loaded. > > I see this in the config file: > >> -- Plugins are searched in all the specified paths in order, and finally >> -- checked in the default plugin directory. > > which I take to mean that modules of the same name will be loaded first from > the optional path and then lastly the defaults. That's correct. Therefore it's likely using the prosody-modules version. If you want to be certain, this is possible through the telnet admin console: > hosts["example.com"].modules.mam.module.path Replace example.com with your XMPP host. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] [PATCH][0.10] muc: Allow clients to change multiple affiliations or roles at once (#345)
Hey, thanks for the patch! On 17 April 2017 at 13:43, Lennart Sauerbeck wrote: > ... > - In line 40 of the patch, I create a temporary variable to find out > whether the loop was run at least once. Is there a different mechanic in > Lua to do this nicer, or is this the way to go? I agree it's a little annoying, but I don't think there is a better approach that is reasonable. The stanza API doesn't have a method to count tags of a particular type, but even if it did it would just be an iterator just the same as what the code is already doing, and I generally dislike hidden performance costs like that. So I think it's fine as it is. > - Regarding the error handling in lines 49, 55 and in-tree 801 (the last > one is not in the patch because I did no changes there): Is it okay to > just send multiple error messages or should they be collected somehow > and sent as batch after the complete stanza was processed? I could find > nothing about this in either the MUC XEP, nor in the three (or so) base > RFCs of XMPP. Yeah, this is a problem. Of the three stanza types, changing affiliations uses which is always request (get/set) -> response (result/error), and it's not acceptable to have multiple responses to a single request. Otherwise if you were the client, you wouldn't know when the responses had stopped coming, for example. I don't have a good suggestion right now. There are a few solutions that come to mind: - Always report success, just ignore errors. The client will see the affiliation change notifications generated by the room for the successful changes. - Treat the request as an atomic change: succeed for all, or fail all (i.e. if one of the JIDs is malformed, don't allow any of the other changes in the request to take place). This would require work to either pre-verify the changes (which we don't have code for) or to roll back changes that were already made (which is a bit hacky, we'd already have sent out notifications, unless we added a new 'batch update' version of :set_affiliation()). > If this patch gets accepted (with possible modifications), I can easily > cook up one just like it for trunk as well. I already saw that the muc > code has changed quite a lot, but in regards to this patch it's only for > the better. Sounds great - ideally we'd have a version of the patch for trunk before merging, but let's keep the focus on 0.10 until we figure out the issue with the errors. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] [PATCH][0.10] muc: Allow clients to change multiple affiliations or roles at once (#345)
On 17 April 2017 at 19:34, Kim Alvefur wrote: > On Mon, Apr 17, 2017 at 02:32:22PM +0100, Matthew Wild wrote: >> - Treat the request as an atomic change: succeed for all, or fail >> all (i.e. if one of the JIDs is malformed, don't allow any of the >> other changes in the request to take place). This would require work >> to either pre-verify the changes (which we don't have code for) or to >> roll back changes that were already made (which is a bit hacky, we'd >> already have sent out notifications, unless we added a new 'batch >> update' version of :set_affiliation()). > > I would prefer this. Possibly by collecting the changed state in a new > table, then overwriting the old affiliations table as a commit. I'd prefer it too, but it's not trivial. If we really want to go this route, I have a suggestion - what about adding a new room method, :set_affiliations() which takes a table of changes instead of a single jid+affiliation? Then the current :set_affiliation() can be simplified to just pass a single item to :set_affiliations(). The current iq handling code can be simplified to just pass a table of JIDs to :set_affiliations() without any of the error checking logic (this would be in :set_affiliations()). Then :set_affiliations() will have the code that :set_affiliation() currently has, but it will iterate through the JIDs in the input table it is given. Currently the code does this: [error checking] [send change notifications] [update room state] The new code would do: [for each JID:] [error checking] [for each JID:] [send change notifications] [update room state] Does this make sense? Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Switching from hg to git?
Hi Chris, On 27 July 2017 at 23:32, Chris Ballinger wrote: > I know that the Prosody project is still fond of Mercurial but, personally, > it makes it more difficult to contribute. Having a mirror on GitHub (with > issues disabled) that accepted PRs would be really great. I know there was > some discussion about this back in 2015, and was wondering if people's > thoughts have changed since then. No harm in this simple asking, but no, no plans or desire to switch. We're still quite happy with our choice of tooling. Nothing has changed in Mercurial, Git or Github since previous discussions to change our minds. I'm sorry you feel it is difficult to contribute. We accept patches in patch form, and universal patches can be generated by Git, Mercurial, plain ol' diff or whatever other tool you choose to use. If you do use Mercurial and have a bunch of commits to send us, simply run 'hg bundle' and send us the bundle file. I'm pretty sure it's easier than a PR :) I don't see the generation and sending of contributions as a problem. But I'll be quite honest and say that we do have a different problem: we have been doing a bad job about handling and processing the contributions we receive. We're planning to fix this with a more visible patch queue (which may be based off our issue tracker or something like the Patchwork tool that the Mercurial project itself uses). However releasing 0.10 is our immediate focus right now. To folks who have sent us such patches that are not yet merged (or rejected): please accept my apologies. Make sure there is an issue open on our tracker, and don't be afraid to poke us about the status if you haven't seen any action for a while. With the exception of the new pubsub code which has not yet been merged, 0.10 remains generally closed to new features, but we'll be doing a review of everything outstanding after its release (very soon now™). Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
[prosody-dev] Mailing list moderators wanted
Hi folks, I'm looking for a volunteer or two to help moderate the prosody-users and prosody-dev mailing lists. We aim to approve posts from new members within 24h, and while we're hitting that goal for the majority of posts, occasionally some are slipping through and don't get posted for days. A Google account is required (sorry). Email me off-list if you're interested in helping out. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] possible issue with event loop block
Hey, On 16 September 2017 at 01:27, Harsha Bellur wrote: > Well, besides setting use_libevent to true in prosody config, is there > anything else to do? > I am using Jitsi components for audio/video conferencing - so NGINX proxies > APIs to these components as well. > When connected the clients send ping messages (XEP-0199) periodically - that > is about it > Basically, I am validating how the websocket server handles loss of > connectivity from all clients at once - this is where I am seeing the issue. Can you provide the output of `strace -Ttt -p PROSODY_PID` for the duration of the socket-closing operation? Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] possible issue with event loop block
Hi,
On 18 September 2017 at 19:33, Harsha Bellur wrote:
> Hi Mathew,
>
> I guess I should have mentioned this earlier - when websocket is closed, I
> send a http request to a microservice. I believe I am establishing multiple
> connections that is either slowing things down or causing segmentation fault
> based on strace.
How are you sending this HTTP request? and where? Did you modify Prosody's code?
>
> 15:16:50.130413 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR,
> si_addr=0x10} ---
> 15:16:50.238181 +++ killed by SIGSEGV +++
> -
A segmentation fault is a very different thing to just a slow server.
Is this reproducible?
Regards,
Matthew
--
You received this message because you are subscribed to the Google Groups
"prosody-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to prosody-dev+unsubscr...@googlegroups.com.
To post to this group, send email to prosody-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/prosody-dev.
For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] possible issue with event loop block
On 19 September 2017 at 13:42, Harsha Bellur wrote: > On Tuesday, September 19, 2017 at 5:00:21 AM UTC-4, Matthew Wild wrote: >> How are you sending this HTTP request? and where? Did you modify Prosody's >> code? > > I am using the request method in net/http.lua to post HTTPS/HTTP requests to > an external http server. I did modify the method to handle POST as well as > PUT - that's about it. net.http already supports POST - you simply specify a 'body' in the options and it will change the default method to POST automatically. To override this and use a different method, simply set 'method' in the options table. >> A segmentation fault is a very different thing to just a slow server. >> Is this reproducible? > > At my end, it is intermittent but reproducible. The way I do it is setup > say 40 thousand WS connections and stop nginx. Basically, I am simulating a > use case where the web socket server has lost connectivity to all clients. Without seeing your code or the strace output I asked for earlier in the thread, I'm afraid we really don't have enough information to diagnose the issue you're having. Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
[prosody-dev] [ANN] Prosody 0.10.0 released!
Hi folks, We are very pleased to announce the final release of Prosody 0.10.0! This is the first release of our 0.10 branch, taking over from 0.9 as our stable branch. The highlights of this release are covered in our blog post at https://blog.prosody.im/prosody-0-10-0-released/ You can find our release notes (please read if upgrading from previous versions) here: https://prosody.im/doc/release/0.10.0 Summary of new features: * Rewritten SQL storage module with archive support * SCRAM-SHA-1-PLUS * prosodyctl check * Statistics * Improved TLS configuration * Lua 5.2 support * mod_blocklist (XEP-0191) * mod_carbons (XEP-0280) * Pluggable connection timeout handling * mod_websocket (RFC 7395) * mod_mam (XEP-0313) # Download As usual, download instructions for many platforms can be found on our download page: https://prosody.im/download If you have any questions, comments or other issues with this release, let us know! https://prosody.im/discuss -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Re: [Buildroot] [PATCH] prosody: bump to version 0.10.0
On 15 October 2017 at 20:53, Dushara Jayasinghe wrote:
> Hi Francois,
>
> I'm listed as the maintainer for Prosody simply by virtue of the
> fact that I first added the Prosody package. I'm not a Prosody
> dev, so these are more questions than comments...
Prosody dev here...
>> -- Not essential, but recommended
>> + "carbons"; -- Keep multiple clients in sync
>> + "pep"; -- Enables users to publish their mood, activity,
>> playing music and more
>> "private"; -- Private XML storage (for room bookmarks, etc.)
>> + "blocklist"; -- Allow users to block communications with other
>> users
>> "vcard"; -- Allow users to set vCards
> I had a brief look at the release notes, and they state that the new modules
> that you added
> are 'native', does that mean that the required libraries are automatically
> included in the
> install?
These modules were added in 0.10. They don't require any additional
dependencies outside of Prosody.
>> -- Other specific functionality
>> - "posix"; -- POSIX functionality, sends server to background,
>> enables syslog, etc.
> Did you mean to comment this out?
This module is auto-loaded in 0.10 (it automatically detects the
appropriate platform module to load). This was triggered by some users
"accidentally" removing/commenting it out and then asking why their
Prosody was broken. It can still be disabled by adding it to
modules_disabled if necessary.
>> --- These are the SSL/TLS-related settings. If you don't want
>> --- to use SSL/TLS, you may comment or remove this
>> -ssl = {
>> - key = "certs/localhost.key";
>> - certificate = "certs/localhost.crt";
>> -}
> Does Prosody start without any certificates? The config I provided was just
> enough to allow
> Prosody to start and accessible (albeit the user needs to make adjustments to
> suite that site).
It will start without any certificates. However it doesn't need this
configuration in 0.10, we've moved to automatic certificate location,
where Prosody scans a location on the filesystem to pick up the
correct certificate/key for a domain:
https://prosody.im/doc/certificates#automatic_location
>> log = {
>> - -- info = "prosody.log"; -- Change 'info' to 'debug' for verbose
>> logging
>> - -- error = "prosody.err";
>> - "*syslog"; -- Logging to syslog
>> + info = "prosody.log"; -- Change 'info' to 'debug' for verbose logging
>> + error = "prosody.err";
> Where are these files created? In root I believe. My preferance is to just
> use syslog. I think
> the posix module needs to be enabled for syslog to work though.
Prosody will chdir to its data directory at startup, so they are
likely being created there. When Prosody is installed system-wide, we
recommend absolute paths here. The destination directory needs to be
writeable by Prosody (/var/log generally isn't, so packages usually
create and use /var/log/prosody).
>> -pidfile = "/var/run/prosody/prosody.pid"
> Is this intentional? I used the pidfile to allow the startup script to
> terminate the service.
> Can you still terminate the service without this?
This is still a required option if you want to control Prosody after
it daemonizes. However some init systems don't need it.
Regards,
Matthew
--
You received this message because you are subscribed to the Google Groups
"prosody-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to prosody-dev+unsubscr...@googlegroups.com.
To post to this group, send email to prosody-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/prosody-dev.
For more options, visit https://groups.google.com/d/optout.
[prosody-dev] Prosody 0.9.13 security release
Hi folks,
This is a maintenance release to our old stable 0.9 branch, with many
bug fixes, including some important security improvements.
In particular there is an issue where using Prosody 0.9 with LuaSocket
3.0rc1 (which is commonly packaged in distributions) can allow an
unauthenticated remote entity to trigger Prosody to exit.
If you are using our nightly packages ('prosody-0.9') from our
repository, this issue was already fixed last year in nightly build
285. Simply upgrade the prosody-0.9 package to ensure you have all the
latest fixes in this branch.
If you are using the 'prosody' package and it is at version 0.9, we
recommend you upgrade it - our repository provides 0.10.0 since the
release in October last year. Alternatively please switch to using the
prosody-0.9 nightly packages to ensure you continue to get updates on
the 0.9 branch.
Note that there is currently no deprecation plan for the 0.9 branch.
We will continue to provide security and major bug fixes for the
immediate future.
NOTE for 0.10.x users: none of the security issues in this release
affect 0.10. However 0.10.1 release will follow shortly with some bug
fixes relevant to that branch.
A summary of changes in this release:
## Security
- Fix for compatibility with LuaSocket 3.0rc1 (fixes denial of service
from remote)
- mod_register: Require encryption before registration if
c2s_require_encryption is set (fixes #595)
- MUC: Ensure that elements which match our from are stripped
(fixes #1055)
## Fixes and improvements
- Compatibility fix with newer LuaSec 0.6 (fixes #781)
- mod_presence: Send probe once subscribed (fixes #794)
- mod_net_multiplex: Enable SSL on the SSL port (fixes #803)
## Minor changes
- core.rostermanager: Add method for checking if the user is
subscribed to a contact
- mod_saslauth: Log SASL failure reason
- mod_disco: Correctly set the 'node' attr (fixes #449)
- mod_bosh: Update session.conn to point to the current connection (fixes #890)
- net.dns: Simplify expiry calculation (fixes #919)
- mod_watchregistrations: Return the pointer to the root of the
stanza, fixes [#922](https://prosody.im/issues/issue/922).
- mod_disco: Add an account/registered identity on subscribed
accounts, fixes [#826](https://prosody.im/issues/issue/826).
- mod_welcome: Return the pointer to the root of the stanza, fixes a
bug similar to [#922](https://prosody.im/issues/issue/922).
- net.dns: Prevent answers from immediately expiring even if TTL=0
(see [#919](https://prosody.im/issues/issue/919))
- mod_saslauth: Use correct varible name (thanks Roi)
- mod_c2s: Iterate over child tags instead of child nodes in stream
error (fixes traceback from
[#987](https://prosody.im/issues/issue/987))
- mod_component, mod_s2s: Iterate over child tags instead of child
nodes (can include text) in stream error (same as 176b7f4e4ac9)
- MUC: Always send subject message, even if it is empty (fixes
[#1053](https://prosody.im/issues/issue/1053))
- MUC: fix the @from on in history replay (fixes
[#1054](https://prosody.im/issues/issue/1054))
- MUC: Rename variable to make it clearer that it is the room JID and
not the MUC host
# Download
Source: https://prosody.im/downloads/source/prosody-0.9.13.tar.gz
Debian/Ubuntu and derivatives: Install 'prosody-0.9' from our [package
repository](https://packages.prosody.im/debian/) to receive nightly
build 289 or higher.
If you have any questions, comments or other issues with this release,
let us know!
--
You received this message because you are subscribed to the Google Groups
"prosody-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to prosody-dev+unsubscr...@googlegroups.com.
To post to this group, send email to prosody-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/prosody-dev.
For more options, visit https://groups.google.com/d/optout.
[prosody-dev] [ANN] Prosody 0.10.1 released
Hi folks, We are pleased to announce the release of Prosody 0.10.1. This is the latest release to our stable branch. It is recommended that all 0.10.0 users upgrade, and users of our nightly packages upgrade to build 477 or later. A summary of changes since the previous release: Security - SQL: Ensure user archives are purged when a user account is deleted (fixes #1009) Fixes and improvements - Core: More robust signal handling (fixes #1047, #1029) - MUC: Ensure that elements which match our from are stripped (fixes #1055) - MUC: More robust handling of storage failures (fixes #1091, #1091) - mod_mam: Ensure a user's archiving preferences apply even when they are offline (fixes #1024) - Compatibility improvements with LuaSec 0.7, improving curve support - mod_stanza_debug: New module that logs full stanzas sent and received for debugging purposes - mod_mam: Implement option to enable MAM implicitly when client support is detected (#867) - mod_mam: Add an option for whether to include 'total' counts by default in queries (for performance) - MUC (protocol): send muc#stanza_id feature as per XEP-0045 v1.31 (fixes #1097) Minor changes - SQL: Suppress error log if a transaction failed but was retried ok - core.stanza_router: Verify that xmlns exists for firing stanza/iq/xmlns/name events (fixes #1022) (thanks SamWhited) - mod_carbons: Synthesize a 'to' attribute for carbons of stanzas to "self" (fixes #956) - Core: Re-enable timestamps by default when logging to files (fixes #1004) - HTTP: Report HTML Content-Type on error pages (fixes #1030) - mod_c2s: Set a default value for c2s_timeout (fixes #1036) - prosodyctl: Fix traceback with lfs < 1.6.2 and show warning - Fix incorrect '::' compression of a single 0-group which broke some IPv6 address matching - mod_dialback: Copy function from mod_s2s instead of depending on it, which made it harder to disable s2s (fixes #1050) - mod_storage_sql: Add an index to SQL archive stores to improve performance of some queries - MUC: Don't attempt to reply to errors with more errors (fixes #1122) - Module API: Fix parameter order to http client callbacks - mod_blocklist: Allow mod_presence to handle subscription stanzas before bouncing outgoing presence (fixes #575) - mod_http_files: Fix directory listing cache entries not expiring (fixes #1130) # Download As usual, download instructions for many platforms can be found on our download page: https://prosody.im/download If you have any questions, comments or other issues with this release, let us know! https://prosody.im/discuss -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
[prosody-dev] Important: MySQL changes in Prosody trunk
Hi folks, If you do not use MySQL with Prosody trunk, you may stop reading now! ## The important part If you upgrade to trunk build 993 or later, and have configured Prosody to store its data in MySQL, Prosody will refuse to connect to the database until you upgrade the schema. This can be done simply by running: prosodyctl mod_storage_sql upgrade After running this command, restart Prosody and it should connect successfully. ## The details Our recent work with persistence of pubsub and PEP data brought to light a couple of bugs in our MySQL storage driver. The first issue (#1073) was caused by Prosody setting an index on the archive store (which is used for MAM and pubsub/PEP) to be 'unique'. However MySQL by default only looks at the first 20 characters of the data, and this caused issues for storage of e.g. OMEMO keys and avatars, as they both store multiple items with the same prefix. MySQL supports increasing the 20 bytes to a larger value, but not to the full size of the column. Therefore we have removed the constraint to avoid placing unnecessary restrictions on what data can be stored by XMPP clients. Prosody already maintains uniqueness itself, and the constraint was just an additional check. The second issue (#1200) was simply our code emitting SQL that MySQL and MariaDB do not support. This SQL was used to enforce a maximum number of items in a store (e.g. in a pubsub/PEP node). We've replaced it with an equivalent query that is supported by MySQL as well as the other databases we support. As part of fixing these issues we also added new tests that perform and verify the same set of operations across all of our supported storage drivers. This should help us catch and fix these kinds of issues sooner and more easily. That's all for now - are you really still reading? :) Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
[prosody-dev] [ANN] Prosody 0.11.0 released!
Hi folks, We are very happy to announce the release of Prosody 0.11.0! This is the first release in the 0.11 series, which will now be considered the stable series. With over 2000 commits this release couldn’t have been achieved without the help from our many contributors, testers and other community members. Thanks! Full details of this release can be found in our blog post: https://blog.prosody.im/prosody-0-11-0-released/ The highlights include: - Significant rewrite of the MUC component for chatrooms - Many new features added to Pubsub and PEP - Support for vCard4 - Mobile traffic optimisations - Lua 5.2 There are some things to be aware of if you are upgrading from a previous release. Please see the upgrade notes at https://prosody.im/doc/release/0.11.0#upgrade_notes As usual, download instructions for many platforms can be found on our download page: https://prosody.im/download If you have any questions, comments or other issues with this release, let us know! https://prosody.im/discuss Happy Thanksgiving to all our American friends celebrating this week :) The Prosody Team -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
[prosody-dev] [ANN] Backports of lua-dbi and lua-event for Lua 5.2 on Debian/Ubuntu
Hi folks, With the release of 0.11.0 last week, it became apparent that a lot of people have been affected by some of our optional dependencies not being packaged for Lua 5.2 in Debian and Ubuntu. I put some time into producing backported packages for these dependencies to hopefully make peoples' lives a bit easier. Official Debian backports will likely come along at some point soon, and note that updated packages are already in Debian testing. I have not backported lua-ldap or lua-cyrussasl, but may do so if there is sufficient demand for those. Overview at https://prosody.im/doc/release/0.11.0#lua-5.2 Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
[prosody-dev] [ANN] Prosody 0.11.1 released
Hi folks, We are pleased to announce the release of Prosody 0.11.1. This is a small bugfix release for some issues that were identified since the release, mainly for the CSI and traffic optimisations. A summary of changes since the previous release: Fixes and improvements - mod_csi_simple: Use the same event name when firing as when hooking (fixes #1245) - mod_csi_simple: Don’t set stamps on stanzas (fixes #1248) - mod_csi_simple: Bypass importance event in active mode (fixes #1249) Minor changes - mod_csi: Set session.state to simplify CSI modules - MUC: Fix traceback on muc#admin query with missing child (#1242) # Download As usual, download instructions for many platforms can be found on our download page: https://prosody.im/download If you have any questions, comments or other issues with this release, let us know! https://prosody.im/discuss -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
[prosody-dev] [ANN] Prosody 0.10.3 released
Hi, again! Three releases in less than a week! I think it's a record. This one is a minor security and bugfix release from our 0.10.x branch, for users and packagers who are not quite ready to make the jump to 0.11 just yet. We will continue to maintain the 0.10 branch in this way with security and major bug fixes until further notice. Note that there will NOT be an updated ‘prosody’ package in our Debian/Ubuntu repository for this release, as that package is now tracking stable releases from our 0.11 branch. You may use the ‘prosody-0.10’ package which is automatically built from the 0.10 branch daily. The 0.10.3 release is equivalent to build 499. A signed tarball of this release is of course available at the usual place: https://prosody.im/downloads/source/ A summary of changes since the previous release: Security - Don’t list room occupants in service discovery (fixes #1162) Fixes and improvements - mod_component: Fix a wrongly-placed closing parenthesis, fixes #1164. - net.dns: Cache all records from the ‘answer’ and ‘additional’ sections (fixes #487) - net.dns: Don’t attempt to cache unparsed data (fixes #1056) - mod_mam: Handle edge-case of max=0 so that complete attr is set (fixes #1128) - mod_s2s: Close sockets held by resolver (#1170) - mod_admin_telnet: Add debug:events() and debug:logevents() - Logging: Improvements to balance logging of stanzas during routing (#776) - util.pposix: Fix building on OS X (#1202) - mod_http: Make sure path from http_external_url always ends with a slash (fixes #1183) Minor changes - prosodyctl: Make log level configurable through PROSODYCTL_LOG_LEVEL (useful for debugging) - prosodyctl: Allow cert dir to not be owned by root (fixes #1075) - prosodyctl: Change ownership of certs to same as the cert base dir when running from a source checkout - prosodyctl: Warn if attempting to run an unknown check (fixes #1161) - mod_s2s: Fix DNS timeout setting for per-session resolvers (fixes #1167) - mod_groups: Log a warning about invalid JIDs (#1180) - mod_proxy65: Return an error if no port is open (fixes #1240) - API: Add stanza method for removing all children with a specific name, xmlns If you have any questions, comments or other issues with this release, let us know! https://prosody.im/discuss -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
[prosody-dev] [ANN] Prosody community survey 2019
Hi folks, As mentioned in today's blog post [1], we are launching a community survey to help us gather feedback for planning our roadmap. All questions in the survey are optional, and responses are anonymous unless you choose otherwise. Survey here: https://goo.gl/forms/L1AKnTLXjIAfP27W2 Many thanks, and a happy new year! Regards, Matthew [1]: https://blog.prosody.im/welcoming-2019/ -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
[prosody-dev] [ANN] Prosody 0.11.2 released
Hi folks, We are pleased to announce the release of Prosody 0.11.2. This is a minor bugfix release to our stable 0.11 branch. This is a minor bugfix release. It fixes a handful of small but important issues. Also a note for those using Prosody with LuaEvent 0.4.5: please upgrade to LuaEvent 0.4.6 (see https://issues.prosody.im/1267 for more info). A summary of changes since the previous release: - mod_csi_simple: Multiple enhancements to built-in ‘importance’ rules (fixes #1250) - mod_vcard_legacy: Limit injection of XEP-0153 to normal presence (fixes #1252) - util.datetime: Make sure timezone difference is calculated correctly (fixes #1262) - MUC: Fix traceback when requesting voice (fixes #1269) (thanks jonas’) - MUC: Adjust priorities of muc-get-default-role handlers (fixes #1272) - MUC: Allow changing data attached to an only owner (fixes #1273) - Multiple fixes and improvements to our experimental epoll (non-libevent) backend - util.stanza: Deserialize stanza without mutating input (fixes #711) - mod_mam: Only accept valid JIDs in and prefs. (fixes #1275) - util.pubsub: Restore subscription index from stored data (fixes #1281) - prosodyctl check: Add statisticsmanager settings to known global options - util.startup: Always reload logging after config (fixes #1284) - mod_posix: Don’t reload log files twice # Download As usual, download instructions for many platforms can be found on our download page: https://prosody.im/download If you have any questions, comments or other issues with this release, let us know! https://prosody.im/discuss -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] [PATCH] mod_http_upload_external: Include hashed/salted JID and quota
Hi JC, thanks for the patch! I think being able to identify the uploader is essential for many services, so thanks for tackling this. I don't have time for a full review right now, but a couple of things would have me request that you hold off pushing this to the repo just yet. I read the diff on my phone, and may be missing stuff, but it seems the q (quota) parameter is not signed, so open to modification by the user (probably not wanted). Also, I see this modifies the existing v/v2 protocols.. is it 100% backwards compatible? Even if it is right now, I don't think it will be if we need to keep 'q' and sign it. This leads me to prefer a v3. Regards, Matthew On Sun, 13 Jan 2019, 12:22 JC Brand Hi folks > > This patch for mod_http_upload_external does two things: > > 1. It adds a new config option `mod_http_upload_external_quota` which is a > number representing bytes. > > The quota is included as a "q" parameter in the URL of the PUT request to > the > external service. > > This allows the external service to enforce quotas, either globally or per > user. > > 2. New config options `mod_http_upload_external_include_jid_hash` and > `mod_http_upload_external_jid_hash_salt` > > The first is a boolean which makes it possible to group files per > hashed/salted JID. > The second is the salt, so that only admins can figure out the hash for a > particular JID. > > This option makes it possible to remove all files for a particular JID > (useful > for GDPR compliance) and also enables the external service to enforce > per-user > quotas. > > I've made a Pull Request to xmpp-http-upload.py to do just that. > https://github.com/horazont/xmpp-http-upload/pull/9 > > --- > > Feedback and comments welcome. If no-one objects, I'll push to the > prosody-modules repo. > > Thanks > JC > > -- > You received this message because you are subscribed to the Google Groups > "prosody-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to prosody-dev+unsubscr...@googlegroups.com. > To post to this group, send email to prosody-dev@googlegroups.com. > Visit this group at https://groups.google.com/group/prosody-dev. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] [PATCH] Adjust code to be able to be compiled in c89 mode
Hi Rosen,
Thanks for the patch. We actually decide to adopt C99 intentionally,
back in 2017 in fact: https://hg.prosody.im/trunk/rev/96fa5ef5d613 -
your patch reverts some of the changes we made around that time.
Lua itself targets C99 these days (Lua 5.3+), and we planning to drop
support for Lua 5.1 and 5.2 in future releases.
Nevertheless, I hope your patch will be found useful by anybody who
needs to remain C89-compatible for some reason!
Regards,
Matthew
PS. for future reference, please only include patches for source
files... your patch included binary patches for the *.so files which
are not in the source repository.
On Wed, 3 Apr 2019 at 12:30, Rosen Penev wrote:
>
> This can help with older compilers.
> ---
> util-src/compat.so | Bin 0 -> 8088 bytes
> util-src/encodings.so | Bin 0 -> 18240 bytes
> util-src/hashes.so | Bin 0 -> 18224 bytes
> util-src/net.so| Bin 0 -> 13264 bytes
> util-src/poll.so | Bin 0 -> 13528 bytes
> util-src/pposix.so | Bin 0 -> 29152 bytes
> util-src/ringbuffer.so | Bin 0 -> 17552 bytes
> util-src/signal.c | 3 ++-
> util-src/signal.so | Bin 0 -> 17832 bytes
> util-src/table.c | 3 ++-
> util-src/table.so | Bin 0 -> 8080 bytes
> util-src/time.so | Bin 0 -> 8288 bytes
> 12 files changed, 4 insertions(+), 2 deletions(-)
> create mode 100755 util-src/compat.so
> create mode 100755 util-src/encodings.so
> create mode 100755 util-src/hashes.so
> create mode 100755 util-src/net.so
> create mode 100755 util-src/poll.so
> create mode 100755 util-src/pposix.so
> create mode 100755 util-src/ringbuffer.so
> create mode 100755 util-src/signal.so
> create mode 100755 util-src/table.so
> create mode 100755 util-src/time.so
>
> diff --git a/util-src/compat.so b/util-src/compat.so
> new file mode 100755
> index
> ..928abce0f8de005118bd0a89459cf62d7a748fa4
> GIT binary patch
> literal 8088
> zcmeHMZ){W76~B%XNJwy81}q7ca1pHlwQkxDNa-^2hlEEJXqF{fx(&U&*e{8-7u(p+
> zZGs9!O1m|qkx+#+K1@@l_Cuwqj1N;qnT7(XXe&(>-B!f34~tfHOE$Enn%1Qfi+9d_
> z_h&yp+taiU`!cTdeD3+(^E>y?yS_g6_)J$%cZJU z>*=#eG)mj5d{a@ae}e--3K5b3_py$i-hfm|hGYe@p~AsKN`l8K^M({}Nbw-2)Knm=
> z9XFzqBtP$|cCXy2>>$~eOYbLkl zN|kflOg{Yd96mN6Mz{Cs@0~yR&7c4N)vCzFt#3|dgAZ{R+|EnKJRaZ6^C6$FvaOae
> z9>XSjI=Vi(^Rtg%ec|%#r-9#`7`(q_!mt1NSASJ2P6j2)dBQLUce7Cj?;||qHdOVG
> zNtW_+vJC#qGWZY6;4OrQ=<$~O2?%*X(k*&QjpyYu`1LZlkMIyZ-m*eKP;3@s!B9by
> zp9n#*MI=2qk7W~m`!0Ak*FU76Ek%AVO8X5WsP^x(s+X-2uN9WU6)c3VkB%qedfGNp
> zwyq037LVCNA0Z+1BmGD9sF^ZHV`
> zsA=1YBv*TMBQlr&{
> z>5;^E(y*mXBxM@5Y0HsuhwL{Ju@dP_%5j%A?U9&iMTKrg4cnku52w@4qzQ^gbLSDx
> zk7iXFROb!w6?IMysrLjN`eJ=ZE-k+<{_deHxo~i}ZN-JVU(Kou-v}op8&tnM4BlfX
> zAs3!ILaA|=3&&Z-oMsp9KF?cRxO>aBxp1`vvTMzStD|4yy)L{~BF@L43$JtG+Vq`j
> z?QGRRO-N`j&D#~(o7(g{)e9oKw~wIggZ=bbzrBrWtdB8sc`-}n!KYd0rC7cx^$yl~
> z36|%jet>m;70Z{T{y6Kr6w7l`-@`gD!SXq&?_iy$zC0!MCf0e%%SowkV!fL6A*p|_
> zIwVHUkuHli+v+2O0d2PGb866@T-9biu^VY>DOPD}8;@rfN5b{nUzGO87kE~Ao%q+-
> zaCYw%5(C=qHR5a6*8JMcigs=3pys=weYj>fki$mhu#O#;^EcIcg3LtbQEj^Qck8J(
> zz~iaY&bIauzSK%nSkma@M%5A0eLS2g9@yU&$mJo&{P^++Sul~_Qb?OQwWOWxTGD3T
> zT{^v%&CYbKPM=!!ooSNb?3Q|Z7gu@x+2BnwcxnC|H(lj-#8`|l3BYI&04%->02a>?
> zaJFl8Ho3;cx7qFrFFw2b(?59(cc)L?74_%m>)*P`CNsCVX*>MDaaaM|c%69fFQ{1s
> zX;!O5T)o0wUZqD4HQ?B zE@Vz5&4_JA#e{RX3EwvVQ@hBHH{(uX(sGM;Nb+ycMRLhI z-?qB-)#s?EorLjk+3ma8>>NoE2zCb=p02NbzIsX=Y%zXCWOa6KDqA>Sc
> z^z5MiZZX&%2!5xcbK|;-52**o_X`Byrgr&Tl56jm?M%5>?ybPR75M*L0mMm&i}0I{
> zcone=;!a#EaqruvmJMf8lhP4)@%h9B?SEg(CRktLQ zSfs&e&c|pfE>SdbTeaidMa=U>h0m*wfj1}}<9tKe)hLPnKF>PicgKdx zLoM7bCI6u0XG*S96WyxhLrU&bvRg^S!G}9L4}^9N3}@nYCbU2NM7a5p$M zTEfj=+U>yJft1kw6zSsr?r!#rirhXZ#Qg&AzYwn!*e8W}mB9Ne#McSD=R&;rKE~~S
> z+NGD&dKKE&h+efmh4_YC-lY&PaZi)}>qG_{%0=*tjk!F93#Rb|#O0Fq^||{_p?y%`
> zdsm3xNBNhK8 zr-Hui$YY^Bpzt}*`ahs>oLjKpPZb~C!*M@X$A;*Zc=7s-D?c~~;b&6X7q9aL!b^?+
> zN6OCub%4lNO!_Eo|6|z}5WP6yNJlB<|7~jYiQ@NoUE;<0hz}I*eP6$oofPl4zexMy
> z_g+a0SSp_qD1$c=9+G_&e(Wk^zqbtDSqASXyi`8r8xk+ho5aibIZb$}ab75c|5W z?<>r1UgFU5@&m#*iQ;qM*JbP%C0_g<|0wa|ywaUAe(n-pYF;9eveR~EWF#CB`IL}u
> zkL#3XiJNK4s6-R`sFfHtEIn!`Qfb}DObE`=SSDS1!u$6 zijkBtZtBs@`1mAIT$;>I6_`3nAR3ev(bc_5*Sq`Lk9O%@#}08q>(H~u+K(RTBuA9M
> z0;osR34P3nM>& zak?v)Y(gq3pW-S=OgXu>ayczFMczwh;!0=R{#}mFmE@vcT)8(VzsJKv&JB4n&V@1V
> z&Zv1(gd&`t9H(3xNjv4pG1TG-+YFD!GvVP(%!)n|iwdcY8R;<*j!wpj=}0>z!YR`-
> z7*w^SWs9&(KZdCq9!-#Hn-laYvytIcLZ zvu7FrrvSs00Tf}{KjXCN@?X6Fvc_>N|HL4EM7#pY_jGqr;c5;FQ|&W~4Z%lz3;AVb
> ziMSDQCLFX-g=1Ur5&uB)`M`zy z?1QV`{`vm_=67%-6~tYTw;fpW=~t$R&p8Yp6T&atKOhmeD>t$))LDL=9ycFx9ON7u
> zxe9*MAcv{V%}2ZkiTT0>bjWXe_=sa5Yp}4&0s4i%6COV9Taex`(7XShSA2AXI1|zv
> ziFx1u84v#z)gk1=7^sro{%1XW#I2A&@bIy2fWJ=_j`i^U!2J^ct9k9AL%v4bdKVvY
> z@E|*-0y{^`>%f0P4ZQczKjP&f#h+3OhIxaB_c%gaHUS@T^&$_7N=Sa@Kfs5)OigZn
> zF8)>>4CSe^1|H-!4 yd)IAxLG?eU?&o~o?WPCg$N9(G6=QevThzv{^*Beru)VJgzf*Pa5e${|^8W=W`Jk-;
>
> literal 0
> HcmV?d1
>
> diff --git a/util-src/encodings.so b/util-src/encodings.so
> new file mode 100755
> index
> ..cde176b518a2669d2d846da4de766ae43069f
Re: [prosody-dev] PATCH - Issue 1315 - c2s:closeall()
Hi João, On Tue, 9 Apr 2019 at 15:41, João Duarte wrote: > > > My very humble rookie attempt at dealing with issue 1315, after struggling > with a lot of prosody stuff this last week =D Looks fine overall :) Anything in particular you struggled with? We're definitely interested in feedback from new contributors, so we can find out what parts we should put more time into simplifying/documenting (contribution here would be welcome too if you're up for it!). Regarding the patch, if you can fix these two issues, we can merge it: 1) the changes to the configure file should not be in the commit. If you have a recent-enough mercurial, you can do this with: # First switch to the commit you want to fix (if it isn't already your current commit): hg update 58118875 # Remove the 'configure' file from the commit hg amend --extract configure 2) There is a minor typo in the help line, 'CLose' instead of 'Close'. Again after you fix this, just run `hg amend plugins/mod_admin_telnet.lua` to update the commit with your fix. If you then export the new commit (`hg export .` will export the current commit) then we can merge it! Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
Re: [prosody-dev] Converse.js and OMEMO libsignal-protocol.js Invalid signature
Hi Davide, On Mon, 22 Apr 2019 at 10:37, Davide Marchi wrote: > > Hi Friends! > On VPS Debian Stretch, Prosody 0.11, Fail2ban 0.9.6-2, Shorewall > 5.0.15.6-1, Apache 2.4.25, modsecurity 3.0.0-3, php7 7.0.33 I've just > installed Converse.js v4.2.0. > All seems working fine except for sending via OMEMO mode, which produces > the error: > > |"Error: Invalid signature libsignal-protocol.js:25278:28" Unless the Converse.js author suggests otherwise, I don't think this is a problem with your Prosody setup (I assume you have a standalone setup, not using mod_conversejs). Regards, Matthew -- You received this message because you are subscribed to the Google Groups "prosody-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev+unsubscr...@googlegroups.com. To post to this group, send email to prosody-dev@googlegroups.com. Visit this group at https://groups.google.com/group/prosody-dev. For more options, visit https://groups.google.com/d/optout.
