1 Minute Crons

[Alex]

On average, with a 5 min cron, the user has to wait 2.5 minutes.

 

Separately for trouble tickets, 5 minutes is a long time to wait (2.5 min on average) for an update to be reflected in the system. Where this matters, we recommend using ticket piping.

How would one implement email piping if they utilize a third-party mail provider, like say Rackspace or Google Apps? My understanding is that email piping is not ideal in such circumstances.

[Paul]

How would one implement email piping if they utilize a third-party mail provider, like say Rackspace or Google Apps? My understanding is that email piping is not ideal in such circumstances.

 

That's the most common reason IMAP/POP may be preferable, but there is a way around it. You can have email forwarded to another address at a different domain, whos MX points to the server running Blesta and pipe it in.

I've not personally tested this, but I don't see any reason it wouldn't work.

[Alex]

That's the most common reason IMAP/POP may be preferable, but there is a way around it. You can have email forwarded to another address at a different domain, whos MX points to the server running Blesta and pipe it in.

I've not personally tested this, but I don't see any reason it wouldn't work.

That doesn't seem like a "clean alternative" as compared to increasing the frequency in which Blesta does an IMAP request to check for new mail. I have tested the Blesta cron system quite a bit and it seems well aware of whether a particular task has finished, and will not trigger it to run again until the last run has finished.

Rather than assigning this as a core task, can you provide insight into how we can modify the Blesta core to support lesser intervals for particular tasks? This could be done at our own risk and any future updates which revert us to the 5 minite minimum wouldn't cause anything to break.

[Paul]

That doesn't seem like a "clean alternative" as compared to increasing the frequency in which Blesta does an IMAP request to check for new mail. I have tested the Blesta cron system quite a bit and it seems well aware of whether a particular task has finished, and will not trigger it to run again until the last run has finished.

Rather than assigning this as a core task, can you provide insight into how we can modify the Blesta core to support lesser intervals for particular tasks? This could be done at our own risk and any future updates which revert us to the 5 minite minimum wouldn't cause anything to break.

 

This is a good question for Cody or Tyson, I'll ask them to take a look.

[Alex]

This is a good question for Cody or Tyson, I'll ask them to take a look.

Thanks Paul

[Cody]

Firstly, I STRONGLY RECOMMEND AGAINST DOING THIS. Adjusting a cron task to run more frequently than once every 5 minutes can be dangerous as it increases the likelihood of a race condition, the results can be unpredictable.

 

1. Find the ID for the "poll_tickets" key in the cron tasks table (SELECT `id` FROM `cron_tasks` WHERE `key`='poll_tickets')
2. Take the ID from #1, and search for the entry in the cron_task_runs table (SELECT * FROM `cron_task_runs` WHERE `task_id`=TASK_ID)
3. Change the cron_task_runs.interval from 5 to 1.
4. Update line 1983 of /app/controllers/cron.php from:

5.                 $last_run_date = date("c", floor($this->Date->toTime($last_run->start_date)/(60*5))*(60*5));

   to:

                   $last_run_date = date("c", floor($this->Date->toTime($last_run->start_date)/(60*min(5,$cron_task->interval)))*(60*min(5,$cron_task->interval)));

6. Set your configured cron to run once every 1 minute, OR (more preferably) create a new cron task that runs every 1 minute at /usr/bin/php /path/to/blesta/index.php cron/pluginTasks/

[Ken]

How would one implement email piping if they utilize a third-party mail provider, like say Rackspace or Google Apps? My understanding is that email piping is not ideal in such circumstances.

 

While Google and Rackspace don't have piping they do have routing options.  So you can route mail to your ticketing server which would then be piped.  That's what I have done since we use Google Apps.

[Alex]

While Google and Rackspace don't have piping they do have routing options.  So you can route mail to your ticketing server which would then be piped.  That's what I have done since we use Google Apps.

The problem I have with this, at least in the case of Rackspace, is that the split domain routing will forward the mail to the server with a ticketing system without keeping a copy. In my case, I want to have a copy of that mail available to me if the server with the ticketing system on it happens to be down with an outage. So, this would defeat our purpose for using external mail. But, thank you for pointing that out.

[Ken]

The problem I have with this, at least in the case of Rackspace, is that the split domain routing will forward the mail to the server with a ticketing system without keeping a copy. In my case, I want to have a copy of that mail available to me if the server with the ticketing system on it happens to be down with an outage. So, this would defeat our purpose for using external mail. But, thank you for pointing that out.

 

There's a couple of things you can do but all involve dancing around Rackspace's limitations.  You can catch the email at rackspace, forward the email to an alias that exists on your local server like support@ticket.yourcompany.com which then forwards (locally) to the piped account via alias.  Or you can catch the initial email at your local mailserver and send a copy to an alias which you have setup at Rackspace.

 

