While configuring fail2ban (0.11.1-10.el7) on a CentOS 7 server (7.9.2009) with SELinux enforcing, I noticed that the audit log was being spammed with events like the following:

type=AVC msg=audit(1619021616.913:2703): avc:  denied  { read } for  pid=11335 comm="f2b/server" name="disable" dev="sysfs" ino=2153 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=file permissive=0
type=AVC msg=audit(1619022022.035:2717): avc:  denied  { read } for  pid=11942 comm="f2b/server" name="disable" dev="sysfs" ino=2153 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=file permissive=0
type=AVC msg=audit(1619022087.058:2748): avc:  denied  { read } for  pid=12260 comm="f2b/server" name="disable" dev="sysfs" ino=2153 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=file permissive=0

The setroubleshoot utility didn't help much in this case:

Apr 21 12:09:33 srvname setroubleshoot: SEL...

tl;dr: On systems running Smokeping, avoid curl 7.74.0 and wait for a newer release!

I have a few Smokeping nodes deployed here and there to keep tabs on various services. Recently, all of the curl-based probes stopped working on one of the Smokeping instances. Any probe using either the Curl.pm or AnotherCurl.pm module would immediately enter "alert" status, indicating 100% failure, and these probes would never recover to a cleared state.

The monitoring node where things went haywire is running FreeBSD 12.2, with Smokeping and curl both installed from the ports collection. It turns out there's a bug in the most recent version of curl, and updating the curl port from 7.73.0 to 7.74.0 caused Smokeping to choke. (My Linux-based Smokeping nodes avoided this fate thanks to slower release cycles for their package universes.)

The bug is that time-based statistics returned by the -w option to curl are suddenly being presented in microseconds instead of seconds, e.g. where Smokeping expect...

A new pre-release version of chrony (4.0-pre3) is out today, with some neat improvements to the client statistics output. Specifically, the chronyc clients command accepts three new options:

• -p, minimum packet threshold
• -r, reset client stat counters
• -k, replace control stats with NTS stats

The first two will be useful to anyone who uses chronyd for a public-facing time server.

One constant challenge of operating any public service is detecting and reacting to abuse. What happens when some gomer decides to synchronize his clock to your NTP server 100 times a second, or a vendor bug floods you with 20Kpps at random intervals? How — and how quickly — would you notice? chronyd can be configured to enforce rate limiting, but it still has to receive the packets and decide to ignore them. That's a drain on resources which is better handled by locating abusive hosts an...

Consider the following PHP code:

<?php
declare(strict_types=1)
echo 'Hello' . PHP_EOL;

Running this code will generate the following error message:

$ php file.php

Fatal error: strict_types declaration must not use block mode in /tmp/file.php on line 2

The fix is easy: there's a missing semicolon after declare(strict_types=1). That's all! This tripped me up because the "declaration must not use block mode" error, which will only be raised for this exact typo in this exact statement, isn't what normally appears when a semicolon is missing.

Sometimes when running yum check-update on a CentOS system, yum will complain about a particular repomd.xml file being out of date. You might see output like this:

[root@host ~]# yum check-update
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
epel/x86_64/metalink
 * base: centos-distro.cavecreek.net
 * epel: d2lzkl7pfhq30w.cloudfront.net
 * extras: linux.cc.lehigh.edu
 * updates: reflector.westga.edu
base
extras
updates
Not using downloaded updates/repomd.xml because it is older than what we have:
  Current   : Thu Jul 16 09:45:59 2020
  Downloaded: Thu Jun 25 14:10:47 2020

This message can appear for any active repository on your system:

Not using downloaded base/repomd.xml because it is older than what we have
Not using downloaded epel/repomd.xml because it is older than what we have
Not using downloaded extras/repomd.xml because it is older than what we have
...etc

What's going on?

Notices about old repomd.xml ...

If you receive the following error from subversion,

svn: E125001: Couldn't determine absolute path of '.'
svn: E000002: No such file or directory

