Web server structure?

[John Salerno]

Hi everyone. This isn't exactly HTML related, but I figured you guys
know a lot about *hosting* all that HTML as well!

Anyway, I was wondering what the common practice is for structuring your
directories on your hosting server. Is it still normal to put CGI
scripts in their own directory? Is it better to put everything in a
single directory?

For some things, like images, it seems maybe beneficial to keep them
separate, just to be orderly. But, assuming there are no server/provider
limitations on where you can put things, is it better to put static and
dynamic web pages in the same directory? Does anyone still use a
/cgi-bin directory, for example?

Thanks!

 

[Chris F.A. Johnson]

Hi everyone. This isn't exactly HTML related, but I figured you guys
know a lot about *hosting* all that HTML as well!

Anyway, I was wondering what the common practice is for structuring your
directories on your hosting server. Is it still normal to put CGI
scripts in their own directory? Is it better to put everything in a
single directory?

For some things, like images, it seems maybe beneficial to keep them
separate, just to be orderly. But, assuming there are no server/provider
limitations on where you can put things, is it better to put static and
dynamic web pages in the same directory? Does anyone still use a
/cgi-bin directory, for example?

I use separate directories for things that might be used by pages
in more than one directory, e.g., images, and css. I can link the
directory at different levels, making moving pages around easier.

I do not use cgi-bin for CGI scripts. (I haven't had to do that
since my very first pages in 1996, and shortly after that, that
requirement was removed.)

 

[Jonathan N. Little]

Everyone with CGI or Perl scripts _must use_ the cgi-bin folder to hold
their scripts.

No, not must, but how most hosting companies set the server for security
and server load reasons. Many times the cgi-bin folder is on another
server...

 

[cwdjrxyz]

Hi everyone. This isn't exactly HTML related, but I figured you guys
know a lot about *hosting* all that HTML as well!

Anyway, I was wondering what the common practice is for structuring your
directories on your hosting server. Is it still normal to put CGI
scripts in their own directory? Is it better to put everything in a
single directory?

For some things, like images, it seems maybe beneficial to keep them
separate, just to be orderly. But, assuming there are no server/provider
limitations on where you can put things, is it better to put static and
dynamic web pages in the same directory? Does anyone still use a
/cgi-bin directory, for example?

If you are buying space on some host server, then the host to some
extent determines what you can do. If you own the server and know how
to set it up, then there are more options. For the sake of discussion
I will describe what I do on the server space I rent. The cgi-perl is
included only if you want it. If you opt for it, then you so select on
the control panel and a cgi bin, etc are automatically set up for you
and cgi is turned on. You can also opt to use php, select mime types,
and many other things. If you don't need something, don't turn it on.
Many hacks on servers are done through scripts, etc. You can set up
about as many directories and sub-directories as you see fit - the
main consideration is how well your organization works for you. A
directory can contain just about any type of file. Since server disk
space is now nearly dirt cheap, many now put everything needed for a
html page in the same directory with it, even if this means
duplication of images etc in several directories. Then when you decide
to delete some file in a directory, you do not have to remember that
it may be also be used for some file in another directory. Exceptions
might be huge files, such as video, which you do not want to duplicate
many times. A little care in the names you give directories may help
remember what they contain in the future.

 

[John Salerno]

If you are buying space on some host server, then the host to some
extent determines what you can do.

That's why I mentioned if there were no host-imposed limitations. For my
host, I can install any type of web app into any directory, so I can put
anything anywhere, basically. For example, I don't even have a cgi-bin
directory because Static/CGI is my default for my main folder, so
technically I can put all .html and .py files in this one directory, but
I didn't know if that was considered good practice.

 

[Raymond SCHMIT]

Hi everyone. This isn't exactly HTML related, but I figured you guys
know a lot about *hosting* all that HTML as well!

Anyway, I was wondering what the common practice is for structuring your
directories on your hosting server. Is it still normal to put CGI
scripts in their own directory? Is it better to put everything in a
single directory?

For some things, like images, it seems maybe beneficial to keep them
separate, just to be orderly. But, assuming there are no server/provider
limitations on where you can put things, is it better to put static and
dynamic web pages in the same directory? Does anyone still use a
/cgi-bin directory, for example?

My opinion is to have directories:
cgi-bin
pages
dynpages
pictures
documents
css
scripts
.....anyway, it's up to you ...

 

[John Salerno]

Everyone with CGI or Perl scripts _must use_ the cgi-bin folder to hold
their scripts.

I know that's not true, which is why I asked if anyone still uses a cgi-bin
directory.

 

[John Salerno]

From what others have written, it appears to be a server-set option. I
stand
corrected, but I'll also add that every host I've used required my scripts
to be placed in the cgi-bin folder.

For some reason I was under the impression that everyone was starting to
move away from the whole idea of a separate cgi-bin directory, so it's good
to know that it's still in wide use.

I guess the basis of my question was since both html and cgi files (often)
serve the same purpose (i.e. displaying a web page), it seemed like they
should be in the same directory with one another -- rather than separating
functionally similar files. (Separating CGI files that do only processing
without displaying HTML makes sense, however.)

So assuming there isn't this cgi-bin/server/host/etc. limitation, would it
be better practice to put all these files together? I would think so, but I
was basically checking to see if there was a "right" way to do it.

 

