Casio DW-290 Watch - Noisy Strap Solution

My Casio DW-290 watch developed an annoying creaking noise where the strap attaches to the watch. The solution is to lightly file down the ends of the strap pieces.

UNIX tip: "up", a better "cd"

This UNIX situation was always annoying to me:

$ cd a/b/c/d/e/f
$ ./some-cmd
$ cd ../../../../..

That is, typing all that ../../../../.. Even just "cd .." seems like a lot of characters to type for such a common task.

So years ago I created a shell function called up to handle cd-ing up the directory tree. If you use up with no arguments, it cds up one directory. But you can also tell it how many directories to cd up, which is where its power comes in. The above example becomes:

$ cd a/b/c/d/e/f
$ ./some-cmd
$ up 5

The shell function code is below. It works for bash and zsh, and it only uses shell builtins. I put this code in my .bashrc and .zshrc files.

function up()
{
 if [[ -z $1 ]]; then
   cd ..
 else
   if [[ $1 =~ [0-9]+ ]]; then
     local U=$(printf "%0${1}d" 0)
     cd ${U//0/'../'}
   else
     echo up: bad arg
   fi
 fi
}

A little explanation... The printf creates a string of N zeros, where N is the number of directories to cd up. The cd line uses the ${parameter/pattern/string} expansion to turn each "0" into a "../".

p.s. Yes, I know that pushd/popd solves the same problem, but I never got used to those. Also, I frequently cd down five directories, but then want to go up two. So for me, up is more versatile.

The Sopranos - google play music playlist

I could not find any existing playlist for Google Play Music for the songs at https://en.wikipedia.org/wiki/Music_on_The_Sopranos

So I created my own playlist. It is at

https://play.google.com/music/playlist/AMaBXymgggoU6qC5g2qT1M81woUxI0f7SBN5hYWjcel8LK_5y5ta1ExHv3PeScJyaBJwQESQYft67KhA7ajMgbBKPM-Eg318Bw%3D%3D

It does not exactly match the wikipedia list. Some of the songs simply are not available in GPM. Others seem to be obscure recordings. Anyway, it's pretty close.

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

module(load="immark")

But what about the MarkMessagePeriod setting? I could not find any useful information about it.  Trying this

module(load="immark")
$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 http://www.rsyslog.com/e/2222 ]

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 http://www.rsyslog.com/e/2207 ]

Time to look at the code: https://github.com/rsyslog/rsyslog/blob/master/plugins/immark/immark.c

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*

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

https://dl.fedoraproject.org/pub/fedora-secondary/releases/26/Server/i386/

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.

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 https://cloud.google.com/storage/docs/gsutil/addlhelp/CRC32CandInstallingcrcmod 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

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 http://forums.fedoraforum.org/showthread.php?t=309879

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.

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:

• Ran a full Avast scan
• Ran the Microsoft Safety Scanner
• Ran the Windows Defender Offline

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. :(

References:

• https://forum.avast.com/index.php?topic=173791.msg1234165
• https://support.opendns.com/entries/59545000-Heads-up-Excessive-DNS-queries-by-AVAST-2015

Switching Fedora 20 sendmail from port 25 to port 587

My fedora server sends outgoing email to smtp.comcast.net.  I've always been able to configure that with just this in /etc/mail/sendmail.mc:

define(`SMART_HOST', `smtp.comcast.net')dnl

But two days ago Comcast finally started blocking port 25 on me (http://customer.comcast.com/help-and-support/internet/email-client-programs-with-xfinity-email/).

There are quite a few posts and articles about switching to port 587.  Below is what I found worked on my Fedora 20 server.

Step 1.  New /etc/mail/sendmail.mc config setup:

define(`SMART_HOST', `smtp.comcast.net')dnl

define(`RELAY_MAILER_ARGS', `TCP $h 587')dnl

define(`ESMTP_MAILER_ARGS', `TCP $h 587')dnl

FEATURE(authinfo)dnl

Step 2. Setup authinfo

Assuming your comcast account is walrushose@comcast.net with password door123 ...

# touch /etc/mail/authinfo && chmod 600 /etc/mail/authinfo

# echo 'AuthInfo:smtp.comcast.net "U:walrushose" "P:door123" "M:PLAIN"' > /etc/mail/authinfo

# makemap hash /etc/mail/authinfo < /etc/mail/authinfo

# chmod 600 /etc/mail/authinfo.db

Step 3. Remake and restart sendmail

# make -C /etc/mail

# systemctl restart sendmail.service

Now my server is happily using port 587 for outgoing email.

Auto-upgrade Raspbian

I like to auto-upgrade fedora systems with yum-cron. To do the same thing on raspbian:

rpi# aptitude install cron-apt
rpi# echo 'dist-upgrade -y' > /etc/cron-apt/action.d/4-upgrade

You can monitor /var/log/cron-apt/log and /var/log/apt/history.log to confirm that upgrades are happening.

OpenWrt - restrict LuCI and ssh to a specific host

For security, I only ever want to connect to my OpenWrt router from a specific internal host.  Here is the firewall setup to accomplish that.

relevant part of /etc/config/firewall:

# Only allow 192.168.1.6 to access LuCI http

config 'rule'

        option '_name' 'Restrict-LuCI-http'

        option 'src' 'lan'

        option 'src_ip' !192.168.1.6

        option 'dest_ip' 192.168.1.1

        option 'dest_port' 80

        option 'proto' 'tcp'

        option 'target' 'REJECT'

# Only allow 192.168.1.6 to access LuCI https

config 'rule'

        option '_name' 'Restrict-LuCI-https'

        option 'src' 'lan'

        option 'src_ip' !192.168.1.6

        option 'dest_ip' 192.168.1.1

        option 'dest_port' 443

        option 'proto' 'tcp'

        option 'target' 'REJECT'

# Only allow 192.168.1.6 to access ssh

config 'rule'

        option '_name' 'Restrict-ssh'

        option 'src' 'lan'

        option 'src_ip' !192.168.1.6

        option 'dest_ip' 192.168.1.1

        option 'dest_port' 22

        option 'proto' 'tcp'

        option 'target' 'REJECT'