Move ejabberd server to another with same hostname?

When i try to use the same cfg file and using the load command in ejabberdctl it creates the tables, but everyone that uses the server says their client gives "not authorized"

I'm stumped. Thanks.

Are the accounts correctly

Are the accounts correctly recovered? Are you able to login to the webadmin? Or if you use ejabberdctl to get the list of accounts, are they there?

Doesn't seem to be

Doesn't seem to be so.
ejabberdctl registered_users (domain.domain)
output is just blank

i just did ejabberdctl restore /tmp/restorefile
again from the backup (i did this first)

** Table caps_features already exists on ejabberd@server1, just entering data
** Table privacy already exists on ejabberd@server1, just entering data
** Table passwd already exists on ejabberd@server1, just entering data
** Table irc_custom already exists on ejabberd@server1, just entering data
** Table roster already exists on ejabberd@server1, just entering data
** Table last_activity already exists on ejabberd@server1, just entering data
** Table sr_user already exists on ejabberd@server1, just entering data
** Table roster_version already exists on ejabberd@server1, just entering data
** Table offline_msg already exists on ejabberd@server1, just entering data
** Table motd already exists on ejabberd@server1, just entering data
** Table vcard already exists on ejabberd@server1, just entering data
** Table pubsub_index already exists on ejabberd@server1, just entering data
** Table sr_group already exists on ejabberd@server1, just entering data
** Table vcard_search already exists on ejabberd@server1, just entering data
** Table motd_users already exists on ejabberd@server1, just entering data
** Table private_storage already exists on ejabberd@server1, just entering data
** Table oauth_token already exists on ejabberd@server1, just entering data
** Table pubsub_item already exists on ejabberd@server1, just entering data
** Table muc_room already exists on ejabberd@server1, just entering data
** Table pubsub_state already exists on ejabberd@server1, just entering data
** Table muc_registered already exists on ejabberd@server1, just entering data
** Table pubsub_node already exists on ejabberd@server1, just entering data

it says everything is there?

on my old server
if i run ejabberdctl registered_users domain.domain it outputs my users list.

So backup+restore doesn't

So backup+restore doesn't show error messages, but _apparently_ accounts aren't there. In that new server with restored database that doesn't show any account: try to dump that database to a text file with "ejabberdctl dump ...". Is there any data there, or is the database really empty of your old data?

By the way, if you have few users (just a few hundreds), you can try in the old server to dump, and in the new server load.

In fact, if you use the same erlang node name in both old and new ejabberd deployments, you can simply copy the old mnesia spool dir (with all its files) to the new location, then start new server.

The text file has everything

The text file has everything in it, but if i try to find "account" or something like that, no results.

But, there is a roster with the user's contacts.

There is this too

{pubsub_item,{<<"XXXXXXXXX">>,X},
{{xxx,xxx,xxxx},{<<"user">>,<<"domain">>,<<>>}},
{{xxxx,xxxxxx,xxxxx},
{<<"user">>,<<"domain">>,
<<"lookslikeahash?">>}},
[{xmlel,<<"tune">>,
[{<<"xmlns">>,<<"http://jabber.org/protocol/tune">>}],
[]}]}.

If you used mnesia/internal

If you used mnesia/internal auth_method, then the account credentials were stored in the 'passwd' mnesia table. So, in your text dump file you should have something like:

{passwd,{<<"user1">>,<<"localhost">>},<<"mypass11">>}.
{passwd,{<<"user2">>,<<"localhost">>},<<"mypass2222">>}.

That means user1@localhost can login to the server providing the password mypass11.

{passwd,{<<"user1">>,<<"domai

{passwd,{<<"user1">>,<<"domain.com">>},
{scram,<<"hash">>,
<<"hash">>,
<<"hash">>,4096}}.

All my users are there.
I'm really confused :(

Ah, that's possible, I forgot

Ah, that's possible, I forgot it.

This happens because ejabberd got configured to store passwords scrammed, instead of plaintext, for security reasons:

auth_password_format: scram

Now, if a client tries to authenticate using an old method (called legacy), ejabberd cannot use the SCRAM method to verify it, so it gets rejected even if the user provided the correct password:

12:32:50.707 [info] (#Port<0.23075>) Accepted connection
 127.0.0.1:34575 -> 127.0.0.1:5222
12:32:51.905 [info] ({socket_state,gen_tcp,#Port<0.23075>,<0.672.0>})
 Failed legacy authentication for user1@localhost/tka1 from 127.0.0.1

From now on, the clients must use the XMPP prefered auth method: SASL. Most clients support it, like Tkabber, Psi, Gajim... Almost all recent XMPP/Jabber clients should support it, and is enabled by default.

In your case, check what clients are having problems to login.
Try with a desktop good client, like Psi or Gajim.
Also, try to create a new account now, and login to it.

Gajim and Pidgin (windows)

Gajim and Pidgin (windows) both fail password still,
and if i try to register a new account (as suggested)

ejabberdctl register user domain.domain password
Can't register user user@domain.domain at node ejabberd@server: not_allowed

Thanks for all the help so far.

Umm, Gajim 0.16.5 in Debian

Umm, Gajim 0.16.5 in Debian logins correctly to a server with scrammed passwords. In fact Gajim has no option to configure that, so surely you have the client side correctly configured.

Do you have starttls enabled in the listener, and scram enabled? Something like this:

listen: 
  - 
    port: 5222
    module: ejabberd_c2s
    certfile: "/etc/ejabberd/ssl.pem"
    starttls: true
...

auth_password_format: scram

Regarding account registration, enable mod_register in your configuration, and check that the 'register' Access rule allows registrarion.

listen: - port: 5222

listen:
  -
    port: 5222
    ip: "::"
    module: ejabberd_c2s
    ##
    ## If TLS is compiled in and you installed a SSL
    ## certificate, specify the full path to the
    ## file and uncomment these lines:
    ##
    certfile: "/etc/ejabberd/ejabberdcert.pem" (own cert that looks like private key + cert)
    starttls: true

and later down in the file is

auth_password_format: scram

That config looks good, I

That config looks good, I copy it to my ejabberd 16.09, and can login with Tkabber and Gajim (both on Linux).

Looking at your first post, you have an old server that runs perfectly, and the login problem appears when you install a new ejabberd and copy the old database, right?

In the old server, passwords were already scrammed, or were still in plaintext? Do you use the same ejabberd version (this shouldn't matter, but who knows)? I mean, what are the differences between good old and new problematic server?

Already scrammed, and same

Already scrammed, and same version.

Anyone?

Anyone?

Syndicate content