When configuring an ejabberd server, we have access to the administration console through port 5280 by default using the internal erlang http server, but normally we have other web applications running on the same server (like a messaging archive interface) listening directly on the http port and we can easily configure the admin console to be accessed through this port using a proxy module (in this case, Apache’s mod_proxy).

To configure the redirector, simply include the following rules in your virtual host:

ProxyRequests Off
SSLProxyEngine On
ProxyPass / http://localhost:5280/ keepalive=On
ProxyPassReverse / http://localhost:5280/

After adding this rules and reloading the httpd server, you can easily access the ejabberd administration console directly from:

http://your.jabber.server.com/admin

The same rules can be applied on a secure virtual host running under mod_ssl (port 443), as this is the recommended and secure way to access an administration console.

A versão 11.3 do OpenSuSE foi lançada trazendo inúmeras atualizações e melhorias no sistema, entre elas Kernel 2.6.34, suporte nativo a MariaDB, Gnome 2.30.1 e KDE SC 4.4.4 nas versões de 32 e 64 bits.

Obs. Está disponível também no sistema o preview do Gnome 3.0!

Mais informações no site oficial do projeto…

Normally when running an Erlang application (like Ejabberd) using Mnesia internal database in a heavy loaded environment you run into the following log message:

=ERROR REPORT==== 23-Jun-2010::00:59:19 ===
Mnesia(node@server): ** WARNING ** Mnesia is overloaded: {dump_log, write_threshold}

This warning event is usually shown when using mnesia disc_copies tables and doing a lot of writes to disk all at once (considering you are using asynchronous writes), and of course it can get really annoying when they start happening every second. We can drastically reduce the occurrence of this error changing 2 configuration parameters, the dc_dump_limit and dump_log_write_threshold.

dc_dump_limit
This parameter controls how often disc_copies tables are dumped from memory, the default value is 4 that means if the log size is greater than the table size divided per 4 (table size / 4) it starts the dump. You can make dumps happen more often increasing this value.

dump_log_write_threshold
This parameter defines the maximum number of writes to the transaction log before a new dump is performed, using the default value 100 a new transaction log dump is performed after every 100 writes. You can increase this value giving more time to the write process to finish, but be sure that you have enough RAM on your server to maintain the transactions running.

And now, what does it mean?
Mnesia activity is recorded in transaction logs, that gets dumped to table logs, which in turn are dumped to table files on disk. By increasing the dump_log_write_threshold, transaction logs are dumped much less often, giving more time to the last dump be completed before the next dump is triggered. By the way, increasing the dc_dump_limit helps ensure that the disk table is dumped form the logs more often.

You can configure the parameters using the following syntax:

{mnesia, [{dc_dump_limit, 40}, {dump_log_write_threshold, 50000}]}
* Remember to change the values according to your needs!

It is possible to reload some ejabberd modules from disk without restarting ejabberd service.
This allows you to modify erlang source files (.erl) and reload them without the need of restarting.

Obs. Reloading modules is also possible via the web interface since ejabberd 0.9.1.

Open an Erlang console on the ejabberd node with:
# ejabberdctl debug

And select the module you wish to compile with:
c(mod_version).

If you just want to reload the .beam file (without recompiling the module), use:
l(mod_version).

Obs. Replace “mod_version” with the name of the file you want to recompile / reload.

There are lots of ways to upgrade ejabberd service without downtime, but sometimes when managing a corporate instant messaging server we need to reformulate our entire messaging architecture in a new server and we can just export all users and passwords to a list and then import them to the new server using just the command line and mod_cltextra / mod_admin module.

There’s no automated way to export all users like Openfire does, but we can dump our entire database, consider that you are using the internal erlang mnesia database, to a text file and filter just the values we want (in this case, users and passwords) using the following steps:

1. Dump the database to a text file:

# ejabberd_ctl ejabberd@localhost dump /tmp/mnesia.dump

2. Filter the dump to get only registered users

# cat /tmp/mnesia.dump | grep ‘{passwd,{‘ > /tmp/tmplist.txt

3. Convert your temporary generated file to the format you prefer, in this case getting a list (username, hostname, password):
   

   # sed -e ‘s/{passwd,{“//g;s/”,”/ /g;s/”},”/ /g;s/”}.//g’ /tmp/tmplist.txt > /tmp/userlist.txt

Obs. The database registers that store user information in the dump have the following format:
{passwd,{“USER”,”VIRTUAL-HOST”},”PASSWORD”}.