Thursday, July 7, 2016

Java cacerts on Intel Edisons and Gateways

The Intel Edison ships with loads of ca certificates in /etc/ssl/certs, and it also ships with Java 8 (OpenJDK), but it does not ship with a pre-configured cacerts file for Java. Ditto for the Wind River Linux installation that is preinstalled on the Dell 3290 gateway device.

So if you try to use Java to access something over HTTPS you'll get a security exception. For example, if you want to run Clojure using the excellent boot build too, the first time you try "$ boot repl" on either WRLinux/Gateway or Yocto/Edison, you’re going to get an exception along the lines of:


Exception in thread "main" javax.net.ssl.SSLException:
java.lang.RuntimeException: Unexpected error:
java.security.InvalidAlgorithmParameterException:
the trustAnchors parameter must be non-empty

The problem is that although both systems ship with a large set of ca certificates, as well as preinstalled OpenJDK 1.8, the latter is not configured to use the former out of the box.  Since I virtually never have to deal with this sort of thing it took me a couple of hours to figure out what the problem was and how to fix it.  All you have to do is create a Java “trust store” by running a Java utility calledkeytoolonce for each certificate you want to add to the trust store. (A trust store is analogous to a key store; the latter is where you keep your keys, the former is where you keep public certificates of trust; if you’re a glutton for punishment take a look at Configuring Java CAPS for SSL Support.)
Here’s what you need to know to make sense of that:
  • Java is installed at /usr/lib64/jvm (WRLinux on the Gateway), or /usr/lib/jvm (Yocto on Edison)
  • The standard place for the Java truststore is $JAVA_HOME/jre/lib/security/cacerts. Note that cacerts is a file, not a directory. You create it with
  • keytool
  • keytool is located in $JAVA_HOME/jre/bin
  • The certificates are in /etc/ssl/certs, which is a directory containing soft links to /usr/share/ca-certificates

Now you just need something to save you the drudgery on installing everything in /etc/ssl/certs into the Java trust store, since keytool must be given an individual file rather than a directory of files as input. Fortunately, somebody already wrote that script for us. You can find it at Introduction to OpenJDK in the subsection Install or update the JRE Certificate Authority Certificates (cacerts) file. I just copied that to ~/bin/mkcacerts, chmodded it to make it executable, and then created a one-time helper:

#!/bin/sh
# certs.sh

# use this for Yocto/Edison:
# LIB=lib
# use this for WRLinux/Gateway
LIB=lib64
if [ -f /usr/$LIB/jvm/java-8-openjdk/jre/lib/security/cacerts ]; then
  mv /usr/$LIB/jvm/java-8-openjdk/jre/lib/security/cacerts \
     /usr/$LIB/jvm/java-8-openjdk/jre/lib/security/cacerts.bak
fi
# if you have a ca-certificates.crt file, use this:
# -f "/etc/ssl/certs/ca-certificates.crt"
# otherwise use
# -d "/etc/ssl/certs/"
./mkcacerts                 \
        -d "/etc/ssl/certs/"           \
        -k "/usr/$LIB/jvm/java-8-openjdk/bin/keytool"      \
        -s "/usr/bin/openssl"          \
        -o "/usr/$LIB/jvm/java-8-openjdk/jre/lib/security/cacerts"

There is one tricky bit: notice the "-d" parameter in the script above. Use that if /etc/ssl/certs contains certificates but no "ca-certificates.crt" - this was the case in earlier versions of the Edison. But if you find /etc/ssl/certs/ca-certificates.crt, then replace that line as noted in the comment.

Now cd to ~/bin and run $ ./certs.sh.  You'll see a bunch of alarming-looking output as it churns through the certificates, adding them to the Java truststore (cacerts file). It takes a while, but once it's done you should be good to go with Java and HTTPS.

Tuesday, July 5, 2016

Why I Still Hate Hate Hate Build Systems

You might think that by 2016 software and systems developers would have figured out build systems. But no.  Build systems, along with package management and configuration, remain the bane of the developer's, not to mention the user's, existence.