[Bergamot]

I know that's not true, which is why I asked if anyone still uses a cgi-bin
directory.

My usual server sets up cgi-bin automatically. I use it if I need a perl
script.

 

[John Salerno]

The actual executables' permissions are something you have to
be very careful about. You would have to set seperate permissions
for each executable. Best to keep these things in one place where
you can work on them together. The whole folder can also be given
special permissions that further prevent hacking.

That's a very good point, and a good reason to keep things separate! Thanks!

 

[Chris F.A. Johnson]

On 2008-06-24, mbstevens wrote:
....

The actual executables' permissions are something you have to be
very careful about. You would have to set seperate permissions for
each executable. Best to keep these things in one place where you
can work on them together.

A single command with wildcard does the job; there's no need for
them to be in a separate directory:

chmod +x *.cgi

The whole folder can also be given special permissions that further
prevent hacking.

There shouldn't be any write permissions other than the owner on
any directory, so that's not an issue.

 

[John Salerno]

A single command with wildcard does the job; there's no need for
them to be in a separate directory:

chmod +x *.cgi


There shouldn't be any write permissions other than the owner on
any directory, so that's not an issue.

Hmm, more good points. And it seems better to keep them together so you
don't constantly have to maneuver through various directories to get things
done.

 

[Chris F.A. Johnson]

Hmm, more good points. And it seems better to keep them together so you
don't constantly have to maneuver through various directories to get things
done.

It seems better to keep them with the files that they relate to,
rather than stick a bunch of unrelated scripts in an arbitrary
directory.

 

[Chris F.A. Johnson]

On Tue, 24 Jun 2008 17:58:19 +0000, el Chris F.A. Johnson punched in:



Well, with hackers it is. You don't want them to be able to read
your programs, either.

If they're in, they're in. You need the same permissions on a
cgi-bin directory as on the others.

Obviously everyone has to execute them, but
you don't want them to be able to know the details of what is on
the other side of that big black box.

Also, executables often want to interact with each other using
data that you also want to keep private. It just makes more
sense to put all this stuff in a single place where you can
administrate it.

Yes, executables other than the front-end CGI scripts should be
outside the area accessible by the web server.

 

[Raymond SCHMIT]

On Tue, 24 Jun 2008 17:58:19 +0000, el Chris F.A. Johnson punched in:



Well, with hackers it is. You don't want them to be able to read
your programs, either.

I have some php files(and i prefer to keep the content secret) ... did
you think that it's possible to read them instead of executing them a
having only the generated page ?

 

[Raymond SCHMIT]

You can set any permission on any file. The generated page won't
show what is in the script unless you have the script
specifically do so if the permission is set not to allow
global reading.

Do you think that i should set the php page only "x"ecutable ? and
removing the r,w options ?

 

[Bergamot]

You can set any permission on any file. The generated page won't
show what is in the script unless you have the script
specifically do so if the permission is set not to allow
global reading.

The source code will also show if the mime type is set to something like
text/plain.

 

[Raymond SCHMIT]

That depends.
I usually set the cgi directory to drwx--x--x,
and executables inside it to rwxr-xr-x, unless
the scripts themselves need to create/rename/delete
files. YMMV -- a lot depends on how
other things are set up. Do some googling on CGI
security and permissions before doing your setup.

If you don't remove the "r" option ...a hacker will be able to examine
your php coding ? Isn't it ?

 

[Jonathan N. Little]

If you don't remove the "r" option ...a hacker will be able to examine
your php coding ? Isn't it ?

No, if no 'r' then no one would see the webpage. Normally PHP files are

-rw-r--r-- (644)

It is how the webserver is setup, PHP is not execute per se, but a
script that is server processed.(AFAIK you can setup PHP as executable
process but that is not how it is typically done)

If the server is setup properly then you should only see the processed
results, not the source script. That is why you should not use
filenames such as:

checkoutform.inc

for a PHP includea because if the webserver may interpret the file as
plain text and someone could directly access file and see your PHP code.
PHP configured servers are normally setup to identify PHP scripts with
extension '.php' to 'application/x-php'

So it is advisable to end PHP includes with the .php extension.

checkoutform.inc.php
myfunctions.lib.php

It is also customary if you wish to display PHP code as text
intensionally, say for coding examples or library documentation the
extension '.phps' is usually reserved for that purpose.

 

[Raymond SCHMIT]

No, if no 'r' then no one would see the webpage. Normally PHP files are

-rw-r--r-- (644)

It is how the webserver is setup, PHP is not execute per se, but a
script that is server processed.(AFAIK you can setup PHP as executable
process but that is not how it is typically done)

If the server is setup properly then you should only see the processed
results, not the source script. That is why you should not use
filenames such as:

checkoutform.inc

for a PHP includea because if the webserver may interpret the file as
plain text and someone could directly access file and see your PHP code.
PHP configured servers are normally setup to identify PHP scripts with
extension '.php' to 'application/x-php'

So it is advisable to end PHP includes with the .php extension.

checkoutform.inc.php
myfunctions.lib.php

It is also customary if you wish to display PHP code as text
intensionally, say for coding examples or library documentation the
extension '.phps' is usually reserved for that purpose.

Thanks a lot ! Well documented answer.