Although I’m more than comfortable using command line tools to manage things there are times where a GUI is just more convenient. Pruning old containers, images and volumes in Docker are all things that are easier much to manage under a new tool I saw via twitter the other day. Portainer promises to make the task of managing Docker a bit easier and they’ve made good progress on delivering on that promise.  Getting up and running with it is incredibly simple because, as you’d expect, it’s available as a Docker image.  Simply issue the following this slightly Mac specific command:

docker run -d -p 9000:9000 -v "/var/run/docker.sock:/var/run/docker.sock" -v portainer:/data --name portainer portainer/portainer

This will get Portainer up and running on your system. If you’re on a Linux system you can skip mapping docker.sock. The other mapping just gives a persistent store for the little bit of data Portainer generates.  For full documentation visit their documentation site.

Found myself with an odd situation when running Jenkins using Docker. The time displayed was correct but claimed it was UTC which lead to some inconsistent behavior. The best way to resolve this is to force the Docker container to use the correct timezone from the host system.

To do so, add the following to your run command:

-v /etc/timezone:/etc/timezone -v /etc/localtime:/etc/localtime

screen-shot-2016-10-24-at-11-22-05-pm

Not too long ago a Raspberry Pi 3 found its way into my home and after looking around on the Internet for Raspberry Pi based projects I decided to turn it into a HomeKit hub using Homebridge. While installing Homebridge isn’t terribly difficult I decided I could make it even easier by utilizing puppet.

Using puppet to install Homebridge as well as any additional modules you want is beneficial because you can backup the puppet files and if you need to rebuild your Raspberry Pi for any reason you can quickly get back up and running by applying your existing puppet config. If you’re feeling adventurous you can manage all of your software and configs using puppet.

This post details how to get Homebridge installed on a Raspberry Pi running Raspbian Jessie and assumes you have already Raspbian installed, have gained access to it using ssh or are using the terminal application in PIXELS.

To install Homebridge, do the following (prefix all commands with sudo if you are not already logged in as root):

  1. apt-get update
  2. apt-get install puppet
  3. puppet module install puppetlabs-apt
  4. puppet module install puppet-nodejs
  5. puppet module install dustinrue-homebridgepi

With that out of the way you can create the puppet file that defines what software is installed on your system. To get started, all you need is the following:

include homebridgepi

Into a file called homebridge.pp using your favorite editor. You can now tell puppet to apply this to your system.

puppet apply homebridge.pp

This will install Homebridge and set it to start on system boot using systemd. Homebridge will be installed to run as root but you can change this behavior by editing /etc/systemd/system/homebridge.service and changing the User value. I choose to run it as root as some modules require root privileges to run helper programs. Know that if you do so you’ll need to manually move your .homebridge directory from /root to whatever user you choose.

You can view the logs of Homebridge by issuing:

journalctl -uf homebridge

You will find your config.json file located at /root/.homebridge/config.json. In it will be the default config that you can expand on. You can configure any additional modules you want to install (described below) in this file as well.

From here you can define additional Homebridge modules you want to install by editing your homebridge.pp file. As an example, here are some of the modules I install on my system to support what I’m using Homebridge for:

 

include homebridgepi

package {
  'vim':
    ensure => 'installed',
    provider => 'apt';

  'homebridge-wol':
    ensure => 'latest',
    install_options => '--unsafe-perms',
    provider => 'npm';

  'homebridge-xbox-one':
    ensure => 'latest',
    source => 'https://github.com/dustinrue/homebridge-xbox-one.git',
    install_options => '--unsafe-perms',
    provider => 'npm';
}

 

My multicore Solr on Ubuntu 10.04 has proven to be one of my most popular posts yet.  Seeing the success of that post I decided it was time to show how to get the latest version of Solr up and running on Ubuntu 10.04.  As of this writing the latest version of Solr is 3.4.0.

Before we get started you should read and follow my previous post because I borrow all of the config settings from Ubuntu’s Solr 1.4 packages.  The default config settings from the Ubuntu maintainers is still a decent starting point with Solr 3.4.  Once finished you can safely remove the old Solr 1.4 package if you want to.

