And you’ll see this
There you go.
And you’ll see this
There you go.
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.
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
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).
First, grab the latest Let’s Encrypt from GitHub:
git clone https://github.com/letsencrypt/letsencrypt && cd letsencrypt
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.
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/httpd/conf.d/ssl.conf (I prefer emacs – but use whatever you prefer), and add the following lines in your VirtualHost directive:
Restart Apache –
service httpd start.
https://domain.tld in your web browser – and you should be golden!
Create a small shell script called
renew-LE-certs.sh somewhere you’ll remember where it is – like
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 firstname.lastname@example.org -d domain.tld -d www.domain.tld
service httpd start
For your crontab entry, do the following to setup monthly cert renewal:
(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.
There are some other ways to accomplish more-or-less the same thing:
Hope this helps you like it’s helped me.
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 annualcreditreport.com.
What’s a body to do?
If you have a Mac, set up a system-wide proxy setting for a new Location, of course!
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.
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.
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.
*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.
And that I find MooseFS to be fascinating. As of 2.0, MooseFS comes in two flavors – the Community Edition, and the Professional Edition. This how-to uses the CE flavor, but it’d work with the Pro version, too.
I started with the MooseFS install guide (pdf) and the Pydio quick start steps. And, as usual, I used Digital Ocean to host the cluster while I built it out. Of course, this will work with any hosting provider (even internal to your data center using something like Backblaze storage pods – I chose Digital Ocean because they have hourly pricing; Chunk Host is a “better” deal if you don’t care about hourly pricing). In many ways, this how-to is in response to my rather hackish (though quite functional) need to offer file storage in an otherwise-overloaded lab several years back. Make sure you have “private networking” (or equivalent) enabled for your VMs – don’t want to be sharing-out your MooseFS storage to just anyone 🙂
Why would you want to do this? Maybe you need an in-house shared/shareable storage environment for your company / organization / school / etc. Maybe you’re just a geek who likes to play with new things. Or maybe you want to get into the reselling business, and being able to offer a redundant, clustered, cloud, on-demand type storage service is something you, or your customers, would find profitable.
Please go make this better and show-off what you did that was smarter, more efficient, cheaper, faster, etc. Turn it into something you could deploy as an AMID on AWS. Or Docker containers. Or something I couldn’t imagine. Everything on this site is licensed under the CC BY 3.0 – have fun with what you find, make it awesomer, and then tell everyone else about it.
I think I’ll give LizardFS a try next time – their architecture is, diagrammatically, identical to the “pro” edition of MooseFS. And it’d be fun to have experience with more than one solution.