USB Serial Devices with Mac OS X

In bygone days, computers used to come with RS-232 serial interfaces as standard. Those days are now long gone and instead we have USB ports. However, occasionally we still need to hook up an RS-232 serial device. In that case, the solution is a USB to serial adapter.

Interfacing USB to serial devices to Mac OS X is straightforward but a little involved. The following procedure is based on that outlined on the instructions at plugable.com.

Confirm the device

Many USB to serial converter devices seem to be made by Prolific Technology Inc., a Taiwanese firm. We first need to confirm the device and then install the driver.

From the Apple icon in the top left corner of the screen, select “About this Mac”, then click “More Info…”. From the next window, click “System Report…”. In the left-hand pane, click on USB under Hardware and browse the USB devices. You should see a device USB-Serial Controller. Click on it to confirm the manufacturer and vendor ID. In the screenshot below we confirm a Prolific Technology 2303.

/markbrown778.files.wordpress.com/2014/06/screen-shot-2014-06-23-at-9-49-52-pm.png”>Browsing USB devices

Obtain and Install the Driver

Cruise over to the Prolific USA website for driver installation guides. The drivers themselves can be obtained from here. Follow the instructions to install the driver. Note that a reboot is required.

Verify driver installation

Fire up a terminal and enter

kextstat | grep prolific

to verify the driver has been installed. Also enter

ioreg -c IOSerialBSDClient | grep usb

to show the USB serial devices. The output should be similar to that shown below.

Verifying USB serial converter driver installation

Test

The device is accessible through /dev/cu.usbserial. You can use the screen virtual terminal program to test it: screen /dev/cu.usbserial.

Happy hacking!

A bare bones mobile compass app in HTML/JS using PhoneGap

As covered in a previous blog post, PhoneGap, based on Apache Cordova, is a compatibility layer and set of Javascript APIs that enable HTML/Javascript web pages running on mobile devices to access features of the underlying platform. This allows reasonably portable mobile apps to be created without having to resort to native code.

This blog post walks through writing a dirt simple compass app in HTML/JS with PhoneGap.

Debugging Tools

Javascript is designed for web browsers. Web browsers are designed to be error tolerant; if there’s an error in Javascript or the HTML, they will try to keep going and display the page without informing the user (who, after all, can do little).

This presents a problem for developers; if you’re testing your app on a mobile device or emulator and there’s even a syntax error in your Javascript code (let alone a bug), there’s no indication of what the problem is except that the Javascript won’t run. However, because the applications we’re developing with PhoneGap/Cordova are HTML/Javascript, a lot of debugging can be done with a desktop web browser with debugging tools (e.g. Firebug for Firefox).

Without a browser, you can use a static analysis tool like JSLint from the command line to check whether the Javascript will compile cleanly. (JSLint has some suckage in that it reports line numbers wrong — maybe it doesn’t count comment lines. C’est la vie.)

The Compass App

The quickest way to get started is to create a skeleton project and modify that.

$ phonegap create Compass

will create a directory called Compass that contains various project files and a very simple skeleton application.

The documentation says that we need a plugin to use the compass. (What happens if we don’t install the plugin? The app won’t work with no indication why.) The documentation says to install the plugin using the cordova command but since we’re using PhoneGap we have to use that command instead.

$ cd Compass
$ phonegap plugin add org.apache.cordova.device-orientation
[phonegap] adding the plugin: org.apache.cordova.device-orientation
[phonegap] successfully added the plugin

The HTML code for the app is in www/index.html. Change the contents of the <body> section as follows:

<body>
    <div class="app">
        <h1>Compass</h1>
        <div id="deviceready" class="blink">
            <p class="event listening">Connecting to Device</p>
        </div>
        <div id="heading" style="display:none;">
            <p class="event listening blink">WAITING FOR COMPASS</p>
            <p class="event received">***</p>
        </div>
    </div>
    <script type="text/javascript" src="phonegap.js"></script>
    <script type="text/javascript" src="js/index.js"></script>
    <script type="text/javascript">
        app.initialize();
    </script>
</body>

