Selenium Server on your desktop controlled by Virtual Machine/remote server via SSH tunnel

If you are running your development environment on a virtual machine (whether by Vagrant, a custom local Virtual Machine or a server elsewhere in vSphere or in the cloud) you may want to run Selenium tests on your code, but have no way to do it as your development environment is headless. On the other hand, you have Selenium Server on your desktop/workstation, but it does not have the software installed to run your application.

You can create a reverse SSH tunnel from your development environment to your desktop/workstation, so that your tests execute on your development environment, but Selenium runs on your desktop/workstation.

To get this to work, first download Selenium Server and make sure Selenium Server is running on your desktop (this assumes on the standard port 4444) via something like this

java -jar selenium-server-standalone-2.40.0.jar

Then create a reverse SSH tunnel to your development environment (hostname)

ssh -R 4444:localhost:4444 hostname -l username

This will route any traffic on port 4444 on your development environment back to your desktop, which is this case is to Selenium Server. If this is working, if you still have the terminal open where you ran Selenium Server you should see some output when the commands are being triggered

Icinga Web, Could not send command. Check if your webserver’s user has correct permissions for writing to the command pipe.

If you are getting this error when trying to perform actions on services or hosts in Icinga Web, most forum posts point to the configuration being correct, etc.

Firstly make sure that the command pipe referenced in access.xml points to a valid place, and has icinga-cmd:icinga ownership

vim /usr/local/icinga-web/app/modules/Api/config/access.xml
<!-- allowed to be written to -->
      <resource name="icinga_pipe">/var/spool/icinga/cmd/icinga.cmd</resource>
ls -l /var/spool/icinga/cmd/

Note: This example is from CentOS, your path(s) may vary

Then, which is much more likely the reason it does not work, is make sure you have not got SELinux preventing Apache from executing commands through the command pipe

Easiest way to test this is to temporarily change SELinux to permissive mode and try the action in Icinga Web again

setenforce Permissive

Note: Leaving SELinux in permissive mode is not recommended, please add a rule as necessary

Icinga Web, Uncaught AgaviLoggingException thrown, Cannot open file “log/debug.log”

When trying to get Icinga Web to work, you may run into issue with the log directory not being writable

Uncaught AgaviLoggingException thrown
Cannot open file "log/debug-2014-01-28.log", 
please check permissions on file or directory.

It doesn’t appear to be referencing the core directory, or any other relative directory, so the easiest fix is to create an absolute path to where you want to log files to be written to.

vi /usr/local/icinga-web/app/config/logging.xml

Then update the directories so that they point somewhere valid as below

Agavi appender to dump into filesystem
* Log files are rotated in a 7 day (AgaviRotatingFileLoggerAppender default) cycle
* Use 'cycle' parameter to alter the cycle.
<appender name="UniversalLogfileAppender" class="AgaviRotatingFileLoggerAppender" layout="ApacheStyle">
<ae:parameter name="dir">/var/icinga-log/</ae:parameter>
<ae:parameter name="prefix">icinga-web-</ae:parameter>

<appender name="DebugLogfileAppender" class="AgaviRotatingFileLoggerAppender" layout="ApacheStyle">
<ae:parameter name="dir">/var/icinga-log/</ae:parameter>
<ae:parameter name="prefix">debug-</ae:parameter>

Icinga Web, Set correct write permissions for directory “/usr/local/icinga-web/app/cache”

If you have followed the Icinga install procedure through as per the installation documentation, and are having difficulty getting Icinga Web to install, you may eventually get an Agavi error saying that the cache directory is not writable (if you find the PHP errors)


Failed to write cache file "/usr/local/icinga-web/app/cache/config/config_handlers.xml_production__d98552ff67d2d50d8def4e3ddb970ba8e8e151fc.php" 
generated from configuration file "/usr/local/icinga-web/app/config/config_handlers.xml".

Please make sure you have set correct write permissions for directory "/usr/local/icinga-web/app/cache".

For some bizarre reason this still occurs if you change the ownership and permissions of the directory.

