Kayako Helpdesk and SSL https connections

Using https with Kayako is not as clean as it could be. It has been an ongoing discussion for a few years now.

The process that I have used is to set the admin panel options as described in this Kayako forum thread and then add a redirect in the .htacess file.

In the Kayako admin page go to the General Settings and change the URL from http:// to be https://whatever.your.helpdesk.url.is and save the new setting.

Then go to the Diagnostics page (almost at the bottom of the admin list) and select Rebuild Cache.

Assuming that you are on a Linux platform then editing the .htaccess file will sort the last piece.

What this is doing is redirecting http to https. In the root of the Kayako installation edit the .htaccess file

[text]
RewriteCond %{HTTPS} !=on
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R,L]

RewriteEngine On
[/text]
if the .htaccess file already has content this might need to be moved within the file to get it to work correctly just in the event that there is a clash of settings. But, for a blank .htaccess file just add these lines and save it.

Again with assumptions, that the Apache configuration is actually looking at the .htaccess for settings but that is another conversation.

So from the Kayako perspective everything internally is https and if someone does call for http the .htaccess redirects them.

Windows 2008 Server virtual server clock resets

There appears to be a lot of conflicting information about configuring Windows time on a virtualised Windows 2008 server. Some of this will stem from the variety of hypervisors in use.

In this case the Windows 2008 server is running under Hyper-V and it appears to be hitting the hardware clock of the host system on every restart.

So depending on what you read you will find advise to manage via the Hyper-V management in the host (which sometimes is not accessible in hosted environments) or to just turn off the Hyper-V sync (depending on which of the posts you believe on that page) and work on the NTP settings.

For this VPS I don’t have access to the Hyper-V and don’t know what the settings are.

In summary I have modified the w32time setting to use an external ntp server at the command prompt rather than relying on the graphical interface that reported the correct settings but running a w32tm query suggested different settings existed.

From a command prompt:

[text]

w32tm /query /status # this just confirmed that the server was not using the ntp server that was set in the graphical interface

w32tm /config /syncfromflags:manual /manualpeerlist:0.pool.ntp.org

w32tm /query /status # confirm changes

[/text]

and with Regedit (this is possibly redundant but I’d prefer to see more frequent checks for NTP than 24 hours and 15 minutes seems ok. Could easily be an hour using 3600 as the setting.)

[text]

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeTimeProvidersNtpClient (SpecialPollInterval)    and modified Decimal value to 900 (15 minutes)

[/text]

And after 2 restarts this morning it all appears to have resolved correctly and the correct time zone hours are still being displayed.

References for results:

Managing the NTP settings under Windows 2008 provided the basic commands and I also read this but the syntax for 3 sources did not work (I did not try to work out why as I am ok with one NTP server selected).

This page provided the regedit info that I needed to get the NTP working every 15 minutes rather than 7 days apart.

This blog post over at Apeture was a funny read and includes some more registry info which helped to clarify the NTP settings.

WordPress wp_list_pages includes Home link for no reason

Well, it’s never for ‘no reason’ but it can be hard to find.

I have been working with the free download ColorWay theme By InkThemes.com and while I like the theme it was annoying me that when I used the wp_list_pages function to get a list of child pages (which I logged earlier this year), it kept adding the Home page to the list as if it were a child of the page.

As it turns out after much tracking of the source of the issue, I find that the Colorway theme includes an add_filter function to insert the Home link at the top of the wp_list_pages function to build the main menu. I tracked this down to this file:

[text]
wp-contentthemescolorwayfunctionsinkthemes-functions.php
[/text]

What I found was that the add_filter was being applied for the specific purpose and was then left as a persistent process.

at around line 46
[php]
wp_list_pages(‘title_li=&show_home=1&sort_column=menu_order’);
[/php]
and at around Line 63
[php]
add_filter(‘wp_list_pages, ‘inkthemes_new_nav_menu_items’);
[/php]

Line 46 was inside a function which builds the main menu:

[php]
function inkthemes_nav_fallback() {
?>
<div id="menu">
<ul class="ddsmoothmenu">
<?php
wp_list_pages(‘title_li=&show_home=1&sort_column=menu_order’);
?>
</ul>
</div>
<?php
}
[/php]

Which I modified to basically place the add_filter as a part of this function only and added a remove_filter at the end to put it back to normal.
[php]
function inkthemes_nav_fallback() {
// 20121103 thowden copied from line 63 to place relevant to this function only
add_filter(‘wp_list_pages’, ‘inkthemes_new_nav_menu_items’);
?>
<div id="menu">
<ul class="ddsmoothmenu">
<?php
wp_list_pages(‘title_li=&show_home=1&sort_column=menu_order’);
?>
</ul>
</div>
<?php
// 20121103 thowden added to reset the standard wp_list_pages function
remove_filter(‘wp_list_pages’, ‘inkthemes_new_nav_menu_items’);
}
[/php]

So now the InkThemes menu will still work but will not perpetuate the wp_list_pages function change.

But, the body of the page list is still a problem and that is because line 63 as shown above is NOT in a function and is always applied. So the simple solution is to delete it, or comment it out of the code.

[php]
// 20121103 thowden to remove Home from list pages
//add_filter(‘wp_list_pages’, ‘inkthemes_new_nav_menu_items’);
[/php]

and all is well with the world again…

sugar_file_utils.php Fatal error: on migrating SugarCRM

[text]Fatal error: sugar_file_put_contents_atomic() : fatal rename failure ‘/tmp/tempI3QakJ’ -> ‘cache/modules/Employees/Employeevardefs.php’ in /home/account_name/public_html/sugarcrm/include/utils/sugar_file_utils.php on line 187
[/text]

It’s a permissions thing. Setting up a new server to migrate SugarCRM. The new install of Sugar appears ok until I update the config.php file and then it breaks.

The trigger is the permissions on the second named file

[text]
‘cache/modules/Employees/Employeevardefs.php’
[/text]

Just for clarity the line 187 that is referenced is in this function in SugarCRM

[php]
180 if (!@rename($temp, $filename))
181 {
182 @unlink($filename);
183 if (!@rename($temp, $filename))
184 {
185 // cleaning up temp file to avoid filling up temp dir
186 @unlink($temp);
187 trigger_error("sugar_file_put_contents_atomic() : fatal rename failure ‘$temp’ -> ‘$filename’", E_USER_ERROR);
188 }
189 }
[/php]

The error is triggered when line 183 fails to rename the temp file as the cache file. Permissions on the temp directory must be ok or the creation of the temp file would have triggered an earlier error. It is also unlinked (deleted) successfully which means that at line 186 the temp directory/file permissions are ok. So it must be the cache directory at issue.

In this case the cpanel server was allocating the user account as both owner and group. Sugar apparently wants to see Apache as the group, or at least the Apache account owner, ‘nobody’. So while the chmod settings for owner and group read/write were ok, the group was incorrect.

[text]
#chown -R owner:nobody sugarcrm/
[/text]

Command for the ownership change for the group to nobody.

Edit: As correctly pointed out I had used chmod when I manually typed up the instructions. Corrected the above to read chown. Thanks Derek.