SROZ.net

auto renew letsencrypt

Turns out this is much simpler than I thought:

#!/bin/sh
/bin/letsencrypt renew || exit 1
service nginx restart

And run it monthly:

@monthly    /home/josh/bin/renew_cert.sh

finalized hugo

There once was a site built upon hard work and naive ideas. I rebuilt it many times, always ending up with what was really just a highly integrated CMS and site-design. Since then I've dabled in Drupal, WolfCMS and MODx. Recently I've found that all of these CMS impose too much, and require constant upkeep. Instead, I've found Hugo which gives me the automation and templating I desire and produces a static result. No worry of being hacked, even if Hugo completely fails on me, I still have a nice plain HTML website to rebuild from.

hugo up and running

First post, not too bad I guess? Just need to import posts from old-old-blog and should be good.

Hrmm… also need a “default” for “posts”. (Oh bugger… markdown doesn’t pass through summary)

Nifty "new-to-me" CMS: MODX

Occasionally while browsing the web I come across a website that strikes me as particularly well designed/written. Too often it’s based on Drupal, Wordpress or some other gargantuan CMS/blog system. After being fairly displeased by Drupal I switched to this site’s current backing: WolfCMS. With only a few minor bumps WolfCMS finally hit my needs for simplicity and manages to be fairly useful. That said, I’m not a huge fan of some of the design decisions underpinning how admin logins are handled: Specifically that I so infrequently log in that I forget which username and password I originally configured. This would be fine normally, except that it has a lock-out feature if I fail too many times… which is great, except that there’s no indication that you are locked out… and looks exactly the same as when the system is unable to create temp files (see previous blog post about that…).

Sooo… while I was on Notepad++’s website today (my IT department’s antivirus suddenly decided that NPP 6.6.9 is a known virus… whatever.) I noted that Don Ho has a page that lists all of the components used in Notepad++, including the CMS used to power the website. (I also learned of a really nice XML library too, TinyXML2)

Enter, MODX. Seems to be highly dynamic, while itself being fairly simple and straightforward. Hopefully I have time tonight or this weekend to give a whirl: It looks like it should be 10x what WolfCMS is, while maintaining the simplicity.

(Yes, this is mostly just a note-to-self… but then so are most of my posts ;-)

Building Mooltipass from source, Part 1

My first attempt at building the Mooltipass firmware from source didn’t go so well: There were a few defines that need to be modified in the source or provided in the Makefile to build for a particular target (Olivier’s design TODO: Link to design/pictures, v1). While writing this up, I found a simpler and slightly better way to build things properly, see commit 2856f843fda26f758c90c3a40778c70d53a1fbd6.

Even w/ the proper defines, it turned out that the version of avr-gcc in Ubuntu 12.04’s reposistories is much too old and doesn’t handle some specific tricks that MP uses to locate the executable outside of the DFU bootloader’s flash space. Trying to program the binary just gave me an error from the dfu program stating that I was about to overwrite the DFU bootloader. Next step? Build avr-gcc from source to get latest versions :-)

The avr-libc website has some excellent instructions for doing precisely this. I ended up following their instructions pretty much verbatim, using /opt/avr-gcc as my installation prefix. I download the latest stable version of each package:

• binutils 2.24
• gcc 4.8.3
• avr-libc 1.8.0

Follows is a log of the commands I used:

export PREFIX="/opt/avr-gcc"
export PATH="${PREFIX}/bin:${PATH}"
###
### binutils
###
cd binutils*
mkdir obj-avr
cd obj-avr
../configure --prefix="${PREFIX}" --target=avr --disable-nls
make -j16
make install
###
### gcc
###
cd ../../gcc*
mkdir obj-avr
cd obj-avr
../configure --prefix=${PREFIX} --target=avr --enable-languages=c,c++ --disable-nls --disable-libssp --with-dwarf2
make -j16
make install
###
### avr-libc
###
cd ../../avr-libc*
./configure --prefix=${PREFIX} --build=$(./config.guess) --host=avr
make -j16
make install

[Edit] If you’re trying to build on OSX, Dimme has a nice write-up on how to use MacPorts to build everything.

Mooltipass tear-down

Got my beta-tester's Mooltipass late last week, and just couldn't wait to pull it apart ;-)

