Ansible Variables all of a Sudden Go Missing?

I’ve written a playbook which deploys a working development environment for some of our internal systems. I’ve tested it with various versions of RHEL. Yet when I ran it against a fresh install of Fedora it failed:

fatal: [] => {'msg': "One or more undefined variables: 'ansible_lsb' is undefined", 'failed': True}

It turned out, that ansible gets it’s facts through different programs on the remote machine. If some of these programs are not available (in this instance it was lsb_release) the variables are not populated resulting in this error.

So check if all variables you access are indeed available with:

$ ansible -m setup <yourhost>

Common docker pitfalls

I’ve ran into a few problems with docker I’d like to document myself and how to solve them.

Overwriting an entrypoint

If you’ve configured a script as an entrypoint which fails, you can run the docker image with a shell in order to fiddle with the script (instead of continously rebuilding the image):

#--entrypoint (provides a new entry point which is the nominated shell)
docker run -i --entrypoint='/bin/bash'  -t f5d4a4d6a8eb

Possible errors you face otherwise are these:

/bin/bash: /bin/bash: cannot execute binary file

Weird errors when building the image

I’ve ran into this a few times. Errors like:

Error in PREIN scriptlet in rpm package libvirt-daemon-
useradd: failure while writing changes to /etc/passwd

If you’ve set SELinux to enforcing, you may want to temporarily disable SELinux for just building the image. Don’t disable SELinux permanently.

Old (base) image

Check if your base image has changed (e.g. docker images) and pull it again (docker pull <image>)


Could not initialize Opera

Just ran into a problem this morning since opera has been working up to Opera v. 12.

On start-up you get something like this:

captainmoonlite :: ~ » opera
Could not initialize Opera.

Running the startup script with strace reveals the culprit:

captainmoonlite :: ~ » strace opera
execve("/usr/bin/opera", ["opera"], [/* 71 vars */]) = 0
lstat("/home/roman/.kde/share/config/kcmnspluginrc", 0x7fffbd443080) = -1 EACCES (Permission denied)
write(2, "Could not initialize Opera.\n", 28Could not initialize Opera.

After fixing the permissions of .kde/share/config, opera started just fine. Opera v.11 must have not accessed this directory or file. strace FTW!

Debugging Byobu

Ubuntu ships with a neat GNU screen enhancement called byobu. One of the nice features is to run custom scripts. The output of your custom byobu scripts are shown in the status line of your byobu session.

Byobu runs custom commands

I’ve converted my former screen script to run as a custom script in byobu, but it suddenly stopped working. I was wondering why and found a way to see what the problem was.

What you need

My script scans my mail directory and checks for new mail. I placed it in my home directory under:

$ ls /home/roman/.byobu/bin


The following points should give you a clue why your custom script won’t work with byobu:

  1. Check if you have enabled custom scripts in byobu (press F9 in a byobu session).
  2. Run the custom command by itself from the plugins directory, not from your home directory. The plugins directory is located under Ubuntu in /usr/lib/byobu/custom.
  3. The output of custom scripts are written to a cache file under /var/run/screen. Check what the cache files tell you.

Upgrading Ghostscript and CentOS

The installed Ghostscript version on CentOS is usually too old if you compare it to installations like Ubuntu. Upgrading ghostscript without compiling the whole package is a challenge, but I found via Chris Schuld’s Blog a link to the repository which provides a recent ghoscript version.

The Problem

Nevertheless, I still had troubles with ImageMagick. If you want to convert PDFs to images for example, the installed ghostscript version was unable to lookup certain font files resulting in an error similar to this one:

Error: /invalidfont in findfont
Operand stack:
   Arial-ISO   Arial-ISO   Arial   Font   Arial
Execution stack:
Dictionary stack:
Current allocation mode is local
Last OS error: 2
Current file position is 279
GNU Ghostscript 7.05: Unrecoverable error, exit code 1

The Solution

I hunted around in the system. Apparently ghostscript still uses a fontmap to lookup fonts. The question is which fontmap was in use. I tried to change the fontmap in /etc/ghostscript which had no affect.

I finally found a bogus fontmap under


which provided all font entries and aliases, but none of the aliases had a font file associated with it. For example, Helvetica-Bold pointed to NimbusSanL-BoldCond, but NimbusSanL-BoldCond had no pointer to an existing font file in the file system. It was simply missing.

The Fix

I got it now working with this in /usr/share/ghostscript/8.70/Resource/Init:

% See Fontmap.GS for the syntax of real Fontmap files.
%% Replace 1 (Fontmap.GS)
/NimbusSanL-Regu        (n019003l.pfb)  ;
/NimbusSanL-ReguItal    (n019023l.pfb)  ;
/NimbusSanL-Bold        (n019004l.pfb)  ;
/NimbusSanL-BoldItal    (n019024l.pfb)  ;

/NimbusSanL-ReguCond    (n019043l.pfb)  ;
/NimbusSanL-ReguCondItal        (n019063l.pfb)  ;
/NimbusSanL-BoldCond    (n019044l.pfb)  ;
/NimbusSanL-BoldCondItal        (n019064l.pfb)  ;

(Fontmap.GS) .runlibfile