With a working Solr 1.4 installation in place, we can get started on getting Solr 3.4 running.  You can change some of the following paths if you want, just remember to change them in all of the appropriate places.  Everything you’re about to see should be done as the root user.

Create some required paths

mkdir /usr/local/share/solr3
mkdir /usr/local/etc/solr3
mkdir -p /usr/local/lib/solr3/data

Next, re-own the data dir to the proper user

chown -R tomcat6.tomcat6 /usr/local/lib/solr3/data

Download the latest version of Solr

You can get the latest version of Solr from http://lucene.apache.org/solr/ and extract the files into root’s home directory.

wget http://mirrors.axint.net/apache//lucene/solr/<version>/apache-solr-<version>.tgz
tar zxvf apache-solr-<version>tgz

Extract the war Solr war file

Extract the Solr war file into a location.  You may need to install the unzip utility with apt-get install unzip.

cd /usr/local/share/solr3 
unzip /root/apache-solr-<version>/dist/apache-solr-<version>.war

Install additional libs

There are a few other libs included with the Solr distribution.  You can install anything else you need, I specifically need to have the dataimporthandler add ons.

cp /root/apache-solr-3.4.0/dist/apache-solr-dataimporthandler-* WEB-INF/lib/

Configure Multicore

If you want to have multicore enabled you’ll need to perform the following actions.  The rest of this post assumes you have copied this file and will require you to make some changes to support multicore.  I’ve marked steps that can be skipped if you also wish to skip the multicore functionality.

Copy in the multicore config file:

cp /root/apache-solr-3.4.0/example/multicore/solr.xml .

You should now edit the solr.xml file at this point, doing the following:

  • Set persistent to true
  • Remove entries for core0 and core1

Next, change the ownership and permissions so that tomcat is able to modify this file when needed

chown tomcat6.tomcat6 /usr/local/share/solr3
chown tomcat6.tomcat6 /usr/local/share/solr3/solr.xml

Copy existing config files

This is where we’re going to borrow some files from Ubuntu’s Solr package maintainer.

