Using strings in SQL select clause in CodeIgniter DB helper

If you need to use literal strings in your select clause (such as a date format) using the CodeIgniter DB helper, you will need to pass false as the second parameter

$this->db->select(
    'DATE_FORMAT(date, "%Y-%m-%d") as something_date', 
    false
);

Quick way to enable MySQL General Query Log without restarting

If you want to quickly enable the MySQL General Query Log without restarting MySQL Server, you can run these couple queries to start outputting all queries to a file located on disk

You can then run a command like “tail -f /var/log/mysql/all.log” to see the queries appear as your application runs. Note never enable this on anything other than a development environment, and make sure to turn it off once you are finished debugging or the disk will fill up

How to solve file exceeds GitHub’s file size limit of 100 MB

You may encounter a problem with GitHub if you are using it as a new remote (or a pull request for a different remote) whereby a file in the history is over 100MB. This means that although your working copy doesn’t have the file, it was there at some point in time

remote: error: File dump.sql is 221.82 MB; this exceeds GitHub's file size limit of 100 MB

Therefore you will need to find out where in the history the file exists, and rewrite history so that it doesn’t. Thus you will need to git rebase and remove them.

First find out which commits the file exists in

git log --all -- dump.sql

Then check which files were touched in each of those commits (for each commit)

git show --name-only xxxx

This gets slightly complicated if the commits contain other modified files, otherwise you may need something like David Underhill’s script

Then if you rebase from the commit before the one you need to remove. An easy way to do this is to use an interactive rebase

git log
git rebase --i xxxx

You may end up with commits that deleted the file later, which are now empty so would effectively not be required. You can keep them as part of the history using

git commit --allow-empty
git rebase --continue

You should then have a copy of your repository with that file no longer present. As mentioned this is simple way to do it, but if you need to untangle a file from larger commits you may need the script linked above

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 -->
  <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

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: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>

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)

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.

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');
Newer posts
Older posts