Spam of the Day

I especially like FreeLottoe and Winniner

From - Thu May 24 09:19:01 2018
X-Account-Key: account2
X-UIDL: _8/"!(Eh"!9>*#!hJT!!
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Received: from REDACTED
	by REDACTED (8.14.9/8.14.3) with ESMTP id w4I0KWfx002926
	for ; Thu, 17 May 2018 20:20:32 -0400
Received: from ([])
	by REDACTED (8.14.9/8.14.9) with SMTP id w4I0KUk0004383
	for ; Thu, 17 May 2018 20:20:31 -0400
Message-Id: <201805180020.w4I0KUk0004383@REDACTED>
Received: (qmail 2921 invoked by uid 399); 18 May 2018 03:57:32 -0000
Received: from unknown (HELO (
  by with SMTP; 18 May 2018 03:57:32 -0000
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Description: Mail message body
Subject: Re: FreeLottoe(R)lottery'
To: Recipients 
From: "Mrs Rose Woods" 
Date: Thu, 17 May 2018 16:53:47 -0500
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by REDACTED id w4I0KWfx002926
X-UIDL: _8/"!(Eh"!9>*#!hJT!!
Status: RO
X-UID: 1885

Dear Winniner,
  We happily announce to you the draw of FreeLotto® online Sweepstakes International program held this year 2018.
You have won 2,000,000 in cash and prize (2 Million USD ) from FreeLotto® online Sweepstakes draw 2018.
Your Email Identity was one of the selected email all over the world in the lottery draw and it comes out one of the lucky winning number. You are to contact claims Officer via email below for claims procedures.

Mr Carl J MCCpherson


Congratulations!! Once again.

Yours in service,
Publicity Secretary.
Rose Woods.

VirtualBox Kernel Modules Won’t Compile with Linux 4.14.24

This morning, I tried to run VirtualBox on my workstation–running Slackware64 Current–at work and found that the kernel modules were not installed. Knowing that I had upgraded the kernel (to 4.14.24) this morning, I tried to build the modules:

cd /usr/src/vboxhost-5.2.8

and got a horrible message (and feeling -):

/opt/VirtualBox/src/vboxhost/vboxdrv/Makefile.include.header:141: *** Error: unable to find the headers of the Linux kernel to build against. Specify KERN_VER= (currently 4.14.24) and run Make again.  Stop.
make[1]: Leaving directory '/opt/VirtualBox/src/vboxhost/vboxdrv'
make: *** [Makefile:49: all] Error 2

I tried replacing the kernel source (the Slackware package) with source from I still got the same error.  As of yet, I have no idea what the exact issue is, but I’ll keep poking around (when I get the time).  For now, I’m back to running Slackware 14.2.

Update: The answer to this is on Linux Questions:!!

So, kudos to mralk3! (I guess this could be viewed as a bug in the Slackware package: kernel-modules-4.14.24-x86_64-1, but I won’t say that out loud -)

I did have to replace the new Kernel source I downloaded with the Slackware Package: kernel-huge-4.14.24-x86_64-1

UPDATE 2018-03-09 — Well, the good folks at Slackware have released an updated kernel-modules package with the links fixed: /kernel-modules-4.14.24-x86_64-2.txz! Happy Daze!

UPDATE 2018-03-12 — Both the superseded Linux-modules-4.14.25 and the (as of now) current Linux-modules-2.14.26 have the correct links and the VirtualBox modules build with no errors. Yay!

UPDATE 2018-03-16 — Today linux-modules-4.14.27 landed and it, too, works jest fine with VirtualBox.

Happy Slacking!

Google Chrome 61 and Slackware 14.2

On Tuesday (September 5, 2017), Google released Chrome 61 (61.0.3163.79).  The .SlackBuild from extra worked to make the Slackware package and it installed just fine.  But, when I tried to run Chrome, it failed to open.

NOTE: Early on September 7, 2017, the good folks at released mozilla-nss-3.31.1 for Slackware 14.1, 14.2 and current, making this post useless. Yay!

So, I tried to run Chrome from the shell, and received the following error message:] NSS_VersionCheck("3.26") failed. NSS >= 3.26 is required. Please upgrade to the latest NSS, and if you still get this error, contact your distribution maintainer

After a bit of poking around, I came to believe that the issue was that Slackware 14.2 uses mozilla-nss-3.23.  So, I grabbed the source for mozilla-nss

wget -r

Then I grabbed the source for nss, from:

Now for the fun stuff:

After looking at the .Slackbuild, I turned nss-3.26.2.tar.gz into nss-3.26.2.tar.xz:

gzip -d nss-3.26.2.tar.gz
xz nss-3.26.2.tar

Then in the .Slackbuild, I changed:




and changed:




Running the .Slackbuild created the package: mozilla-nss-3.26.2-x86_64-1stu. After installing my new package, Chrome runs.

Happy Slacking!

Yet Another Domain Registration Company Violating WHOIS Policy

On 2 June 2017, I received physical junk mail from yet another scammy domain seller. Apparently, (a.k.a., Internet Domain Name Serivces hopes that I’m stupid enough to believe that are some official domain registration organization and that I should pay them $45 per year to renew/extend one of my domains. The letter claims that I should reply by 31 July 2017, though the domain in question is valid until 25 September 2017.

Here we have another organization scamming folks and using WHOIS information in violation of the WHOIS policies.

This service is intended only for query-based access. You agree that you will use
this data only for lawful purposes and that, under no circumstances will you use
this data to: (a) allow, enable, or otherwise support the transmission by e-mail,
telephone, or facsimile of mass unsolicited, commercial advertising or solicitations
to entities other than the data recipient's own existing customers . . .

The only way they could have connected my mailing address to the domain name is to use WHOIS.  I guess they hope I’m too dumb to know that I did not register my domain(s) with them.

To give an idea of the upstanding nature of this organization, here’s an excerpt from their WHOIS record:

stu@angus:~$ whois
Domain Name: IDNS.AG
Registry Domain ID: D105800000003060849-AGRS
Registrar WHOIS Server:
Registrar URL:
Updated Date: 2017-04-17T22:20:49Z
Creation Date: 2015-04-17T18:03:51Z
Registry Expiry Date: 2018-04-17T18:03:51Z
Registrar Registration Expiration Date:
Registrar: NicAg Registrar
Registrar IANA ID: 800117
Registrar Abuse Contact Email:
Registrar Abuse Contact Phone:

That’s right: no abuse contact information given.

Of course, this physical spam arrived on the day that I switched my WHOIS records to my P.O. Box, instead of the address.  Now I’ll be able to prove that future crap like this is from whois  Like the email address I use for WHOIS, this P.O. Box will only be used for my domain ICAN information.

I Was Wrong (again): Let’s Encrypt Works For Me, Thanks to A2Hosting!

As often happens, when I bitch and whine about something, I’m bloody wrong! I was wrong about being unable to use Let’s Encrypt.

No, the folks at EFF didn’t fix anything. It turns out that my hosting provider, A2Hosting took care of it for me, before I asked!! Yay A2Hosting!

I took another look through the support documents at and found the certificates I had been unable to create were there just waiting to be used!!

All I had to do was change the site_url in the xx_options database table to https (instead of http), then add a couple lines to the .htaccess file:

After the line:
RewriteEngine On

I added:
RewriteCond %{HTTPS} !=on
RewriteRule (.*)$1 [L]

Once I cleared the WordPress cache, my site(s) are all HTTPS all the time!

Woohoo and major kudos to A2 Hosting!

If you want excellent hosting with phenomonal support, try A2 Hosting for yourself!

Happy Slacking!

Still Fighting (and Failing) with Let’s Encrypt

I’m still fighting with Let’s Encrypt.  Like a Mac, it’s so easy to use, I can’t figure it out!

UPDATE: A2 Hosting had the answer the entire time! Oops!

Here’s an outline of my latest failure: says: python --public-key domain.csr > signed.crt

I used: python ~/tmp/test/letsencrypt-nosudo-master/ --file-based --public-key domain-redacted.csr > domain-redacted.crt

Script above said:
openssl dgst -sha256 -sign user.key -out register_gI2frw.sig register_LvKVaG.json
openssl dgst -sha256 -sign user.key -out domain_jJRoxo.sig domain_BmX1i4.json
openssl dgst -sha256 -sign user.key -out cert_b2jwiM.sig cert_6c9otr.json

I used:
openssl dgst -sha256 -sign domain-redacted.key -out register_gI2frw.sig register_LvKVaG.json
openssl dgst -sha256 -sign domain-redacted.key -out domain_jJRoxo.sig domain_BmX1i4.json
openssl dgst -sha256 -sign domain-redacted.key -out cert_b2jwiM.sig cert_6c9otr.json

Then script above said:
openssl dgst -sha256 -sign user.key -out challenge_wdJ_kc.sig challenge_XoHFc0.json

I used:
openssl dgst -sha256 -sign domain-redacted.key -out challenge_wdJ_kc.sig challenge_XoHFc0.json

Script above said create file:

containing QOtda4ngP4J-My0JgU8vZXixUjGiPURMo8YuwMNTkcI.4sYEd6yKWeYPjvJB5RJMuAN9IY19lhuVHsHShPlVV0A

I did:
cd ~/public_html
mkdir .well-known
cd .well-known
mkdir acme-challenge
cd acme-challenge
vi QOtda4ngP4J-My0JgU8vZXixUjGiPURMo8YuwMNTkcI

At this point, the command curl -I

HTTP/1.1 200 OK
Date: Sat, 29 Apr 2017 17:04:53 GMT
Server: Apache
Last-Modified: Sat, 29 Apr 2017 17:03:15 GMT
ETag: "1586735-58-54e512a7647cb"
Accept-Ranges: bytes
Content-Length: 88
Vary: User-Agent
Content-Type: text/plain

And the script above bombs with:
"type": "urn:acme:error:badNonce",
"detail": "JWS has invalid anti-replay nonce 3rsTr_0FsH4iz-QzvzqfzheGl4nx6ecaAMNGfKY8Ry0",
"status": 400
Traceback (most recent call last):
File "/home/kentucky/tmp/test/letsencrypt-nosudo-master/", line 446, in
signed_crt = sign_csr(args.public_key, args.csr_path,, file_based=args.file_based)
File "/home/kentucky/tmp/test/letsencrypt-nosudo-master/", line 386, in sign_csr
resp = urllib2.urlopen(csr_url, csr_data)
File "/usr/lib64/python2.6/", line 126, in urlopen
return, data, timeout)
File "/usr/lib64/python2.6/", line 397, in open
response = meth(req, response)
File "/usr/lib64/python2.6/", line 510, in http_response
'http', request, response, code, msg, hdrs)
File "/usr/lib64/python2.6/", line 435, in error
return self._call_chain(*args)
File "/usr/lib64/python2.6/", line 369, in _call_chain
result = func(*args)
File "/usr/lib64/python2.6/", line 518, in http_error_default
raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 400: Bad Request

