Despite I don't favour 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.

• local APT mirror
• automatic installation of Debian
• Building Debian packages

Print out all and full APT key fingerprints, not just the short ones.

apt-key adv --list-public-keys --with-fingerprint --with-colons

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(yeah, I was reading through man pages), I've overlooked the fact '.' isn't allowed character. I think I've got “saved” by some forum post in the end, resp. re-read man page again.

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 - probably a bit incomplete, but who cares years later

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!

Yet another round fun. My private Jabber has been off for a long time, because client decided server is no good anymore. This was due to vulnerabilities in SSL/TLS, resp. OpenSSL(?) and there seemed to be no fix for Jessie. I've ignored it, because I didn't have time and it's not that important to me anyway. Now, on the verge of migration to Stretch, I couldn't ignore it anymore. Of course I've hit couple snags on the way.

First of all, I found out I can neither perform backup or dump of ejabberd at Jessie. Mad props to devs, because all I had to do was to move /var/lib/ejabberd to the new server.

Second of all, there was the change of format of configuration file from whatever to YAML. In theory, you can convert old cfg to YAML via ejabberdctl convert_to_yaml src dst. Theory being theory, it wasn't my case.

ejabberdctl convert_to_yaml /etc/ejabberd/ejabberd-old.cfg /etc/ejabberd/ejabberd.yaml
Error: erofs

Not exactly nice, but worry not, because it's not that hard to adjust whatever needs to be adjusted, if your configuration is simple.

Last, but not least, was the certificate. I guess that was the issue on Jessie as well, but then I didn't really spend any time on it. Anyway, once I got ejabberd up and running, I couldn't connect. “Host unknown” was the error and some others later on. The following should've been the big hint, unfortunately wasn't.

foo@bar:~/openssl$ s_client -connect XXX:5222
CONNECTED(00000003)
140252860966144:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:252:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 176 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1512468671
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)                                                                                                                                                        
    Extended master secret: no                                                                                                                                                        
---                                                                                                                                                                                   
foo@bar:~/$ openssl s_client -connect XXX:5222 -starttls xmpp                                                               
CONNECTED(00000003)                                                                                                                                                                   
---                                                                                                                                                                                   
no peer certificate available                                                                                                                                                         
---
No client certificate CA names sent
---
SSL handshake has read 295 bytes and written 126 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
---

Well, at least I've found out you must(?) disable SSLv2 in the config as well. Also, that there is starttls_required: true. Anyway, this didn't help either and I didn't find error messages really helpful(I guess I should've, shouldn't I?).

2017-12-05 11:13:30.742 [error] <0.376.0> Supervisor ejabberd_s2s_in_sup had child undefined started with {ejabberd_s2s_in,start_link,undefined} at <0.528.0> exit with reason no match of right hand value {error,<<"SSL_CTX_use_certificate_file failed: error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak">>} in ejabberd_socket:starttls/3 line 153 in context child_terminated
2017-12-05 11:13:49.406 [error] <0.530.0> gen_fsm <0.530.0> in state wait_for_feature_request terminated with reason: no match of right hand value {error,<<"SSL_CTX_use_certificate_file failed: error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak">>} in ejabberd_socket:starttls/3 line 153

So, as the last ditch effort, I've generated new SSL certificate. Lo behold, the miracle! Everything works now. I wonder what the problem was. May be SSL cert generated in ~ 2013 wasn't strong enough and that's what the issue was about from the get go. Comparison of old and new one:

Signature Algorithm: md5WithRSAEncryption
Signature Algorithm: sha256WithRSAEncryption

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