I've worked with many such systems, from the venerable make/autotools system, to Cmake, to Scons, to Ant, Maven, Gradle (Boo!) and who knows what else. I hate them all.  They are all misbegotten monstrosities that only their mothers could love.

Case in point: I want to use the tinyb Bluetooth LE library on the Intel Edison and on a Dell 3290 gateway device.  You'd think that would be easy enough - download, configure, make, install, use. The project uses CMake, which ought to be even better than Make.

But like all build systems, Cmake works just great - until it doesn't.  In this case:


  • It started out by offering an inscrutable error message:  "A required package was not found". I'm not making this up, that is the message.  Which package?  Why so coy, CMake?  Cantcha just say???
  • So you look in the error log, and you see that a check for Pthreads failed. But you know your system has pthreads, so you flail around for a while, then notice it failed because the test command specified not "-lpthread", but "-lpthreads".  Whaa? A bug in CMake? An hour and a half later you finally realize that was a spurious report - the error message was not caused by Pthreads testing but by the check that occurred just before the error message. You proceed to feel both very stupid, because you should have thought of that immediately, and very, very pissed that the morons in charge of Cmake could have saved you the trouble by simply saying what the problem is.  I dunno, maybe something like "A required package was not found: gio-unix-2.0>=2.40"?  Izzat so hard?
  • And the way you actually figure out that gio-unix-2.0 was the problem is by creating a test project and painstakingly going through the CMakeLists.txt file line by line, trial-and-error. You begin to fear you might have an aneurism.  You are glad the Cmake devs are not within throttling distance, lest you squeeze their throats very hard.
  • But, but, bu bu - my system does so have gio-unix-2.0!  It's right there! (Of course, you waste a good 20-30 minutes googling around trying to figure out what exactly gio-unix is).
  • More trial and error.  Maybe its the version number.  You try a bunch, nothing makes a difference, the test always fails.
  • Finally, you inspect the pkg-config file for gio-unix-2.0. Everything looks hunky dory. Except for that @VERSION@ thingie there, it looks a little fishy, but you are not a pkg-config expert, you assume that it must be there for a reason.  But then you look at the related gio-2.0 file, and there in the version field is an actual number!  2.48.1, to be exact!
  • So finally it dawns on you: the person whose neck you need to squeeze, hard, mercilessly, is the person who install the broken pkg-config file for gio-unix-2.0, the one that didn't get the version number so it fails all checks.
  • But the CMake devs do not get away so easily!  It's still a flaw in their product - when they test for a library with a version >=2.40, and the version they get is obviously broken - not a version number at all - they should throw a "broken config file" exception, not a "package not found" error.  It's just false to say the package was not found! And it would also be false to say that the package found had too low a version number! It did not fail the version test, it was incapable of even taking the version test, and that is the exception.

The real problem with build systems is that they do not treat the build engineering problem as a software development problem. To manage builds you need a real programming language, and you need to write your build scripts with all the care you would use in writing critical C code.  There is actually one project out there that takes this approach, the only one I know of: http://boot-clj.com/. Whereas previous build systems are of the "build a better mousetrap" variety, so they're all pretty much the same thing, boot represents a fairly radical re-conceptualization of what building software is all about.

opkg

Both the Intel Edison and the Dell 3290 (Intel IoT Gateway) with Wind River Linux, being embedded systems, run a Yocto-based OS.  The package manager for Yocto is opkg, not apt nor rpm nor any of the other PMs one typically encounters in full-featured Linux environments.  Unfortunately, good information on how to correctly use opkg is not easy to find.  Here's what worked for me:

Here "Edison" means an Intel Edison module updated to the latest image as of June 2016, and "Gateway" means a Dell/Wyse 3290 running Wind River Linux version 6.  Note that the Intel IoT Gateway platform also supports Ubuntu and Windows OSs.

opkg homepage:  https://wiki.openwrt.org/doc/techref/opkg.

Repositories:

