I’m on HostMonster and I’m trying to setup cron to play nicely with a Drupal install I have running and I’m running into problems trying to code for a condition that says, “IF I’m the server and I’m making the request to do CRON, then do the following…”
Basically (in layman’s terms), I’m having a hard time trying to figure out how I should code for cron requests from the server, which brings me to the following questions:
1.) Do cron jobs always execute from the host server? For example, if $_SERVER[SERVER_ADDR] is always “123.123.123.123”, does this mean that the 583 bytes sent for cron jobs always come from the same IP address or are there exceptions to this? The reason I ask this is because I have a poor man’s byte counter in this cron code I’m working with that sets up a file read and keeps you in the reading loop until the byte count reaches 583 (which, according to my IP logs, is the number of bytes sent with each cron “ping” that gets made.) The code isn’t firing, however, because I’m having a hard time making the code run from either cron requests or else from an inconsistency between the IP comparison code I have.
2.) Before any cron code gets executed, I have “ignore_user_abort(true);” called at the beginning of the page. Will this effectively process all proceeding code thereafter if cron pings the page? In other words, will using this make the page get processed as if someone traveled to the cron.php page in their browser?
I wouldn’t worry too much about it… Drupal’s cron doesn’t do anything inordinately processor-intensive or security-sensitive. It just updates statuses on certain things. If someone wanted to hack your Drupal site, they’d attack the login form as “admin”.
If you’re running the cron as cgi, there will be no $_SERVER collection.
If you’re running the cron as lynx, there may be a couple conditions:
a. 128.0.0.1 if the client is interpreted as “localhost”
b. Server IP address if client is interpreted as a remote host.
c. Local network IP address if a firewall is configured to return that.
Thanks for that, Steve. I had some testing code setup before anything to write the IPs to an output file just to see what IP was being recorded and when I ran the cron, NOTHING was stored / recorded at all. I’m using WGET in the following form to do my cron:
Thanks for the help with this, Steve. It seems to be working, but should I create any condition(s) for the bytes sent? I did with the WGET routine as it showed in my IP logs that it sent a total of 583 bytes and in my mind, I kept thinking that any conditions that check against this might prevent future attacks of some sort. Is this irrational thinking? Too paranoid? Note that now that I’m using Lynx, the bytes sent is now showing up in my logs as being a total of 519 bytes. Will this be constant or will that ever change?
Any insight into this is appreciated, and by the way, I went ahead and decided to use “lynx -source http://www.wabashvalleywebguild.org/cron.php”. Will this have any adverse impact on the CRON being ran?
Not sure what’s the relevance of bytes sent. How does that relate to what you want to achieve? --dump isn’t necessary, but it will return the output of whatever page you call, which you could then pipe into some other action in your cron (if you chose to).
I suppose your point merits reward when I think about. I guess I’m just worried that someone will figure out a way to forge an IP address and then run my Drupal’s CRON without being admin.
I’ve been trying to rig it to where I can login and travel to the CRON page and make it run while also providing for the host to run its CRON routine autonomously (without requiring further action from myself). It is doing this now thanks to Lynx and I do have it set to only fire-off like this if $_SERVER[‘REMOTE_ADDR’] === $_SERVER[‘REMOTE_ADDR’], but do you think this is enough to safeguard against possible anonymous users running the page while also providing the HOST what it needs to run cron?