cd /usr/local/etc/solr3
cp -av /etc/solr/* .

Because we simply copied the config files we need to modify them to fit our new environment.  Change the following in the solr-tomcat.xml file:

  • Change docBase to /usr/local/share/solr3
  • Change Environment value to /usr/local/share/solr3

Also edit tomcat.policy file changing:

  • Modify all entries referencing solr to point to appropriate /usr/local location

Change the following in conf/solrconfig.xml:

  • Change <dataDir> to /usr/local/lib/solr3/data

If you are using multicore and you followed the Solr 1.4 multicore post you’ll have a conftemplate directory and you’ll need make changes to conftemplate/solrconfig.xml

  • Change <dataDir> to /usr/local/lib/solr3/data/CORENAME

Create symlinks

Here we’ll create some symlinks to support the way Ubuntu packages Solr.  This is necessary because we copied Ubuntu’s config files and those files reference a few locations.  Creating the symlinks also allows us to continue using the scripts created in the previous post with minimal modifications.

  • cd /usr/local/share/solr3
  • ln -s /usr/local/etc/solr3/conf
  • ln -s /usr/local/etc/solr3/ /etc/solr3
  • ln -s /usr/local/lib/solr3 /var/lib/solr3

Enable/Start the new Solr instance

We can now enable our new Solr 3.4 instance in tomcat by doing the following:

cd /etc/tomcat6/Catalina/localhost
ln -s /usr/local/etc/solr3/solr-tomcat.xml solr3.xml

Note that the name of the symlink is important as it will define where we find this instance (/solr vs /solr3).  At this point you can create a new core.  I’ve provided the updated scripts here.

 

I’m not going to lie.  I think OS X Lion 10.7.0 is a buggy release.  Is it buggier than some other releases of OS X?  Possibly.  Can Apple fix the bugs, most certainly.  But bugs aside, there a few design decisions Apple made that don’t seem fully baked.

First, lets touch on some of the bugs I’ve noticed so far.

Finder is one of those things in OS X that is almost universally disliked for one reason or another.  Finder in Lion has a new feature where it just stops doing things at all.  At times disk usage stops being updated and it won’t actually copy files.  While a restart of Finder resolves this issue, it’s odd that it is there at all.

Wi-Fi, formerly known as AirPort, has a strange tendency to just not connect after resuming from sleep.  That said, when it is connected I find it to be more reliable with more stable throughput.

Launchpad, the iOS like view of your installed applications has a tendency at times to lag heavily when launching an app.

There are a number of other smaller bugs that exist in Lion that are a bit grating but I have faith that Apple will fix them in short order.  Leopard was initially, at least in my opinion, unusable after the initial installation and I found myself going back to Tiger a couple of times.  Apple fixed those issues and then some.

But what really gets me are the things Apple will probably never fixed because they are working as designed and my real issue is that I don’t like the design.  Gestures for one are a cluster.  Many were changed from Snow Leopard and worse is that a good number of them contradict what a person would have learned.  Four finger swipe up now produces mission control rather than show desktop.  The show desktop gesture has now been replaced by a more awkward five finger gesture.  All in all, I spent the most time tweaking gesture settings on Lion than anything else after install.  Between the available options in System Preferences and BetterTouchTool I think I have things where I want them.

More annoying than the gestures is the addition of “natural scrolling.”  Natural scrolling reverses the scrolling direction when using the mouse wheel so that to scroll the page down you pull your fingers down on the trackpad or mouse.  The naming of this option is also interesting because unchecking the natural scrolling option says to the user they are about to enable something that is less natural.  I don’t think this could be further from the truth.  Like flying a plane, it’s natural for your body to want to push the stick forward to cause the plane to pitch down, but you push left or right to pitch left or right.  Natural scrolling makes complete sense on touch device where it is more like you are pushing a sheet of paper around.  At any rate, my issue comes in when you disable natural scrolling.  Not only does it reverse scrolling but it also reverses the direction used for changing spaces.  With natural scrolling off, using four fingers left causes you to go to the space on the left and four fingers right brings the space on the right into view.  In writing this makes sense, but in practice it feels awkward.

Lion also lacks the kind of polish I’ve come to expect from OS X.  Parts of it down right ugly.  Mail.app for example has a new layout which is great except for the hideous message count badging, shown below:

 

There is just something about the numbers that make them appear to be off in some fashion.

The boot process, at least what you see on screen, has been revamped some and I can’t help but feel that it all looks very clunky.  While the fading and moving the Apple logo from the center of the screen to above the list of users on the login screen is very clever, the steps required to move from boot splash to getting this animation setup is jarring.  The boot process basically boils down to showing the typical boot splash screen with the Apple logo which is then replaced with an image that looks the same and is ultimately used during the final animation that reveals the available users.  This transition just isn’t the kind of smooth and elegant thing a person would expect from Apple.  Couple that with the sometimes jarring color correction applied just prior to the animation effect and you have what is in my eyes a really poorly done boot sequence.  The shutdown process is also odd in that the desktop goes way and is covered with a plain gray screen.  The blue screen used in previous releases was much better and if it had to be replaced at all it should have been replaced with black.

All that said, there is a lot to like about Lion.  I find the autocorrect to be a fine addition.  I like Mission Control a lot, resume is a great feature, Mail.app’s new layout is superb and the refinements to iCal and Contacts are welcome.  I know Apple will fix the real bugs in the software but I can only hope they provide better System Preference options for customizing gestures.

I’m also surprised that none of the reviews I read seemed to point out the shortcomings of Lion and gave it glowing reviews.  As I said, there is a lot to like but it certainly isn’t perfect and I think Apple deserves to hear about it.  Lion isn’t Apple’s Vista by any means, but it’s obvious to me that Jobs had less input in this release than previous releases.