I’m giving up for a while . . . maybe I’ll hafta learn python and fix their code. Sheesh!

Wishing you Happy Slacking!

Let’s Encrypt Sounds Good, But I Found its Easier Way to be Impossible

About  a year ago, the Internet Security Research Group (ISRG) launched an effort now called Let’s Encrypt to provide free (no cost) SSL certificates for web servers. The EFF (and perhaps others) have launched a set of tools known as certbot that aim to make getting and installing SSL certificates painless.

My experience getting and installing a certificate has been terrible!  After several hours of struggling, I seem to have discovered that Let’s Encrypt works for most everyone, except, of course, me!

UPDATE: A2 Hosting had the answer the whole time! Oops!

I have been requesting and using SSL certificates on Apache web servers for about 20 years.  Except for long wait times being verified, I have found the process painless and quite easy. It seems users have to be able to su or sudo to root in order to be able to request a certificate manually. This can’t be done on the shared hosting system I use. So it goes.

I’ll file this in the category with Bill Gates Tuva initiative which works for “everybody.” That definition of everybody does not include me.

UPDATE: With a bit more searching, I found a project on GitHub called Let’s Encrypt No Sudo which, of course, expects one to use sudo!!! There is a –file-based option that claims it will work without sudo. No such luck! Using this method bombed with the error:

