Kay's pages

Logbook

Finally I found the time to try to run efaLive on a Raspberry Pi. It was less effort than expected. You just need a Raspbian installation that you upgrade from Wheezy to Jessie. This can be done by exchanging "wheezy" by "jessie" in the /etc/apt/sources.list. Then run "apt-get update" and "apt-get dist-upgrade". This will take a lot of time, but at the end you have a Debian Jessie based installation. Now add "deb http://efalive.hannay.de/debian jessie main" to /etc/apt/sources.list and run "apt-get updat"e and "apt-get install efalive" (ignore the missing GPG key for now). Many dependencies are installed now. At the end everything is ready to run efaLive. Just configure raspi-config to boot into the GUI and put the following lines into a file /home/efa/.xsessionrc:

#!/bin/bash
exec ~/.xinitrc

Now you have to change the autologin user from "pi" to "efa" in /etc/lightdm/lightdm.conf. From now on, the efaLive Kiosk environment should start automatically.

Maybe I can provide a complete image for the Raspberry Pi in the future, we will see.

Finding a secure and compatible Apache configuration that is dealing with all the nice vulnerabilities in SSL and TLS handling is not an easy task. I always try to use an optimal configuration for my Apache 2.2. There are many threads in the Internet, but often the recommendations there don't work, because they are for Apache 2.4 or outdated. Often it is hard to find out, which version of Apache is dealt with in such a thread. Anyway, it might be helpful for others, so here is my configuration that gets an A+ at SSL Labs. It works with Apache 2.2.29.

LoadModule headers_module modules/mod_headers.so
SSLProtocol all -SSLv2 -SSLv3
SSLCompression Off
SSLInsecureRenegotiation Off
SSLHonorCipherOrder On
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
SSLCipherSuite "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!EDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA"

I now have uploaded efaLive 2.3 to the server. The main difference is that this version is now based on the new stable Debian release "Jessie" 8.0. Besides that there is a small watchdog that restarts the PC in case of a X-server crash. For more details have a look to the efaLive page.

Unfortunately the image size has grown over 700 MB. So you can not burn the image to a standard CD. You need an oversize CD oder a DVD. However, I recommend to use a USB stick, anyway.

Yesterday I have implemented a test for a Python module of the efaLive project. It required me to mock out one class that is used by the test target. So I used the @patch annotation to mock the class. In a first step I used assert_called_once(), copied from some website, to verify that a specific method of the mock has been called. The test was green. Then I changed the test to use assert_called_once_with() to verify the arguments of the mock method as well. After that, the test became red. I checked the test code and did not find the reason for this. With assert_called_once() I verified that the method is called, but assert_called_once_with() tells me that it is called with other arguments than I expected. Here the test code that was green:

@patch("package1.ThirdPartyClass")
def test_my_module(self, third_party_mock)
    class_under_test = my_module.MyClass()
    class_under_test.do_something()
    third_party_mock.called_by_do_something.assert_called_once()

After a while I found an interesting article about this problem. The point is: third_party_mock is a mock object and in Python you can call any method of such a mock and it will not fail. The method assert_called_once() does not exist. It was a failure to copy this code from an article in the web. However, the method assert_called_once_with() exists and triggers the statistics of the mock object. But there is another problem in the test code. The method called_by_do_something() is never called of the mock, but of its instance. So the correct code would be:

@patch("package1.ThirdPartyClass")
def test_my_module(self, third_party_mock)
    class_under_test = my_module.MyClas()
    class_under_test.do_something()
    third_party_mock.return_value.called_by_do_something.assert_called_once_with("foo")

This code will work and trigger the correct mock statistics. To avoid issues like this, I even go a step further now. I don't use the convenience method assert_called_once_with() any more. Now I use the statistics attributes call_count and call_args directly. Here is what I would suggest to use for the test:

@patch("package1.ThirdPartyClass")
def test_my_module(self, third_party_mock)
    class_under_test = my_module.MyClas()
    class_under_test.do_something()
    self.assertEqual(1, third_party_mock.return_value.called_by_do_something.call_count)
    self.assertEqual(call("foo"), third_party_mock.return_value.called_by_do_something.call_args)

I have updated my web pages, the layout and the CMS, as you might have recognized already. The layout works responsive now. This was one of my main goals. Besides that I simplified the layout so that there are less graphics. This hopefully reduces the page load and loading time. So the pages should be ready for the mobile world. The only part that does not work responsive completely is the gallery. The details view does not resize. I hope that I will find a solution for that. The content is more or less the same as before.

Now have fun on the pages!