diff --git a/content/ansible-modules.rst b/content/ansible-modules.rst
index 9004026151955d3dac7b732746568af1ea5223c6..2cc5e522e4c8f7e2623ef7c756b1b2a0e1e0df9d 100644
--- a/content/ansible-modules.rst
+++ b/content/ansible-modules.rst
@@ -6,17 +6,17 @@ Sharing Ansible modules
 With Ansible you're expected to share roles with the Ansible Galaxy tool (either
 through the `Ansible Galaxy hub <https://galaxy.ansible.com/>`_ or just using
 straight git repositories). This works well enough (and personally I am using
-:code:`ansible-galaxy init` to start each new role, even those that I'm not going to
-share with the community). However, for sharing modules there is no such easy
-solution, or is it?
+:code:`ansible-galaxy init` to start each new role, even those that I'm not
+going to share with the community). However, for sharing modules there is no
+such easy solution, or is it?
 
 Sharing with git submodule
 --------------------------
 
-I'd like to start by saying that git submodule is the poor man's package
-manager and it's lack of popularity is (somewhat) justified. However, this is a
-nice demonstration of a case where there is no package manager available and of
-using git submodule instead. Also, I've only been able to use this technique for
+I'd like to start by saying that git submodule is the poor man's package manager
+and it's lack of popularity is (somewhat) justified. However, this is a nice
+demonstration of a case where there is no package manager available and of using
+git submodule instead. Also, I've only been able to use this technique for
 modules written in Python, which is nice considering the lack of boiler-plate
 that Ansible provides and that Python is my personal preference.
 
@@ -25,8 +25,8 @@ the modules in it. You can put them in sub-directories and as a far as I know,
 there's no restriction on the hierarchy depth. In your playbook directory create
 a :code:`library` directory (the Ansible default, so you can change this in
 :code:`ansible.cfg`) and create an empty :code:`__init__.py` file inside that
-directory. Add a git submodule inside that directory and you're done. Let's see an
-example
+directory. Add a git submodule inside that directory and you're done. Let's see
+an example
 
 .. code:: shell
 
@@ -44,8 +44,8 @@ example
     git push
 
 Really, not that complicated. The only magic (undocumented) bit is creating a
-:code:`__init__.py` file inside the :code:`library` directory, which is a
-shame that the Ansible documentation doesn't cover that. If you want to see a
+:code:`__init__.py` file inside the :code:`library` directory, which is a shame
+that the Ansible documentation doesn't cover that. If you want to see a
 real-life example, checkout my `ansible-playbooks
 <https://git.shore.co.il/ansible/ansible-playbooks.git>`_ and `ansible-modules
 <https://git.shore.co.il/ansible/ansible-modules.git>`_ git repos.
diff --git a/content/pelican.rst b/content/pelican.rst
index b107dcefa7a8f33f9002764167b5c60a16aa400f..c5eaa89d35b8ae1b2b88540fb33e67caae00c444 100644
--- a/content/pelican.rst
+++ b/content/pelican.rst
@@ -6,13 +6,17 @@ Blogging with Pelican
 What is Pelican?
 ----------------
 
-`Pelican <http://blog.getpelican.com/>`_ is a static site generator.
-It's written in Python, focusing on blogs, using reStructuredText, Jinja2 and Fabric (but you can use Markdown and makefiles and has provisions for normal web pages as well).
-It's a pythonic tool that's easy to use and was a breeze to setup.
+`Pelican <http://blog.getpelican.com/>`_ is a static site generator.  It's
+written in Python, focusing on blogs, using reStructuredText, Jinja2 and Fabric
+(but you can use Markdown and makefiles and has provisions for normal web pages
+as well).  It's a pythonic tool that's easy to use and was a breeze to setup.
 
 Installing Pelican
 ------------------
