Trying the ELK Stack Locally on Ubuntu 14.04

Trying the ELK (ElasticSearch, LogStash, Kibana) stack locally on my laptop, I took some notes while following the excellent instructions and scripts provided by DIgitalOcean:

This was for a local install not exposed to the web on a 32-bit install of Ubuntu 14.04. Here is my steps were different than those provided by DigitalOcean:

  1. Java OpenJDK 7 works fine (openjdk-7-jre), so I did not install Java 8
  2. Kibana
    1. Use the 32-bit package if needed, the tutorial uses the 64-bit package.
    2. There’s no need to modify the ‘kibana.yml’ configuration file for a local install.
    3. Kibana process log files are located in /var/log/kibana/
  3. Nginx for a reverse proxy – skip this for local install
  4. All sections, skip the update-rc.d commands if you do not want the services to run at boot on your machine

Port Configuration for ElasticSearch in Docker

The current Docker hub image for ElasticSearch for version 2 is configured to only listen to loopback devices by default, ignoring non-loopback devices. This makes it difficult to use the container for development.

If your Docker VM is running on, with port-forwarding set to port 3278 (use ‘docker inspect’ to verify this), when checking for connectivity from outside of the container, you will end up with the following:

curl: (7) Failed to connect to port 3278: Connection refused

One workaround is to force ElasticSearch to mount to non-loopback devices: _non_loopback_

A configuration file for the container is expected to be created and named elasticsearch.yml, located at /usr/share/elasticsearch/config

Either a bind-mount location for the configuration file (docker run -d -v), or add a configuration elasticsearch.yml file directly into the filesystem.

For example, to write to the filesystem from the container’s command shell:
echo ' _non_loopback_' > /usr/share/elasticsearch/config/elasticsearch.yml

Restart service or container and it will take effect.


Some Notes for Building Unofficial Ports of Android

Here are some quick notes of how to use other people’s work on Github when building unofficial Cyanogenmod or other custom Android builds.

Many unofficial device maintainers have a local_manifests xml file, which specifies replacement projects. See some documentation about local_manifests here:

This modifies the repo command to tell it to pull in altered projects that should replace or add to the original set of projects you are working off, such as device specific files. Example here:

Next, you want to look for the build patches, which maintainers typically put in the device specific folders (from the root folder, look in device common or the by the actual device name). For example, some maintainers may place the patches here:

Ultimately how this is organized will vary by the maintainer.

Android Launcher 3 Build from Eclipse (From 4.4.2 Source)


Work done


Do it yourself

  1. Use Git to pull down the latest Launcher 3 source:

    git clone

  2. Import existing code into Eclipse (Android Project from Existing Code)
  3. Change the project build target to API level 19
  4. Add Android support libraries
  5. Build protocol buffers JAR from AOSP source. You will actually need to build the protoc binary as well. You need to know how to use ‘make’ have gcc available for the protoc binary, and Maven for the JAR:…l/protobuf.git
  6. Use protoc binary built from step above to generate the file:

    protoc –javanano_out=src/ -I protos protos/backup.proto

  7. Rename the Android package (Android Tools->Rename Application Package) to one of your choice
  8. Add min SDK in a new ‘uses-sdk’ element in AndroidManifest.xml (works down to API level 17 without too many complaints in Lint, obviously stick to 19 to play it safe).
  9. Clean and run. BIND APP WIDGETS error can be ignored


Fabio Lo Brutto:

Quick Reference – Viewing the Android Platform Source Code

One of the best things about developing on Android is the availability of the source code of the operating system itself. It means that developers don’t just have a blackbox to work with as with other operating systems.

Downloading the entire source code for the Android operating system can be time consuming depending on your internet connection, and building times depend on your computer’s processing power. For the typical develop who is just curious about the code in general without having to commit to downloading the whole thing, Google has made most of their code web viewable.

The main code repository is found at It is partially mirrored at Github as well. There are also many alternate mirrors out there.

Of all the code that have been made available, it is platform/frameworks/base that contains most of the relevant code for most Android application developers.

Another place to look is in everything preceded by packages/apps, which translate to applications compiled as APKs and deployed to the system partition. Taking a quick glance at the manifest file and string resources will help figuring out which packages do what. Some of these packages use hidden APIs unsupported by the Google distributed SDK, including the Launcher application. It is still possible to build these applications into work apps as described here (Stackoverflow).

New Command Line Tool ‘settings’ in Android 4.2

There is a new binary shipping with Android Jellybean 4.2, which can be used to directly read/write to the system settings provider, accessible via command line.

This tool also makes it easy to change system settings using shell commands (Github source). Since adb is run as a system process, using ‘adb shell’ allows full read/write. If these commands are run from within an application, it requires the appropriate permissions unless it is being run with elevated permissions (root).
usage: settings [--user NUM] get namespace key
settings [--user NUM] put namespace key value
'namespace' is one of {system, secure, global}, case-insensitive
If '--user NUM' is not given, the operations are performed on the owner user.

Corresponding keys can be found in the frameworks core (Github source).

It can be used to get system state without explicit API calls. For example, change screen brightness to 200 (1-255):

settings put system screen_brightness 200