Just throwing ideas out here because piping is important enough for me to not set up fetch.  Also have you by any chance spoken with Rackspace about this?  They may have a solution for you.  I mean they should if they're an Enterprise mail system.  Routing is just standard.

[Alex]

You can catch the email at rackspace, forward the email to an alias that exists on your local server like support@ticket.yourcompany.com which then forwards (locally) to the piped account via alias.

 

Let me see if I follow:

 

1) Rackspace receives email at a real mailbox, stores a copy and forwards to support@ticket.yourcompany.com using mail filters

2) support@ticket.yourcompany.com pipes the forwarded copy to Blesta

 

Is that correct? If so, it seems like a reasonable solution to me. Thanks Ken!

[Michael]

Let me see if I follow:

 

1) Rackspace receives email at a real mailbox, stores a copy and forwards to support@ticket.yourcompany.com using mail filters

2) support@ticket.yourcompany.com pipes the forwarded copy to Blesta

 

Is that correct? If so, it seems like a reasonable solution to me. Thanks Ken!

 

It looks correct mate.

[Ken]

Let me see if I follow:

 

1) Rackspace receives email at a real mailbox, stores a copy and forwards to support@ticket.yourcompany.com using mail filters

2) support@ticket.yourcompany.com pipes the forwarded copy to Blesta

 

Is that correct? If so, it seems like a reasonable solution to me. Thanks Ken!

 

That is correct but then it's going to be piped at support@ticket.yourcompany.com to which your department would have to be setup with that address.  So what I was thinking is add another local mail forward to support@yourcompany.com so that it's piped to the proper address.  The idea is that ticket.yourcompany.com is only used for routing purposes in between mail servers.  But from client to Blesta it would go from support@yourcompany.com --> support@yourcompany.com

 

This is only theoretical, I've not tested this configuration but if I'm not mistaken it should work.

[Alex]

That is correct but then it's going to be piped at support@ticket.yourcompany.com to which your department would have to be setup with that address.  So what I was thinking is add another local mail forward to support@yourcompany.com so that it's piped to the proper address.  The idea is that ticket.yourcompany.com is only used for routing purposes in between mail servers.  But from client to Blesta it would go from support@yourcompany.com --> support@yourcompany.com

 

This is only theoretical, I've not tested this configuration but if I'm not mistaken it should work.

Ah okay, I understand the extra step now. I'm not sure if cPanel will support the local exchange when a domain is set to remote exchange, but I could set up an Exim smart route. But, I think we can avoid this problem...

Blesta has an SMTP option for company outgoing mail which is seperate from the support department incoming mail settings. I can pipe the mail to the ticket system from the sub-domain, but use SMTP for outgoing mail from Blesta. Am I missing something? Outgoing mail wouldn't be delayed by SMTP, would it? I think it's still sent out immediately.

[Ken]

Ah okay, I understand the extra step now. I'm not sure if cPanel will support the local exchange when a domain is set to remote exchange, but I could set up an Exim smart route. But, I think we can avoid this problem...

Blesta has an SMTP option for company outgoing mail which is seperate from the support department incoming mail settings. I can pipe the mail to the ticket system from the sub-domain, but use SMTP for outgoing mail from Blesta. Am I missing something? Outgoing mail wouldn't be delayed by SMTP, would it? I think it's still sent out immediately.

 

When you use SMTP insteal of php mail() it's going to use that account to authenticate but it's still going to use the department email in the message header.  And yes it'd be sent out immediately.

 

Just make sure that after you set this up that people can still send email to your exchange accounts and not just route locally.  To be honest I did not take cPanel into consideration when I should have.  Blesta is configured on my end with it's own mail server which is strictly for receiving piped emails.

[Alex]

When you use SMTP insteal of php mail() it's going to use that account to authenticate but it's still going to use the department email in the message header.  And yes it'd be sent out immediately.

 

Just make sure that after you set this up that people can still send email to your exchange accounts and not just route locally.  To be honest I did not take cPanel into consideration when I should have.  Blesta is configured on my end with it's own mail server which is strictly for receiving piped emails.

 

This may fall flat, but I think I can make it work. I'll post back results when I've had time to test. Either way, thank you for the ideas, they have been helpful. (As with other hanging threads I have, it may be a few days before I get time to test.)

[Ken]

This may fall flat, but I think I can make it work. I'll post back results when I've had time to test. Either way, thank you for the ideas, they have been helpful. (As with other hanging threads I have, it may be a few days before I get time to test.)

 

No problem.  I'm following the topic so I'll keep an eye out.