Despite I don't favor Debian distribution too much for this and that, this page is not meant as rant. It is actually quick reference for me. If you find it useful, good. If not, just move on.

If you got offended by the content, I'm sorry.

NOTE: I have no idea how apt works. # apt-cache show <package> ; didn't show MySQL as recommended package nor as suggested one. Yes, I will have to read up on apt … some day.

Just to give an example. Installation of postfix surprised me with installation of libmysql, mysql-client and what not.

If you don't want to give in so easy, because I don't need nor plan to utilize MySQL at this host right now, you can try:

root@foo:~# apt-get install --no-install-recommends <packages_to_install>

This way I ended up with what I wanted and needed - postfix and ssl-cert as an extra, which made a bit of sense. However, I didn't get away with it in case of dovecot.

WARNING - still work in progress!!!

Debian 6.0 Squeeze, however I think this doesn't depend on your GNU/Linux distribution.

• Migrating from: ejabberd-2.0.5-x86_84
• Migrating to: ejabberd-2.1.5-3+squeeze1

I recommend to backup /var/lib/ejabberd prior to any changes. If anything goes wrong or doesn't work, you can start very quickly from scratch.

root@foo:~# # backup
root@foo:~# cp -apr /var/lib/ejabberd /tmp

root@foo:~# #restore, which is just way around
root@foo:~# cp -apr /tmp/ejabberd /var/lib/

• dump database at old ejabberd

root@foo:~# ejabberdctl backup /tmp/ejabberd.backup

• move backup, configs etc. to new machine, if needed, using eg. SCP
• change hostname, if needed or got changed, as described in Migrate FAQ
• restore database as shown bellow. Skipping tables can be iterative process:

root@foo:~# sh /etc/init.d/ejabberd stop
root@foo:~# ejabberd debug
[...]
(ejabberd@foo)1> mnesia:restore("/tmp/ejabberd2.backup",[{skip_tables,[disco_publish]}]).
{aborted,{no_exists,user_caps}}
(ejabberd@foo)2> mnesia:restore("/tmp/ejabberd2.backup",[{skip_tables,[disco_publish,user_caps]}]). 
{aborted,{no_exists,user_caps_resources}}
(ejabberd@foo)3> mnesia:restore("/tmp/ejabberd2.backup",[{skip_tables,[disco_publish,user_caps,user_caps_resources]}]).
{atomic,[config,privacy,local_config,passwd,irc_custom,
         roster,last_activity,sr_user,offline_msg,route,motd,acl,s2s,
         vcard,caps_features,sr_group,mod_register_ip,vcard_search,
         motd_users,session,private_storage,pubsub_item,muc_room,
         pubsub_state,iq_response,muc_registered,muc_online_room|...]}
(ejabberd@foo)4>q().

• start ejabberd

root@foo:~# sh /etc/init.d/ejabberd start

• now, I would like to say “enjoy”, but there was no joy. I couldn't get authenticated no matter what. Perhaps password encryption got changed, I don't know.

• dump database at old server

root@foo:~# ejabberctl dump /tmp/ejabberd.dump

• move backup, configs etc. to new machine, if needed, using eg. SCP
• start ejabberd at new server
• restore database
  • you may try to restore database right away by following command. However, it didn't work for me, not even after removing disco stuff.
  • OR write a parser to get rid of problematic things in .dump
    • problematic stuff is:
      • everything related to disco
      • user_caps - since it has a lot of entries, I didn't want to remove it by hand. Thus I've removed just 'mod_caps'
      • pubsub_node - I had to remove data related to this table, because something got changed and no, I'm not going to study Erlang right now

root@foo:~# ejabberdctl load /tmp/ejabberd.dump

• hopefully enjoy!

Ok, this is a bit of rant I have. Still, we are cool.

I found this one quite annoying, bothering and worrying at the same time. You have your fresh install, or install new network service, and everything gets started. MySQL, HTTP server, mail server etc. everything is up and running. Great, but you haven't configured it yet. And despite I'm sure default/dist configuration is as much as secure as possible(right???), I still don't trust it and I still prefer to start (network) services when they're “ready” to start, operate and serve.

So don't forget to check your fresh installation, or you might end up unpleasantly surprised!

root@foo:~# netstat -nlp | less

I've seen something like this at linuxquestions.org in thread regarding to SysV init vs. BSD init scripts.

I, as a Slackware user, like BSD init scripts. They're not the best but have their pros and cons. Anyway, I don't see anything complicated on SysV init scripts unless you have to write one and you didn't bother to read specifications and distribution specifications as well. Management of init scripts in Debian is easy.

“Easy you say? But init scripts are linked into N directories. And how am I supposed to know where to link which one, if I want to enable service Foo? Screw this!”.

Heh, just calm down and relax. update-rc.d is your best friend. Not only you can use it to enable/disable service, but for start/stop service as well.

root@foo:~# update-rc.d lighttpd disable
root@foo:~# update-rc.d lighttpd enable