Toby's Log page 89

Raspberry Pi: playing with BerryBoot, RetroPie, and OpenElec

Played with my Raspberry Pi a bit more this weekend. I bought another micro-SD card and installed BerryBoot, a bootloader / OS installer sort of like Noobs, on it.

I installed RetroPie, a project that is built on top of Raspbian but with numerous emulators and a special interface that can be operated by a gamepad. It seems like it would be cool to condense all of my video game systems and even my oldest Mac (an SE) into a tiny box. Unfortunately, I wasn’t able to do much with it since I have to figure out how to get games onto it. It doesn’t have a web browser or other normal Linux stuff accessible from its special interface.

I also installed OpenElec, a media center. It has a dedicated interface meant to be operated by a remote control, though since I don’t have one of those, it operates a bit slowly by mouse. It has various media applications that can be installed from its interface, basically one for each of any online services. I installed quite a few and watched some old commercials on GetTV.

I’m thinking maybe I’ll eventually get a second Raspberry Pi to use as a media / gaming center. It’s easy to dual boot them using BerryBoot. It would be cooler if I could figure out a way to more easily switch between them, rather than rebooting. opensource++


Logging service worker cache headers

As part of the service worker API, a cache interface has been provided to manage cached request-response pairs. In working on the service worker for my site, I wanted to see what headers the cached requests and responses had, but due to the asynchronous way many of the cache properties are accessed, this was a bit verbose. I wrote out a script that I could paste in the JS console to look at all stored request-response pairs in a given cache so I could examine them:

caches.open('cache-name').then(function(_cache){ 
    _cache.keys().then(function(_keys){ 
        _keys.forEach(function(_request){
            var _requestLog = [];
            _requestLog.push(['request', _request.url, _request]); 
            _request.headers.forEach(function(){ 
                _requestLog.push(['request header', arguments]); 
            }); 
            _cache.match(_request).then(function(_response){ 
                _requestLog.push(['reponse', _response]); 
                _response.headers.forEach(function(){ 
                    _requestLog.push(['response header', arguments]); 
                }); 
            }).then(function(){
                _requestLog.forEach(function(_item){
                    console.log.apply(console, _item);
                });
            });
        });
    }); 
});

Replace cache-name with whatever key you’re using for your cache. Be warned that this will produce a long log if you’ve got more than a few items in the cache. You can also see just the requests you have a cache for with something like:

caches.open('cache-name').then(function(_cache){ 
    _cache.keys().then(function(_keys){ 
        _keys.forEach(function(_request){
            console.log(['request', _request.url, _request]); 
        });
    }); 
});

Self-signed certificate for testing

In playing with service workers, I set up a self-signed SSL certificate for my local development environment. I used instructions from debian.org. It was very simple, since I didn’t need the security involved with a real operating site. Creating the certs took a single command:

openssl req -new -x509 -days 365 -nodes -out /path/to/server/config/certs/sitename.pem -keyout /path/to/server/config/certs/sitename.key

You then just need to set things up in the server configuration (Apache in my case). mod_ssl must be installed and enabled, which looks something like:

Continue reading post "Self-signed certificate for testing"

First play with service workers

I started playing with service workers as a client side cache manager a bit tonight. I’m using this Smashing Magazine article as a guide. I’ve been reading a bit here and there about them, intrigued by their role in making web sites installable as apps and their ability to allow sites to function even while offline. However, my site’s current lack of pages and other priorities plus the learning curve and things that have to be done to set them up kept me from playing with them until now.

Workers require HTTPS, unless, luckily, you are serving from localhost. I had to modify my local app install to use that instead of the more site-indicative name it was using. They also require placement at or above the path level they apply to, or theoretically a Service-Worker-Allowed header, though I was unable to get that working. I’m assuming this is for some security reason. Because my file is stored in a Symfony bundle and because I am serving multiple sites with the same application, I didn’t want an actual file in my web root. I made a Symfony route and action that passes through the file, like:

Continue reading post "First play with service workers"

On my site, I’m using Apache’s ‘mod_deflate’ and ‘mod_filter’ to compress my compressible responses (mostly text), with a setup based on h5bp’s server config. I got my sites running over HTTPS recently, and today, when looking at my site performance with webpagetest.org, I noticed that my content wasn’t compressing. It was still working fine over HTTP. I noticed in h5bp’s comments that <IfModule mod_filter.c> could be removed in Apache versions below 2.3.x. I removed it, and sure enough, compression was working again. I’m not sure why it’s different depending on what protocol I use. Perhaps Dreamhost has separate versions of Apache running for the two protocols. Or perhaps it’s just something different about the configuration in the virtual hosts. Regardless, it’s working now. I just hope this doesn’t cause problems whenever they move to Apache 2.4.


Listening to some music, I thought it quite powerful, that it presented some important truth of the world. Then I thought that some others might not find it as such, but may find some other music powerful that I do not. “Everybody finds their own truths,” I thought, as I had many times before. Truths in everything: music, lyrics, statements, tweets, books, posts, articles, shows, scenes, thoughts, choices, situations: anything.


Used SSL Labs’ SSL Server Test to analyze my site now that I have LetsEncrypt certificates installed. Got an A. The only things of note it mentioned were:

  • My HSTS is too short. It considers less than 180 too short. The cert isn’t even valid for 180 days (90 for LetsEncrypt). My HSTS is actually only one day, and I will probably leave it on the short side until I’m sure things are safe.
  • It is an SNI certificate, so it will not be supported by some old browsers. 94%+ is good enough for me when I still support HTTP.