Recent posts
Preferences
Feeds
- - Abhi’s Weblog » XMPP
- - Clochix - Tag - XMPP
- - ejabberd Community Site | the Erlang Jabber/XMPP daemon
- - Etherpad team blog - Live Document Collaboration from the Ethervillage
- - Instant Messaging | ndl@home
- - Je code donc je suis » XMPP
- - munin-monitoring/contrib - GitHub
- - News Jabber
- - nil desperandum
- - Piwik
- - Planete JabberFR
- - ProcessOne Blogs
- - Revisions : alternc
- - ↓ Revisions : alternc-awstats
- - Revisions : alternc-munin
- - Revisions : Icecast
- - SHOUTcast Blog
- - sinnwidrig » monitoring
- - Tag - munin - Personal Workflow Blog
opml
Sedna
24 May
Revisions : alternc http://www.alternc.org/log/alternc/trunk
-
16:09
DON'T show password in cleartext if you can avoid it, never -- Log
ejabberd Community Site | the Erlang Jabber/XMPP daemon http://www.ejabberd.im/
-
12:52
In reply to web_admin empty response from server when logging in as admin :
Maybe the code crashes, an error report is added to the ejabberd log, and returns an empty web page. Check if the ejabberd log has some ERROR REPORT.
23 May
Planete JabberFR http://planet.jabberfr.org/
-
23:47
Rapidement, je voulais écrire un article à ce propos, mais quelques contributeurs ont rapidement couvert le sujet sur LinuxFr.org :
Google Hangouts remplace Talk : la fin de la fédération XMPP ?
Quelques commentaires sont également intéressants…
--
Revisions : alternc http://www.alternc.org/log/alternc/trunk
- 17:39
- 17:38
- 17:37
-
18:29
Bug pour lister les droits SQL -- Log
-
18:18Revision 4346: L'aternance des couleurs dans les listes est maintenant en CSS3 - Revisions : alterncL'aternance des couleurs dans les listes est maintenant en CSS3 -- Log
22 May
ejabberd Community Site | the Erlang Jabber/XMPP daemon http://www.ejabberd.im/
-
03:21
In reply to Modules development:
ejabberd internal modules using only the route table can also be used as external modules conform to XEP-0114 (Jabber Component Protocol) with epeios, and thus, they can be used with any other XEP-0114 compliant XMPP servers.
If you wish to gamble on-line this online casino gambling have every one of the perfect wager games that you've been seeking.
This excellent on the net betting site delivers both web gambling with some of the finest slot machine games out there and also the downloadable online gambling which offers much more various { wager site games.
21 May
ejabberd Community Site | the Erlang Jabber/XMPP daemon http://www.ejabberd.im/
-
12:32
In reply to module mod_muc_odbc for Mysql. Need your help.:
I cannot open a muc_odbc conference.
My Config is (as of ejabberdctl dump file)
{mod_muc_odbc,
[{host,"conference.@HOST@"},
{access,muc},
{access_create,muc_create},
{access_persistent,muc_create},
{access_admin,muc_admin}]},There are no errors in the log file.
If I change mod_muc_odbc to mod_muc it works.
Ngrepping the traffic I can see that odbc is working
Login user:T 127.0.0.1:39266 -> 127.0.0.1:3306 [AP]
3....select password from users where username='admin';
#
T 127.0.0.1:3306 -> 127.0.0.1:39266 [AP]
.....8....def.ejabberd.users.users.password.password.!.........................password.........Open a MUC
T 127.0.0.1:55881 -> 127.0.0.1:3306 [AP]
Y....select opts from muc_room where name='main2' and host='conference.my_jabber.de';
#
T 127.0.0.1:3306 -> 127.0.0.1:55881 [AP]
.....6....def.ejabberd.muc_room.muc_room.opts.opts.!..................................So database connection is there.
I also manually entered an entry into the 'rooms' database table (with empty opts field), but no change.Grepping on port 5222 I can see:
T 192.168.178.126:39428 -> 192.168.178.171:5222 [AP]test
#
T 192.168.178.171:5222 -> 192.168.178.126:39428 [AP]test Any help is appreciated.
-
12:37
In reply to module mod_muc_odbc for Mysql. Need your help.:
I cannot open a muc_odbc conference.
My Config is (as of ejabberdctl dump file)
{mod_muc_odbc,
[{host,"conference.@HOST@"},
{access,muc},
{access_create,muc_create},
{access_persistent,muc_create},
{access_admin,muc_admin}]},There are no errors in the log file.
If I change mod_muc_odbc to mod_muc it works.
Ngrepping the traffic I can see that odbc is working
Login user:T 127.0.0.1:39266 -> 127.0.0.1:3306 [AP]
3....select password from users where username='admin';
#
T 127.0.0.1:3306 -> 127.0.0.1:39266 [AP]
.....8....def.ejabberd.users.users.password.password.!.........................password.........Open a MUC
T 127.0.0.1:55881 -> 127.0.0.1:3306 [AP]
Y....select opts from muc_room where name='main2' and host='conference.my_jabber.de';
#
T 127.0.0.1:3306 -> 127.0.0.1:55881 [AP]
.....6....def.ejabberd.muc_room.muc_room.opts.opts.!..................................So database connection is there.
I also manually entered an entry into the 'rooms' database table (with empty opts field), but no change.Grepping on port 5222 I can see:
T 192.168.178.126:39428 -> 192.168.178.171:5222 [AP]test
#
T 192.168.178.171:5222 -> 192.168.178.126:39428 [AP]test Any help is appreciated.
-
17:17
In reply to Display chatrooms on a website:
You may add module mod_admin_extra
Then you will have an additional command, e.g.ejabberdctl muc_online_roomsThis works and returns all muc rooms.
I have also tried this via xml-rpc (ruby), but I get an error:
result = client.call("muc_online_rooms","my.domain")T 127.0.0.1:44922 -> 127.0.0.1:4560 [AP]
<?xml version="1.0" ?>muc_online_rooms my_domain
##
T 127.0.0.1:4560 -> 127.0.0.1:44922 [AP]
HTTP/1.1 200 OK..Content-Length: 316..Server: Erlang/1.13..Content-Type: text/xml..Connection: close....<?xml version="1.0"?>faultCode -112 faultString Error -112.Unknown call: {call,muc_online_rooms,["my_domain"]} So I cannot use it. But this should be the way.
If you get it working, please give a feedbck, as I would be very much interested.
-
17:03
In reply to module mod_muc_odbc for Mysql. Need your help.:
Note the above post is happening when I have manually set up an entry in the muc_rooms tabele.
It dissappears when I delete this entry.However I cannot open a muc_odbc conference.
My Config is (as of ejabberdctl dump file)
{mod_muc_odbc,
[{host,"conference.@HOST@"},
{access,muc},
{access_create,muc_create},
{access_persistent,muc_create},
{access_admin,muc_admin}]},There are no errors in the log file.
If I change mod_muc_odbc to mod_muc it works.
Ngrepping the traffic I can see that odbc is working
Login user:T 127.0.0.1:39266 -> 127.0.0.1:3306 [AP]
3....select password from users where username='admin';
#
T 127.0.0.1:3306 -> 127.0.0.1:39266 [AP]
.....8....def.ejabberd.users.users.password.password.!.........................password.........Open a MUC
T 127.0.0.1:55881 -> 127.0.0.1:3306 [AP]
Y....select opts from muc_room where name='main2' and host='conference.my_jabber.de';
#
T 127.0.0.1:3306 -> 127.0.0.1:55881 [AP]
.....6....def.ejabberd.muc_room.muc_room.opts.opts.!..................................So database connection is there.
I also manually entered an entry into the 'rooms' database table (with empty opts field), but no change.Grepping on port 5222 I can see:
T 192.168.178.126:39428 -> 192.168.178.171:5222 [AP]test
#
T 192.168.178.171:5222 -> 192.168.178.126:39428 [AP]test Any help is appreciated.
-
18:29
In reply to gzip compression for BOSH HTTP traffic:
Few comments:
- gzipping all of the content unconditionally is just a waste of CPU, due to the nature of BOSH most server responses are very small (they contain only
"") and fit into a single packet, gzipping single packet response gives completely no gain, but obviously uses CPU; it would be better to gzip only responses that are larger than one packet (HTTP body larger than 1200-1300 bytes, depending on the amount of HTTP headers) - ungzipping incoming traffic is useless, no browser will send such traffic since there is no way for a browser to know, beforehand, that the server supports it
- ejabberd uses GPL2, not GPL3 (but I'm not sure if that matters)
- if you want to include your patch in ejabberd then send a pull request on github
- gzipping all of the content unconditionally is just a waste of CPU, due to the nature of BOSH most server responses are very small (they contain only
munin-monitoring/contrib - GitHub https://github.com/munin-monitoring/contrib/
-
13:43
Merge pull request #306 from beanieboi/patch-1 Update lighttpd_
-
14:13
Merge pull request #309 from jd/master Fix getenv usage in swift plugins
ejabberd Community Site | the Erlang Jabber/XMPP daemon http://www.ejabberd.im/
-
12:44
In reply to module mod_muc_odbc for Mysql. Need your help.:
I just received a crash report:
=PROGRESS REPORT==== 21-May-2013::14:25:01 ===
supervisor: {local,ejabberd_sup}
started: [{pid,<0.325.0>},
{name,'ejabberd_mod_muc_sup_my_domain.de'},
{mfargs,
{ejabberd_tmp_sup,start_link,
['ejabberd_mod_muc_sup_my_domain.de',
mod_muc_room]}},
{restart_type,permanent},
{shutdown,infinity},
{child_type,supervisor}]=CRASH REPORT==== 21-May-2013::14:25:01 ===
crasher:
initial call: mod_muc_odbc:init/1
pid: <0.326.0>
registered_name: []
exception exit: {undef,[{ejabberd_odbc,decode_term,[[]]},
{mod_muc_odbc,'-load_permanent_rooms/5-fun-0-',6},
{lists,foreach,2},
{mod_muc_odbc,init,1},
{gen_server,init_it,6},
{proc_lib,init_p_do_apply,3}]}
in function gen_server:init_it/6
ancestors: [ejabberd_sup,<0.37.0>]
messages: []
links: [<0.62.0>,<0.226.0>]
dictionary: [] -
06:33
In reply to Управление shared_roster через XMPP:
Да, ejabber v 2.1.10 на Ubuntu 12.04
Можно перевести на 11 или 12 версию.
20 May
Planete JabberFR http://planet.jabberfr.org/
-
13:46
Voici 8 mois qu’a eu lieu la dernière réunion de travail. 8 mois pendant lesquels on s’est déchaîné comme des fous !
Ha, omega me souffle que ce n’est pas crédible, et il n’a pas tout à fait tort (IRL, tout ça). Quoi qu’il en soit, il y a quand même eu suffisament d’avancées pour que cela vaille la peine qu’on fasse le point sur la situation actuelle, et que l’on prépare l’avenir ensemble.
Une réunion aura donc lieu le jeudi 23 mai 2013 de 20h30 à 22h00 (heures de Paris) sur le salon association@chat.jabberfr.org. La réunion étant ouverte à tout le monde (membres de l’association ou pas), nous vous attendons nombreux, mais dans le calme et respectueux du lieu.
L’ordre du jour est disponible dès maintenant sur le wiki. Pour les plus impatients, sachez que l’on y parlera, entre autres, de la migration de im2 sur prosody (et de ce que ça entraîne) et du fait que l’on stagne à 13 membres depuis janvier. Le temps restant sera consacré aux éventuelles questions du « public » restées sans réponse.
News Jabber http://news.jabberfr.org/
-
11:46
Voici 8 mois qu’a eu lieu la dernière réunion de travail. 8 mois pendant lesquels on s’est déchaîné comme des fous !
Ha, omega me souffle que ce n’est pas crédible, et il n’a pas tout à fait tort (IRL, tout ça). Quoi qu’il en soit, il y a quand même eu suffisament d’avancées pour que cela vaille la peine qu’on fasse le point sur la situation actuelle, et que l’on prépare l’avenir ensemble.
Une réunion aura donc lieu le jeudi 23 mai 2013 de 20h30 à 22h00 (heures de Paris) sur le salon association@chat.jabberfr.org. La réunion étant ouverte à tout le monde (membres de l’association ou pas), nous vous attendons nombreux, mais dans le calme et respectueux du lieu.
L’ordre du jour est disponible dès maintenant sur le wiki. Pour les plus impatients, sachez que l’on y parlera, entre autres, de la migration de im2 sur prosody (et de ce que ça entraîne) et du fait que l’on stagne à 13 membres depuis janvier. Le temps restant sera consacré aux éventuelles questions du « public » restées sans réponse.
-- JabberFR
ejabberd Community Site | the Erlang Jabber/XMPP daemon http://www.ejabberd.im/
-
00:44
In reply to Authentication with any login and password:
Configure your server to Anonymous authentication.
https://git.process-one.net/ejabberd/mainline/blobs/raw/v2.1.11/doc/guid...
17 May
munin-monitoring/contrib - GitHub https://github.com/munin-monitoring/contrib/
-
10:36
Fix getenv usage in swift plugins os.getenv returns a string, not an integer, so using %s will fail if the variable SWIFT_OBJECT_PORT is set.
ProcessOne Blogs http://www.process-one.net/en/blogs/
-
19:55
As you know, ProcessOne is about realtime messaging. Our core component is XMPP ejabberd scalable and ubiquitous server. We recently acquired Boxcar to use a familiar and popular brand for our large scale push notification service for mobile as well.
From this perspective, Google’s huge update on its Cloud Messaging service is the biggest announcement from this year Google I/O, as it mixes our two core strengths. We strongly believe this is a big deal for mobile developers and we will explain why.
What is Google Cloud Messaging (GCM) ?
In case you never heard about it, here is a quick overview.
Google Cloud Messaging have been announced last year as a replacement of Google Cloud to Device Messaging. This is a service that allows mobile developer to notify mobile devices (but also Chrome browser) about important changes on the server-side component of the application. It makes it possible for the device to stay up to date, without the need to use polling. Polling is about checking periodically for updates on your server and is bad for several reasons:
- it consumes lot of battery, periodically waking up the mobile device network stack.
- it consumes a lot of useless resources on the server as most of this resource lead to a “no update” reply.
- it introduces latency as the request for new data can happen long after the data availability (unless you put a very low polling interval, which is even worse for the mobile battery). You can get your news alert hours after every one already knows about it, which defeat the purpose of the alert in the first place.
Push notifications avoid all those drawbacks, saving battery life, providing lower latency, reducing server load. As a permanently connected session to Google servers, it get the important notification messages as soon as they happen, in a battery efficient way.
Being a service that runs at device level, it can be optimized across applications running on the same device and perform further battery saving benefits.
So, this is a really critical feature to implement in application relying on data coming from the network (which actually covers a lot of applications).
GCM offers nice outstanding features like:
- Support two use cases:
- “send to sync”: short notification to tell client to get update from developer server.
- “send data”: larger notification containing the data payload, avoiding an extra client to developer server roundtrip.
- Time to live can be used to destroy message without notification if device was not online before its expiration. Pending messages can also be replaced with the collapse feature.
- Delay when idle can be use for less urgent notifications. Device will get it when becoming active again.
- Multicast messages to send the same notification to up to 1000 devices.
What does GCM update brings to developers ?
The new update is a brand new service deployment bringing a large set of new features for developers.
In short, it brings:
- Persistent connections are supported between developer backend and Google, allowing sending a larger number of notifications faster.
- Upstream messaging: This allows the device to send back notifications to the developer server, through Google platform.
- Notifications synchronization between devices. Basically, this allows a developer to remove a notification from a device when it has been read / processed on another device.
GCM Cloud Connection Service (CCS): Persistent connections using XMPP
Google choose to use XMPP to allow developers to keep a persistent connection. It works as follow:
- You open an XMPP client connection to Google XMPP GCM server (Port 5235 on gcm.googleapis.com).
- You can then keep the secure connection open for as long as you wish.
- You can then send your usual GCM JSON payload in XMPP message packets.
- This is streaming so you receive possible errors asynchronously and you can match it to original push thanks to XMPP message id.
This alone brings you a huge performance increase, allowing your server to send up to 4000 messages per second on the persistent connection. Knowing you are allowed up to 10 connections, you can possibly send many notifications fast (up to 40k notifications per second).
A few things to note:
- You cannot use multicast messages with XMPP persistant connection (at least yet).
- However, you can mix HTTP connexions and XMPP persistant connections in your use case to optimize the performance depending on the use case.
Upstream messaging
Upstream messaging allows your client to send data asynchronously to your server. Compared to HTTP posts, it offer several advantages:
- It is easy for client developer, with a simple gcm.send command. This is “fire and forget”. Client developer sends the data. Android GCM framework save it locally, with the commitment to deliver it.
- It is reliable with reliability handled transparently by GCM mobile framework on the client. There is acknowledgement mechanism on the client and between GCM and your server that ensure no message can be lost.
- Timing to send is optimized across mobile applications. This allow significant battery saving for messages that are not very time sensitive. Optimization is even performed based on the server side down stream needs. If client or server send messages first, the other direction queue is flushed at the same time.
- It supports time to live. If the message could not be send, because network is unavailable and is not relevant anymore, it is discarded.
As a developer, your server will receive the message through an XMPP connection. However, be very careful about your server efficiency: you have to be robust and read data fast as the GCM server will queue for you 100 messages before starting to overwrite them (and if you are offline for 24 hours it will discard your messages).
Multi-devices notification synchronisation
The goal of this feature is to makes your notifications state becomes up to date and consistent across a user devices, by propagating state change between the user application installations on your various devices.
This feature is designed to bring many added benefits in the way multiple devices are handled.
First, to know that your app is used by the same users, you can group your device Registration Ids under the same notification_key. Notification key is typically a hash of the username. You are allowed up to 10 devices linked to that notification_key.
Once you have done that, you can use that notification_key as a user id to send notifications to all devices of a given user. By doing so, you let GCM performs lots of optimizations under the hood. Notification will be send in priority to the active device or the last active device. Other devices will get the notification a bit later in a delay while idle type of delivery.
Once the notification has been processed and dismissed, other devices are notified and they can remove the notification as well. If they were not notified yet, notification is directly canceled from the notification queue.
Conclusion
As you see, update to Google Cloud Messaging is really a big update for developers, increasing the number of situation this platform is relevant.
We are already working on supporting those improvements on our push notification platform to help you all benefits of those improvements.
Stay tuned for more information on this support very soon.
Here is the video of Francesco Nerieri’s talk on GCM:
