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.

You want some job being executed on regular basis as a part of cron.hourly/cron.daily/cron.weekly/cron.monthly, but nothing happens. What the problem might be, you ask?

1. make sure script has +x set
2. make sure anacron isn't present
3. make sure script name consists of allowed characters. And yes, '.' is not allowed character!

This did happen to me and I fould myself scratching on the head. Despite being close to solution, I've overlooked the fact '.' isn't allowed character. I think I've got “saved” by some forum post in the end.

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.

Of course I mean changing $PAGER system-wide and playing with words in title a bit. To change $PAGER use update-alternatives. My ex-colleague showed this one to me, to be honest. Of course update-alternatives allows you to configure more stuff, yet I haven't used it for more than this.

So, to do the trick:

root@foo:~# update-alternatives --config pager

and choose whatever pager you like. My choice is less. Of course, prerequisite is your favorite “pager” is already installed. You know to do that, don't you?

I don't know where to get list of alternatives nor I looked/searched for one. To get list of “alternatives” which are up for configuration, issue:

root@foo:~# ls /etc/alternatives/ | grep -E -e '^[a-z0-9]+$'

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

Simply - don't. If you do, make sure you modify your “old” configs to reflect paths in Debian, or else … problems.

Postfix version:

root@foo:~# apt-cache show postfix
Package: postfix
Priority: extra
Section: mail
Installed-Size: 3340
Maintainer: LaMont Jones <lamont@debian.org>
Architecture: amd64
Version: 2.7.1-1+squeeze1

Error in log:

Nov  5 10:43:29 foo postfix/local[8229]: fatal: open dictionary: expecting "type:name" form instead of "#"
Nov  5 10:43:30 foo postfix/master[29102]: warning: process /usr/lib/postfix/local pid 8229 exit status 1
Nov  5 10:43:30 foo postfix/master[29102]: warning: /usr/lib/postfix/local: bad command startup -- throttling

If you look at postfix in big-picture it tells you where the problem is. However, it is one of less descriptive cases of error.

Config lines to blame:

alias_maps = hash:/etc/postfix/aliases #, hash:/var/lib/mailman/data/aliases
[...]
alias_database = hash:/etc/postfix/aliases #, hash:/var/lib/mailman/data/aliases

Strange enough this works perfectly at different host … and with different version of Postfix. Well … shrug

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