Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By dejamuse on
When I first installed Drupal I had a single site and running cron.php via lynx worked just fine (I'm running my own FreeBSD 6.3 server).
Then I changed to a multi-site installation and followed the advice in another blog about making the installation more secure by moving all Drupal files out of the document root of Apache and using a combination of symlinks and php directory redirect dummy files to keep everything out of sight in spite of .htaccess which isn't apparently all that secure. Read about the technique here: http://justinhileman.info/blog/2007/06/a-more-secure-drupal-multisite-in...
After getting all of that to work lynx no longer runs the cron script, but accessing it via an ordinary browser works just fine. I'm trying to figure out why that is.
I'm using the default script line as follows:
/usr/local/bin/lynx -source http://example.com/cron.php > /dev/null 2>&1
This produces no errors anywhere but the cron script does not run.
Running lynx manually (as root in the tcsh shell) yields:
# lynx -source http://example.com/cron.php
<HTML><HEAD>
<META NAME="description" CONTENT="example.com">
<META NAME="keywords" CONTENT="">
</HEAD>
<FRAMESET border=0 rows="100%,*" frameborder="no" marginleft=0 margintop=0 marginright=0 marginbottom=0>
<frame src="http://68.107.24.241:8082/cron.php" scrolling=auto frameborder="no" border=0 noresize>
<frame src="/pop-src-page.script" topmargin="0" marginwidth=0 scrolling=no marginheight=0 frameborder="no" border=0 noresize>
</FRAMESET>
</HTML>The code in the "dummy" cron.php in the document root looks like this:
<?php
chdir('/usr/local/www/apache22/drupal/');
include('./cron.php');
?>It's purpose is to not expose the real php scripts that are kept out of the document root.
BTW, wget and curl also don't work.
I realize there are other ways of doing this, like for example with 3rd party cron job sites, but I'd like to know why this isn't working in case it affects other things, that might be caused by the cloaking technique mentioned above.
Can anyone tell why this doesn't work but an ordinary browser like Firefox does?
Tnx, Jeff
Comments
Look at the code lynx is
Look at the code lynx is outputting there. You're apparently hosting your site on an IP address, and aliasing your domain name to it via a frame.
Thus, having http://example.com/cron.php won't ever actually trigger your real cron.php, as it never gets that far.
Have it poll your http://68.107.24.241:8082/cron.php URL instead and it'll go just fine.
Fixed, but more questions...
Thanks, that was it!
But I was accessing the cron.php script with Firefox directly, using the alias "example.com" and it worked, so apparently there's a difference in the way FF works VS lynx and curl.
One point I haven't seen mentioned elsewhere with regards to a multi-site setup: Each site has to run its own cron script. In my case I have a common code base and separate databases for each site. This might not be necessary if the database is shared.
Now for the next question - on a presumably related subject...
I noticed that the browser tab (Firefox in this case) does not show the title tag supplied by Drupal - it shows:
http://example.com rather than "Example | Imagine That!". Actually that's both the title and the site slogan - not sure how that happens.
In fact the address bar only shows http://example.com, and never any appended subdirectories. I used the developer plug-in for FF to look at the source code. There are two available under "frame source", one for http://example.com and one for http://68.107.24.241:8082. If you look at the code for the first one it looks like this:
And the first few lines of the second one look like this:
Another interesting quirk is that the favicon never makes it and is probably related as well.
I suspect the way around this problem is not to use the alias domain name in the "C" record, but then the address bar will show the IP address which isn't especially desirable. Either way it's ugly, I guess.
This is all because I'm trying to host several websites from one IP address on my Cox cable connection. Cox as well as many other internet providers of course block port 80, otherwise this wouldn't be an issue since you could just use name based resolving in Apache. I'm using trickery to get around this by implementing IP forwarding in ZoneEdit, with the domain alias, and a separate port number for each site. Then Apache sorts it out according to the port numbers and forwards the traffic to each separate Drupal subdirectory, each with its own settings.php, etc.
It's just weird how Drupal (Garland theme) uses frames like this and the browser sees the meta tags but not the title tag. Hmmm, maybe I'll be forced to drop the alias, not that this will ever be anything close to a production site - just fooling around on the cheap to learn Drupal. Then I'll move the whole shooting match to a real server.
Wish there was another way around this... Jeff
But I was accessing the
lynx and curl do not handle frames. Firefox does. As such, Firefox requests the frame code at http://example.com/, then follows the frame URLs contained within and displays them as the frame code requests. lynx and curl, however, request the frame code and stop. This means the frame URLs - which include your cron.php - are never requested, and thus never triggered.
This has nothing to do with Drupal. There are no frames in the Garland theme. All of the issues you describe are due to the frame-based domain aliasing you're using - presumably through your domain name registrar.