Category Archives: Debian

ntp running in chroot stopped working after Debian Stretch upgrade

Today I upgraded my root server from Jessie to Stretch, and suddenly ntp stopped working.

I found errors like follows in the log, which were obviously due to failures in name resolution:

2018-05-31T07:44:48.900756+00:00 myhost ntpd[22855]: giving up resolving host 1.debian.pool.ntp.org: Servname not supported for ai_socktype (-8)

The solution to make this work was to bind-mount some files and directories essential for name resolution into the chroot jail.

First create some directories and some dummy files:

# mkdir /var/lib/ntp/etc /var/lib/ntp/lib /var/lib/ntp/proc
# mkdir /var/lib/ntp/usr /var/lib/ntp/usr/lib
# touch /var/lib/ntp/etc/resolv.conf /var/lib/ntp/etc/services

Then update your /etc/fstab as follows:

...
#ntpd chroot mounts
/etc/resolv.conf  /var/lib/ntp/etc/resolv.conf none bind 0 0
/etc/services	  /var/lib/ntp/etc/services none bind 0 0
/lib		  /var/lib/ntp/lib none bind 0 0
/usr/lib	  /var/lib/ntp/usr/lib none bind 0 0
/proc		  /var/lib/ntp/proc none bind 0 0

Finally mount all these binds:

# mount -a

Thanks to the ArchLinux guys where I found this.

To check whether your ntp is working again, you can use the following command which shows a list of peers known to your ntp server:

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 0.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 1.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 2.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 3.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
*ptbtime1.ptb.de .PTB.            1 u   46   64  377   11.483   -0.411   0.201
+ptbtime2.ptb.de .PTB.            1 u   52   64  377   11.502   -0.533   1.069
+ptbtime3.ptb.de .PTB.            1 u   47   64  377   11.451   -0.510   3.866
#batleth.sapient 131.188.3.221    2 u   44   64  377    0.188    1.097   0.176
#5.199.135.170 ( 130.149.17.21    2 u   45   64  377   11.271    0.581   0.396
-mail.morbitzer. 193.175.73.151   2 u   47   64  377    2.760    0.556   0.278
#hotel.zq1.de    161.62.157.173   3 u   46   64  377    0.094    1.384   0.261
-ntp2.m-online.n 212.18.1.106     2 u   47   64  377    7.167   -0.333   0.190
#2a03:b0c0:3:d0: 81.94.123.16     3 u   49   64  377    6.288   -2.071   1.760
#touka.thehomeof 130.149.17.21    2 u   48   64  377    0.206    0.932   0.222
+maggo.info      124.216.164.14   2 u   42   64  377    0.278   -0.137   0.436
+weyoun4.cord.de 124.216.164.14   2 u   44   64  377    2.849   -0.255   0.409
+opnsense.sauff. 222.217.153.8    2 u   43   64  377    0.270   -0.617   0.167
-web1.sys.ccs-ba 192.53.103.104   2 u   35   64  377    0.173   -1.251   0.220
#uruz.org        122.227.206.195  3 u   49   64  377    0.216    1.694   0.309
#clients5.arcani 162.23.41.55     2 u   38   64  377    6.120   -1.500   0.130
+stratum2-1.NTP. 129.70.130.71    2 u   47   64  377   14.043    1.625   0.394

The following command confirms that your current time is actually correct (within certain limits, of course):

# ntpstat
synchronised to NTP server (192.53.103.108) at stratum 2
   time correct to within 15 ms
   polling server every 64 s

If this was helpful, I would be happy to hear from you.

Exim malware scanner issue after upgrade from Jessie to Stretch

Today I finally upgraded by personal root server from Debian Jessie to Stretch, thereby upgrading Exim from 4.84 to 4.89.

After the upgrade, I observed the following errors in mainlog:

2018-05-31 08:02:03 +0000 1fOIX5-0001rg-AM malware acl condition: cmdline  : scanner returned error code: 36096
2018-05-31 08:02:03 +0000 1fOIX5-0001rg-AM H=([IPv6:2a00:6020:1efc:ee20:8857:7824:6a49:8368]) [2a00:6020:1efc:ee20:8857:7824:6a49:8368]:48523 I=[2a01:4f8:141:429::2]:465 Warning: ACL "warn" statement skipped: condition test deferred
2018-05-31 08:02:04 +0000 1fOIX5-0001rg-AM malware acl condition: cmdline  : scanner returned error code: 13
2018-05-31 08:02:04 +0000 1fOIX5-0001rg-AM H=([IPv6:2a00:6020:1efc:ee20:8857:7824:6a49:8368]) [2a00:6020:1efc:ee20:8857:7824:6a49:8368]:48523 I=[2a01:4f8:141:429::2]:465 Warning: ACL "warn" statement skipped: condition test deferred
2018-05-31 08:02:05 +0000 1fOIX5-0001rg-AM malware acl condition: cmdline  : scanner returned error code: 13
2018-05-31 08:02:05 +0000 1fOIX5-0001rg-AM H=([IPv6:2a00:6020:1efc:ee20:8857:7824:6a49:8368]) [2a00:6020:1efc:ee20:8857:7824:6a49:8368]:48523 I=[2a01:4f8:141:429::2]:465 Warning: ACL "warn" statement skipped: condition test deferred

Each of the three cmdline scanners caused an error, as shown above.

It seems there was a change in Exim from upstream, as reported by another user. Somehow it seems that if you define a cmdline scanner that uses a chain of commands, when there was an error return code encountered in the middle of the chain, the whole chain is considered failed.

