Tuesday, 13 May 2014

Using openhab bluetooth binding on linux

OpenHab does not distribute the bluecove GPL library in the Bluetooth binding because it is GPL licensed. OpenHAB is EPL (Eclipse Platform License) which is friendly to business since they do not have to open source their own bindings.
You will get this error if you do not modify the Bluetooth binding:
To fix the problem follow these steps:
unjar the org.openhab.binding.bluetooth-1.4.0.jar bundle
change directory to lib

Download the blue cove GPL jar from here
http://sourceforge.net/projects/bluecove/files/BlueCove/2.1.0/

Add the Bluecove GPL library in lib directory of the bundle along with the blue cove jar

Add the new library to manifest:
Bundle-ClassPath: .,lib/bluecove-2.1.1-SNAPSHOT.jar,lib/bluecove-gpl-2.1.0.jar
create the jar file with the original manifest file
jar -cvmf META-INF\MANIFEST.MF org.openhab.binding.bluetooth-1.4.0.jar *

This will solve your bluetooth problem.

Tuesday, 8 April 2014

Having a keystore with 2 certificates

You are able to have more than 1 key and certificate chain in your keystore. A problem is only when you are using the default key manager to pick the cert to represent your client to the server. If the wrong cert is picked for representation then the server will no accept you a trust client.

In this example you have 2 aliases. Both are key certificate chain entries in the keystore. Both aliases have the same CN (common name) in their certs. The default key manager will find the matching aliases with the same same CN from what I can see from my testing. If you have 2 certs that are using the same CN then you might have problem since you do not know what cert the default key manager will pick to represent the client to the server.

Snippet output from javax.net.debug=all
You will see this print out after the server has requested the client certificate.
*** ServerHelloDone
matching alias: client1
matching alias: client2
*** Certificate chain
It picks the first in the list of its print out.
The rest of the print out will the be the details of the client1 alias in the keystore which it uses to identify the client to the server. It imght of picked the wrong alias which will give you a unknown_ca error.

What I noticed about the default keymanager picking aliases

  • does not pick them alphabetically.
  • does pick the first entry in the keystore

Only place i could find this information is here.
http://www.angelfire.com/or/abhilash/site/articles/jsse-km/customKeyMana...


If you need to use certificates that have very similar attributes then you have to implement you own custom KeyManager so you can choose the correct alias to represent your client to the server. If only it was easy to configure the default KeyManager....

Saturday, 25 January 2014

SCCS cheat sheet

Source Code Control System is on old version control systems. It predates RCS which predates SVN. You can see how old it is now. Some companies still use in their legacy systems. To remind myself I have made a cheat sheet.
All commands start with a call to the sccs binary. For example "sccs edit".

edit
Check out a new version of a file in SCCS

unedit
Just like uncheckout

get
Will get the latest file from the SCCS directory to your current location

create
Add a file to SCCS

clean
This will remove all files in the current directory that you are able to retrieve again from SCCS. This is better then delete the file using a linux or unix command because you might delete files that are not under SCCS control.

check : Used in scripts. It returns a non zero exit status if a file is being edited. It will check what files are being edit in the current directory. For this command you have to be in the directory where the SCCS directory is. IT also provides more information than tell e.g user,version,date it was checked out

tell : Used on the command line to inform user if files are being edit in the current directory. It checks the SCCS directory for the information.

diffs
Will show the difference between the current version and previous version you specified.