Each image is commented, but apparently there's no way for the public to see my comments... I'll figure out how to export them later... for now the important bits: Heat gun was set to 210°F, waited ~10-15 minutes for everything to come up to temp, use the thinest part of plastic spudger to go around the perimeter, use progressively more of the spudger focusing mainly on the bottom end. Go VERY slow and try not to flex the acrylic too much! In retrospect, more heat might've made it much easier. I imagine a glass screen would require at least 220°F (and lots more patience).

Damned permissions...

Most Linux distros I’ve used all have this same insane problem… just because most of your users want apache, does not mean that EVERY FOLDER that apache needs to touch should be owned BY the apache user/group! It makes no earthly sense for me to add the lighttpd user to the apache group for the system to work properly… both apache and lighttpd should be added to the www group (or something similar). Thanks to this kind of foolishness, I just spent over an hour debugging my CMS only to realize that PHP was (silently) unable to access the session directory because the ownership got switched back to apache:apache. So, thank you PHP for silently failing in a useless fashion, and thank you CentOS for having terrible permissions (and overwriting MY changes to the filesystem).

Hopefully next time, I’ll remember to check the permissions on /var/lib/php/session before tearing through WolfCMS’s source.

Starting rev B in earnest

QtLedTest

Project source: QtLedTest on GitHub
Screen shot:

Description

This is a little program I threw together to help evaluate different OLED displays and GUI layouts for them. Internally, it's comprised of 1 external widget and 3 of my own:

• QLedMatrix: I briefly contemplated writing my own widget to emulate the actual LED display, but thanks to a quick search I found one already written for me. Actually, I think the author, Pierre-Etienne Messier, did an amazing job! :-)
• SSD1306: A simulation of the OLED controller by the same name. This wraps Pierre-Etienne's QLedMatrix with the same interface as the real thing (see lines 46 thru 48). Unlike the real thing, you can resize the display dynamically at run-time. In the future I'd actually extend this model to include various timing and output features of the real controller, such as updating the pixels at the actual "clock-rate" and generating the "frame" signal for synchronizing writes to the device. (Hrm... I suppose I could even simulate the clock-rate of the SPI bus... hehe ;-)
• Graphics: Not wanting to draw just a single static bitmap to the display, I chose to implement a very basic (and very inefficient) graphics library. The library works directly on the same image format as the SSD1306's internal GDDRAM: each byte of a page corresponds to the 8 bit rows at that particular column. I implement the minimum set of operations I felt I would need to make a useful UI: Fill, Rect, Line, Arc and a convenience "Tab" function.
• Font_info: Shortly after completing the Tab function, I realized my UI would useless without some kind of font support ;-) I used Font Builder to convert some free fonts into rasterized images. This also generates an XML description file that lists all of the important metrics for each character of the font. I wrote a quick program to convert the png and XML of each font into a C source/header pair (encoded in the same format the graphics lib works on).

Future work

I'd really like to make the SSD1306 simulation a bit more realistic, and most importantly make it work asynchronously from the main Qt thread. Right now the entire interface locks up while the fairly lengthy process of rendering the scene entirely through setPixel() calls, then transfering the 1k (8 pages of 128 columns) of memory, 1 byte at a time, and finally rendering the individual pixels one at a time. On my reasonably powerful laptop (2x Core-i7), this takes a noticeable amount of time. Another thought I had, was to maybe split the display and user-inter code in to separate processes connected via IPC mechanism. I could then re-compile and re-run the user logic while keeping the display on and active.

Certainly, the next thing I'll probably actually work on is getting the MainWindow class to remember the selected options when you restart the program. ;-)

Building it yourself

Pre-reqs:

• Git: Version 1.8.4 or newer (possibly older, when ever they introduced submodule support)
• Qt: Version 4.8 or newer (AFIK, I've done nothing incompatible with 5.x)

Build instructions

git clone https://github.com/jnwatts/QtLedTest.git
cd QtLedTest
git submodule init
git submodule update
cd QLedMatrix
qmake && make -j4
cd ../
qmake && make -j4

Running the program

LD_LIBRARY_PATH=QLedMatrix/build/ ./QtLedTest

Towards rev B

Recently I've started thinking about designing a second revision (or more likely an alternate device). For this new version, I'd like to incorporate a small display so the user can see the name of the password directly on the device. To see if this is even feasible (0.91" is VERY small...) I wrote up an OLED display simulation (complete down to the display controller ;-).

Edit: Upon urging from Mathieu I've done a given QtLedTest it's own project page and full write-up.