Enable Letsencrypt and Joomla behind proxy

// posted here so I remember it //

LetsEncrypt offers owners of domains the option to create free-of-charge SSL certificates. Having a blog's login form sending passwords via encrypted channels is a Good Idea, but so far I put it off because previously it was costly and a hassle to get this done.

When the initiative to have SSL everywhere started, the tools were not so great and not all browsers recognized LetsEncrypt. Often they would show warnings about an unknown certificate authority, but by now it looks those things have been solved. There are even a lot of tools and package to get you started quickly for your given web server and host operating system.

sudo apt-get install letsencrypt

will get you started on Ubuntu.

sudo letsencrypt --apache

will give a list of your enabled domains on the Apache web server and ask which ones to SSLify. 

Caveat 1: if you are using vhosts, each must be in its own configuration file. This was some work.

Caveat 2: if you are using Joomla, you need to configure it to use SSL - I did simply turn on "force SSL for entire site" and whoops, endless redirect loop.

Since my Joomla instances live inside a virtual machine (KVM), the proxy Apache on the host would serve as a termination to the SSL connection and then send the unencrypted request to the virtualized Joomla. But since Joomla would try to force a redirect to SSL, it would always answer with "hey, you need to encrypt this request" - and the browser would follow the redirect, only to end up in another iteration of the host de-crypting and Joomla complaining.

You need to add a request header to the host Apache:

<VirtualHost *:80>
    RequestHeader set X-Forwarded-Proto "http"
<VirtualHost *:443>
    RequestHeader set X-Forwarded-Proto "https"

and add

SetEnvIfNoCase X-Forwarded-Proto https HTTPS=on

to the Apache server's config file inside the VM.

Only that did not work for me, I kept getting either redirect loops or mixed content problem (when some links point to non-encrypted URLs). So my hack is to use 

    RequestHeader set X-Forwarded-Proto "http"

and a second SetEnvIf for: SetEnvIfNoCase X-Forwarded-Proto http HTTPS=on

on the guest system.

This makes all traffic coming to Joomla look like it's encrypted via https. 

Note: this is only secure against MITM because the Joomla VM is on the same machine as the proxy server and does not listen to the internet (all traffic to the VM must originate on the host, in this case the Apache proxy server).

Renewing certificates:

Add a cron file "letsencrypt" to /etc/conf.d folder with:

 17 1,13 * * * root letsencrypt renew && /usr/sbin/service apache2 reload17 1,13 * * * root letsencrypt renew && /usr/sbin/service apache2 reload

so it tries two times a day to renew any certificates in danger of expiration. (Tool to create cron expressions: the beautiful Crontab.Guru)

Cinnamon Portable - Preview 3.7

The Cinnamon Portable Edition is a way to run a full version of Cinnamon on your Windows desktop without installing any software or configuring your environment in any way.

The current version for download at the Cinnamon's SourceForge.net project page is really outdated, so I have put together a new version. It's a little rough on the edges and does not include a DITA renderer at the moment, but it has all the features of the most recent Cinnamon version.

Download the zip archive of Cinnamon Portable 3.7, use right-click to set the is-secure flag on the properties page (otherwise Windows holds all contained code as suspicious and you cannot run the programs). Then unpack the archive and read the Getting-Started.html page.

Note: the server's background Java process tends to stick around even after termination. You may need to end it via the task-manager.