As well as changing the heading in the <h1> tag, we’ve modified the deviceready div and added a new heading div to contain the heading display.

Next, edit the file www/config.xml and change the name of the app in the <name> tag from ‘Hello World’ to ‘Compass’. This will be the name of the app shown underneath its icon.

The logic is contained in the file www/js/index.js. Replace the file with the following code:


var app = app || {};

app.watchID = null;


app.initialize = function () {
    document.addEventListener('deviceready', app.onDeviceReady, false);
};


app.onDeviceReady = function () {
    app.receivedEvent('deviceready');
    app.watchID = navigator.compass.watchHeading(
        app.compassUpdate, 
        app.compassError, { frequency : 3000 });
};


app.compassUpdate = function (hdg) {
  var mh = hdg.magneticHeading;
  app.showHeading(true, 'Heading: ' + mh);
};


app.compassError = function (err) {
  var errcode = err.code;
  app.showHeading(false, 'Compass error: ' + errcode);
};


app.showHeading = function (f_ok, s) {
  var parentElem = document.getElementById('heading');
  var nodataElem = parentElem.querySelector('.listening');
  var dataElem   = parentElem.querySelector('.received');
  if (f_ok) { 
    nodataElem.setAttribute('style', 'display:none;'); 
    dataElem.setAttribute('style', 'display:block;'); 
    dataElem.innerHTML = s;
  }
  else {
    nodataElem.setAttribute('style', 'display:block;'); 
    dataElem.setAttribute('style', 'display:none;'); 
    nodataElem.innerHTML = s;
  }
};


app.receivedEvent = function(id) {
    var parentElement = document.getElementById('deviceready');
    parentElement.setAttribute('style', 'display:none;');
    var headingElement = document.getElementById('heading');
    headingElement.setAttribute('style', 'display:block');
};

Once the application has started, the PhoneGap (Cordova) runtime sends a deviceready event which invokes the app.onDeviceReady callback function. This hides the deviceready div and displays the heading div, then calls navigator.compass.watchHeading to sample the compass heading at 3000ms intervals. The app.compassUpdate function is then called periodically with the value of the magnetic heading, or app.compassError is called with an error on failure. The function app.showHeading is displays the heading value or the error code.

To compile the program for Android and install it on a device or an emulator, execute the command

$ phonegap run android

from the Compass directory, and voila:
Compass app
(You can get rid of the icon by editing the CSS file but I couldn’t be arsed.)

Afterword

So we have a mobile app that reads the compass and spits out the heading to the screen, in around than 100 lines of HTML/Javascript and without writing a single line of Java or Objective-C. Of course there are issues; Javascript sucks, HTML/JS apps are slower than native apps, and your source code is available for all the world to see (it’s just HTML and Javascript after all), but if you can live with those issues you can create interesting mobile apps with minimal effort. Could also be useful for proof-of-concept/prototyping.

I’ll be looking to escape Javascript and HTML suckage altogether by using something like Elm. But that’s for a later blog.

Cross-Platform Mobile Apps in HTML5: PhoneGap

TL;DR

Introduces PhoneGap, an abstraction layer based on Apache Cordova that exposes mobile platform sensors and capabilities to HTML5 apps through a Javascript API. Goes through installation and running a skeleton app on Android and iOS emulators.

Introduction

Mobile applications are currently a huge growth area for software. Unfortunately, mobile devices have a variety of operating systems, programming languages and APIs, each with their own particular forms of brain damage.

Now HTML5 is establishing itself on the scene, sweeping away great piles of old cruft and bringing new capabilities. It’s supported by all major mobile devices, making it feasible to create mobile applications using HTML5, Javascript and CSS. Of course, HTML5/JS apps are going to be slower than native apps and you won’t have a native “look and feel” (at least, not out of the box) but not every app needs great performance and looking at iOS7, maybe lack of native look and feel is not so bad. Since a pure HTML5/CSS/JS application is basically just a web page you don’t have to worry about going through some Crapp store for approval.

