sendmail STARTTLS TLSv1/SSLv3 verify=FAIL

I have logwatch running on a number of servers and have had a message within the sendmail section on one server for some time but as everything was working I figured it could wait. I finally took the time to check it out this morning and I was correct in my assumption.

[php]——————— sendmail Begin ————————

**Unmatched Entries**
STARTTLS=client, relay=mysmarthost.exchange.2007.server., version=TLSv1/SSLv3, verify=FAIL, cipher=AES128-SHA, bits=128/128: 9 Time(s)

———————- sendmail End ————————-
[/php]

The server is configured to send all mail from the linux server to our internal MS exchange server.

This message with the verify=FAIL is just saying that the CA authority for the certificate being used could not be verified. This is normal with self-issued certificates and is just a note.

From my perspective the main thing is that the count of X time(s) is higher than 9 on a normal day as it is our Kayako HelpDesk server and typically it is 300+ emails / ticket actions. So a low count indicates a problem.

Thanks to Alexander in the nginx forums for the pointer and link to the relevant sendmail details on starttls..

Linux Logwatch in Debian and Redhat

Debian is what I use for most our my Linux servers (other than SME) but I have one older Redhat server that I still maintain.

I was messing with changes to the Logwatch emails (where they are sent: MailTo option) and had modified all the Debian settings easily by editing the /etc/cron.daily/00logwatch file which calls the Logwatch script with a parameter of ‘mailto: root’ as a default. Changing root to the email address was straight forward.

The Redhat setup was different in that the /etc/cron.daily script was a Perl script and while it had apparently editable settings, changing the setting threw an error.

Possible unintended interpolation of @mydomain in string at /etc/cron.daily/00-logwatch line 35.

The Perl compiler/interpreter was taking the email @ symbol and trying to read it as code. So I changed it back to the local root setting and did some research.

I think it’s just an issue with the way that Logwatch has been configured. The file I should have edited is the logwatch.conf and I found it in /etc/log.d/conf/logwatch.conf

Changing the MailTo setting in the .conf file worked fine.

SugarCRM upgrading 5.2 to 5.5 and beyond

I’ve started a process of upgrading our live SugarCRM system from 5.2.0c to later versions. The upgrade paths leave a blind trail at 5.5.4 as there is currently no direct upgrade to 6.1 from 5.5.4. So I am using 5.2.0 to 5.5.1 and then 5.5.1 to 6.1beta5.

The main reason for the upgrade is that we want to use the projects tracking and in 5.2.0 there is no ability to connect the projects panels with prospects/targets, only with accounts/contacts.

I use the prospects/targets for anyone that may be associated with a project but is not a key player, i.e. I dont need to see as much detail for a business or person that plays a minor role.

5.5.x fixes that limitation, and I expect 6.1 will also, but the question is how much time do I spend on 5.5 given that 6.1 is looking pretty stable.

I think I’ll be shooting for 6.1 as the next upgrade to production unless we find a show stopper in testing.

Sugar CRM upgrade IIS7 Internal Server error timeout

There are days that I loathe software. For the record, the config this relates to is Windows Server 2008, IIS 7, SugarCRM 5.2.0c, separate MS-SQL 2005 database server. PHP 5.2.6,

HTTP Error 500.0 – Internal Server Error
C:inetpubphpphp-cgi.exe – The FastCGI process exceeded configured activity timeout

Two ‘supposedly’ identical servers. SugarCRM 5.2.0c installed on production and working a treat. The dev system just just been setup for a new instance of Sugar to provide for testing of the upgrade path to 5.5.1 and probably 6.1 but first the cloned 5.2.0c had to work.

A freshly installed 5.5.1 on dev was working and apparently so was the copied 5.2.0c from production. Except that the Upgrade Wizard in the cloned copy gave the time out error shown above. The 5.5.1 however worked fine which left me thinking it was a Sugar issue, or specific to the site or app pool.

To cut a full 8 hour day down to the stuff we need to know, the issue was that while I looked at all the settings, site level, app pool, and server, for whatever obscure reason the Fast-CGI icon was not showing in the dev server configuration panel.

http://www.iis.net/download/AdministrationPack
The admin pack for IIS7 is required for that interface and provided access to the time out setting which I raised from 30 to 300 and the Upgrade Wizard could then function.

There is a marked difference in performance between 5.2.0c and 5.5.1 in the Upgrade Wizard and this is the bit that threw me at first, because the 5.5.1 clean install would run with the default timeout set at 30 while 5.2.0c would not.