Ticket #1343 (closed defect: fixed)

Opened 1 year ago

Last modified 11 months ago

Cron calls may end up in wrong host in staging/live situations

Reported by: bergie Assigned to: jval
Priority: blocker Milestone: 8.09.6 Ragnaroek
Component: Midgard Data Version: 8.09 Ragnaroek
Keywords: Cc:

Description

The current Midgard cron runner (/usr/share/midgard/setup/php/midgard_cron.php) queries for hosts in the database and performs cron runs for them. As MidCOM cron is designed to run only once per sitegroup (see #815), there can be the following problem:

  • Cron is run for the staging database (in my case with option -c midgardstaging)
  • Cron seeks hosts
  • Cron finds the *live* host of a website first in the list
  • Since other hosts of the SG are skipped, that is the only host found
  • The cron request to live host is done via HTTP, and cron thinks it complete based on the fact that it succeeded
  • Staging cron never got run

Change History

09/15/09 10:32:24 changed by bergie

  • owner changed from bergie to piotras.
  • component changed from MidCOM component to Midgard Data.

10/07/09 12:47:05 changed by jval

I wonder how can we know which of the hosts is the staging one..? Compare to Apache HTTP Server virtual host configuration? That might be a bit tricky (and very tricky if done properly - not impossible, but who has the time to do it...). Or is there another (easier) way?

10/07/09 12:53:46 changed by jval

<bergie> jval: yep, that is the tricky thing there

<bergie> I don't know the good solution yet

<jval> it can be seen from the vhost configuration (MidgardDatabase? directive), but parsing that information isn't actually easy if done properly (parsing it from the whole httpd configuration)

<jval> we can of course just grep it from the vhost files, but that's not the proper solution - we might have to live with that though because that's the only quick solution i can think of right now

10/12/09 15:24:01 changed by jval

  • owner changed from piotras to jval.

#815 is the reason this one exists. Perhaps it's best to revert/disable the solution done there until it's implemented properly (in a way nothing breaks).

Asked about this and bergie agreed:

<bergie> jval: yeah, OK

<bergie> that is the way easiest solution

10/12/09 15:29:39 changed by jval

<bergie> jval: it may slow things down, as every host will fetch RSS feeds etc

<bergie> but shouldn't be serious

10/12/09 15:45:39 changed by jval

  • status changed from new to closed.
  • resolution set to fixed.

(In [23574]) Revert solution done for #815 because it caused a new defect. The solution didn't take into consideration the fact that same host can exist in multiple databases (e.g. with staging/live setups). Fixes #1343, reopens #815