The workaround I found involves changing the cache path to somewhere else on the filesystem outside of the Icinga application directory.

vi /usr/local/icinga-web/app/config.php

Then change the cache directory to be somewhere outside of the application directory (make sure the directory exists and has the correct writeable permissions for Apache)

//AgaviConfig::set('core.cache_dir', '/usr/local/icinga-web/app/cache');
AgaviConfig::set('core.cache_dir', '/var/icinga-web');

Add URL query parameters to links using view helper in Zend Framework 2

There are 2 ways to add query parameters using the URL view helper in Zend Framework 2, either using Segment route placeholders, or adding them as normal query parameters (e.g. url?id=1&name=barney)

Which one you need to use depends on what route the view helper is being used on; since all URL’s in Zend Framework 2 need to be route-aware (even if you’re mimicking ZF1 routing) it depends whether the route you’ve specific is ‘aware’ of the parameters.

Segment route parameters

If you have setup a route with segment placeholder for the parameters you need to use, you will be able to specify them

Normal query parameters

Sports Points on DailyProgrammer

Here is my solution to the Sports Points code test on r/dailyprogrammer

You must write code that verifies the awarded points for a fictional sport are valid. This sport is a simplification of American Football scoring rules. This means that the score values must be any logical combination of the following four rewards:

  • 6 points for a “touch-down”
  • 3 points for a “field-goal”
  • 1 point for an “extra-point”; can only be rewarded after a touch-down. Mutually-exclusive with “two-point conversion”
  • 2 points for a “two-point conversion”; can only be rewarded after a touch-down. Mutually-exclusive with “extra-point”

A valid score could be 7, which can come from a single “touch-down” and then an “extra-point”. Another example could be 6, from either a single “touch-down” or two “field-goals”. 4 is not a valid score, since it cannot be formed by any well-combined rewards.

Formal Inputs & Outputs

Input Description

Input will consist of a single positive integer given on standard console input.

Output Description

Print “Valid Score” or “Invalid Score” based on the respective validity of the given score.

Sample Inputs & Outputs

Sample Input 1

Sample Output 1
Valid Score

Sample Input 2

Sample Output 2
Invalid Score

Mock a JSON HTTP API response in a PHPUnit unit test for Zend Framework 2

In order to mock an API in a unit test, you need to be able to mock the response that comes back from the API request. Therefore you need to specify in the test what JSON (for example) would come back from the HTTP client.

To do this in Zend Framework 2, you need to mock the Zend\Http\Client so that it always returns a mock response, and have the mock Zend\Http\Response always return the JSON content that you want.

Install ZeroMQ on Mac with PHP PECL extension

Getting ZeroMQ working on a Mac looks like a pain if you try to compile, but there’s a much easier way to get it up and running, with just a few brew and PECL commands.

I’ve been wary of Homebrew for a while, as there were lots of issues with Macports in the past, but I’ve found it’s a lot easier than trying to compile various things yourself in OS X (I tried to compile 0MQ, which took a while and ended up broken anyway)


Install Homebrew and ZeroMQ

Grab a copy of Homebrew then run the following command

brew install zeromq

Then once this is installed, install the PECL extension for PHP

Enable ZeroMQ support for PHP

sudo pear channel-discover
sudo pecl install


If you have more than one PHP binary on your computer (such as if you are using Zend Server on OS X, which means you will have the default PHP binary and the Zend PHP binary) then even if 0MQ looks like it is enabled using phpinfo() you may still get the following error from Composer:

– Installation request for react/zmq dev-master -> satisfiable by react/zmq[dev-master].
– react/zmq dev-master requires ext-zmq * -> the requested PHP extension zmq is missing from your system.

This is because Composer uses the PHP-CLI binary to both check and install things, meaning that unless it’s enabled for the binary it’s looking at, it won’t install, even if your web server has it enabled.

You just need to add (even temporarily) the correct PHP binary to the shell path:

export PATH=/usr/local/zend/bin:$PATH

(change depending on where your other binary is)

Then run composer.phar install again and it should work.

Newer posts
Older posts