-As Pelican is a static blog/ website generator, all we're doing is in your workstation. All you need to have server-wise is a bog-standard web server (like Apache or Nginx). Everything else is done on your local machine. I installed Pelican from Debian (it's currently available in testing)
+As Pelican is a static blog/ website generator, all we're doing is in your
+workstation. All you need to have server-wise is a bog-standard web server (like
+Apache or Nginx). Everything else is done on your local machine. I installed
+Pelican from Debian (it's currently available in testing)
 
 .. code:: shell
 
@@ -61,12 +65,16 @@ Create a blog directory and an empty blog ::
   > Do you want to upload your website using GitHub Pages? (y/N)
   Done. Your new project is available at blog
 
-Since Pelican uses OpenSSH, you can use servers defined in your SSH preferences. Now, lets configure the blog to our liking.
+Since Pelican uses OpenSSH, you can use servers defined in your SSH preferences.
+Now, lets configure the blog to our liking.
 
 Configuration
 -------------
 
-In the blog directory there are the 2 configuration files: pelicanconf.py for configuring Pelican and publishconf.py for configuration that are only for publishing using Make or Fabric. Pelican also creates standard Makefile and fabfile.py for you. I've made the following modifications to pelicanconf.py: ::
+In the blog directory there are the 2 configuration files: pelicanconf.py for
+configuring Pelican and publishconf.py for configuration that are only for
+publishing using Make or Fabric. Pelican also creates standard Makefile and
+fabfile.py for you. I've made the following modifications to pelicanconf.py: ::
 
     TIMEZONE = 'Asia/Jerusalem'
     PATH = "content"
@@ -81,11 +89,20 @@ And to publishconf.py: ::
 
     CATEGORY_FEED_ATOM = None
 
-I've set the timezone to mine (so that the time of published articles is correct), add everything under contents/static as static contents to be uploaded to the server, disabled showing of categories of articles and creating feeds for them, disabled saving of articles by tags and set pages (which are simple web pages unlike articles which are blog entries) to show on the menu. Next, themes.
+I've set the timezone to mine (so that the time of published articles is
+correct), add everything under contents/static as static contents to be uploaded
+to the server, disabled showing of categories of articles and creating feeds for
+them, disabled saving of articles by tags and set pages (which are simple web
+pages unlike articles which are blog entries) to show on the menu. Next, themes.
 
 Themes
 ------
