One can send SIGUSR2 to a running clamd instance to reload the signatures.
But how can I (from a script) determine, if the signatures have been reloaded? I can of course try "sleep 30" which will suffice in most cases (from my experience) but is there a script based approach apart from trying to parse the logfile?
I'm trying to monitor my OWA logon page using smokeping. smokeping uses echoping like this:
# /usr/bin/echoping -t 2 -4 -C -h /owa/auth/logon.aspx -n 20 email.charite.de
HTTP error "HTTP/1.1 401 Unauthorized ( Der ISA Server erfordert Autorisierung, um die Anforderung durchführen zu können. Der Zugriff auf den Webserver wird v"rweigert. Wenden Sie sich an den Serveradministrator. )
So, basically the page tells me I need to authenticate. But when surfing to https://email.charite.de/owa/auth/logon.aspx I get a login page. No need to authenticate anything (yet).
Recent version of Ubuntu and Debian (stretch) bring a new network interface naming scheme.
Now, when updating from a system that's using old style names like "eth0", I'd like to know prior to booting what the new name will be.
How can I do this? Is there a magic invocation of "systemd" I can use to edit /etc/network/interface befor booting (and subsequently losing network connectivity)?
my BIND 9.10.3 is logging strange entries like:
Jan 12 12:44:49 www named[24776]: client 117.136.25.126#18977: message parsing failed: FORMERR
Jan 12 12:50:47 www named[24776]: client 117.136.25.126#18978: message parsing failed: FORMERR
Jan 12 13:00:08 www named[24776]: client 117.136.95.15#24805: message parsing failed: FORMERR
117.136.95.15 is not in my network, and I don't allow recursion for anything but localhost, thus it must be for a zone I'm authoritative for.
This only started recently (Jan 5th). Looking at the log it seems, that only queries from:
# zfgrep "message parsing failed: FORMERR" daemon.log* | awk '{print $7}' |awk -F\. '{printf("%s.%s.x.x\n",$1,$2)}' | sort | uniq -c | sort -n
1 101.27.x.x
1 121.31.x.x
1 1.84.x.x
1 61.158.x.x
104 223.104.x.x
150 117.136.x.x
are causing this. Looking at the WHOIS info for those IPs:
inetnum: 117.128.0.0 - 117.191.255.255
netname: CMNET
descr: China Mobile Communications Corporation
descr: Mobile Communications Network Operator in China
descr: Internet Service Provider in China
country: CN
inetnum: 223.64.0.0 - 223.117.255.255
netname: CMNET
descr: China Mobile Communications Corporation
descr: Mobile Communications Network Operator in China
descr: Internet Service Provider in China
country: CN