What should fp 6.0 look like?

[Fairlight]

Only Kenneth Brody would say something like:
> Fairlight wrote:
> [...]
> > IIS 6.0 is your only
> > choice on Win2K3.  IIS 6.0 does not support drive letters, and -requires-
> > UNC syntax. filePro will not work in a web-enabled environment with
> > -anything- under that kind of environment.  Anyone migrating upwards might
> > want to bear that in mind.  And I didn't see it in the 5.0.14 feature
> > additinons.
> 
> I guess you haven't seen the 6.0 features list?  (Remember, there is
> virtually no difference between Windows' UNC names, and *nix's path
> names, and filePro already uses that under *nix.)

Last I heard, y'all were shooting for 5.1, not 6.0.  But okay...

And actually, that won't stop a person or two who already need it -now-
from leaving in short order--well before 6.0 might ever see the light of
day.  If it's so easy to implement, it should have gone into 5.0.14.  It
would probably have saved you at least one or two customers that are
trying to move entirely to win2K3 and are screwed in this area.  

> [...]
> > Actually be polite and DIE OFF when your parent processes have received a
> > signal (HUP, TERM, INT, etc.), instead of hanging around.
> 
> What makes you think that filePro stays around if it gets a SIGHUP?

I know it sticks around when the parent dies.  Read the bug report Ron got
regarding fpcgi vanishing and *clerk and *report hanging about.  Those
children -do- get a signal from apache--I'm almost positive.  It's not HUP.
More likely t be TERM or INT.  Assuming you don't turn on FPNOREMOTECMD in
2.0, I have 11 lines of perl that will adequately demonstrate this for you
(the 'ps' flags are BSD-based [works on BSD variants, as well as linux]):

     #!/usr/bin/perl
     for ($x=0;$x<2048;$x++) {
          system("lynx -dump http://somefphost.com/cgi-bin/fpcgi\\?Field_ddir=/tmp\\&Field_cmd=dreport+somebogusnamehere >/dev/null 2>&1 &");
          unless ($x % 5) {
               sleep(10);
               @pids=`ps auxww |grep lynx |grep somebogusnamehere`;
               foreach $line (@pids) {
                    (undef,$pid)=split(/ +/,$line);
                    kill(9,$pid);
               }
          }
     }

That's directly from the bug report that I submitted through Nancy, who
gave it directly to Ron.  This will suck your license dry and strand every
*clerk and *report process generated, even though the fpcgi's will go away
after a timeout.  This works with fpcgi 1.0, and even 2.0 if you don't set
some environment variables (it's -not- secure by default, in the name of
backwards compatability).

But given what this does, let's just say it doesn't act correctly.  Two
parents above it vanish, report's still there.  That's Not Right[tm].  And
even Ron acknowledged this, because he said in one response that he should
look into why they don't disappear.  And the fpcgi 2.0 stuff (somewhere...I
can't remember if someone showed me docs, or if it's in an email regarding
the bug fix discussion) says that if you set the new timeout env var, it
will kill the directly spawned process, but not any under it--meaning
any forked fP processes also stay around, and since you're obviously not
tracking the whole tree, something should be done about this.

This is why it's imperative that people upgrade to v2.0 of fpcgi, -and-
turn on the protection.  A DoS against the system, and specifically
filePro's license count, is exceedingly trivial--and -very- inexpensive
for the attacking server.  It's only as long as it is because I -made- it
inexpensive...it kills the retrieval agents every five instances.  Brute
force code would be even shorter.  I see nothing unethical about releasing
the proof of concept code--the vendor was made aware over a month ago, and
already has a patch available--at a price if you don't already have 2.0,
since I was told it wasn't back-ported to 1.0.  Maybe this will drive home
the ease with which one can screw over a 1.0-based system and convince some
people to upgrade.

> > UNIXTIME()
> 
> What would that return?  (And what would it return under Windows?)

A unix timestamp.  And it would return the same thing in Windows--just like
perl does.  Perl has no trouble getting the same value on every
platform--even win95.  Seconds since the epoch.  Fine, call it EPOCHTIME().

> As for some of the other things you've listed, I guess you'll just have to
> wait to see a 6.0 features list before making further comments.  ;-)

Hmmm.  I've never really let that stop me before, have I?  :)  

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html