One thing that’s missing, though, is access to the mobile “platform” itself from Javascript; the accelerometers and GPS sensors, media players and the like. That’s where PhoneGap (and the open source package it’s based on, Apache Cordova) comes in — it provides a device-independent Javascript API which exposes the platform. (Unfortunately, that means you can no longer deploy your app purely from the web – the HTML5/JS app needs to be bundled with some sort of runtime for deployment.)

Installing PhoneGap

PhoneGap depends on NodeJS, so you need to install that first – download from here. Once you have NodeJS installed, PhoneGap is installed using NodeJS’s package manager npm which automatically pulls in all its dependencies — a very straightforward process (providing you don’t have complications like an authenticating proxy to worry about, of course).

$ sudo npm install -g phonegap
Password:
npm http GET https://registry.npmjs.org/phonegap
npm http 304 https://registry.npmjs.org/phonegap
npm http GET https://registry.npmjs.org/cordova/3.3.0-0.1.1
npm http GET https://registry.npmjs.org/optimist/0.6.0
...

The application is installed in /usr/local/ on Mac OS X. PhoneGap is then basically driven from the command line program /usr/local/bin/phonegap.

You will also need the SDK for the mobile platform you’re targeting installed: XCode for iOS, the Android SDK for Android etc.

Creating a Test Application

A new application is created using the phonegap create command: e.g. to create an application called my-app:

$ phonegap create my-app

This creates a directory my-app and populates it with various directories and files for a skeleton application that just response to the DeviceReady event. Let’s try it on a couple of target platforms; Google Android and Apple iOS.

Android

To run the skeleton app on the Android emulator, execute

$ phonegap run android

in the my-app directory. (The Android SDK directories sdk/tools and sdk/platform-tools need to be set in the PATH environment variable.)

$ phonegap run android
[phonegap] detecting Android SDK environment...
[phonegap] using the local environment
[phonegap] compiling Android...
[phonegap] successfully compiled Android app
[phonegap] trying to install app onto device
[phonegap] no device was found
[phonegap] trying to install app onto emulator
   [error] An error occurred while emulating/deploying the android project. 
...
ERROR : No emulator images (avds) found, if you would like to create an
 avd follow the instructions provided here:

http://developer.android.com/tools/devices/index.html

 Or run 'android create avd --name  --target '
 in on the command line.

Note the helpful diagnostics! Bum, I forgot to create an Android Virtual Device (AVD) (or plug in a real Android device). Let’s create an AVD using the AVD tool or command line, fire it up and try again.

$ phonegap run android
[phonegap] detecting Android SDK environment...
[phonegap] using the local environment
[phonegap] compiling Android...
[phonegap] successfully compiled Android app
[phonegap] trying to install app onto device
[phonegap] no device was found
[phonegap] trying to install app onto emulator
[phonegap] successfully installed onto emulator

aaaand…
Basic PhoneGap app on Android
Banzai!

iOS

Okay, let’s try iOS. I’ve got XCode 5 installed and fired up an iPhone emulator, so let’s see how far we’ll get.

$ phonegap run ios
[phonegap] detecting iOS SDK environment...
[phonegap] using the local environment
[phonegap] adding the iOS platform...
[phonegap] missing library cordova/ios/3.3.0
[phonegap] downloading https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=snapshot;h=3.3.0;sf=tgz...
[phonegap] compiling iOS...
[phonegap] successfully compiled iOS app
[phonegap] trying to install app onto device
[phonegap] no device was found
[phonegap] trying to install app onto emulator
 [warning] missing ios-sim
 [warning] install ios-sim from http://github.com/phonegap/ios-sim
   [error] An error occurred while emulating/deploying the ios project. Error: ios-sim was not found. Please download, build and install version 1.7 or greater from https://github.com/phonegap/ios-sim into your path. Or 'npm install -g ios-sim' using node.js: http://nodejs.org/

Again, excellent diagnostics! We’re missing the ios-sim package so we’ll just install that with npm (run as root) and try again.