-Pelican comes with a default theme (the same as used by Pelican's website) but I wanted something more understated so I took at look at `https://github.com/getpelican/pelican-themes <https://github.com/getpelican/pelican-themes>`_ and chose pelican-mockingbird. Either clone it or add it as a git submodule (depends on if you're using Git to version control your blog or not)
+Pelican comes with a default theme (the same as used by Pelican's website) but I
+wanted something more understated so I took at look at
+`https://github.com/getpelican/pelican-themes
+<https://github.com/getpelican/pelican-themes>`_ and chose pelican-mockingbird.
+Either clone it or add it as a git submodule (depends on if you're using Git to
+version control your blog or not)
 
 .. code:: shell
 
@@ -96,12 +113,16 @@ and set the theme to that by adding the following to pelicanconf.py: ::
 
     THEME = "./pelican-mockingbird"
 
-I've also edited :code:`base.html` and :code:`article.html` inside of :code:`pelican-mockingbird/templates` to suite my liking. Next, let us add a new entry.
+I've also edited :code:`base.html` and :code:`article.html` inside of
+:code:`pelican-mockingbird/templates` to suite my liking. Next, let us add a new
+entry.
 
 Adding an entry
 ---------------
 
-Create a ReStructuredText file inside of contents. The filename is for personal use and not critical. The heading is the article name and you can add the following for Pelican to use: ::
+Create a ReStructuredText file inside of contents. The filename is for personal
+use and not critical. The heading is the article name and you can add the
+following for Pelican to use: ::
 
     :date: 2014-04-19
     :slug:  this-will-the-filename
@@ -114,7 +135,12 @@ After we added the content we want to upload it to our web server (I use fabric)
 
     fab publish
 
-If you don't have keys set for the server it will ask you for your password to the server.
-Last thing, you can create pages, create a pages directory inside contents and save the files there. Their format is the same as articles but they'll have a somewhat template applied and they will be shown in the menu. A good example will an 'About Me' page.
+If you don't have keys set for the server it will ask you for your password to
+the server.  Last thing, you can create pages, create a pages directory inside
+contents and save the files there. Their format is the same as articles but
+they'll have a somewhat template applied and they will be shown in the menu. A
+good example will an 'About Me' page.
 
-That's it, you now have Pelican installed, configured and published to your web site. If you want to see a real life example, clone `my blog <https://git.shore.co.il/nimrod/blog>`_.
+That's it, you now have Pelican installed, configured and published to your web
+site. If you want to see a real life example, clone `my blog
+<https://git.shore.co.il/nimrod/blog>`_.
diff --git a/content/ssl.rst b/content/ssl.rst
index cca0cff89af88ca0bd356b418d5d4aa6ae99f10c..d8ff77195ff944eff7cb6f835e33468591b42c44 100644
--- a/content/ssl.rst
+++ b/content/ssl.rst
@@ -7,35 +7,74 @@ SSL/TLS ciphers
 The problem at hand
 -------------------
 
-You have a website and you want to encrypt the traffic going in and out of your webserver. Since you heard about the attacks currently known at SSL and TLS, you want to configure your server to not be vulnerable to any. In a perfect world (or if you control your clients) all you have to do is allow TLS 1.2 and AES-GCM with elliptic-curve Diffie-Hellman key exchange only (AESGCM+ECDH when using openssl) and you're set. This combination is secure, fast, offers perfect forward secrecy and at the time of writing there are no known attacks that make it crackable in a reasonable time. So what's the problem? With a public website you don't control the web browser the visitor uses. If he or she is using IE on Windows XP or Android 2.x the browser doesn't support TLS 1.2 or AES-GCM and the visitor can't access the website. How do you keep your website secure yet reasonably accessible?
+You have a website and you want to encrypt the traffic going in and out of your
+webserver. Since you heard about the attacks currently known at SSL and TLS, you
+want to configure your server to not be vulnerable to any. In a perfect world
+(or if you control your clients) all you have to do is allow TLS 1.2 and AES-GCM
+with elliptic-curve Diffie-Hellman key exchange only (AESGCM+ECDH when using
+openssl) and you're set. This combination is secure, fast, offers perfect
+forward secrecy and at the time of writing there are no known attacks that make
+it crackable in a reasonable time. So what's the problem? With a public website
+you don't control the web browser the visitor uses. If he or she is using IE on
+Windows XP or Android 2.x the browser doesn't support TLS 1.2 or AES-GCM and the
+visitor can't access the website. How do you keep your website secure yet
+reasonably accessible?
 
 Known attacks on SSL and TLS
 ----------------------------
 
-First, SSL 2.0 is insecure (it's even disabled by default in IE7) so we'll not be using it. Version roll back attacks allow a man in the middle to change the response from the client to force a lower grade (read the lowest grade possible) cipher suite.
-The BEAST attack exploits a weakness in CBC ciphers in TLS 1.0. But fixes all major browsers have been released for quite some time, so we're going to assume that the client is secure and CBC ciphers are safe to use (reasonable assumption, but still an assumption).
-CRIME and BREACH exploit a weakness in compression and RC4 is considered to be weak although not broken like DES or MD5.
+First, SSL 2.0 is insecure (it's even disabled by default in IE7) so we'll not
+be using it. Version roll back attacks allow a man in the middle to change the
+response from the client to force a lower grade (read the lowest grade possible)
+cipher suite.  The BEAST attack exploits a weakness in CBC ciphers in TLS 1.0.
+But fixes all major browsers have been released for quite some time, so we're
+going to assume that the client is secure and CBC ciphers are safe to use
+(reasonable assumption, but still an assumption).  CRIME and BREACH exploit a
+weakness in compression and RC4 is considered to be weak although not broken
+like DES or MD5.
 
 
 IE in Windows XP
 ----------------
 
-All version of IE that are available on Windows XP offer RC4 and 3DES as the best ciphers available. Unfortunately Chrome uses the Windows scrypt library so it has the same limitation. For a user this means that if you're on Windows XP you should be using an up-to-date version of Firefox to have the best experience until you can move from Windows XP (or Windows in general). For the website manager it leaves you with 2 options, either add support for either 3DES or RC4 ciphers with SHA1 hashes (for openssl, add RC4-SHA or 3DES-SHA at the end of the cipher list) or ask users to use Firefox if they're still on XP. I chose the latter rather then the former, but I have that luxury.
+All version of IE that are available on Windows XP offer RC4 and 3DES as the
+best ciphers available. Unfortunately Chrome uses the Windows scrypt library so
+it has the same limitation. For a user this means that if you're on Windows XP
+you should be using an up-to-date version of Firefox to have the best experience
+until you can move from Windows XP (or Windows in general). For the website
+manager it leaves you with 2 options, either add support for either 3DES or RC4
+ciphers with SHA1 hashes (for openssl, add RC4-SHA or 3DES-SHA at the end of the
+cipher list) or ask users to use Firefox if they're still on XP. I chose the
+latter rather then the former, but I have that luxury.
 
 What are we left with?
 ----------------------
 
-Since modern browser browsers that support SSL 3.0 support TLS 1.0, we'll be using TLS 1.0 or newer. Any AES cipher (AES-GCM preferred) with ECDH key exchange (preferred) or DH key exchange and SHA2 (preferred) or SHA1 hashes and disable compression. On my server (OpenBSD firewall/ load-balancer/ SSL terminator and reverse-proxy) with the included OpenSSL and Nginx the configuration is as followed ::
+Since modern browser browsers that support SSL 3.0 support TLS 1.0, we'll be
+using TLS 1.0 or newer. Any AES cipher (AES-GCM preferred) with ECDH key
+exchange (preferred) or DH key exchange and SHA2 (preferred) or SHA1 hashes and
+disable compression. On my server (OpenBSD firewall/ load-balancer/ SSL
+terminator and reverse-proxy) with the included OpenSSL and Nginx the
+configuration is as followed ::
 
     ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
     ssl_ciphers !kRSA:!3DES:!RC4:!DES:!MD5:!aNULL:!NULL:AESGCM+ECDH:AES256+ECDH:AES128:+SHA1;
     ssl_prefer_server_ciphers on;
 
 
-Take note that I first disable what I don't want, then allow what I do want in the order I prefer. I've also disabled DH key exchange with AES-GCM since all browsers that support AES-GCM support ECDH so I've opted for that (the reasoning being that ECDH is faster than DH so it's preferable).
+Take note that I first disable what I don't want, then allow what I do want in
+the order I prefer. I've also disabled DH key exchange with AES-GCM since all
+browsers that support AES-GCM support ECDH so I've opted for that (the reasoning
+being that ECDH is faster than DH so it's preferable).
 
 Final words
 -----------
 
-This is not enough to call your site secure. I haven't mentioned secure cookies, HSTS, input sanitation, cross-site scripting, OCSP, certificate strength, implementation vulnerabilities (such as OpenSSL's heartbleed) or any of the other security considerations. For testing purposes I used `sslscan <http://sourceforge.net/projects/sslscan/>`_ and `Calomel's SSL validation add-on for Firefox <https://calomel.org/firefox_ssl_validation.html>`_. You can also `SSLLabs' SSL test <https://www.ssllabs.com/ssltest/index.html>`_.
+This is not enough to call your site secure. I haven't mentioned secure cookies,
+HSTS, input sanitation, cross-site scripting, OCSP, certificate strength,
+implementation vulnerabilities (such as OpenSSL's heartbleed) or any of the
+other security considerations. For testing purposes I used `sslscan
+<http://sourceforge.net/projects/sslscan/>`_ and `Calomel's SSL validation
+add-on for Firefox <https://calomel.org/firefox_ssl_validation.html>`_. You can
+also `SSLLabs' SSL test <https://www.ssllabs.com/ssltest/index.html>`_.
 
diff --git a/content/why-no-blogging.rst b/content/why-no-blogging.rst
index b9fc40c4deaf18905931b417824a54ebca0f8a0d..b42b62b4e39d723f546a98190c9ee1bff03fc6b9 100644
--- a/content/why-no-blogging.rst
+++ b/content/why-no-blogging.rst
@@ -5,16 +5,16 @@ Why I don't write on my blog often?
 
 I often criticize myself on not blogging more often. The process goes like this:
 I'm doing something mildly interesting and I say to myself 'This is mildly
-interesting, maybe someone else will find this mildly interesting.'. But
-9 out of 10 times, what ever I'm doing has some code (when I say code I usually
-mean an Ansible playbook, a shell script or something similar) accompanying.
-Instead of a lengthy blog post, I publish a git repo. The repo has a :code:`README`
-file, the code is documented, there's a :code:`Makefile` or :code:`fabfile`,
-you can clone and fork the repo. It's almost always better than a blog post.
+interesting, maybe someone else will find this mildly interesting.'. But 9 out
+of 10 times, what ever I'm doing has some code (when I say code I usually mean
+an Ansible playbook, a shell script or something similar) accompanying.  Instead
+of a lengthy blog post, I publish a git repo. The repo has a :code:`README`
+file, the code is documented, there's a :code:`Makefile` or :code:`fabfile`, you
+can clone and fork the repo. It's almost always better than a blog post.
 
-However now I have many repositories and just a few blog posts. What I'm going to do
-from now on is I'll publish the git repo, but add a short post announcing the
-repo.
+However now I have many repositories and just a few blog posts. What I'm going
+to do from now on is I'll publish the git repo, but add a short post announcing
+the repo.
 
 ssl-ca
 ------
@@ -24,4 +24,5 @@ signed certificates. The main use case is an internal network (like a
 development or staging environment, but not just) where you control all nodes.
 For that goal, it's as close to a real CA as needed and somewhat secure. There's
 no OCSP or CRL, the certs serial is random, but the default hash, bit length and
-algorithms are modern and secure. You can get it at: https://git.shore.co.il/nimrod/ssl-ca/.
+algorithms are modern and secure. You can get it at:
+https://git.shore.co.il/nimrod/ssl-ca/.