Beware, Ransomware Is Everywhere

Back up your files and photos regularly, somehow or other, please! A cousin of mine just came to me in hopes that I can help him. All of his files have been locked. When trying to open a file, he gets a message that he can only unlock the files by paying a $500 ransom in bitcoin (an untraceable digital currency). This threat is real. It's not just an annoyance that will slow your computer down or splash nasty ads on your screen.

If you back up regularly, you can restore your files and tell these lazy bums to take a hike. If not, you can pay up and hope they actually restore your files (then back them up fast before they hit you again). TechWorld has an article that mentions some tools that *might* help remove some strains of ransomware. The article mentions writing down the bitcoin address and affected files (if possible) for future reference; seems like a good idea.

Macs are generally less susceptible to viruses. But, this threat appears to have made its way to Mac OS. Sadly, my go-to operating system, Linux has also seen it.

The best way to avoid malware altogether is to use Google's ChromeOS. It comes on Chromebooks, such as the Acer Chromebook 14. Beware that you will not be able to install Microsoft Office, Java, and several other apps. Instead, on ChromeOS, you will use editors and spreadsheet software like Google Docs and Sheets.

Using Linux or Mac OS are probably your next best bets. I see no reason to run Microsoft Windows these days. Stay away from spammy sites. Don't open spammy emails; especially don't click on suspicious links in emails. Using online file services like Google Docs will keep your files backed up, often with multiple versions.

Backing up with something like Backblaze would work great. I like the idea of syncing to DropBox, Google Drive, OneDrive, etc. *BUT*, those might just sync the hacked/encrypted version of your files, overwriting the good ones. Supposedly, the three aforementioned sync services offer versioning, more akin to a true backup like Backblaze. But, you may be left restoring one file at a time. Backblaze will send you a hard drive in the mail with the restore date of your choice. Of course, if you're disciplined, you can backup to a USB thumb drive or external drive. Beware that most ransomware will try to encrypt all attached drives, probably including those on online backup services that appear as a normal hard drive. Backing up to DVD is a safe option, albeit a big hassle.

Did I mention ChromeOS and not clicking on suspicious email links? :)

Beware of Mismatching Client and Server Binaries on Deis

Until today, I had not had any trouble accessing Deis with a Deis client that didn't match the server.  of course features that didn't exist in the server might not work (or it might; take deisctl ssh from 1.10.0 to a 1.7.3 cluster as an example).

But, beware the jabberwok.  I was missing the client on my mac.  So, I just downloaded the latest client, 1.11.2 to work against a 1.10.1 cluster.

I just needed to certs:add; what could it hurt, I thought.  Certs:add from 1.11.2 client to 1.10.1 server blew away all of the certs as it added the new one.  Yikes!

I was able to ssh into one of the hosts and find them in etcd /deis/certs.  After ensuring that I had all of the certs/keys, I deleted those keys and their parent directory keys. Why?  Because even with the keys, I couldn't add them, presumably because they were really in etcd, just not show up with deis certs:list.

Attempting to push the old keys, I get a 500 error.  I can push new keys --just not keys to replace the ones in a bad state.

Now, I'm looking for someplace else that may contain old references to to the keys, which may be preventing me from uploading this "duplicate" cert name.

Oh, and because of my sorted history with Deis and Docker, I have multiple DEIS clusters.  I am able to add that cert/key pair to another cluster.

Consider heeding the warning to avoid mismatching client and server versions.

DEIS Nuggets: scale up then back down to apply SSL cert

I found that simply uploading a cert with deis cert:add will not affect the running processes.  The cert is applied to the DEIS router.  Scaling the application down, then back up will work.  But, why not scale up then back down?  Works for me.  HTH

Stateless DEIS - no Ceph

I'm sure Ceph is fine.  But, I don't want to add any uneccesary complexity to my DEIS cluster.  And, I don't know Ceph well enough to feel comfortable keeping it if I don't have to.

Below are a few notes I took in trying to get my stateless DEIS 1.9.0 cluster going.

First, I needed a log server to which I could send syslog from DEIS.  BTW, the "deis logs" command will cease to work once you send them to an external syslog service.  We are testing CloudWatch Logs.  Funny enough, I ended up trying Amazon ECS to host a docker image configured with CloudWatch Logs.  I fired up a service with two syslog tasks (listeners).  I will use these syslog servers for other purposes as well.

Second, I needed a PostgreSQL database.  RDS to the rescue.  So far, I'm getting by with a t2.micro.

