Used the script installer to install Drupal to a virtual server. The install went well. When I browsed to the site I recived an error = internal server error. After some checking around found that the htaccess file installed with Drupal was causing this problem. I am not sure yet what in the htaccess file is causing this. Renamed the htaccess file and browsed to the site. If this is the first time to access the site the default setting.php will be read and gave an error. After checking I found that in the /sites/default/settings.php file that the $base_url = 'http://xxx.xxx/' was present. After reading the documentation removed that trailing / in the url and the problem was corrected.
I know these are minor things but they can cause some clients to be upset when they went to the site for the first time to set it up.
I need find out what in the htaccess file is causing the error. Any one have any suguestions?
The other error can be corrected in the installer script?
Hey Kevin,
Thanks for the head's up, and excellent sleuthing of what is wrong. I'll open a bug so Jamie can correct the problems you've found, and I'll look into the htaccess file so see what's going amiss.
--
Check out the forum guidelines!
Hi Kevin,
Check the ~/logs/error_log file for the virtual server or the global Apache error log for details on what entry in the .htaccess file is causing the problem. I could easily have Virtualmin remove that file automatically, but it seems to contain some configuration entries that are important to Drupal..
I will fix that base_url problem in the next release though.
--
Check out the forum guidelines!
Joe,
I did some checking and found that the error was /home/xxxx/public_html/.htaccess: Options not allowed here.
Found that in the /etc/httpd.conf file at line 149 on my system that AllowOverride none is set. When the system tries to overide the options set in the .htaccess file they are not allowed. I placed into the
/etc/apache2/vhosts.d/xxxx.xxx.conf
<@Directory /home/xxxx/public_html>
AllowOverride Options
Options Indexes IncludesNOEXEC FollowSymLinks
allow from all
<@/Directory>
The @ sign used to keep your system form thinking this was code to run. It is not present in the file.
This cleared the error.
The second thing I had to do was in the /etc/sysconfig/apache2 file was add the rewrite module to the APACHE_MODULES statement.
This cleared up the problem with using the rewrite rules in the .htaccess file.
So far I have not seen any problems with this configuration.
What are your thoughts on this?
Joe, Jamie,
Got ahead of my self in the above post (read my notes wrong) When the AllowOverride is set to optons I get the following error in the domain error log: /home/xxxx/public_html/.htaccess: order not allowed here.
I set the AllowOverride to All and the problem went away. I know that this setting is wrong and will have to look futher into the .htaccess file for the flags that need to be set to limit the script to only what it needs to run.:-(
Just wondered if this points out a possible improvement in the script installer system. The script installer needs to be aware of what apache config and php config a script might require, and then be able to implement those config changes. It should then be able to detect if other scripts are compatible with those changes, and not install conflicting scripts.
I guess the system can leave configuration options which the user can change upto the user, but if its apache or php settings that need changing then the user can't do that without admin intervention.
However the system would have to be trusted enough to make unattended changes to httpd.conf without breaking it.
Just some thoughts, that you've probably already had ;)
Hey Chris,
I agree, and we do actually have that kind of thing in place to some degree (and it is entirely possible to check everything that Webmin knows about--which is probably everything of relevance). There are already checks in some or all of the scripts for php version and availability, website configuration, SSL availability, etc. I believe Jamie also added a couple of checks for PHP options for some of the scripts (which require compatibility options to be enabled, for example).
In this case, it's probable that the include file would actually need to be added to the script in some form, rather than doing whatever it takes to make it include'able by the user--that way it could go right into the httpd.conf file (but in a way that we control it, so that security holes aren't opened by outside code).
We're still learning the ropes of some of these scripts. Some require a lot of hand-holding to work. Please keep hollering when things don't work right!
--
Check out the forum guidelines!