If you need help or want to provide feedback, please write me an email (This email address is being protected from spambots. You need JavaScript enabled to view it.


Cinnamon Portable 3.7 Preview edition checksums (to verify the integrity of your downloaded files):

md5sum: 03e1625fe57a58157a43d9b81ea4dbf7

sha256sum: 77de5c153ad34b78c0d044a68a9efd \ b227afbee173a39625c95b429c8ef263b5


Cinnamon 3.6 Server VM and Client

The newest version of the Cinnamon Enterprise CMS is finished: Cinnamon 3.6

New features

  • Microservice-Change-Trigger: You can configure almost all API requests with a pre- or post-trigger which calls a remote web service with all the parameters available to the server at the respective stage. 
    Possible applications:
    • Blocking of API requests. If the remote service sends a non-OK response at the beginning of a request, the Cinnamon API call will not be executed. Use case: validity checks on documents through third party tools (no need to add Grails plugins to Cinnamon, use any language / tool you want to implement custom features).
    • Enhancement / modification of parameters. Example use case: ensure that all documents have a valid copyright header - if one is missing, add it prior to storing the content in the repository.
    • Trigger render server and other tools: if new content is stored or existing content is updated, you can now start a render server process to generate updated renditions of the content (for example, running a DITA to PDF conversion process which also creates thumbnail images [some customization required])
    • Logging of Cinnamon responses to third party tools / services.
  • Summary-flag: Many parts of the API have been enhanced to accept summary information on content. This way you can use the client application to easily searchable meta data which can be displayed without fetching the complete content of a document or data item.
  • Flag to disable change tracking for system accounts: normally all changes to an object are tracked and the modified date field is updated as well as the modifier data. This caused system accounts (for example the render server) to appear as modifiers on documents where they just updated meta data (thumbnails etc). But when looking at a document, most users want to track human interaction with the content, not modifications by system users. Cinnamon 3.6 allows you to enable / disable this.


Incompatible Changes

Cinnamon server now uses one repository per installation. Handling multi-database multi-tenancy on each request was more trouble than it was worth, and it was never really used by customers.


  • Demo Server VM 3.6.1 (4.7 GByte, includes DITA sample data)
    md5sum: f4c4de6d9ac5bfd21639fe3e01873840
    945f55294c3cafd0f8b32241a0967e0d05b0d70ce2cf6ee \
    4e2b8768bb18db9f66055025b6e4df66ad02ed279833e6fd8cb26f876 \

  • Desktop Client (500 KByte)
    md5sum: c01f77e3ee8f15b12b91e41efc6d5fc3
    bfe340e9c4f4609046eba60c2d20e13cb5d9dcde45a95 \
    6ad8cef7f21c50ce0ab15b411dc94c0edc4b8743ed870d4e9611 \
  • Introductory video for the very first steps once you have downloaded both client and server

The source code for the server and its dependencies is available from the Github repositories:

The source code for the client is available via SourceForge.

The Cinnamon homepage can be found at: http://cinnamon-cms.com


Edit: updated link to new version 3.6.1 (bugfixes, more sample data)

org.apache.hadoop.security AccessControlException: Permission denied:

Exception in thread "main" 
org.apache.hadoop.security.AccessControlException: Permission denied: 
user=publisher, access=EXECUTE, inode="/data/foo/configuration.xml":publisher:publisher:-rw-r--r--
at org.apache.hadoop.hdfs.server.namenode.DefaultAuthorizationProvider.checkFsPermission(DefaultAuthorizationProvider.java:257)
at org.apache.hadoop.hdfs.server.namenode.DefaultAuthorizationProvider.check(DefaultAuthorizationProvider.java:238)
at org.apache.hadoop.hdfs.server.namenode.DefaultAuthorizationProvider.checkTraverse(DefaultAuthorizationProvider.java:180)
at org.apache.hadoop.hdfs.server.namenode.DefaultAuthorizationProvider.checkPermission(DefaultAuthorizationProvider.java:137)


Always a nice error message to waste some time upon - your HDFS user seems to have all the required permissions, the file exists, and still you get the a Permission denied.
In this case, the EXECUTE permission seems to be missing, but that's surely bogus, since you only want to read a single file, not execute it.
Turns out, when accessing a file as a folder, HDFS checks the permission and denies further access because the file cannot be used as a folder. In this case, the code was searching for 
/data/foo/configuration.xml/foo/configuration.xml due to a two pieces of code both appending a part of the path to the final filename.


  • Errors

    Descriptions of error messages and possible solutions

  • Little Goblin

    Posts about Little Goblin, the Grails based open source browser game engine and its reference implementation.

    The home page of Little Goblin is littlegoblin.de