Adding custom hostname to docker-machine VirtualBox image

When boot2docker was changed to docker-machine, it added dubious feature of being read only container, so no changes to VirtualBox will be preserved after restart. Saving changes is still perfectly fine for Linux Docker users, but not docker-machine users anymore for some reason.

So, to add new hostname before, you could just go to VirtualBox, change /etc/hosts file, and this is it - this will not work with docker-machine, as hosts file will be erased after restart. You are luckier, if you are not using net:host in docker-compose, there is special property for that too. But, if you are using net:host, the only working option is to change VirtualBox image and add this configuration:

VBoxManage modifyvm "default" --natdnshostresolver1 on

In this case it will use host machine to resolve all dns requests, even those from /etc/hosts.

Ansible freezes during start

If Ansible stops for several minutes or so during start without any messages, check if it calls your inventory script, because it might query for additional options using --host parameter and if there are a lot of hosts, it may take some time.

It can be easily fixed by adding this to JSON root:

    "_meta" : {
       "hostvars" : {
       }
    }

More about it here.

VirtualBox DHCP gives same IP address to different machines

Usually happens after cloning VMs and problem is because there is the same MAC address. Check virtual machine network settings and change as needed.

Grails dies in the middle of Jenkins jobs after update

If you have upgraded recently and facing problem when job suddenly dies in the middle of test execution, like:

19:20:39  | Running 277 unit tests... 156 of 277
19:20:53  Build step 'Execute shell' marked build as failure
19:20:54  Description set: 

Most probably it is because since version 2.2 test-app, run-app, run-war runs in fork mode and Jenkins has some fancy zombie process detection that kills spawned processes it does not like.
Quick solution is to disable fork in test environment or you can refer my previous post about hiding such processes.

Setting environment variables when running command via SSH in Ubuntu

There are less environment variables available when running command directly by SSH then interactively. This is because for some reason, Ubuntu does a little less for non-interactive shells and stops executing .bashrc after this line:

[ -z "$PS1" ] && return

So if you wish to run anything, it should be done before, like:

export JAVA_HOME=/usr/lib/jvm/jdk1.7.0_21/
[ -z "$PS1" ] && return

Setting PATH for Jenkins slave agent

There is a lot of variables and settings available for Jenkins slave agents, but for some reason nothing worked for PATH in my case. Finally, the only configuration that did the job, was to set PATH in user's home .bashrc (.profile, profile, .bash_profile, etc. was not working) on slave node, like:

  PATH=$PATH:/opt/phantomjs-1.9.1-linux-x86_64/bin/

Run background java process from Jenkins

Jenkins is using mechanism to detect spawned processes and kill them after finishing job, so if you will just start such ad-hoc background daemon process, Jenkins will kill it with warning:

Process leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information

Fortunately, there is easy hack to tell Jenkins ignore such process, just create fake BUILD_ID and start your application, for example, this can be entered into Execute shell build step:

BUILD_ID=dontKillMe nohup java -jar test.jar &

Warning is still there, but process should be fine and running. There is more about it here.

"Cannot find any VM in Java Home ..." error in Tomcat

During migration from JDK 6 to 7, I found strange issue: Tomcat was working fine when starting via catalina.sh, but was failing when starting via jsvc with just this error:

Cannot find any VM in Java Home /usr/lib/jvm/jdk1.7.0_10/

Jsvc recompilation or any other measure was not helping, but finally I found out that it was running flawless with specific x64 version of JDK instead of i586 version.

Sudo without password prompt

Remote scripts often do something that requires root rights, common approach is to use sudo. But by default it interactively prompts for password, which is not easy thing if you execute commands automatically. Fortunately, it can be easily configured not to do it. All that is needed to do is to update /etc/sudoers, and change something like this:

testuser    ALL=(ALL) ALL

to something like this:

testuser    ALL=(ALL) NOPASSWD: ALL