"type": "urn:acme:error:malformed",
"detail": "Error creating new cert :: certificate public key must be different than account key",
"status": 400
Traceback (most recent call last):
File "../../test/letsencrypt-nosudo-master/", line 446, in
signed_crt = sign_csr(args.public_key, args.csr_path,, file_based=args.file_based)
File "../../test/letsencrypt-nosudo-master/", line 386, in sign_csr
resp = urllib2.urlopen(csr_url, csr_data)
File "/usr/lib64/python2.6/", line 126, in urlopen
return, data, timeout)
File "/usr/lib64/python2.6/", line 397, in open
response = meth(req, response)
File "/usr/lib64/python2.6/", line 510, in http_response
'http', request, response, code, msg, hdrs)
File "/usr/lib64/python2.6/", line 435, in error
return self._call_chain(*args)
File "/usr/lib64/python2.6/", line 369, in _call_chain
result = func(*args)
File "/usr/lib64/python2.6/", line 518, in http_error_default
raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 400: Bad Request

So easy and simple to understand . . . NOT! I tried the URL for which this bleeping python script claims it got a 400 error and the page loads just fine.

I’m surrendering again for a while until I calm down enough to follow the easy to use directions!

Happy Slacking!

WordPress 4.7.x: Issues Uploading Images (or other media)

On Friday, February 10th 2017, one of our multi-site WordPress installs began giving errors when attempting to upload media (images, etc.) and would not allow uploads.

"docname.png" has failed to upload.
Sorry, this file type is not permitted for security reasons.