Third, I needed some external storage for real files.  DEIS allows for an S3 backend.  I found no documentation for required permissions.  So, I tinkered until I came up with this small set:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1440163063000",
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "arn:aws:s3:::the-bucket/*"
            ]
        },
        {
            "Resource": "arn:aws:s3:::the-bucket",
            "Action": "s3:*",
            "Effect": "Allow"
        },
        {
            "Resource": "*",
            "Action": "s3:ListAllMyBuckets",
            "Effect": "Allow"
        }
    ]
}

The special deis install stateless-platform & deis start stateless-platform are the commands used to turn up the lean environment.  I had trouble with the registry starting until I tweaked the S3 permissions.  The builder wouldn't start because the controller didn't start (/deis/controller/* etcd keys didn't exist).

After much angst, and by running each command in fleetctl cat deis-controller individually, I found that the password for my postgres database had a single quote in it.  My luck, the startup script also used single quotes around the password.  FAILHORN!  After getting the controller whipped into shape, it still shows as inactive/dead in deisctl list.  But, I can register/login; and, the builder automatically continued after the controller came on.

So, I just first my first app to it.  I'm already enjoying (of necessity) those CloudWatch Logs.  Weeee!

Arduino On Ubuntu 15.04

The Arduino Uno clone I picked up from a Chinese Ebay seller has a USB-to-serial adapter that lacks Mac support.  Well, there is a Mac driver.  But, I wasn't comfortable installing a driver whose download link (and installer, I think) was only in Chinese.

Luckily Linux has the driver built right in.  So, using my Ubuntu 15.04 laptop, I installed Arduino 1.0.5 from the default apt repositories.  First thing I found was that the "Tools->Serial Port" menu item was grayed out.  I added myself to the dialout group and logged out/into my X session (or run newgrp and then run arduino from the terminal).  I found that I could not save or open a file.  I was using Iced Tea java.  I pointed at java 7.x.  No luck.  Turns out, it depends on Java 6 runtime, still available in Oracle's archive area.

My son and I played with the blink example.  I'm so glad that little LED is built in!

Back to coding.  So long.

RHEL7 sshd Ignores authorized_keys2

I found out the hard way that my authorized_keys2 files is ignored in Redhat Enterprise Linux 7.  My ssh client would submit the key file and then prompt me for my password.

The line "#AuthorizedKeysFile .ssh/authorized_keys" from sshd_config was uncommented, which changed the default behavior of reading both authorized_keys and authorized_keys2.

Unfortunately, I don't find any announcement of this change.  And, the sshd man page still reads

"AuthorizedKeysFile specifies the files containing public keys for public key authentication; if none is specified, the default is ~/.ssh/authorized_keys and ~/.ssh/authorized_keys2."

Renaming the authorized_keys2 file to authorized_keys will fix the problem.  Be sure to merge these files if authorized_keys also exists.

I've submitted product feedback to Redhat asking that they announce the change and fix the man page.  FWIW, we've been warned in the past, starting in 2001 with the release of openssh version 3, that this authorized_keys2 is deprecated.  It just seems like an explicit "your stuff will now break" announcement is warranted.

AuthorizedKeysFile specifies the files containing public keys for public key authentication; if none is specified, the default is ~/.ssh/authorized_keys and ~/.ssh/authorized_keys2.

AuthorizedKeysFile specifies the files containing public keys for public key authentication; if none is specified, the default is ~/.ssh/authorized_keys and ~/.ssh/authorized_keys2.

AuthorizedKeysFile specifies the files containing public keys for public key authentication; if none is specified, the default is ~/.ssh/authorized_keys and ~/.ssh/authorized_keys2.

AuthorizedKeysFile specifies the files containing public keys for public key authentication; if none is specified, the default is ~/.ssh/authorized_keys and ~/.ssh/authorized_keys2.

ViewSonic DCR Causes Dim Terminal/Console Screens

For a long time, I've been fighting with my screen dimming while I'm in a terminal session (black or dark backgrounds).  I simply could not see the text due to the dim screen.  I didn't know if it was a bug in power savings code in Ubuntu or some issue with my monitor.  Today I accidentally won the battle.

I have a ViewSonic VA2226w monitor.  I happened to press and hold the up arrow on the monitor and I saw an on-screen display message that I hadn't before noticed.  It said "DCR off".  Turns out, Viewsonic's "Dynamic Contrast Ratio" was the culprit!

So, at least for the ViewSonic VA2226w, the way to toggle DCR is:

1. exit all OSD menus, if opened
2. press and hold the up arrow until you see "DCR on" or "DCR off"

I hope you haven't fought with this as long as I have.  DCR is a bug, not a feature.