Tag Archives: Debian

Computers, Debian, English, Linux, Networking

ntp running in chroot stopped working after Debian Stretch upgrade

Leave a comment

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.

Debian, English, Security

Exim malware scanner issue after upgrade from Jessie to Stretch

Leave a comment

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

Debian 6.0 to 7.0 upgrade issues…

Leave a comment

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… →