Monthly Archives: February 2011

rsync windows failed: Invalid argument (22)

Rsync from linux server to a Windows server as a redundant backup using cwrsync but getting an error for the chown command on the directories being backed up.

The issue was simple enough, stop telling rsync to change the owner as the linux command is invalid on the windows server.

[php]rsync -atv /directorytobackup/ windowsserver::cwshare
[/php]
changed to
[php]rsync -rtv /directorytobackup/ windowsserver::cwshare
[/php]
and all is now quiet from an error message perspective.

Thanks to Marcin and Linux Questions Forum for the solution.

Kayako HelpDesk email settings and Ticket Post Reply Slow

I have used Kayako HelpDesk for around 3 years and had pretty much forgotten how it was setup originally. Over the past 6 – 12 months the process for posting a reply has been taking a long time, i.e. 40 seconds or more from the moment you click ‘Send’ to respond to a ticket and the application returning the user to the ticket listing ready to select another task. It was odd, but as it was still working, and was possibly just an issue with size of db, or similar, we(I) ignored it.

I was making a change the other day and noted that our setting in the Admin -> General -> CPU & Server settings for the SMTP server was not correct.

[php]
SMTP Server: mailserver.forexternal.relay
SMTP Port: 25
[/php]

Now I knew that our exchange server for the external email was not using port 25 as under Exchange 2007 and Server 2008 the preferred config around preventing open relays is to vary the SMTP port. The hostname itself was correct, so I changed the port to the ‘correct’ port and saved the settings. I then finished the other change and logged out.

A while later I was completed a ticket response and was stunned to see a 2 sec response time. WTF?

I experimented for a while and found that the response time for a Post Reply was consistently working the way it should have and if I changed the SMTP server port back to 25 it was back to 45 sec.

Sounds like it was a server setting issue and all should be fabulous with the fast response time. That about wrapped up that day but…..

The next morning we noted that there were no HelpDesk ticket emails being sent.

After some more investigation it turns out that the Kayako HelpDesk although it asks for the SMTP server it will actually still forward via the local host. The localhost was not using the modified SMTP port and the combination of trying to use the remote server hostname with its correct port was failing to allow any email.

The solution was to simply set the SMTP Server to ‘localhost’ and the default port ’25’.

Email now flows correctly and the timeout issue on the Post Reply page is still good.

I still do not understand why the system managed to work, albeit with a long delay, previously. I think that Kayako / PHP might have been trying to connect to the remote server on the incorrect port first and waiting for a time-out before reverting to the local host. My best guess is that when I changed it to the correct remote port, it was no longer timing out, it was getting a rejection and therefore not trying again. Setting it to use localhost directly works fine with email going immediately and no timeout, but the emails used to get the actual staff / team member responding to the ticket as the sender, whereas we are now getting just the label ‘helpdesk’. But that is for another day.

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