Stefan Helander

Cherry Framework 4 header not using full page width when breadcrumbs are disabled

/0 Comments/in , /by

When you disable breadcrumbs in Cherry Framework 4, it still reserves space for it in the header/title section of the page. This is a bit annoying, because it makes the title wrap when there still is space on the right side.

A simple CSS solution can fix this. By applying this, the breadcrumbs will not be visible even if they are enabled again.

.cherry-breadcrumbs .col-md-5 { /* no breadcrumbs, title in full width */
width: 100%;
}
.cherry-breadcrumbs .col-md-7 { /* no breadcrumbs, hide the breadcrumb container */
display: none;
}

Stefan Helander

Ispconfig 3.0 to 3.1 update issue – PHP-FPM and SSL problems

/0 Comments/in /by

After updating a multi server installation of Ispconfig3 problems occured when editing existing or adding new websites on one of the servers.

  • If the site had SSL enabled the apache2 vhosts file for the site (located in /etc/apache2/sites-availible) would get empty values for SSLCertificateFile, SSLCertificateKeyFile and SSLCertificateChainFile fields, causing it to revert to old configuration or not load the site at all. At some point apache2 wouldn’t reload at all so to get it upp the site had to be disabled by removing /etc/apache2/sites-enabled/100-sitename.vhost file.
  • If the site was running under PHP-FPM the site would report Internal server error 501 caused by the socket file /var/lib/php5-fpm/webXXX.sock was owned by root and not by the web user. This in turned was caused by the fields listen.owner and listen.group in webXXX.conf (for PHP-FPM) was empty.

Since this was a multi server installation and this problem only occured on one server they could be compared. It turned out that the problem was caused in the directory /usr/local/ispconfig/server/plugins-enabled. The files in this directory should be symbolic links to the corresponding files in /usr/local/ispconfig/server/plugins-available, but after a move of the Ispconfig3 installation from an older server, these links had become real files instead of symbolic links.

This meant that the files in /usr/local/ispconfig/server/plugins-enabled was still Ispconfig 3.0 files while the ones in /usr/local/ispconfig/server/plugins-available was Ispconfig 3.1. To resolve the problem, to be on the safe side, make a backup of /usr/local/ispconfig/server/plugins-enabled and then run:

cd /usr/local/ispconfig/server/plugins-enabled
ln -s -f /usr/local/ispconfig/server/plugins-available/apache2_plugin.inc.php apache2_plugin.inc.php
ln -s -f /usr/local/ispconfig/server/plugins-available/apps_vhost_plugin.inc.php apps_vhost_plugin.inc.php
ln -s -f /usr/local/ispconfig/server/plugins-available/aps_plugin.inc.php aps_plugin.inc.php
ln -s -f /usr/local/ispconfig/server/plugins-available/bind_plugin.inc.php bind_plugin.inc.php
ln -s -f /usr/local/ispconfig/server/plugins-available/cron_jailkit_plugin.inc.php cron_jailkit_plugin.inc.php
ln -s -f /usr/local/ispconfig/server/plugins-available/cron_plugin.inc.php cron_plugin.inc.php
ln -s -f /usr/local/ispconfig/server/plugins-available/firewall_plugin.inc.php firewall_plugin.inc.php
ln -s -f /usr/local/ispconfig/server/plugins-available/ftpuser_base_plugin.inc.php ftpuser_base_plugin.inc.php
ln -s -f /usr/local/ispconfig/server/plugins-available/getmail_plugin.inc.php getmail_plugin.inc.php
ln -s -f /usr/local/ispconfig/server/plugins-available/maildrop_plugin.inc.php maildrop_plugin.inc.php
ln -s -f /usr/local/ispconfig/server/plugins-available/mailman_plugin.inc.php mailman_plugin.inc.php
ln -s -f /usr/local/ispconfig/server/plugins-available/mail_plugin_dkim.inc.php mail_plugin_dkim.inc.php
ln -s -f /usr/local/ispconfig/server/plugins-available/mail_plugin.inc.php mail_plugin.inc.php
ln -s -f /usr/local/ispconfig/server/plugins-available/mysql_clientdb_plugin.inc.php mysql_clientdb_plugin.inc.php
ln -s -f /usr/local/ispconfig/server/plugins-available/network_settings_plugin.inc.php network_settings_plugin.inc.php
ln -s -f /usr/local/ispconfig/server/plugins-available/postfix_filter_plugin.inc.php postfix_filter_plugin.inc.php
ln -s -f /usr/local/ispconfig/server/plugins-available/postfix_server_plugin.inc.php postfix_server_plugin.inc.php
ln -s -f /usr/local/ispconfig/server/plugins-available/shelluser_base_plugin.inc.php shelluser_base_plugin.inc.php
ln -s -f /usr/local/ispconfig/server/plugins-available/shelluser_jailkit_plugin.inc.php shelluser_jailkit_plugin.inc.php
ln -s -f /usr/local/ispconfig/server/plugins-available/software_update_plugin.inc.php software_update_plugin.inc.php
ln -s -f /usr/local/ispconfig/server/plugins-available/webserver_plugin.inc.php webserver_plugin.inc.php

Verify with ls -l /usr/local/ispconfig/server/plugins-enabled that all your files are symbolic links.

 

Stefan Helander

Microsoft Office 365 SSL certificate error in Outlook [solved]

/0 Comments/in , /by

Clients moving over to Office 365 who had purchased a valid SSL certificate for their mail server still got SSL certificate errors in Outlook and mobile clients. This was despite the mail service was equipped with a valid SSL certificate (not self signed, but issued by a real CA).

It turns out here that Outlook seems to investigate https root domain (i.e. the customer’s web site) for auto configuration before trying autodiscover.customerdomain.com. And if there is no valid SSL certificate installed on the customers web site, an error is displayed. This was verified by examining the customer’s web site logs where we could se repetitive accesses to /autodiscover/autodiscover.xml.

If only Outlook just would have ignored the SSL error and continued to the next method….

A simple solution was just to add a valid SSL certificate to the customer’s web site, and the problem was solved. That way Outlook didn’t get SSL certificate error when trying to retrieve the non-existing autoconfiguration information from the customer’s web site.