To “fix” this issue (or rather work-around it), I changed the three ACL clauses as follows:

   warn  message                = This message contains malware ($malware_name)
         set acl_m0      = cmdline:\
-                               /usr/lib/AntiVir/guard/avscan -s --batch --scan-mode=all %s; /bin/echo -e \N"\navira_retval $?"\N:\
+                               /usr/local/bin/avscan_wrapper %s:\
                                \N^avira_retval 1$\N:\
                                \N^.*ALERT::[ \t]+([^;]*)[ \t]+;.*$\N
         malware                = *

I created a “wrapper” that effectively hides error return codes, and forces a return code of 0. The above wrapper looks like this:

#!/bin/bash

ARG="$1"

/usr/lib/AntiVir/guard/avscan -s --batch --scan-mode=all "${ARG}"
/bin/echo -e "\navira_retval $?"

exit 0

To make sure I didn’t break the malware scanning by my changes, I downloaded the EICAR test virus and sent it to myself. Exim caught the “virus” and ditched it.

Debian 6.0 to 7.0 upgrade issues…

I upgraded from Debian 6.0 (Squeeze) to Debian 7.0 (Wheezy) today. In general the upgrade was relatively painless, but as always some things went worse than they could… 🙁

My local Subversion repository is using a Berkeley DB, and the underlying BDB version went up from 4.8 to 5.1. In consequence I got an error when I wanted to check in a changed config file:

svn: DB_VERSION_MISMATCH: Database environment version mismatch
svn: bdb: Program version 5.1 doesn't match environment version 4.8

I remember that this has already been an issue with the last major Debian upgrade… Did I miss something in the release notes or package doc, or did the Debian folks miss this one?!

Anyway, here’s how to repair the above (based on instructions found here). Install packages db4.8-util and db5.1-util and execute the following commands:

# cd /path/to/repo
# db4.8_checkpoint -1
# db4.8_recover
# db4.8_archive
log.0000000024
# svnlook youngest ..
746
# db5.1_archive -d

Afterwards you can remove the two packages again.

Next thing I noticed Continue reading Debian 6.0 to 7.0 upgrade issues…

Solved: WordPress on Debian and media uploads not working

I was struggling with a problem that I couldn’t upload media files to my blog — which I host myself on a Debian box in a multi-site configuration. When I tried to do so I got an error message saying that WordPress couldn’t write to the directory. Actually I had this very problem since 2005 when I started this blog — I never took the time to really investigate it (but used the work-around to refer to static content I manually uploaded to my web-server document directory)… 😉

Now that my wife wanted to start blogging, I finally had a good reason to fix this issue. It took me about an hour, and it was done. What I had to do was just two entries in my admin’s Settings (I might not have set up WordPress cleanly when I started it, so you might not have to manually set this) as follows:

And then I needed one Alias in my Apache configuration to redirect the URL prefix to a directory under my web-server document root:

# "Intercepts" files prefix and redirect to "local" (user's) directory
Alias /blog/files /home/rabe/var/www/bergs.biz/blog/files
# This is the prefix to the root of my blog
Alias /blog /usr/share/wordpress

That’s it! Sometimes things are so easy, and it only takes a short while to fix them… 😉

Integrate “AVG Anti-Virus Free Edition” into Exim with ExiScan patch

If you would like to integrate “AVG Anti-Virus Free Edition” into Exim, using the ExiScan patch, this is actually quite easy.

Just insert the following fragment into your Exim config:

  # Reject virus infected messages.
  # Add message to implicit X-ACL-Warn: header
  warn  message         = This message contains malware ($malware_name)
        set acl_m0      = cmdline:\
                          /usr/bin/avgscan --arc %s; echo -e \N"\navg_retval $?"\N:\
                          avg_retval 5:\
                          \NVirus identified *(.*)$\N
        malware         = *
        log_message     = This message contains malware (avg:$malware_name)

Let me know if this works for you — I hacked this up quite quickly, but it seems to do its job…

Courier IMAP: Could not log in after Debian 5.0 upgrade

After I had upgraded my server to Debian 5.0, I found that I could no longer log in via IMAP. I turned authentication debugging on by changing /etc/courier/authdaemonrc as follows:

DEBUG_LOGIN=1

This did not reveal any problems. Here’s an excerpt from mail.info:

authdaemond: received auth request, service=imap, authtype=cram-md5
authdaemond: authmysql: trying this module
authdaemond: cram: challenge=[...], response=[...]
authdaemond: cram: decoded challenge/response, username 'user@example.org'
authdaemond: SQL query: SELECT username, crypt, clear, uid, gid, pop, "",
  "", realname, "" FROM users WHERE username = 'user@example.org'
authdaemond: cram validation succeeded
authdaemond: Authenticated: sysusername=<null>, sysuserid=1000,
  sysgroupid=1000, homedir=/home/user/var/mail/example.org/user,
  address=user@example.org, fullname=Joe User, maildir=<null>,
  quota=<null>, options=<null>

Even though all seemed fine, Thunderbird complained about “server doesn’t support secure authentication.”

So I telnetted into my IMAP server by issuing telnet localhost imap and manually logged in as follows:

a login user@example.org thePass

Now I noticed immediately what was wrong:

* BYE [ALERT] Fatal error: Account's mailbox directory is not owned
  by the correct uid or gid:

The solution is that Courier now by default performs stricter checks on the “sanity” of your setup. I changed /etc/courier/imapd as follows, and all was fine again:

IMAP_MAILBOX_SANITY_CHECK=0