The most likely cause is that your current working directory has been deleted by another process. Change your working directory to a valid path before proceeding. If the error message appears while running a shell script, make sure the script is cd'ing out of any temporary directories it might have cd'ed itself into.

If you have a Vantec SATA/IDE to USB 2.0 Adapter (model CB-ISATAU2) that suddenly stops working, and Windows tells you that the USB device isn't recognized, check to see if you have a service named "Macrium Service" running. This service is part of the Macrium Reflect backup suite; among other things, it watches for new USB drives to be plugged in. Something about this mechanism interferes with the SATA/IDE to USB adapter's ability to load its drivers. As a result, Windows can't figure out what you plugged in.

Disabling the Macrium Service in services.msc and then reconnecting your USB adapter will allow your drive to be recognized properly. Once the drive is mounted, you can run Macrium Reflect to interact with it as needed. Unfortunately, Reflect appears to reset the Macrium Service to "automatic" startup mode each time it runs, so whenever you want to plug in a drive with the adapter, check for and disable the Macrium Service first.

Yesterday I received a brief message to an email address listed in various security.txt files:

Date: Sun, 3 Nov 2019 21:36:01 +0100
From: Jay Niffley <jayniffley [] gmail.com>
Subject: Security issues

      Hello,

I´ve found some security issues in your website. Where can i report these
issues over? Do you reward for valid security issues?

Thank you!
-Jay

A Google search for the name "Jay Niffley" was unproductive, and it's likely no real person by that name exists. But the "jayniffley" handle has been used at least once before, in what appears to be an attempted XSS probe on a cryptocurrency wallet manufacturer's support forum. The forum post containing the failed XSS attack references jayniffley.xss.ht. This hostname corresponds to a user of a service called XSS Hunter, a sort of canary interface for people conducting automated XSS testing. Visiting the host in a browser serves up a l...

In early September, I noticed a new web robot performing a number of rudimentary scans from 160.1.30.97. While hundreds of different bots are making the rounds on any given day, this one was unusual in that the IP is part of Amazon GovCloud's 160.1/16 allocation. GovCloud is an AWS product that's segmented from the public Amazon cloud, and, as its name suggests, is reserved for use by US government entities.

The HTTP traffic from 160.1.30.97 was clearly automated; the User-Agent header was left empty, and the robot requested only index pages with no supplemental content. The timing of observed activity suggests the bot was spidering a predefined list of domains in alphabetical order. Here, for example, is the robot's first visit to this site:

160.1.30.97 - - [04/Sep/2019:15:21:58 -0500] "GET / HTTP/1.1" 301 227 - "-" "-"
160.1.30.97 - - [04/Sep/2019:15:21:58 -0500] "GET / HTTP/1.1" 302 - on "-" "-"
160.1.30.97 - - [04/Sep/2019:15:21:58 -0500] "GET /blog/ HTTP/1.1" 200 30146 on "-" "-"
`...

If you want to compile Doxygen (/usr/ports/devel/doxygen/) on FreeBSD without also building LaTeX and Ghostscript, disabling the "LaTeX support" option in the make config screen isn't sufficient.

You also need to disable the "Build and/or install documentation" option.

Turns out, Doxygen uses itself to build its own docs, and requires features from the LaTeX and Ghostscript support to do so. As such, if you disable LaTeX support but ask for the documentation to be built, LaTeX will be silently re-enabled! This isn't intuitive or apparent from the config interface; you have to look in the Makefile to figure it out. The DOCS_IMPLIES line forces LaTeX back on:

DOCS_USES=              ghostscript:build
DOCS_ALL_TARGET=        docs
DOCS_BUILD_DEPENDS=     dot:graphics/graphviz
DOCS_CMAKE_BOOL=        build_doc
DOCS_PLIST_FILES=       man/man1/doxygen.1.gz \
                        man/man1/doxyindexer.1.gz \
                        man/man1/doxysearch.1.gz \
                    ...