====== Debian ======
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.
===== Other topics =====
* [[apt-mirror|local APT mirror]]
* [[automatic-installation|automatic installation of Debian]]
* [[build_package|Building Debian packages]]
===== Quick Tips and Tricks =====
==== APT fingerprints ====
Print out all and full APT key fingerprints, not just the short ones.
apt-key adv --list-public-keys --with-fingerprint --with-colons
==== cron.hourly/cron.daily/cron.weekly/cron.monthly jobs aren't being executed ====
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?
- make sure script has ''+x'' set
- make sure ''anacron'' isn't present
- 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.
==== Dependency hell ====
**NOTE:** I have no idea how ''apt'' works. **''# apt-cache show ;''** 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
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''.
==== Change ''$PAGER'' system-wide aka I hate you ''more'', Debian ====
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]+$'
==== Migrating ejabberd 2.0.x to 2.1.x ====
**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/
=== Version 1: ===
* 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 [[http://www.ejabberd.im/migrate-host|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.
=== Version 2: ===
* 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** FIXME 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!
==== Migrating ejabberd from Jessie to Stretch ====
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
==== Network services being started by default ====
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
==== Postfix ====
=== Configuration files from different Postfix/distro ===
Simply - don't. If you do, make sure you modify your "old"
configs to reflect paths in Debian, or else ... problems. :-)
=== Trailing hash '#' aka "what the problem is?" ===
Postfix version:
root@foo:~# apt-cache show postfix
Package: postfix
Priority: extra
Section: mail
Installed-Size: 3340
Maintainer: LaMont Jones
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 [[http://postfix.eu.org/big-picture.html|postfix in big-picture]] it
tells you where the problem is. However, it is one of less descriptive cases of
error.
{{:linux:debian:postfix-big-picture.gif?700|}}
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 :-)
==== SysV init scripts are complicated ====
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