Whilst there is some good documentation on the Symfony Config component there isn’t an obvious example to get you started. Here is a simple way (there is much more you can do) to get started using the component as a standalone, without Symfony for example.
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
If you need to delete all the directories only and not files in a directory in Linux, you can do it with the “rm -r */” command
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
<!-- allowed to be written to --> <write> <files> <resource name="icinga_pipe">/var/spool/icinga/cmd/icinga.cmd</resource> </files> </write>
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
Note: Leaving SELinux in permissive mode is not recommended, please add a rule as necessary
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.
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:parameters> <ae:parameter name="dir">/var/icinga-log/</ae:parameter> <ae:parameter name="prefix">icinga-web-</ae:parameter> </ae:parameters> </appender> <appender name="DebugLogfileAppender" class="AgaviRotatingFileLoggerAppender" layout="ApacheStyle"> <ae:parameters> <ae:parameter name="dir">/var/icinga-log/</ae:parameter> <ae:parameter name="prefix">debug-</ae:parameter> </ae:parameters> </appender>
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)
AgaviCacheException 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.
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');
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
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 will consist of a single positive integer given on standard console input.
Print “Valid Score” or “Invalid Score” based on the respective validity of the given score.
Sample Inputs & Outputs
Sample Input 1
Sample Output 1
Sample Input 2
Sample Output 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.
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 pear.zero.mq
sudo pecl install pear.zero.mq/zmq-beta
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:
(change depending on where your other binary is)
Then run composer.phar install again and it should work.