🚀 go-pugleaf

I do not know what your problem is, but I also used to use .shtml files and
had some problems with a program I used to use.  I finally converted the
site to .html files and added this to my .bhtaccess

AddType text/x-server-parsed-html .html


I have no idea if this will help, but it might be worth a shot.

Derek

: Hello,

: Previously to now I have assumed best.com offers no limits to what
: I can do with web design. Well of course that got shattered when I first
: touched SQL and realized I want to redo my whole site with SQL and if
: they have that here then I could probably skip most of this. :)

: The problem is...

: I upgraded my website here (www.clandenial.org - it's a Highlander thing)
: this weekend, to put in a centralized links program. I have many pages 
: in my site and they all have this list of links on the left side. Imagine
: changing that list every now and then? For instance yanking the awards
: and webrings information off the front page and making a separate
: department for them all, would require updating every page with link
: information (for consistency's sake). To simplify this I made a CGI that
: outputs those links and all pages call upon it. One cgi script does the
: work for many pages. Now I can get on with the upgrades!

: Problem...wwwboard won't put up with this. First I noticed I could not call
: the links.cgi (as I'll call it here) from it; it would print the code that
: calls the file instead. (eek!) This also messed up my Trivia page. So I
: zapped references to links.cgi from there and sucked down the realization
: that the "post results" page would have no links (and so would the trivia
: score results page). The rule obviously is that a CGI cannot run another
: CGI (I think).

: Then I encountered a more sinister problem. wwwboard.cgi was writing .shtml
: files so as to let them call links.cgi so no matter where I moved things,
: if you view a post, you can jump out of the wwwboard to any spot in my
: site. (Standard functionality in my book.) BZZZZZZZZZT. A cgi creating
: .shtml with the userid of the web server = "404: File Not Found/url is not
: found or is insecure". That's the error I got whenever I tried to lynx to
: that shtml file remotely. When I changed the suffix back to .html, it
: worked, but of course I had to strip the CGI references out.

: Is this basically it? Is there a go-around to this problem? I had
: envisioned writing a CGI that would wrap the whole site...serving all the
: pages centrally and allowing me more simplification and also allowing for
: troll control. :) But if a CGI cannot call another...and a cgi cannot
: create a .shtml file...that's pretty much DOA. How would I handle this?


: -- Steve


-- 
Derek Beda
derek@anxst.com
Web Comics & Babylon 5 Fan Fiction: http://www.anxst.com/
Mailing Lists: b5-creative@lists.best.com & b5-speculation@lists.best.com

In article <avm-1511981841480001@avm.vip.best.com>, avm <avm@best.com> wrote:
>Best is not stopping you installing an SQL DB engine on your shell machine.
>I have mSQL, and so do other people. There's a limit to number of simultaneous connections to 64. mSQL or mySQL, possibly Postgress also. Not sure if this runs on freeBSD tho. Why not go grab a copy and try it @ : http://www.mysql.com/
>There's also a lite-weight perl SQL module called sprite, available from CPAN.

I wouldn't say they're stopping anything; I always assumed SQL is about a
client (the web page?) accessing a constantly running server. I assumed
even if best allowed such a thing the cpu cycle usage would be
prohibitively high. Then again my experience comes from ASP/Access. I
wouldn't be surprised if unix is a whole new rule. I'd rather continue my
learning in unix. :) Thanks for the info!


-- Steve

In article <72nlcp$q3t$1@shell3.ba.best.com>,
remove DONTSPAM to reply <paladinDONTSPAM@best.com> wrote:
>Is this basically it? Is there a go-around to this problem? I had
>envisioned writing a CGI that would wrap the whole site...serving all the
>pages centrally and allowing me more simplification and also allowing for
>troll control. :) But if a CGI cannot call another...and a cgi cannot
>create a .shtml file...that's pretty much DOA. How would I handle this?

For the things you've described, I don't see any reason to call a
CGI each & every time the page is needed.  All you want is to be
able to update some templates and have all of the pages updated.
You should be doing this with script(s) on the command line ("back
end processing"), so that whenever you update a template, the script
rebuilds all of the relevant files.  Then you run it only when you
change something, and the rest of the time you are getting the good
performance of static pages.

Besides the very legitimate security concerns (of course, that's
the reason for the prohibition on cgis writing other cgis), Best
is doing you a favor by making you do this right.  Running a program
on every hit for something which changes relatively rarely is very
poor design.

In article <72putr$l2$1@machaut.medieval.org>, Todd Michel McComb <mccomb@medieval.org> wrote:
>In article <72nlcp$q3t$1@shell3.ba.best.com>,
>remove DONTSPAM to reply <paladinDONTSPAM@best.com> wrote:
>>Is this basically it? Is there a go-around to this problem? I had
>>envisioned writing a CGI that would wrap the whole site...serving all the
>>pages centrally and allowing me more simplification and also allowing for
>>troll control. :) But if a CGI cannot call another...and a cgi cannot
>>create a .shtml file...that's pretty much DOA. How would I handle this?
>
>For the things you've described, I don't see any reason to call a
>CGI each & every time the page is needed.  All you want is to be
>able to update some templates and have all of the pages updated.

