Vagrant: The guest operating system of the machine could not be detected!

TLDR; check that the shell defined by your config.ssh.shell is installed

Edit: Reported as https://github.com/mitchellh/vagrant/issues/3040 and got immediate reaction, cool.

Today I encountered following error with Vagrant when executing "vagrant up":

The guest operating system of the machine could not be detected!
Vagrant requires this knowledge to perform specific tasks such
as mounting shared folders and configuring networks. Please add
the ability to detect this guest operating system to Vagrant
by creating a plugin or reporting a bug.

This box had worked before, and it was based on Ubuntu 13.10, so I was pretty confused.

After enabling debug logging for vagrant (well, after updating vagrant and trying zillion different things :)), following log was given:

.... (a lot of log)
DEBUG ssh: stderr: bash: /bin/zsh: No such file or directory

DEBUG ssh: Exit status: 127
ERROR warden: Error occurred: The guest operating system of the machine could not be detected!
.... (a lot of log)
ERROR vagrant: The guest operating system of the machine could not be detected!
Vagrant requires this knowledge to perform specific tasks such
as mounting shared folders and configuring networks. Please add
the ability to detect this guest operating system to Vagrant
by creating a plugin or reporting a bug.
ERROR vagrant: /opt/vagrant/embedded/gems/gems/vagrant-1.4.3/lib/vagrant/guest.rb:48:in `detect!'
/opt/vagrant/embedded/gems/gems/vagrant-1.4.3/lib/vagrant/machine.rb:182:in `guest'

After seeing this, the reason was obvious: I had added zsh as shell with

config.ssh.shell = "/bin/zsh"

And it was not installed to box.

Few tips for making application Docker friendly (Or some problems with WebLogic 10.3.6 and Docker)

I've been playing around with Docker trying to install WebLogic 10.3.6. Here's some tips for making application Docker friendly, mainly from issues I encountered. Perhaps some of these are just general good practices

1. Make it possible to bypass disk space checks
Docker (0.8) doesn't allow you to define disk size, so when Weblogic tries to verify that there's enough space on the disk, it fails. Luckily there's a parameter which makes it possible to ignore this. As a side note, Oracle DB has the same option but it still asks user "Are you sure" or something similar. Sucks when trying to install with puppet.

2. Use environment variables to define configuration options.
Docker has excellent way to define environment variables in Dockerfile and in run -command. Also there's a lot of useful variables present. I found this when trying to deploy separate front- and backend -servers, and needed a way to define addresses for connections.

3. Do not assume anything about ports or addresses.
WebLogic maven plugin seems to have some weird issue when port is forwarded to different one, ie. docker run -p 7001:7002 for Admin server. This causes deployment to fail. Just a little thing you should test.

I've managed to get WebLogic up and running with docker, which is a huge plus. Testing our application with WebLogic is so much easier now.

And no, we did not select WebLogic. Our customer did.

Weblogic with Docker: Insufficient disk space!

When installing WebLogic 10.3.6 in docker container, the installer complained that there wasn't enough disk space.

Insufficient disk space! The installer requires:
222MB for the BEA Home at /opt/wls/Middleware11gR1,
476MB for the product at /opt/wls/Middleware11gR1/coherence_3.7,/opt/wls/Middleware11gR1/utils/uninstall/WebLogic_Platform_10.3.6.0,/opt/wls/Middleware11gR1/wlserver_10.3 and
1087MB temporary work space at /tmp/bea805456445130318772.tmp.
There is only 1MB available at /opt/wls/Middleware11gR1.

I think that Docker resizes filesystem as needed, so it is just the installer that gets confused. According http://docs.oracle.com/cd/E24329_01/doc.1211/e26593/issues.htm#BCFIHGCJ
this check can be circumvented with -Dspace.detection=false.

As I'm playing around with Edmond Biemonds fantastic puppet modules (https://github.com/biemond/puppet), I needed to have a way for adding this parameter into installation command. Luckily it was simple, and pull request has already been merged (https://github.com/biemond/puppet/pull/28).

Aborting export of VMs with Ovirt 3.1

I was going to upgrade Ovirt from 3.1 to 3.2, and in prepration, I started to export VMs. I thought that I had enough space on export -domain, but it seems that the thinly provisioned disks will use all the space they've been assigned. So I needed to abort exporting.

Exporting locks the images, so I was a little bit afraid that aborting export with good old 'kill' would leave them into that state. After finding http://www.mail-archive.com/users@ovirt.org/msg08588.html, I decided to bit the bullet and just kill the processes. Ovirt actually worked very well, and all images became unlocked automatically. Hooray for proper error handling.

Try at your own risk, though.

trivial-rebase.py in Gerrit 2.6, fixing "trivial_rebase.py: error: Incomplete arguments"

Trivial rebase detection had some changes when Gerrit 2.6.0 was released, and my previous patchsets-created hook didn't work anymore. In logs, there was