$ phonegap run ios
[phonegap] detecting iOS SDK environment...
[phonegap] using the local environment
[phonegap] compiling iOS...
[phonegap] successfully compiled iOS app
[phonegap] trying to install app onto device
[phonegap] no device was found
[phonegap] trying to install app onto emulator
[phonegap] successfully installed onto emulator

aaand….
Skeleton PhoneGap app on iOS simulator
Fandabidozi!

Afterword

So far, things look encouraging, because:

  1. Apache Cordova seems to be a result of Firefox OS efforts so should be receiving a lot of positive development.
  2. NodeJS is also an upcoming technology receiving a lot of care and attention. The npm package manager does what it says on the tin and does it well.
  3. So far the diagnostics are nothing short of excellent.

The next step is to delve into the API and try to write a mobile HTML5 app.

Creating a private cloud with ownCloud. Part 2: The Clients

Now you have an ownCloud server. What can you do with it?

Synchronise calendars and reminders between devices.
Synchronises calendars and reminders between calendar applications that support the Caldav protocol, such as those built into iOS or Android devices, and the Mac OS X calendar application.
Synchronise contacts between devices.
Like calendars, allows you to synchronise contact information between applications that support the CardDav protocol.
Automagically upload photos taken on mobile devices.
You need to install with ownCloud client application to do this.
Share files between devices.
Uses the ownCloud client app.

For setting up, basically follow the documentation but there are a few gotchas I’ve found with Mac OS X (Mavericks). I assume the use of ownCloud server version 6.

1. Calendar and Contacts

