Saturday, February 10, 2018

rsyslog and $MarkMessagePeriod

For a long time I had this rsyslog configuration to emit MARK messages every 10 minutes
$ModLoad immark
$MarkMessagePeriod 600
That config syntax was deprecated and finally broke in recent versions of rsyslog. That's fine... let's update to the new config syntax. The module load becomes
But what about the MarkMessagePeriod setting? I could not find any useful information about it.  Trying this
$MarkMessagePeriod 600
resulted in
liblogging-stdlog[881]: command 'MarkMessagePeriod' is currently not permitted - did you already set it via a RainerScript command (v6+ config)? [v8.24.0 try ]
and the information at the link was unhelpful.

My next attempt was
module(load="immark" MarkMessagePeriod="600")
and that resulted in this error
liblogging-stdlog[1084]: error during parsing file /etc/rsyslog.d/mark.conf, on or before line 1: parameter 'MarkMessagePeriod' not known -- typo in config file? [v8.24.0 try ]

From there I finally found the correct name to use in the module-global parameters struct. It's called interval. So the working configuration is
module(load="immark" interval="600")
I wish the maintainer had published a list of conversions for the configuration of the plugins. In no way is it obvious that $MarkMessagePeriod should be changed to interval. *sigh*

Wednesday, July 12, 2017

Fedora 26 i386

The Fedora project finally killed i386 (aka "x86") as a primary architecture starting in Fedora 26. It's still available, but not easy to find.

It's now a "secondary" architecture, and you can find it at

Saturday, March 18, 2017

Uninstalling Avast - breach of customer trust

I've been using Avast antivirus for quite a while. Today I noticed that it started adding an email signature to my outgoing gmail with an ad and link for Avast! Without my consent or telling me! Holy Schnikeys! That's a complete and total breach of trust. What genius at Avast thought it is a good idea to modify a customer's email?!  I'm uninstalling it now.

Monday, September 5, 2016

Fedora 24 and gsutil and crcmod

I was using gsutil rsync on a Fedora 24 system to copy data to google cloud storage.  I got this message:
WARNING: gsutil rsync uses hashes when modification
time is not available at both the source and
destination. Your crcmod installation isn't using
the module's C extension, so checksumming will
run very slowly. If this is your first rsync since
updating gsutil, this rsync can take significantly
longer than usual. For help installing the
extension, please see "gsutil help crcmod".

I followed the instructions at hoping to get the fast C extension installed.  But after following the Fedora instructions there, I still did not have the C extension for crcmod.

Troubleshooting and debugging eventually determined that the reason the C extension was not built and installed for crcmod was a missing file dependency, /usr/lib/rpm/redhat/redhat-hardened-cc1, which is provided by the redhat-rpm-config package.

So the solution to getting the fast crcmod C extension on Fedora 24 is to install redhat-rpm-config.

# dnf install redhat-rpm-config

Monday, May 9, 2016

DNF and logwatch

When Fedora linux used yum, logwatch reports contained a section about package changes.  When Fedora switched from yum to dnf, logwatch reports no longer contained a package-changes section, because there are no dnf scripts for logwatch.

I have a patch for that.  Details at

Saturday, October 3, 2015

Don't lose your crontab

I use Fedora on my home server, and I maintain /home as a separate filesystem, which I backup.  When I upgrade to new Fedora versions, I do a full reinstall using kickstart, keeping the /home filesystem intact.

The one thing that I want to preserve across upgrades that is not kept in /home is my crontab, which lives in /var/spool/cron.  Occasionally I would forget to grab a copy of my crontab before upgrading, and then I'd be sad.

It finally occurred to me that I should keep an up-to-date copy of my crontab in my home directory.  And what better way to do that than with cron itself.  Here's what I have in my crontab now:

00 03 * * * /bin/crontab -l > $HOME/.crontab-${USER}-backup

Now I always have a recent backup of my crontab in my home directory, and I never have to worry about losing it during an upgrade.

Sunday, July 26, 2015

Suspicious burst of dns queries from Windows

Reviewing dns query logs on my home network, I discovered that every afternoon a Windows 7 machine would issue a fast burst of about 1000 dns queries.  The list of domain names queried each day appeared to be the same, and included quite a few porn and foreign sites.

Right away I figured I've got malware on the machine.  I did the following:

Everything came up clean -- no detected problems.

Since the dns burst happened every day, I was trying to figure out how to determine what process on a Windows 7 machine issued a given dns query.  And in the middle of working on that, some google searches pointed out that Avast itself is the culprit.  Arghhhh.

Apparently Avast performs a dns lookup on the top 1000 sites to spot dns hijacking. Of couse, in doing so, Avast creates a highly suspicious traffic signature. Sounds like many people have wasted hours trying to hunt this down, only to find that Avast is the root cause. :(