Insecure Docker Registries and RHEL7

In developing and deploying Docker applications it is sometimes necessary to push and pull images to/from a HTTP Docker registry. This is considered very insecure and HTTPS is preferred, but when you don’t control the registry yourself you may need to resort to this option. This guide describes how to push/pull images to/from a plain HTTP Docker registry from Red Hat Enterprise Linux 7.2, where the exact steps are non-obvious.

The official Docker documentation says to add the --insecure-registry flag to your docker engine’s configuration file and restart the daemon but doesn’t give the precise commands for RHEL7, so here they are.

# edit the docker configuration file (as root)
$ sudo vim /usr/lib/systemd/system/docker.service
# append the --insecure-registry flag to the ExecStart command
ExecStart=/usr/bin/dockerd --insecure-registry <registry>:<port>
# restart the docker daemon
$ sudo service docker restart

That’s it. Now go secure that Docker registry!

Dependency Management in Eclipse PDE

Allow me to relate the following problem which took me a day to solve. Java’s classpath, from which an executing Java program loads its dependencies, is notoriously difficult to manage so that many solutions exist in tooling to manage it for you. One such solution is the Plugin Development Environment (PDE) in the Eclipse IDE. But solving complexity with more complexity has obvious pitfalls.

In PDE collections of Java packages are bundled as plugins annotated by metadata descriptors (an aggregation of META-INF/MANIFEST.MF, plugin.xml, and build.properties files). One plugin can declare dependencies on another, or expose a subset of its packages as an interface on which another plugin may depend.

My plugin A depended on a package (org.apache.lucene.analysis.tokenattributes) exposed by another plugin B. Since two conflicting versions of a JAR (Lucene Core 3.5.0 and 4.8.0) existed in the runtime I declared plugin A’s dependency to be against a particular version of the package to avoid a conflict.

Import-Package:
 org.apache.lucene.analysis.tokenattributes;version="4.8.0",

This failed to build in a most obscure way. The build log hinted that plugin A could not be resolved but without indicating why.

<plugin C> failed to resolve.:
 [java] Missing required plug-in <plugin A>_0.0.0.

Eventually I discovered that PDE was unable to fulfill the explicitly versioned dependency from plugin A to plugin B, because it didn’t know if plugin B’s exported package was of the required version level. By explicitly versioning the exported package in plugin B, PDE was able to resolve the dependency and complete the build.

Export-Package:
 org.apache.lucene.analysis.tokenattributes;version="4.8.0",

bootstrapping gtk-gnutella on ubuntu

gtk-gnutella is a native unix client for the Gnutella P2P file-sharing network. It can be installed from the Ubuntu repositories but getting it to work ootb is not as simple as one might hope.

I used Synaptic to install the lastest version then available in the repository: gtk-gnutella v0.96.8. However, once started the gtk-gnutella client was unable to connect to the p2p network.

On startup gtk-gnutella attempts to connect to a list of known hosts or peers on the network with which it share searches/download files/etc., a process known as bootstrapping. The list of initial hosts is included in builds and is subject to frequent change as peers join and leave the network.

The age of the .deb package in Ubuntu’s repository causes the bootstrapping process to fail. The repo’d package is almost 1 year old, making its list of bootstrapping hosts obsolete.

To solve this I upgraded my gtk-gnutella to a recent svn build (1 month old), which I obtained below:
http://stinker.serveftp.net:8000/gtkgnutella/gtkgnutella.html

On launching the upgraded app it immediately found and connected to other Gnutella peers. Problem solved!

Cheers to the owner of that site for maintaining recent svn builds.

For those unable to upgrade their gtk-gnutella installation to a recent svn build, try running the kickstart.sh script from the same site. I haven’t tried it personally as I was able to upgrade, but it looks like a promising method to bootstrap your gtk-gnutella client.
http://stinker.serveftp.net:8000/gtkgnutella/kickstart.sh

Thinkpad T400 fails to boot after BIOS reset

I have a Lenovo Thinkpad T400 running Ubuntu 10.10. I was forced to do a hard reboot when the system would not resume from suspend. When I powered it back on the Thinkpad stated that some BIOS settings had been lost and prompted me to reset the system clock, which I did. Following this the Ubuntu boot process stalled before reaching the gnome login screen.

No useful error messages were displayed. I could enter runlevel 2 with ctrl+alt+f1 but not could not start the X server. dmesg did not reveal anything useful. Memtest and hard disk checks found no errors.

I hit the same error on trying to boot older kernels but was able to boot any kernel in recovery mode (with low graphics). This put me on the graphics trail and it was then I remembered an earlier problem with the T400 and its BIOS graphics settings. I had discovered then that the ATI graphics driver for Linux (fglrx) only worked with certain BIOS settings.

The BIOS reset had set the computer to “switchable graphics”, which was preventing X from loading. I changed the BIOS settings back to discrete graphics and Ubuntu booted normally once more.

It is funny how quickly one forgets. I spent considerable time debugging this error, only to find that I had already solved it months prior.

ADO DB/MSSQL Permissions and Misleading Error Messages

I fell down another sinkhole today when programming a new MSSQL stored procedure and an ASP/JScript wrapper function to call it. As ever with ADO I wasted hours trying to find the source of an obscure bug in my code.

The new stored procedure was to insert some values into a table. Simple stuff you say, but when I executed it from the JScript wrapper function the stored procedure threw the following exception:

Item cannot be found in the collection corresponding to the requested name or ordinal.

Stranger still, the stored procedure functioned just fine when executed from the MSSQL Server Management Studio application. So it was failing from one client but not from the other.

The above error message would normally indicate an attempt to access a non-existent column in a recordset. Not the case here as I was not operating on a recordset.

Eventually, much later, I found the problem to be one of permissions. I had mistakenly failed to grant the IIS web server user permission to execute the new stored procedure. The following line of SQL completed the stored procedure and solved the problem.

GRANT EXECUTE ON "db"."table" TO "iis_user"

But of course!

UnsupportedOperationException and XML Parser versions

I lost a day struggling with this Java error. I had been trying to parse a XML document in a Java web application. It had worked in previous deployments so I knew the code was sound. But when I deployed the WAR file onto my Tomcat6 server on Ubuntu Linux 9.10 I hit an obscure error I had not encountered before.

Apache Commons Digester was throwing an error when it tried to load a XML parser.

java.lang.UnsupportedOperationException: This parser does not support specification "null" version "null"
	at javax.xml.parsers.SAXParserFactory.setXIncludeAware(SAXParserFactory.java:448)
	at org.apache.commons.digester.Digester.getFactory(Digester.java:534)

This caused another exception in turn:

Digester.getParser:
NullPointerException

I tried everything: switching parsers from xerces to crimson; running tomcat with different JVMs; overriding classloaders; all to no avail. Finally I came upon a blog post which revealed that “[the] message This parser does not support specification “null” version “null” [is] the secret. That’s the default error message of the XML parser if you turn on XInclude but that isn’t a supported feature.”

The reason for the UnsupportedOperationException error was that the XML parser implementation I was using did not support the features Commons Digester was trying to set on it. I upgraded my version of xercesImpl.jar from 2.6.2 to 2.9.1, restarted tomcat, and the problem was solved!