Site file organization

bradcathey has asked for the wisdom of the Perl Monks concerning the following question:

I'm reorganizing an entire site that uses a simple content manager that I developed with Perl, HTML::Template, the MS DHTML Editing Component, and MySQL. At the risk of this being OT, my question is where to put everything to keep the file tree as clean as possible, make it easy to maintain, avoid confusion in paths to things, be secure, and generally be a smart monk. Here's what I have planned:

   ROOT DIR--+
             |
          CGI-BIN-----+
             |        |
             |   single Perl script that handles
             |   all input and DB maintenance
             |   
          TEMPLATES---+
             |        |
             |   all page .tmpl's
             |   and editor.tmpl
             |
          ADMIN-------+  (protected)
             |        |
             |    index.html (calls admin scripts)
             |
          index.cgi (calls loader.cgi?pg=index)
             |
          loader.cgi (fetches content from db and displays tmpl)
             |
          data.txt (db connect info--needs to go in secure dir)
             |
          external.js (for various javascript)
             |
          external.css
[download]

Comments? TIA.

Update: Added ADMIN directory

—Brad
"A little yeast leavens the whole dough."

Comment on Site file organization Download Code

Replies are listed 'Best First'.
Re: Site file organization by b10m (Vicar) on Jan 31, 2004 at 20:12 UTC
The only thing I really have to comment on is this line: data.txt (db connect info--needs to go in secure dir) I'm not sure what you mean with "secure dir", but I take it you put some data in that file that shouldn't fall into wrong hands. Please note that something like this is really hard to really secure, if there are other users on the system this site runs on. Your http daemon probably runs under some user account with few permissions (nobody, or www, or whatever), but somehow, that user is supposed to be able to read that file. Another user on that machine can do the same (write a little Perl CGI app. that opens and prints the file contents). This is quite a big problem, for which I haven't really seen good solutions besides using things like RSBAC¹ (Linux). This all may not be appropriate for your specific case, but probably worth mentioning. -- b10m ¹ please note that up to now, I still have been too lazy to plunge into reading up on RSBAC, and thus this might not even solve the problem ... All code is usually tested, but rarely trusted.	[reply]
Re: Re: Site file organization by abell (Chaplain) on Feb 01, 2004 at 09:02 UTC
By using suexec you can have apache run CGIs as the user owing them. If you chmod 600 (-rw-------) the files containing the configuration data, no other user should be able to access them (apart from root). Cheers Antonio The stupider the astronaut, the easier it is to win the trip to Vega - A. Tucket	[reply]
Re: Re: Site file organization by bradcathey (Prior) on Jan 31, 2004 at 20:51 UTC
b10m, I knew that file and explanation would raise eyebrows around the monastery. I am trying to avoid hard coding the dbi connect info into my scripts. I thought about encoding it somehow and having the scripts decode it as it is read. Thanks for the caution which underlines my original reservations. We'll see if another monk as advice, but in the meantime, I'll look at RSBAC. Update: In surfing CPAN I found Crypt::Blowfish and Crypt::CBC that seem to do a good job of what I need--I think. —Brad "A little yeast leavens the whole dough."	[reply]
Re: Site file organization by valdez (Monsignor) on Jan 31, 2004 at 22:57 UTC
I like how *unix file systems are organized, they have a place for everything: `server_root/bin etc htdocs lib tmp var/logs sessions templates` [download] You have a place for your shell scripts (bin), it should not be accessible to web users; I keep there some script to tail error logs or to access database. Etc is the place for configuration files. All static documents, and may be cgi scripts, live under htdocs; every piece of software or data that you want to keep private should be outside of htdocs. Lib should contain all of your libraries and var is the place for logs, sessions, templates and other variable data. I don't see why you need to make TEMPLATES accessible to every one, are you planning to protect them? Are you also planning a place with restricted access with administrative scripts and data? HTH, Valerio	[reply] [d/l]