After a big of Googling and reading, I found a post that helped. It seems there is a not bug in WordPress 4.7.2 that leads to this issue.

The fix on the first site on which I encountered this issue was fairly easy.  I installed the Disable Real Mime Check plugin, then went to settings for the WP Add Mime Types plugin (as Network Admin) and clicked the Save button.

Done! We are now able to upload .png files and attach them to pages.

This morning (Sunday, February 12, 2017), we began experiencing the same issue on another WordPress site. I tried the magic that worked before (added Disable Real Mime Check plugin and clicked Save in the settings for WP Add Mime Types. We could now upload .png files, but they didn’t display either in the Media Library or on the pages to which they were attached. Ugh!

More poking around, reading and testing led to discovery that requests for  images (and other uploaded media) returned a 403 Forbidden error.

NOTE: I used “curl -I http://mysite/image_url” to ferret out this info.

As I looked at the URL WordPress was giving for the image, I noted that it didn’t include wp-content as I expected.  Instead, the URL was: http://mysite/subsite/files/2017/02/image.png. Hmmmm. no directory called files exists on that server.

Looking that the top-level .htaccess file, I found that media files for multi-site WP installs are served by ms-files.php.

# uploaded files
RewriteRule ^files/(.+) wp-includes/ms-files.php?file=$1 [L]

A little more Googling and reading, I found the page:

This turned out to be my answer.  My .htaccess was the wrong one!  I replaced it with the WordPress 3.0 through 3.4.2 .htaccess example from that page and everything worked!!


Happy Slacking!

KRDC Fails on Slackware Current (a.k.a 14.2) with Could not start “xfreerdp”; make sure xfreerdp is properly installed.

Along with the excellence of Slackware current comes a broken version of KRDC (KDE Remote Desktop Client) that doesn’t work for RDP connections.  It fails with a dialog saying:

Could not start "xfreerdp"; make sure xfreerdp is properly installed.


After poking around the source code, I got rather frustrated as I found the KDE source way out of my league.  Some research using the working KRDC on Slackware 14.1, lead me to rdesktop, which seems to be what KRDC uses to connect rdp to Windows machines.

I found that rdesktop was installed on my Slackware current install and would run, without complaining about the lack of xfreerdp. Reading the output of:rdesktop -h, I eventually came up with a command line that worked to connect to the Windows XP box at work.

My last step was to create an XFCE launcher with a command line, something like:

rdesktop -u user -g800x600 -a 24

Just replace user with your username, 800✕600 with your preferred desktop geometry and with the name (or IP address) of the machine to which you wish to connect. So, I didn’t fix KRDC, but I now have w workable solution for connecting to Windows machines via rdp from Slackware current.

Happy Slacking!

Segfault Running perl on Slackware Current (2015-12-22)

This morning, Tuesday 2015-12-22, I noticed that some PERL scripts which had worked in the past now segfault on Slackware64 Current.

My investigation revealed that the issue is with Term::ReadKey, as when I run:

perl -d -MCPAN -eshell

I get:

Loading DB routines from version 1.49
Editor support available.

Enter h or 'h h' for help, or 'man perldebug' for more help.

main::(-e:1):    shell
Signal SEGV at /usr/local/lib64/perl5/Term/ line 303.
require Term/ called at /usr/local/share/perl5/Term/ReadLine/ line 491
eval {...} called at /usr/local/share/perl5/Term/ReadLine/ line 493
readline::preinit called at /usr/local/share/perl5/Term/ReadLine/ line 207
require Term/ReadLine/ called at /usr/local/share/perl5/Term/ReadLine/ line 63
eval {...} called at /usr/local/share/perl5/Term/ReadLine/ line 63
Term::ReadLine::Perl::new("Term::ReadLine", "perldb", GLOB(0x18a8db0), GLOB(0x173cf88)) called at /usr/share/perl5/ line 6840
DB::setterm() called at /usr/share/perl5/ line 1832
DB::_DB__read_next_cmd(undef) called at /usr/share/perl5/ line 2761
DB::DB called at -e line 1

Poking around a bit, I learned that: while ReadTerm is part of the Slackware package perl-5.22.0-x86_64-1, ReadKey is something added by me via CPAN.

To fix this, I removed all the perl stuff from /usr/local/ using:

rm -r /usr/local/lib64/perl5

After that, no segfault when I run:

perl -MCPAN -eshell

Woohoo! A quick reinstall of some CPAN stuff I like and I’m back in business. At the CPAN prompt:

install YAML
install Bundle::LWP
install Bundle::CPAN

My guess is that the aaa_elflibs upgrade of 15 December caused this, but that’s only a guess.  Regardless of the cause, this fix worked.

Happy Slacking!