https://downloads.openwrt.org/snapshots/trunk/

Config file:

  • Edison:
  • Gateway:  /etc/opkg/opgk.conf
Here's what I used on the Gateway:

# opkg.conf

dest root /
dest ram /tmp
lists_dir ext /var/opkg-lists
option overlay_root /overlay
src/gz x86_base http://downloads.openwrt.org/snapshots/trunk/x86/64/packages/base/
src/gz x86_packages http://downloads.openwrt.org/snapshots/trunk/x86/64/packages/packages/

Thursday, June 2, 2016

Zephyrizing the Curie

Disorganize Notes on Getting started with Zephyr on the Arduino 101

Ubuntu Linux:

* forget the JTAG stuff
* install the latest dfu-util (and libusb)

$ gpg --verify dfu-util-0.9.tar.gz.md5.asc 
$ tar -zxvf dfu-util-0.9.tar.gz 
$ cd dfu-util-0.9
$ ./configure
...
configure: error: *** Required libusb-1.0 >= 1.0.0 not installed ***
$ sudo apt-get install libusb-1.0-0-dev
$ ./configure
$ make
$ sudo make install
$ dfu-util -V
dfu-util 0.9

* install the Arduino IDE (>= 1.6.7)
* install the Curie board in the IDE (Tools->Board -> Boards Manager)

  (Note: Tools->Board will show a selected board so it doesn't look like a list of boards. Click on it anyway to see the list and the Boards Manager option)

The list of boards will then include "Arduino/Genuino 101".

As a side effect a hidden directory ~/.arduino15/ will be created.  For dfu-util to work a udev rule must be set up.  A shell script is included to do this, in

~/.arduino15/packages/Intel/tools/arduino101load/1.6.4+1.18/scripts/create_dfu_udev_rule 

Execute that script (using sudo) and you'll be ready to flash.  To do that, you have to reset the board and then run your dfu-util command within 5 seconds.

"The MASTER RESET is intended to reset both the cores of Curie chip, while RESET will only reset the sketch (though the software doesn't support that yet, so they both reset the whole board).
When pressing MASTER RESET the board will enter DFU and you should see an entry in your device manager similar to this one" (http://forum.arduino.cc/index.php?topic=369653.5;wap2)
  • minimum version of dfu-util required, and instructions for obtaining and installing
  • the required udev rule
  • required group memberships - my UID was a member of plugdev (from the old instructions) and dialout (required by Arduino IDE).  But when I removed myself from those groups I was still able to flash so I guess they're not required
  • "flash mode"
    •  if you press the master reset button, then wait > 5 sec, the flash will fail with message "No DFU capable USB device available"
    • if you press the master reset and flash within 5 sec, it will work
    • thereafter, you can flash at will, until you hit the master reset again
    • so I would say there is a "flash" mode, or something like that, which you enter if you flash within 5 secs of a master reset
    • in flash mode, if you press the plain reset, you do not have to flash within 5 seconds
    • exit flash mode by pressing master reset (and not flashing)
    • once in no-flash mode, the only way to flash is via the master reset button, the plain reset won't work that way

It should be possible to get started without installing the Arduino IDE, by using the script create_dfu_udev_rule:
    #!/bin/bash
    #

    if [ "$(id -u)" != "0" ]; then
       echo "This script must be run as root"
       exit
    fi

    NAME=99-arduino-101.rules

    echo >/etc/udev/rules.d/$NAME
    echo \# Arduino 101 in DFU Mode >>/etc/udev/rules.d/$NAME
    echo SUBSYSTEM==\"tty\", ENV{ID_REVISION}==\"8087\", ENV{ID_MODEL_ID}==\"0ab6\", MODE=\"0666\", ENV{ID_MM_DEVICE_IGNORE}=\"1\", ENV{ID_MM_CANDIDATE}=\"0\" >>/etc/udev/rules.d/$NAME
    echo SUBSYSTEM==\"usb\", ATTR{idVendor}==\"8087\", ATTR{idProduct}==\"0aba\", MODE=\"0666\", ENV{ID_MM_DEVICE_IGNORE}=\"1\" >>/etc/udev/rules.d/$NAME

    udevadm control --reload-rules
    udevadm trigger

    Intel firmware page:  https://downloadcenter.intel.com/download/25832  (source available)



    Wednesday, June 1, 2016

    Iotivity on the Intel IoT Gateway

    Iotivity is "an open source software framework enabling seamless device-to-device connectivity to address the emerging needs of the Internet of Things."  It has the backing (as in paid programmers) of some of the major players, including Intel and Samsung, to name just two.

    You probably wouldn't want to build Iotivity on an IoT gateway machine; it is designed as embedded software, after all, so you'd cross-compile it on a more powerful machine and then install it.  Or rather, you'd build a platform image in the proper way, but that is beyond the scope of this article (I'll blog about it later).  But if you're working on Iotivity itself, and if you're pulling changes on the bleeding edge, you need to build it by hand. Here's how.

    The instructions for Linux on the Iotivity website are for Ubuntu LTS 12.04.  They assume that apt-get is installed, which is not the case with WindRiver Linux on a gateway.  WRLinux does have rpm, but I'm not yet familiar that so let's do it by hand.

    WARNING: this is a little bit messy at the moment, as I'm composing it as my build proceeds, but it should be of some use.  I'll clean it up a bit later.

    Note that the build scripts are supposed to do some of this stuff automatically (e.g. download and compile some of the deps).  Which they do, on Ubuntu.  I had some trouble getting them to work on WRLinux (also OS X), plus the build scripts make some assumptions that only work on Ubuntu. So I decided to pull out most (all?) of the dependency stuff and handle it separately, manually.  Once you have that stuff installed the build seems to proceed smoothly.

    Dependencies:
    • tinycbor - see below
    • gtest-1.7.0
      • the build scripts use https://googletest.googlecode.com/files/gtest-1.7.0.zip, but google has switched to github: https://github.com/google/googletest
    • bzip2 - only need for downloading other deps?
    • uuid
    • libicu
    • gio - BLE uses gdbus.  deps:
      • glib - low-level C routines etc. from the Gnome project http://ftp.gnome.org/pub/gnome/sources/glib/2.48/glib-2.48.1.tar.xz
        • libffi - Foreign Function Interface
          • https://github.com/libffi/libffi - download zipfile, ./autogen.sh, .configure...
        • libpcre - Perl Compatible Regular Expressions
          •  ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/
    • python 2.7.*
    • scons
    1. Python 2.7.* - should be already installed.  Needed for scons
    2. Install bzip2
      1. $ wget http://www.bzip.org/1.0.6/bzip2-1.0.6.tar.gz
      2. verify md5 checksum:  $ md5sum ...
      3. $ tar -zxvf bzip2-1.0.6.tar.gz
      4. $ cd bzip2-1.0.6
      5. $ sudo make install
    3. Install libuuid
      1. $ wget http://downloads.sourceforge.net/project/libuuid/libuuid-1.0.3.tar.gz
        1. Do NOT use OSSP uuid, it seems to be missing some fns
      2. verify integrity - on Sourceforge you can find the checksums in the file browser; see Verifying Downloaded Files.
      3. $ tar -zxvf libuuid-1.0.3.tar.gz
      4. $ cd libuuid-1.0.3
      5. $ ./configure
      6. $ make
      7. $ sudo make install
    4. Install libicu
      1. e.g. $ wget http://download.icu-project.org/files/icu4c/57.1/icu4c-57_1-src.tgz
      2. build it
    5. Install libpcre (ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/)
      1. $ wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.38.tar.bz2
      2. $ wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.38.tar.bz2.sig
      3. $ gpg --verify pcre-8.38.tar.bz2.sig
      4. $ gpg --recv-keys FB0F43D8 (or whatever key is shown by the --verify op)
      5. $ tar -jxvf pcre-8.38.tar.bz2
      6. $ ./configure --enable-utf --enable-unicode-properties
      7.  $make && sudo make install - puts libs in /usr/local/lib
    6. Install libffi
    7. Install glib - this may be a pain, see Notes on glib below.
      1. blah....
      2. $ ./configure
        1. Unfortunately the system pcre lib in /usr/lib64 is apparently not compiled with unicode support so ./configure will not finish.  I linked /usr/lib65/libprc.so.1 to /usr/local/lib.  I dunno if that's a good idea, but it got me thru ./configure
    8. Install boost
      1. $ wget https://sourceforge.net/projects/boost/files/boost/1.61.0/boost_1_61_0.tar.bz2
      2. verify sha256 hash:  $ sha256sum ...
      3. $ tar -jzvf boost_1_61_0.tar.bz2
      4. $ cd boost_1_61_0
      5. $ ./bootstrap.sh --with-libraries=system,filesystem,date_time,thread,regex,log,iostreams,program_options --prefix=/usr/local
      6. $ ./b2
      7. go make a cup of coffee, the build takes a long time
      8. $ sudo ./b2 install
    9. Install scons
      1. $ wget http://downloads.sourceforge.net/project/scons/scons/2.5.0/scons-2.5.0.tar.gz
      2. see  Building and Installing SCons on Any System
    10. Build Iotivity
      1. Download:  $ http://mirrors.kernel.org/iotivity/1.1.0/iotivity-1.1.0.zip
        1. NOTE: download the zip file and check the sha256 sum.  As of the time of writing, the tar.gz file does NOT match its checksum!
        2. $ unzip iotivity-1.1.0.zip
        3. $ cd iotivity-1.1.0
        4. $ scons
    The build takes quite a while.

    tinycbor

    At the very beginning you will see a message like this:

    *********************************** Error: *************************************
    * Please download cbor using the following command:                               *
    *     $ git clone https://github.com/01org/tinycbor.git extlibs/tinycbor/tinycbor *
    ******************************************************************************

    But when you try to do this you will get an error:

    fatal: unable to access 'https://github.com/01org/tinycbor.git/': Problem with the SSL CA cert (path? access rights?)

    Gateways running WRLinux come with lots of certificates (see /etc/ssl/certs) but apparently not the one we need for git cloning.  The workaround is to use wget.  Go to the tinycbor git repo in your browser, click on the "Clone or download" button, then right click on the "Download zip" link to copy the link address.  On the gateway, cd to iotivity-1.1.0/extlibs/tinycbor, wget the zip file, and unzip it.  You'll get a directory called tinycbor-master.  Rename this to tinycbor, and then return to the iotivity-1.1.0 dir and rerun scons.

    Other notes:

    $ scons -c  seems to hang when it gets to "scons: Cleaning targets ..."  ???

    Notes on glib:


    The bluetooth le stuff for linux depends on the Bluez stack, which
    depends on gdbus, which depends on gio, then glib, etc.

    So we install glib-2.0, and then the trouble starts.  The pkg-config
    files go in /usr/local/lib/pkgconfig, but when scons runs pkg-config
    it only uses the default dir, namely /usr/lib64/pkgconfig.  I don't
    know how to get it to also look in /usr/local, you can't pass stuff
    via env vars.  So the quick-n-dirty is to copy the relevant *.pc
    files.  Ditto for the headers; copy /usr/local/include/gio-unix-2.0 to
    /usr/include.



    Sunday, May 29, 2016

    IoT resources




    Linux tools

    Wednesday, May 11, 2016

    Embedded programming

    Excellent talk by John Light: Embedded Programming for IoT.  Light is involved in Iotivity development.

    He talks a little bit about coroutines but the talk focuses mostly on memory management in very constrained environments.  He has also written about this topic:

    01.org blog:

    Heap Allocation on the Internet of Things

    IoT Memory Management: A Case Study

    On the Iotivity wiki:

    Memory Management Design

    Memory Management Design ii

    Memory Management Design iii