fighting the lack of good ideas

automated let’s encrypt ssl certificate renewal on centos 7

In my how-to for Let’s Encrypt, I gave an example script that can be called via cron (or manually) which will renew Let’s Encrypt SSL certificates under CentOS 6.

If you want to do it on CentOS 7 (which is what I am now running), use the following:

cd ~/letsencrypt
git pull
systemctl stop httpd.service
~/letsencrypt/letsencrypt-auto --agree-tos --keep --rsa-key-size 2048 --standalone certonly -m user@domain.tld -d domain.tld [-d sub.domain.tld [-d ...]]
systemctl start httpd.service

Now, what does this script do? Step by step:

  1. clear-out the last grab of the Let’s Encrypt git repo (there’s probably a better way to do this, but I don’t know what it is)
  2. go to root’s home (/root)
  3. clone-down the Let’s Encrypt toolset
  4. stop httpd (Apache in my case, though you might be running nginx or something else
  5. run the cert tool in automated form:
    1. agree to terms of service
    2. keep current cert if it doesn’t need to be updated
    3. key size of 2048 bits
    4. run the standalone webserver to verify “ownership” of the domain
    5. generate just the cert
    6. administrative email (optional, but “encouraged”)
    7. domain(s) to issue cert for (must be individually identified with successive -d flags; LE does not support wildcard certs)
  6. restart httpd

I set mine to run @weekly in cron@monthly is likely good enough, but since it’s “free” to run, running slightly more than is necessary seems good to me. Plus, if you’re getting SSL certs for many domains all being served from the same server, they may have different expiration dates, so running more often is better.

My crontab entry for renewing certs:

@weekly /root/

lock screen slideshow in windows 10

In similar fashion to what I wrote about for OS X last year, and spurred by this article from Microsoft, here is my brief guide for doing the same on Windows 10.

Click your Notifications button near the clock.callout

Now click All Settingsnotifications

And you’ll see this


Click Personalization, then Lock Screen. Select “Slideshow” from the dropdown.lockscreen

There you go.

i’m a medium plogger now*

(*Though most people would call me an XXXL blogger.)

Following in the steps of Dave Winer, I am now plogging (sorta) on Medium.

And, like Mr Winer, I’m doing it via IFTTT (though not via RSS, I’m doing it via the WordPress channel).

If you’d like to do the same, use this IFTTT recipe.

let’s encrypt centos 6 – truly free ssl

There’s been quite a bit of excitement surrounding Let’s Encrypt recently – a truly 100% free SSL issuer.

Last week I helped a friend of mine get his first Let’s Encrypt certificate generated and configured for his website. One of the things I found incredibly frustrating is that Let’s Encrypt does not have a package for Red Hat/CentOS/Fedora! Ignoring such a massive installed base seems monumentally dumb – so I hope that they correct it soon. Until they do, however, here’s a tutorial that should cover the gotchas for getting Let’s Encrypt to work on a CentOS 6 server with Apache 2.

The documentation (as of 06 Jan 2015) on the Let’s Encrypt website is in error in a few places (or, at least, not as correct as is could/should be). One big thing to note, for example, is that it says Python 2.6 is supported (the current release for RHEL/CentOS 6). If you run the certificate generator without the --debug flag, though, it will error-out saying Python 2.6 is not supported.

While I used an existing CentOS 6 server, I’ll start this tutorial as I have many others – by telling you to go get a CentOS 6 server from Digital Ocean or Chunk Host.


Login as root (or a sudo-privileged account – but root is easier), and install Apache, Python, and SSLyum install httpd python mod_ssl.

Also enable the EPEL repository: yum install epel-repository (available from the CentOS Extras repository. I’m going to assume you are familiar with configuring Apache, and will only provide the relevant snippets from ssl.conf herein.

Now that the basics are done, let’s move to Let’s Encrypt. I ran the tool in interactive mode (which is going to require ncurses to be available – it’s probably already installed on your system) – but you’ll want to add a crontab entry since Let’s Encrypt certs expire after 90 days, so I’ll compact the interactive session into a single command-line call at the end, which you’ll need to “know” how to do, since the --help argument doesn’t do anything yet (that I could find).

Initial Certificate Creation

First, grab the latest Let’s Encrypt from GitHub:
git clone && cd letsencrypt

Stop Apache: service httpd stop. Let’s Encrypt is going to try to bind to ports 80 and 443 to ensure you have control the domain.

Now run the letsencrypt-auto tool – in debug mode so it’ll work with Python 2.6: ./letsencrypt-auto --debug certonly.

Use certonly because the plugins to automate installing for Apache and Nginx don’t work on CentOS yet.

Enter your domain name(s) for which you want to issue a certificate. If you accept incoming connections to www.domain.tld and domain.tld, be sure to put both in the list (likewise, if you have, say, blog.domain.tld that you want included).

Enter an administrative email address.

When the tool finishes, it’ll put symlinks in /etc/letsencrypt/live/domain.tld, with the “actual” certs in /etc/letsencrypt/archive/domain.tld. We’re going to reference the symlinks in /etc/letsencrypt/live/domain.tld next.

Edit /etc/httpd/conf.d/ssl.conf (I prefer emacs – but use whatever you prefer), and add the following lines in your VirtualHost directive:
SSLCertificateFile /etc/letsencrypt/live/domain.tld/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/domain.tld/privkey.pem
SSLCACertificateFile /etc/letsencrypt/live/domain.tld/cert.pem

Restart Apacheservice httpd start.

Try hitting https://domain.tld in your web browser – and you should be golden!

Automating Renewal

Create a small shell script called somewhere you’ll remember where it is – like /root:
service httpd stop
# add additional '-d' entries for more subdomains
/path/to/letsencrypt/letsencrypt-auto --debug --keep --agree-tos --rsa-key-size 2048 certonly -m ssladmin@domain.tld -d domain.tld -d www.domain.tld
service httpd start

For your crontab entry, do the following to setup monthly cert renewal:
@monthly /path/to/

show only most recent facebook news feed

(Note: I did this in Chrome – it’ll be a little different in other browsers)

I have several complaints about the book of the face – not least of which is that it likes to reset your News Feed from “Most Recent” (aka most useful) to “Top Stories” (aka whatever Facebook wants you to see).

I also like to avoid the fluff off the other columns (ads, games, groups, pages, chat, etc) when all I want is the most recent stream. So, after some searching, fiddling, and tweaking, I now have my news feed (and only my news feed) appear on the side of my screen in chronological order.

How to do what I did:

  • install the Auto Refresh extension for Chrome (only if you want the news feed to automatically update)
  • go to (this is the mobile Facebook view sorted by chronological order) in a new window (not new tab)
  • right-click on the tab holding the mobile Facebook feed, and select Pin Tab
  • click the Auto Refresh extension button and select how often you want your feed to refresh, and click Start
  • resize the window to a comfortable reading width (mine is about 15% of my screen, or about 3″)
  • slide it all the way to one side of your screen or another
  • enjoy

There are some other ways to accomplish more-or-less the same thing:

  • bookmark the mobile news feed URL
  • set the mobile news feed URL as your home page
  • sign-in to your Facebook account in more than one browser (instead of having two windows in one browser), and load the mobile edition therein

Hope this helps you like it’s helped me.

system-wide proxying with os x (yosemite)

Perhaps you’re at a coffee shop, and want to ensure your communication is secure.

Or maybe you are out of the country, and need access to something like

What’s a body to do?

If you have a Mac, set up a system-wide proxy setting for a new Location, of course!

This is a very simple thing to do, but does require you have access to an SSH server somewhere.


  • Create a new Location in your Network Preferences (name it something ‘obvious’ like “Proxy” or “Untrusted”Locations
  • Remove services you don’t need (most likely you only need WiFi) Services
  • Go to Advanced -> Proxies
  • Enable SOCKS Proxy and set server to ‘localhost’ with ‘9999’ as the port proxies
  • Start a port-forwarded SSH session in Terminal :: ssh -D 9999 user@remotehost
  • Click OK in the Proxies setting window
  • Click Apply in the Network preferences panel

That’s it. You do need to remember to create the port-forwarded SSH connection, or your web browsers and such will fail to connect properly.

You can change Location easily via ->Location.

Tested on OS X Yosemite. It should work elsewhere, but I only have a 10.10 machine to work with.

owncloud vs pydio – more diy cloud storage

Last week I wrote a how-to on using Pydio as a front-end to a MooseFS distributed data storage cluster.

The big complaint I had while writing that was that I wanted to use ownCloud, but it doesn’t Just Work™ on CentOS 6*.

After finishing the tutorial, I decided to do some more digging – because ownCloud looks cool. And because it bugged me that it didn’t work on CentOS 6.

What I found is that ownCloud 8 doesn’t work on CentOS 6 (at least not easily).

The simple install guide and process really is about version 8, and the last one that can be speedy-installed is 7. And as everyone knows, major version releases often make major changes in how they work. This appears to be very much the case with ownCloud going from 7 to 8.

In fact, the two pages needed for installing ownCloud are so easy to follow, I see no reason to copy them here. It’s literally three shell commands followed by a web wizard. It’s almost too easy.

You need to have MySQL/MariaDB installed and ready to accept connections (or use SQLite) – make a database, user, and give the user perms on the db. And you need Apache installed and running (along with PHP – but yum will manage that for you).

If you’re going to use MooseFS (or any other similar tool) for your storage backend to ownCloud, be sure, too, to bind mount your MFS mount point back to the ownCloud data directory (by default it’s /var/www/html/owncloud/data). Note: you could start by using local storage for ownCloud, and only migrate to a distributed setup later.

Pros of Pydio

  • very little futzing needed to make it work with CentOS 6
  • very clean user management
  • very clean webui
  • light system requirements (doesn’t even require a database)

Pros of ownCloud

  • apps available for major mobile platforms (iOS, Android), desktop)
  • no futzing needed to work with CentOS 7
  • very clean user management
  • clean webui

Cons of Pydio

  • no interface except the webui

Cons of ownCloud

  • needs a database
  • heavier system requirements
  • doesn’t like CentOS 6

What about other cloud environments like Seafile? I like Seafile, too. Have it running, in fact. Would recommend it – though I think there are better options now than it (including ownCloud & Pydio).

*Why do I keep harping on the CentOS 6 vs 7 support / ease-of-use? Because CentOS / RHEL 7 is different from previous releases. I covered that it was different for the Blue Grass Linux User Group a few months ago. Yeah, I know I should be embracing the New Way™ of doing things – but like most people, I can be a technical curmudgeon (especially humorous when you consider I work in a field that is about not being curmudgeonly).

Guess this means I really need to dive into the new means of doing things (mostly the differences in how services are managed) – fortunately, the Fedora Project put together this handy cheatsheet. And Digital Ocean has a clew of tutorials on basic sysadmin things – one I used for this comparison was here.