Right. And in my presumed perfect mastery of CGI and html coding, I thought
I'd had the right technique. Alas a blemish! :) I like having the total
dynamic and maintenance free nature of CGI, but apparently there are
possibly better ways and I'm all up for exploring them.


>You should be doing this with script(s) on the command line ("back
>end processing"), so that whenever you update a template, the script
>rebuilds all of the relevant files.  Then you run it only when you
>change something, and the rest of the time you are getting the good
>performance of static pages.

That was the thing I was trying to avoid: the extra effort of running a
script to update stuff. Apparently the way to avoid it is to accept the
extra setbacks of much higher CPU usage, possible security holes, and loss
of functionality. Oh well. I guess that's how it goes. Your way looks
better.


>Besides the very legitimate security concerns (of course, that's
>the reason for the prohibition on cgis writing other cgis), Best
>is doing you a favor by making you do this right.  Running a program
>on every hit for something which changes relatively rarely is very
>poor design.

Oh come on now what about all the /<-rad coding that has to go in to make
it work in the first place? Only a true genius could swing that muhahaha!
Why do things the quicker and simpler way when you can show everyone how
you toiled and labored over it? :)

Oh well. I guess I'll just have to accept the non-Einstein path of using
includes. The real issue with that is, if I use <!--#include --> to pick up
raw text, that means I have to use absolute address
(http://blah/file.html versus "../../file.html") references. The include
file will require a mass "sed" operation if the site moves anywhere. Thank
God I can still centralize this.


-- Steve

    It should be possible to construct CGI's which write other CGI's or
    ssi, but they would have to be suid.  BestWWWD's restriction is that
    it will refuse to execute cgi's or ssi's from group or other-writable
    directories, or cgi's or ssi's owned by 'nobody', verses your user id.

    If you write a suid CGI, then the files you create are owned by you
    rather then 'nobody', and you can create them in directories owned by
    you that are not group-writable.  BestWWWD has no problem with that.

						-Matt

-- 
    Matthew Dillon  Engineering, HiWay Technologies, Inc. & BEST Internet
                    Communications
    <dillon@best.net> (Please include original email in any response)

In article <72tbas$d80$1@flea.best.net>, Matt Dillon <dillon@best.net> wrote:
>It should be possible to construct CGI's which write other CGI's or
>ssi, but they would have to be suid.

Yes, of course, but for many of the queries raised here, a Makefile for
the whole website is the perfect solution on all levels.  I want to keep
saying so until people believe me.... :-)

In article <avm-1711982019140001@avm.vip.best.com>, avm <avm@best.com> wrote:
>A script with embeded boilerplate html that reads in content from
>a flat file DB or DBM, would do it. you could gen and re-generate,
>thousands of pages quickly like that. I've done this before. You
>would only have to run it once when you modify any data. No CGI
>involved at all.

Yes, that is exactly the idea.  If your underlying data/files are
not that complicated or extensive, as most websites aren't, then
there is little need for the real DB backend.  The "source" files
can be combined in a straight-forward way.  Likewise, "make" has
the built-in capcity to update only those files which need to be
updated when a source file changes.  I do all my updates incrementally
in this way, instead of regenerating the whole site, not only
because it takes fewer computer cycles, but because it gives me a
good "update trail" in the timestamps on the files.

In article <72suq6$ims$1@shell3.ba.best.com>, paladinNOSPAM@best.com (you know the drill!) wrote:

>(http://blah/file.html versus "../../file.html") references. The include
>file will require a mass "sed" operation if the site moves anywhere

Chances are you'll have to change more than just the pathnames
if you move docs with SSI's to another server. The SSI syntax
tends to be different with different servers (e.g. Bestwwwd and
Apache). Not dramatically different -- but enough to require
a bit of work.

-- 
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Malcolm Hoar           "The more I practice, the luckier I get". |
| malch@malch.com                                     Gary Player. |
| http://www.malch.com/               Shpx gur PQN.                |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Todd Michel McComb <mccomb@medieval.org> wrote:
> In article <avm-1711982019140001@avm.vip.best.com>, avm <avm@best.com> wrote:
>>A script with embeded boilerplate html that reads in content from
>>a flat file DB or DBM, would do it. you could gen and re-generate,
>>thousands of pages quickly like that. I've done this before. You
>>would only have to run it once when you modify any data. No CGI
>>involved at all.

> Yes, that is exactly the idea.  If your underlying data/files are
> not that complicated or extensive, as most websites aren't, then
> there is little need for the real DB backend.  The "source" files
> can be combined in a straight-forward way.  Likewise, "make" has
> the built-in capcity to update only those files which need to be
> updated when a source file changes.  I do all my updates incrementally
> in this way, instead of regenerating the whole site, not only
> because it takes fewer computer cycles, but because it gives me a
> good "update trail" in the timestamps on the files.

A related approach is to prototype the site using .shtml, then arrange
to "snapshot" the .shtml into .html files, making the latter visible
to the world. If you set up a makefile, you can do incremental updates.

http://www.best.com/~dws/tools/ssi is a Perl5 script that simulates
server-side-include processing, translating .shtml into .html. It
supports #include, #exec, and a number of date formats.

Dave
____________________________________________________________________________
Dave W. Smith          mailto:dws@best.com          http://www.best.com/~dws

In article <72tbas$d80$1@flea.best.net>, Matt Dillon <dillon@best.net> wrote:
>    It should be possible to construct CGI's which write other CGI's or
>    ssi, but they would have to be suid.  BestWWWD's restriction is that
>    it will refuse to execute cgi's or ssi's from group or other-writable
>    directories, or cgi's or ssi's owned by 'nobody', verses your user id.
>
>    If you write a suid CGI, then the files you create are owned by you
>    rather then 'nobody', and you can create them in directories owned by
>    you that are not group-writable.  BestWWWD has no problem with that.

Hmmm. I'll add that as an option. Right now this impasse is giving me a
chance to stop and take a look at how I do CGI and review the new
technologies that are out there. As I said I prefer a non-proprietary
design. Is there a way to set up a BestWWWD style server on my Linux
development machine and design a whole site there and test it before
bringing it online? If I use best.com's proprietary add-ons I have to do it
live (and let all the users see the bugs :), or copy the site (doubling my
disk usage) and work on a backup...running up my web usage. (That and I
prefer the instantaneous loading of pages on a local test server.) Thanks.


-- Steve

In article <36526516$0$12779@nntp1.ba.best.com>, Dave W. Smith <dws@shell3.ba.best.com> wrote:
>
>A related approach is to prototype the site using .shtml, then arrange
>to "snapshot" the .shtml into .html files, making the latter visible
>to the world. If you set up a makefile, you can do incremental updates.
>
>http://www.best.com/~dws/tools/ssi is a Perl5 script that simulates
>server-side-include processing, translating .shtml into .html. It
>supports #include, #exec, and a number of date formats.

Interesting...I should check this out. I'm not too keen on new technology
as it invites proprietization and thus cross-platform incompatibility, At
least this sounds like it doesn't invite such a problem.


-- Steve

In article <364fb1d0$0$12764@nntp1.ba.best.com>,
Derek Beda  <beda@shell11.ba.best.com> wrote:
>I do not know what your problem is, but I also used to use .shtml files and
>had some problems with a program I used to use.  I finally converted the
>site to .html files and added this to my .bhtaccess
>
>AddType text/x-server-parsed-html .html
>I have no idea if this will help, but it might be worth a shot.

Nope, that won't help Steve's problem at all.

1) If a CGI script that processes forms creates a file, the file has
   to be in a directory that is writeable by "nobody".  (This is how
   a lot of wwwboard scripts work.)
2) If you have a CGI script that resides in a writeable directory,
   the web server refuses to run it: "document is insecure".
3) A *.shtml file in a writeable directory is also insecure.

Therefore a bboard script should only write out plain files (*.txt) and
plain HTML files (*.html).

There is a way around this problem.  Don't put html files in the writable
directory.  Instead, write data files that require a CGI script to display
them.  When the display CGI comes across an HREF in the data file, it
needs to rewrite the HREF so that it uses the display CGI with appropriate
arguments.  For instance, rewrite
  <A HREF="105.msg">prev</A> <A HREF="107.msg">next</A>
as
  <A HREF="disp.cgi?105.msg">prev</A> <A HREF="disp.cgi?107.msg">next</A>.

To see what I'm talking about, go to
http://www.inwap.com/img/index.cgi?pawprint.gif
and notice how the "prev" and "next" hyperlinks are set up.

If you do it this way, disp.cgi needs to be in a non-writeable directory
and the data files can be kept in a hidden writeable directory
(such as "data/*.msg").  The outside world would not even know that
the "data/" diretory exists; disp.cgi would be all that is visible.
	-Joe

-- 
INWAP.COM is Joe and Sally Smith, John and Chris O'Halloran and our cats
See http://www.inwap.com/ for PDP-10, "ReBoot", "Shadow Raiders"/"War Planets"

In article <72vbia$8rc$1@shell3.ba.best.com>,
remove "NOSPAM" <paladinNOSPAM@best.com> wrote:
>Is there a way to set up a BestWWWD style server on my Linux development
>machine and design a whole site there and test it before bringing it online?

That's what I do.  I have the Apache server running on my Unix box at home
with one tiny modification: I made "#counter" doe exactly the same thing as
"#include" so that <!--#counter file="index.count"--> would at least output
something.  Changes are made on the home machine, then copied (via rdist) to
the Best machine daily.  I also have a cron job to keep the .htaccess file
at home updated from selected portions of the .bhtaccess file at Best.
	-Joe
-- 
INWAP.COM is Joe and Sally Smith, John and Chris O'Halloran and our cats
See http://www.inwap.com/ for PDP-10, "ReBoot", "Shadow Raiders"/"War Planets"

In article <7353d8$89s$1@shell3.ba.best.com>,
Smith and O'Halloran <inwap@best.com> wrote:
>Changes are made on the home machine, then copied (via rdist) to
>the Best machine daily.

You should switch to rsync... faster updates and easy to run over ssh.