[2013-06-25 12:05:33,916] INFO com.google.gerrit.common.ChangeHookRunner : hook[patchset-created] output: trivial_rebase.py: error: Incomplete arguments

To fix this, I modified my patchset-created hook to following (original came from some discussion list, and I was extremely stupid and didn't write down where I got it :( ):

#!/usr/bin/perl

use strict;
use warnings;
use Getopt::Long;

my $gerritHome="/home/gerrit2";
my $gerritRoot=$gerritHome."/review_site";
my $hookDir=$gerritHome."/scripts";

my $change;
my $project;
my $commit;
my $patchset;
my $changeurl;
# Not really needed, but without these error_log will have entries like
# INFO com.google.gerrit.common.ChangeHookRunner : hook[patchset-created] output: Unknown option:
my $branch;
my $uploader;
my $isdraft;

my $result = GetOptions("change=s" => \$change,
"project=s" => \$project,
"branch=s" => \$branch,
"commit=s" => \$commit,
"patchset=s" => \$patchset,
"change-url=s" => \$changeurl,
"is-draft=s" => \$isdraft,
"uploader=s" => \$uploader);

system($hookDir."/trivial_rebase.py",
"--project", $project,
"--commit", $commit,
"--patchset", $patchset,
"--change-url", $changeurl,
"--private-key-path", $gerritRoot."/etc/ssh_host_dsa_key");

To use this, trivial_rebase.py must be in /home/gerrit2/scripts/trivial_rebase.py and it must be executable by gerrit2 user.

Git subtrees and contributing upstream

I needed Puppetlabs Apache -module, so I added it into my vagrant training repository with following command

git-subtree add --squash --prefix=puppet/modules/apache https://github.com/puppetlabs/puppetlabs-apache.git master

As I started to use this module, I spotted a minor commenting error: one class parameter was removed, but it was still
used in comments. This seemed to be a good place to train to contrinute into upstream repository using github workflow.

First I cloned the puppetlabs/puppetlabs-apache in github, and then I tried to pull it as subtree

git subtree pull --prefix=puppet/modules/apache --squash https://github.com/jyrkiput/puppetlabs-apache.git

Didn't actually do anything, as puppetlabs/puppetlabs-apache.git and jyrkiput/puppetlabs-apache.git were both at same commit. So I'm not sure if this was actually needed.

I did just a minor fix, git add -u and git commit, then

git subtree push --prefix=puppet/modules/apache git@github.com:jyrkiput/puppetlabs-apache.git #21262

Some counting happened, and then the commit was transferred to github. Branch name #21262 is ticket number from Puppet Labs issue tracker.

Then I made a pull request to puppetlabs-apache, which got merged in few days. When I got a message telling me that the pull request had been merged, I wanted to see how I could pull changes back. So I tried

git-subtree pull --prefix=puppet/modules/apache https://github.com/puppetlabs/puppetlabs-apache.git master

But this caused a lot of conflict. But adding --squash removed those.

git-subtree pull --squash --prefix=puppet/modules/apache https://github.com/puppetlabs/puppetlabs-apache.git master

I'm don't know if usage of --squash was a mistake, or should I have gotten the whole history? Anyway, I managed to go contribute into upstream project using subtrees.

Converting Git submodules to subtrees

While learning to use Vagrant, I've been using git submodules. But git subtrees seems to be a lot better choice, so I wanted to start using them.

So, in my repository, which can be found from https://github.com/jyrkiput/vagrant-jenkins-gerrit, I had following .gitmodules:

[submodule "puppet/modules/jenkins"]
path = puppet/modules/jenkins
url = https://github.com/rtyler/puppet-jenkins.git
[submodule "puppet/modules/java"]
path = puppet/modules/java
url = https://github.com/puppetlabs/puppetlabs-java.git
[submodule "puppet/modules/stdlib"]
path = puppet/modules/stdlib
url = https://github.com/puppetlabs/puppetlabs-stdlib.git
[submodule "puppet/modules/firewall"]
path = puppet/modules/firewall
url = https://github.com/puppetlabs/puppetlabs-firewall.git
[submodule "puppet/modules/apt"]
path = puppet/modules/apt
url = https://github.com/puppetlabs/puppetlabs-apt.git

And with Git 1.8.3.1 installed from with Homebrew (http://brew.sh/).

Unregister all submodules with git submodule deinit

git submodule deinit .

This removes submodule configurations, so each module must be removed. So for each module

git rm puppet/modules/[modulename]

ie.

git rm puppet/modules/jenkins

Commit your changes

git commit -m "Removed submodules"

Add modules as subtrees, so for each module

git-subtree add --prefix=path/to/subtree --squash repository master

ie.

git-subtree add --prefix=puppet/modules/jenkins --squash https://github.com/jenkinsci/puppet-jenkins master

git-subtree will make a commit when a subtree is added, so these are now in your repository

Finally remove .gitmodules for cleaning up things.

The man page of git subtree was really helpful when finding out what to do, and it contains a lot more information.