Da Does Not Have A "normal" Ssi Environment

[TMC]

DA does not have a "normall" SSI environment

• Claim: the default configuration of Direct Admin does not provide a "server-wide normal SSI environment".
  
  Now that we have your attention, this is an advance apology for making the sweeping generalization above. We're very much aware that a number of overlapping issues are to blame for this long-standing problem. Numerous existing forum threads can be found here and on other boards which discuss partial problems and partial solutions.
  
  What we're very specifically trying to do here is to create a SINGLE forum thread which clearly and unarguably documents DA's default SSI configuration. More importantly we seek to document the absolute and unequivocal solution to the specific SSI problem illustated below, so that inexperienced DA customers such as ourselves can resolve it! **NO** OFF-TOPIC POSTS please.
  
  Here are two initial examples which we offer for comment and diagnosis. As you can see we have installed the same set of files with the same permissions (644) on two different servers (one without DA and one with DA). Feel free to copy and test on your own server.
  
  EXAMPLE #1: "NORMAL SERVER-WIDE SSI ENVIRONMENT (NON-DA SERVER)"
  http://www.suttonweb.com/ssitest.htm (this is the test script; it runs correctly here)
  http://www.suttonweb.com/ssitest.htm_source.txt (this is just for your reference)
  http://www.suttonweb.com/htaccess_source.txt (this is just for your reference)
  http://www.suttonweb.com/phpinfo.php (4.3.9 just for your reference)
  
  EXAMPLE #2: "ABNORMAL SERVER-WIDE SSI ENVIRONMENT (DA SERVER) WITH DEFAULT PERMISSIONS"
  http://www.wlys.com/ssitest.htm (this is the test script; it does NOT run correctly here)
  http://www.wlys.com/ssitest.htm_source.txt (this is just for your reference)
  http://www.wlys.com/htaccess_source.txt (this is just for your reference)
  http://www.wlys.com/phpinfo.php (4.3.8 just for your reference)
  
  Some possibly relevant info common to both servers:
  The default virtual root folder ("public_html") permissions are active ("750").
  The default virtual cgi-bin folder ("public_html/cgi-bin/") permissions are active ("755").
  The .htaccess files and individual file permissions are identical on both servers.
  We do not have root on the NORMAL server, but we do have root and DA admin on the ABNORMAL server.
  
  Questions:
  
  [1] Using the NORMAL server, why does http://www.suttonweb.com/ssitest1.php work with
  permissions 644? (see http://www.suttonweb.com/ssitest1.php_source.txt for the source code)
  We assume it should not because there is no Exec permission on the file.
  
  [2] Using the ABNORMAL server (with DA), why does http://www.wlys.com/ssitest1.php work with
  permissions 644? (see identical source http://www.wlys.com/ssitest1.php_source.txt)
  Again we assume it should not because there is no Exec permission on the file.
  
  [3] Using the NORMAL server, why does http://www.suttonweb.com/cgi-bin/ssitest1.php work with
  permissions 644? Again there is no Exec permission on the file.
  
  [4] Using the NORMAL server, why does http://www.suttonweb.com/cgi-bin/ssitest1.php_source.txt
  generate an error? It has the same permissions as item [3] which works fine.
  
  [5] Using the ABNORMAL server (with DA), why does http://www.wlys.com/cgi-bin/ssitest1.php
  generate an error? (see item [3] which works without error, also
  http://www.wlys.com/ssitest1.php_source.txt for the identical source)
  
  [6] Using the NORMAL server, why does http://www.suttonweb.com/ssitest.htm work, but using the
  ABNORMAL server (with DA), http://www.wlys.com/ssitest.htm does not? (see
  http://www.suttonweb.com/ssitest.htm_source.txt or http://www.wlys.com/ssitest.htm_source.txt
  for the identical sources)
  
  Please do not hesitate to identify any "obvious" errors in the above claim and/or examples. Also if you believe any information is missing please state what and why!
  

 

[matrixx]

1. Wierd that you felt you had to make people jump through this thread before trying to help you - any particular reason?

2. I think it's the way that the header tags on the includes are parsed - have you tried knocking out the <?php tag from the include?


Rob

 

[TMC]

Interesting Logic

• Thanks for the prompt reply, Rob.

  1. Wierd that you felt you had to make people jump through a hoop and click on another new thread before trying to help you.

  As you may have noticed, the DA Forum unfortunately provides three separate categories: User-Level Difficulties, Reseller-Level difficulties, and Admin-Level Difficulties. Because this problem applies to all of these categories, we felt it best not to cross-post the entire thread. Apart from which there were zero replies to this thread until we created a link to it from one of the other categories

  2. I think it's the way that the header tags on the includes are parsed - have you tried knocking out the <?php tag from the include?

  Please explain your conjecture in more detail. Are you suggesting the DA server does not support legal PHP syntax whereas the non-DA server does?

 

[matrixx]

Hey - I dunno whats legal and whats not - not my dept! - BUT I found it worked for me - but give it a go and see if it works or not!

Rob

 

[TMC]

• Ok, the include statements still generate errors and the included files no longer execute at all when invoked on their own (hardly surprising as they no longer contain the legal syntax needed by PHP).
  
  Please post your working solution sources and we will install them!

 

[matrixx]

ok - when I get a mo I'll look into it more - there maybe others that beat me to it

Rob

 

[matrixx]

ok I've had a quick look,
Example 1 & 2 are .htm files with php includes - I'm unsure if you can get away with this.

When you get to the questions you switch to php extensions with php includes (I think although I can't see the links to them to check)

Basically it seems like you're giving 2 examples and then asking questions based on something else.

Sorry if I don't understand or got this wrong but it's just not clear enough for me.

An obvious question but do you have php enabled for the users account?

Rob

 

[TMC]

Maybe DA just can't handle Server Side Includes

• Hi again Rob. Hopefully you're not at work on a Sunday?

  ok I've had a quick look, Example 1 & 2 are .htm files with php includes - I'm unsure if you can get away with this.

  No. You are mistakenly interpreting SSI includes as PHP includes. There is no connection between the two, and there is nothing to "get away with". If you are not familiar with how SSI can be enabled within HTML files, please view the well-commented .htaccess sources (links are provided, just click them). Keep in mind that Example 1 and Example 2 are identical HTML files, and they both work 100% on all other Apache servers EXCEPT a DA Apache server. Hence our need for posting these questions in the first place!

  When you get to the questions you switch to php extensions with php includes (I think although I can't see the links to them to check)

  No. Look closely at all of the source files. There are no PHP includes anywhere in any of our examples. Yes you can easily see the SSI links which work correctly without DA but fail with DA, that's why we provided source files you can view on-line (please just click on them).

  Basically it seems like you're giving 2 examples and then asking questions based on something else.

  No. Please invoke the HTML SSI test script on each server, then read the questions carefully.

  Sorry if I don't understand or got this wrong but it's just not clear enough for me.

  Not a problem, few people have a good understanding of SSI because it's popularly (and wrongly) viewed as a 'low-tech' scripting environment. Thanks for copying the examples to your DA server.

  An obvious question but do you have php enabled for the users account?

  Please explain the technical basis of your question. Are you suggesting the individual PHP example scripts on the DA server (provided above) would continue to execute correctly (as they do now) if PHP was disabled?

 

[matrixx]

Working on a Sunday? As a hosting company we work 24/7/365 ! - I personally get a day off each week though - which I believe everybody needs!

EDIT: Hey - have you saved the parent pages as SHTML ? Looks like just HTM to me which won't work either.

Look, I use ssi's in our designs and they work on and off DA boxes just fine.

If there was a big SSI problem with DA I think it probably would have been spotted a while back - and as all the SSI's we use work (php and shtml) work then I'm sure it's probably the code you're using.

But frankly there is so much info posted here, all seemingly inter-woven that it gets jumbled in my tiny mind

If you want ME to look at it any more then you'll need to simplify your question.

Rob

 

[fusionictnl]

Ok I took a look at you're sources you're problems occur when calling a PHP script, that is placed in a CGI-BIN directory.

Why use CGI-BIN dir ?? Running PHP as CGI ??? Just using the public_html will do the trick, but ok when configured correctly you're right it should work.

Does you're CGI-BIN dir have a .htaccess file ?? (Maybe it doesn't allow php after it )

Furthermore, this works on my DA server.

Some things you could take in mind:

- PHP Safe mode ? enabled ??
- I use apache2 and PHP 5

Please don't post like these posts anymore just asking for help does the trick. As you're pointing out to DA having a problem in their SSI enviroment, but do you have several DA servers with different configurations and having them all generating the same problem ?? Probaly not, so don't be too fast at pointing the problem directly to DA.

Edit: On my other DA server it doesn't work.. I have a lot of customations on my primary DA server so I will look in the matter to see where the problem resides.

 

[fusionictnl]

Ok I've found the problem

Due to my customations I couldn't see where to start, but offcourse it was simpler than I thought

Do a command on you're server:

httpd -l

This shows a list of load modules in HTTPD (Apache)

There should be a module called mod_include. This enables SSI in apache. Standard this is not specificaly ON (apache 2) Apache 1.33 Does have the .so, but doesn't has the LoadModule statement, wich you should add

And put the mod_include.so,c,o etc. to the /usr/lib/apache/ and Add the handler. Sorry don't have a server running 1.33 only 2 :s So can't make a howto.

Furthermore I will look if the problem really is this, but this is one of the missing parts

I will try to find out howto make it work and write it in this thread. (HowTo) For Apache 2, could work for 1.3 either.

 

[fusionictnl]

Update: Mod_include is "build-in" apache 2

 

[fusionictnl]

Ok I'll gues that using Apache 1.3 it all could work. As for Apache 2 most of the commands aren't working at all. :s So my symptoms are completly different as if I used 1.3.

 

[fusionictnl]

Overlooked a small thing in the .htaccess.

I've got all working now, with the following .htaccess as specified by apache.org:

AddType text/html .shtml
AddOutputFilter INCLUDES .shtml
Options +Includes

Created a .shtml file:

<!--#include file="test1.shtml"-->
<!--#include virtual="test1.shtml" -->
<!--#include virtual="/cgi-bin/test-cgi" -->
<!--#config timefmt="%A %B %d, %Y" -->
<!--#flastmod file="test1.shtml" -->

And they all work

 

[TMC]

Glaedelig Jul

• Hi fusionictnl
  
  Many thanks to you for all the detailed information. Sady today is a busy work day so it will take at least 12 hours before we can start testing your recommendations!

  Why use CGI-BIN dir ?? Running PHP as CGI ??? Just using the public_html will do the trick, but ok when configured correctly you're right it should work.

  We are new to running both DA and running remote dedicated servers (which is what our DA server is) and maybe this is the biggest problem! A long time before DA was invented we were taught ALL scripts must be located securely inside the CGI-BIN folder. Maybe this is not true in 2004? Are you saying it's not correct to run PHP scripts in CGI-BIN??

  Does you're CGI-BIN dir have a .htaccess file ?? (Maybe it doesn't allow php after it )

  None of our CGI-BIN folders contain any .htaccess file (same on the DA server and on the the Non-DA server). But PHP works fine inside the CGI-BIN of the non-DA server!!! Please explain if this is good or bad or what is better or what does not please you?

 

[fusionictnl]

It's not bad But I don't know if you need to add an extra .htaccess in this dir. I think it does need it. Why? Because it's a special dir and will overide the .htacces in you're main public_html dir. So You will probably solve the issues by just creating a .htaccess as I specified above.

 

[nobaloney]

Re: Glaedelig Jul

A long time before DA was invented we were taught ALL scripts must be located securely inside the CGI-BIN folder.

Note that I've not responded earlier because your post was so long and complex and full of examples that there wasn't just one or two places to click to see a problem. Like many of us, I don't have enough hours in any day to follow such complex issues on my own time; I work for my clients.

Let me point out before I start that I'm NOT a web-programmer; I'm a systems administrator and I've been locking down public webservers since 1994; for approximately ten years.

I have available programmers on staff should it be necessary to hire one to resolve the problem.

However I think it should be easily resolved (if you really want to do what you're doing) with some changes to httpd.conf.

I still can't tell if you're trying to run .htm or .html from your cgi-bin or not.

I believe that a properly configured apache server does NOT allow that by default.

I also cannot tell if you're trying to run .php from your cgi-bin or not.

I believe that a properly configured apache server does NOT allow that by default, either.

See this section in your /etc/httpd/conf/httpd.conf file:

    # ScriptAlias: This controls which directories contain server scripts.
    # ScriptAliases are essentially the same as Aliases, except that
    # documents in the realname directory are treated as applications and
    # run by the server when requested rather than as documents sent to the client.
    # The same rules about trailing "/" apply to ScriptAlias directives as to
    # Alias.

Also see the documentation for the Apache AddHandler directive.

Because I haven't taken the time to try everything in your overly long posts, I apologize in advance if I'm not targeting your problem correctly.

Jeff

 

[fusionictnl]

He has a problem with SSI

Not ScriptAliasses It's indeed a long post of the problem

 

[mike_p]

[1] , [2] & [3]The exec bit controls the handling of files by the operating system. With a .php file, PHP reads the file and processes the contents. With a .cgi file the operating system attempts to execute it directly. Since PHP merely reads the file, isn't affected by the Exec bit.

[4], [5] & [6]It is normal to configure APACHE such that: the cgi-bin assumes that all files within it are CGI executables and will attempt to execute them. If it cannot execute a file, it throws up an error. It is possible to override this.

The settings for the CGI-BIN behaviour may be set in the httpd.conf ( as opposed to an .htaccess file).

Your overall question is a red herring. This problem has nothing to do with SSI working, but a lot to do with CGI-BIN configuration.

My recommendation to you would be to place your PHP scripts anywhere except the CGI-BIN.

Hope this helps

 

[mike_p]

Also

A long time before DA was invented we were taught ALL scripts must be located securely inside the CGI-BIN folder.

No. You should have been taught that CGI executables should be located in the CGI-BIN.

Personally I configure my servers to allow CGIs to run anywhere. It helps the logical organisation. ( I also use a lot of PHP as CGI scripts)