The ownCloud server’s CalDav service for user name username is accessed from the URL /owncloud/remote.php/caldav/principals/ (assuming ownCloud is accessed from https://server/owncloud).

1.1 Apple iOS

Follow the instructions in the user guide.

1.2 Apple Mac OS X

The ownCloud documentation tells you how to configure Mac OS X to share contacts, reminders and calendar information. However, there’s a twist for Mac OS X Mavericks and also if you have a user name that contains an @ symbol.

  1. Select ‘Internet Accounts’ from ‘System Preferences’.
  2. Scroll to the bottom of the list of providers on the right of the screen and click ‘Add another account’. Select ‘Add a CalDav account’ and click ‘Create’.
    Create a new CalDav account
  3. In the ‘Add a CalDAV Account’ dialogue box, select ‘Advanced’ as the account type, then enter the other details. For the server address, do not include the protocol name; just enter the server’s FQDN or IP address, whichever is appropriate. Also, check ‘Use SSL’ (the ownCloud server does use HTTPS, right?) and enter 443 as the port number (the HTTPS port). I found you also need to check ‘Use Kerberos v5 for authentication’ if you have an @ symbol in the user name. Finally, click ‘Create’.
    Add a CalDAV account
  4. That’s it! Open iCal and check you can see your ownCloud calendar in the Calendars list.

1.3 Android

CalDAV-Sync logoThe application CalDAV-Sync enables synchronisation of events and tasks with the default Android calendar application. Though only a beta release at the time of writing, it seems to work, including ‘two-way sync’ which allows upload of calendar information from the mobile to the server as well as vice versa.

2. Contacts

2.1 Apple iOS

Follow the instructions in the user guide.

2.2 Apple Mac OS X

The ownCloud documentation tells lies for OS X Mavericks: you have to use the server address https://server/owncloud/remote.php/carddav/addressbooks/username. (See this forum post for details.)

  1. Proceed as for setting up a CalDav account, except select ‘Add a CardDav account’.
    Add a CardDav account
  2. At the ‘Add a CardDav account’ dialogue, enter the user name and password as requested, and https://server/owncloud/remote.php/carddav/addressbooks/username as the Server Address, then click ‘Create’.
    Add a CardDav account

2.3 Android

CardDAV-SyncSimilarly to CalDAV-Sync, the CardDAV-Sync application allows synchronisation between the ownCloud server and the Android default contacts apps. There’s a free version as well as a paid-for version with more features.

Afterword

Once you have the ownCloud server up and running, clients installed and CalDAV and CardDAV configured, you can leave iCloud and DropBox behind.

Creating a private cloud with ownCloud. Part 1: The Server

Introduction

As mobile devices proliferate, so does our need to share data between them: calendars, contacts, music, photographs, documents. Many companies are competing to offer “cloud services” to allow us to access our data anytime, from anywhere. However, there is a big drawback: once the data is on their servers you are no longer in control of it. Concerns include:

  1. Privacy: the provider may “share” your data with third parties or attempt to “mine” it to find out more about you from it.
  2. Jurisdiction: the laws of where your data are stored, not where you live, are applicable. Some jurisdictions offer less protection of your privacy and intellectual property than others.
  3. Intellectual property issues: the cloud provider’s user agreement might give them some rights to use what you upload. You did check the fine print, didn’t you? Even if you did, they can still…
  4. Bait and switch: Companies can change their terms of service at any time. When they do so, you might already be so invested in their services that migration will be a major hassle.
  5. Security: A lot of data concentrated in one place makes a juicy target for criminals.
  6. Continuity: Companies can discontinue services with little or no notice, leaving you in the lurch.

So what can you do about it? Many of these issues can be avoided altogether (or at least mitigated) by hosting your own cloud service. ownCloud is an open source “private cloud” package that can provide file synchronisation, calendar and contacts management. The server supports multiple operating systems and clients are available for common mobile platforms and desktops. Service interfaces are standard rather than proprietary (WebDAV, CalDAV and CardDAV for file management, calendar and contacts respectively), increasing interoperability.

To use ownCloud, you need to:

  1. Install the ownCloud server package on a server which is always connected to the internet.
  2. Install ownCloud clients on your devices that you wish to share files between.
  3. Configure your calendar and contacts applications to synchronise with your ownCloud server using the CalDAV/CardDAV protocols.

This blog post covers the first part.

One great thing about the ownCloud server is that, being written in PHP, it will run on nearly all common web servers and platforms more or less out of the box. That said there are a few shortcomings. There is no client-side encryption and files are stored unencrypted on the server by default. WebDAV/CalDAV/CardDAV are layered on top of HTTP, so an HTTPS connection (i.e. use of SSL/TLS transport layer security) is required to secure communications between the client and server. SSL/TLS needs a bit of knowledge to configure and deploy securely; it has several old protocols and ciphers which are insecure and deprecated but are still used to support antediluvian browsers. Since we control all the clients we can avoid the need to use insecure features but we still have to know how to configure SSL/TLS properly if we want the best security.

Virtual Private Server

The server requires a reliable machine that is “always on” and always connected to the Internet, and has a public IP address. This kind of infrastructure could be hard to set up at home, so an alternative is to use a Virtual Private Server (VPS); basically a virtual machine running on someone else’s hardware. VPS offerings range from the cheap and cheerful, aimed at personal web sites and blogs, to enterprise-grade solutions with prices to match. You can choose services that provide given amounts of CPU, memory and disk, different levels of redundancy and backups, and levels of support. There is often a choice of operating system, typically between Microsoft Windows and variants of Linux.

Installing ownCloud on Linux (Debian)

1. Prepare the server

Once you sign up for a VPS, you will often get a server within a few minutes of submitting your credit card details. The first thing to do is to make the server reasonably secure. Changing the root password is the first priority, especially if it was sent to you by email. See My First 5 minutes on a server for further ideas.

2. Install ownCloud

You then need to get an Owncloud server installation. ownCloud is written in PHP so doesn’t require compilation, but has a number of dependencies. The easiest option is to use a Linux package installer, since that way dependencies and updates can be installed automatically. Packages are hosted by OpenSUSE here. Select your operating system and follow the instructions.

3. Create an encrypted data directory (Optional)

ownCloud lives in /var/www/owncloud by default, but allows you to select another directory to store data. To (marginally) increase security, I used encfs to create an encrypted directory. This will be inaccessible if the machine is rebooted, requiring manual remounting with a password. An advantage of encfs is that it doesn’t require you to create a fixed-size file or partition. Here, we store encrypted files in a directory /srv/encrypted-owncloud and mount the decrypted directory on /srv/decrypted-owncloud. The procedure below is cribbed from here with some modifications and corrections.

# apt-get install encfs
# mkdir -p /srv/encrypted-owncloud /srv/decrypted-owncloud
# chgrp www-data /srv/decrypted-owncloud
# chmod -R g+rw /srv/decrypted-owncloud
# gpasswd -a www-data fuse
# chgrp fuse /dev/fuse
# chmod g+rw /dev/fuse
# encfs --public /srv/encrypted-owncloud /srv/decrypted-owncloud

Select the ‘paranoia’ configuration (p) when prompted. Make sure you use a strong password, and don’t lose it! The /srv/decrypted-owncloud directory can be unmounted with unmount as usual, and mounted using the enfcs command again.

4. Update PHP

Operating systems such as Debian and CentOS are designed for server use and prioritise stability than being “bleeding edge”. The downside is that some packages are a little old. In particular, ownCloud 6 recommends PHP 5.3.8 or later, which is later than the version that ships with Debian 6. Fortunately, the dotdeb group maintains a repository of more up-to-date packages including PHP. Follow the instructions there.

5. Configure HTTPS

HTTPS is critical to the security of the ownCloud installation. Do NOT deploy ownCloud without it! Basically, you need to create an X.509 certificate and a private key, and configure Apache with their locations. A few points of note:

  • The Common Name (CN) of the X.509 certificate must match the name of the site (i.e. the virtual host name). If you have multiple web host names you will need multiple certificates.
  • Since this is a private-use server we can use a self-signed certificate. This will cause web browsers and other clients to issue a warning when we first attempt to connect, but this can be ignored. (For https services you want to offer to the general public, it’s advisable to obtain a certificate signed by a Certification Authority.)
  • Since we control the web browsers that will connect to the server, we don’t need to support antique browsers and so can disable the use of older, insecure protocols and ciphers.

Unfortunately some guides are out of date. mod-ssl is now provided in the apache2-common package. Documentation (including on certificate setup) is in /usr/share/doc/apache2.2-common/README.Debian.gz. This guide provides details for debian 7. The following borrows from it.

(1) Enable apache2 ssl

SSL is already provided in the default apache2 distribution.

$ sudo a2ensite default-ssl
$ sudo a2enmod ssl
$ sudo service apache2 restart

(2) Generate an SSL key and self-signed certificate

As mentioned the SSL certificate’s Common Name (CN) must match the domain name being served.

An X.509 certificate was created automatically by the ssl-cert package using the fully qualified domain name (hostname) at that time as the Common Name. The certificate saved in /etc/ssl/certs/ssl-cert-snakeoil.pem and the key in in /etc/ssl/private/ssl-cert-snakeoil.key (readable only by root). If the hostname has changed, these can be regenerated by

# make-ssl-cert generate-default-snakeoil --force-overwrite 

Alternatively, use openssl to generate a self-signed certificate, giving finer control, e.g.:

$ sudo openssl req -x509 -nodes -days 365 \ 
    -newkey rsa:2048 -keyout /etc/ssl/private/hostname.key \
    -out /etc/ssl/hostname.crt

creates a certificate and a 2048-bit RSA key valid for 356 days. You will be prompted for various inputs including the CN. Remember to set the access restrictions for the private key. (In debian, the group should be ssl-cert, the owner should be root and the permissions 640.)

You can view the details of the certificate with the incantation

openssl x509 -in /etc/ssl/certs/ssl-cert-snakeoil.pem -noout -text

Note: openssl is a kitchen-sink command that has multiple functions. See https://www.sslshopper.com/article-most-common-openssl-commands.html for a useful overview.

(4) Configure Apache to use the certificate/key and test

You can use the file /etc/apache2/sites-available/default-ssl as an starting point. Test by enabling the site file (if not already enabled: see whether a symbolic link exists in /etc/apache2/sites-enabled) and restarting the server.

$ sudo a2ensite default-ssl
$ sudo service restart apache2

then connect using a web browser.

As a quick and dirty hack for better security, have the following directives outside any blocks but inside the block:

SSLRandomSeed startup file:/dev/urandom 1024
SSLRandomSeed connect file:/dev/urandom 1024

Then inside the block for the owncloud server:

	SSLEngine on
        SSLProtocol -all +TLSv1 +SSLv3
        SSLCipherSuite HIGH:MEDIUM
	SSLCertificateFile    /etc/apache2/ssl/mycert.crt
	SSLCertificateKeyFile /etc/apache2/ssl/mykey.key

obviously substituting the appropriate paths to your certificate and key files. This disables all except the TLS 1.0 and SSL 3.0 protocols and uses whatever of OpenSSL regards as good cipher suites. However, these change with time as attacks and vulnerabilties are discovered.

More advanced stuff:

The version of openssl provided by Debian 6 does not support the TLS 1.2 protocol or the ciphers necessary for forward secrecy. To solve this issue, you will need to compile recent versions of OpenSSL and Apache2, preferably without touching the default OS packages: see here. Regarding SSL configuration for forward secrecy, see here.

6. ownCloud configuration

You need to enable rewrites

$ sudo a2enmod rewrite
$ sudo service apache2 restart

Now to create an ownCloud configuration file as per the ownCloud installation guide. You can create one from scratch or copy the default /etc/apache2/sites-available/default-ssl to something like /etc/apache2/sites-available/owncloud-ssl and edit that. Disable the default SSL configuration and enable ownCloud configuration file:

$ sudo a2dissite default-ssl
$ sudo a2ensite owncloud-ssl
$ sudo service reload apache2

The point your browser at it, and you should be rewarded with a screen that invites you to create an administrative user. Do this now (and use a strong password), obviously, because at this point anyone can do this. You’ll also have the option of setting up a data directory other than the default /var/www/data. Point it at /srv/decrypted-owncloud directory you created earlier (if you did so).

Assuming you’re successful, ownCloud will then run through some diagnostics, then you’ll be in.

Troubleshooting

What could go wrong? Quite a lot actually, but most issues are probably due to misconfiguration rather than breakage. Fortunately, ownCloud does produce some mostly helpful diagnostics that are only occasionally misleading.

  • If the apache2 server fails to start then the server configuration file is probably broken. A good starting point for troubleshooting is examining web server logs (by default in /var/log/apache2).
  • Check permissions. ownCloud expects the /var/www/owncloud directory (and data directory) to have the owner and group www-data. The web server also has to run as the user www-data to access these files. Although this is the default, some installations can differ.
  • If ownCloud issues some diagnostics as a result of its self-test, you can see details in the log accessible from the Admin link.

Conclusion

That’s basically it. You should now have a working ownCloud server. In Part 2 I’ll explain how to configure various devices to use it.

Building SBCL on Red Hat Enterprise Linux 6

Unfortunately the latest version of SBCL is not supported by RHEL 6.5. We need to build from source, using another Common Lisp compiler. Unfortunately it seems that only older versions of SBCL compile with other CL compilers, so we need to build one of those first, then use it to build the latest version of SBCL.

What’s the Recipe Today Jim?

Overview:

  1. Install development tools (C compiler etc.)
  2. Install CMUCL
  3. Build an older version of SBCL that compiles with CMUCL
  4. Use the older version of SBCL to compile a newer version of SBCL

This is What You Do

(i) Install development tools.

This command installs the whole kitkaboodle. Modify if you don’t want a kitchen sink dev environment.

# yum groupinstall "Development Tools"

(ii) Install CMUCL version 19a

Grab from http://www.cons.org/cmucl/download.html.

Requires 32-bit library

# yum install glibc.i686

(iii) Download and build SBCL sources for version 1.0.35

Grab from http://sourceforge.net/projects/sbcl/files/. First build SBCL version 1.0.35 in a local directory.

$ sh make.sh "lisp -batch" --prefix=$HOME/local/sbcl-1.0.35
$ cd test && make test
$ INSTALL_ROOT=$HOME/local/sbcl-1.0.35 sh install.sh

(iv) Download and build the latest version of SBCL

This step left as an exercise for the reader.

An LCD display module for a Raspberry Pi: Part 1

DRAFT – WORK IN PROGRESS

Introduction

Although the Raspberry Pi can be used as a desktop computer in its own right, its small size and low performance mean that it can equally be used for specific applications, running in “headless mode” without a keyboard or monitor. For many such applications, it is often useful to have a limited display capability, for example to show device status. For this purpose, we add a dot-matrix liquid crystal display (LCD) module.

LCD Module Interfacing

Most dot-matrix LCD modules are driven by an integrated Hitachi HD44780 display controller/driver IC. This presents a 4-bit or 8-bit bus interface to external logic and drives the LCD module directly. It includes a display data buffer and a character generator ROM.

The Raspberry Pi makes a number of General-Purpose Input/Output (GPIO) pins made available on a 26-bit header that we can use to drive such an LCD display module directly. Although this gives a very low parts count, it leaves few pins for other purposes (for example, inputs for a pushbutton interface). However the Raspberry Pi’s GPIO also has two I2C interface pins. I2C is an industry-standard specification for serial communications, typically used within electronic devices to connect several modules. Using the I2C bus in conjunction with bus expanders such as the Microchip MCP 23017 16-bit I2C I/O expander can allow up to seven
16-bit I/O devices or ports to be daisy-chained onto the Pi’s I2C bus.

One scheme is therefore to use the Raspberry Pi as an I2C bus master and the LCD module as an I2C slave with the MCP 23017, as shown below.


----------. 3v3 
      1,17|----------------+--------------------------+------------+-----
          |                |                          |            |
          |                +--.                       +--.         |
          |            VDD |  | RESET-            VDD |  | LED+    |
          |              .-------.                 .---------.     |
          |              |       |                 |         |Vo   \ 10k
          |              |       |                 |         |---->/ trim
          | SDA          |       |GPA0-3      DB0-3|         |     \ pot.
         3|--------------|       |=================|   LCD   |     |
          | SCL          |  MCP  |                 | Module  |     |
   RPi   5|--------------| 23107 |GPA4-6  RS,R/W-,E|         |     |
   GPIO   |              |       |=================|         |     |
          |              |       |                 |         |     |
          |         A0-A2|       |            DB4-7|         |     |
          | Address =====|       |          ..=====|         |     |
          |              |       |          ||     |         |     |
          |              .-------.          ||     .---------.     |
          |              VSS |              ||     VSS |  | LED-   |
          |                  |              ||         +--.        |
          | GND              |              ||         |           |
6,14,20,25|------------------+--------------++---------+-----------+-----
----------.

Notes:

  1. Here we operate the LCD module in 4-bit mode, using only the MCP231037’s GPA interface. This leaves the GPB interface free for other purposes. Alternatively, we could operate the LCD module in 8-bit mode, which would slightly simplify the software on the Raspberry Pi but would tie up both of the MCP231037’s interfaces.
  2. The LCD module has a backlight (connected to the LED+ and LED- pins) and also a contrast adjustment input VO. This is connected to a potentiometer (10k – 20k Ohms).
  3. The GPIO header provides 3.3V output (max. 50mA) and 5V output (max. 300mA). However, the Raspberry Pi’s logic uses 3.3V and the GPIO pins are not protected. Applying 5V to the I/O pins will likely result in damage to the Pi, so the above circuit uses only the Pi’s 3.3V supply.
  4. The address pins on the MCP23017 are used to program the its address on the I2C bus. These could be either hard-wired directly to VSS or VDD, or set via a small switches/jumpers with pull-up resistors.
           --------+----------
           VDD     |
                   #
                   #  10k
                   #
                   |
           Jumper |*
            or    |
           switch |*
                   |
                   +---------- Address pin
                   |
                   |
           VSS     |
           --------+----------
    

Bill of Materials

   26-pin IDC socket connector        x 2
   26-way ribbon cable                x 0.5 m
   26-way IDC header                  x 1
   MCP23017                           x 1 
   LCD module                         x 1
   Trimmer, 10k                       x 1
   DIP switch, 4 way                  x 1
   SIL resistor pack, 4x10k, commoned x 1