fpCGI failure, part 2

[Fairlight]

Yo, homey, in case you don' be listenin', Nancy Palmquist done said:
> I have to say that you are giving fpCGI too much credit.  All it does is

There's credit to be given?  For the DoS potential, poor overall security
design, inefficiency, bugginess, lack of features, being limited to fP's
user count, slow support and bugfixes, or...what?

I think the word you were looking for was "blame", not "credit".

> act as a go-between.  It grabs form data send via POST or GET methods and
> writes it to a file and then it executes a filePro application passing
> the name of that data file, which is responsible to grab the data via an
> IMPORT of some kind.  Process the data and generate output.
>
> The output is then dragged back to the Browser that made the request.

Not exactly.  The output is actually spit onto the server's hard drive.
Then the browser is told to look -that- up, (up to) doubling the connection
overhead of your web server itself, based on the fact that if the browser
doesn't re-use the same connection, the first will still be in TIME_WAIT
and the secondary wait states before release while the second is brought
from syn to ESTABLISHED to retrieve the actual results.

I never really thought of it before, as my main complaint (everyone's,
really) was that the data files were left on the server for cleanup.
I -thought- I heard that's been added in a late v2 release, but the
connection issue is actually something I never thought of before now.
Given either browsers/clients that doen't know how to reuse connections,
or given a configuration that prevents connection reuse, the web server is
taking twice as many resources as it has to.  In effect, your available
-socket- connection count is cut by up to 50%, if I'm thinking about this
correctly.  And I believe I am.  That's why "wardialing" an ftp site really
ticks off admins...you're eating socket connections per socket per process,
and you only get 1024 (used to be 256!) on stock systems.  On a busy
system, that could be bad.  Sure, apache will fork off more children if
needed, but that's more RAM and more resources (memory, etc.).

> I think Mark's suggestion that onegate would solve your problem is wrong,
> it will give you different errors and recovery capabilities.  If you are
> getting filePro errors, or not generating any output, or reading the
> input file incorrectly, you will have the same issue with onegate.

Not necessarily.  Clients have had issues on both Windows and Linux systems
where fP binaries were not getting executed -at all- by fpcgi.  They
switched to OneGate and *poof* it ran fine.  Bruce, care to chime in on
that for Windows?  I'm trying to remember who hit this under Linux--it
may actually also have been Bruce, in addition to someone else.

My support also would have had an issue like this pinned down within a
couple hours, and the blame either laid squarely at fP with diagnostics,
or would have seen a patch released already.  My longest patch turnaround
is 72hrs, and that was a -really- convoluted issue.  My average is 2hrs
from report to new version release, including testing.  That's -me- testing
it, not some company sending you a new version that doesn't work (or
even run--fP-Tech has supplied versions that segv, had wrong library
linking, etc., and you -know- I'm being straight on this because you were
involved in the incidents in question), then sending another, and another
up to about 5 before you get one that actually works and generates the
diagnostics...so they can actually fix it 30-45 days later.

If there's a problem, I help find it, and if it's my software, I fix it
posthaste.  I never would have let Tyler sit like this, and anyone that's
ever hit an OG bug and reported it knows that.  Patches are free if it's
actually a bug in my code (for v4.x, as v3 is now EOL).  Diagnostics that
lead to a fault elsewhere than OG are billable.

> I use them both.  They both work.  

Mine works consistently.  The people that switched from one to the other
have different things to say about fpcgi's "working" and consistency.

You're entitled to your opinion based on your own experience, but I
guarantee that mileage is varying for different people on this one.

As for Tyler's problem and diagnosing it, here's a bit more info...

As for my previous assertion that if the files didn't show up on a
redirect, the shell that sits between fpcgi and *report was never getting
called; that's actually shell dependant, which I didn't previously know.
I just tested both bash 1.14 (old, old, old!) and tcsh 6.09, and both
will redirect and create an empty file not only if the command errors,
but even if the command doesn't even exist.  In other words, they can't
fail to redirect and create the file (barring permissions issues with the
destination).  However, stock Bourne shell on OSR 5.0.6 fails half of this
test, and the file is not created if the command did not exist.  However,
it will redirect if there's an error condition and the command existed:

# ls -l fldebug
ls: fldebug not found: No such file or directory (error 2)
# echo $?
2
# ls -l fldebug >fldebug2 2>&1
# ls -l fldebug2
-rw-r--r--   1 root     sys           59 Mar 19 15:19 fldebug2
# cat fldebug2
ls: fldebug not found: No such file or directory (error 2)

So, unless the command -doesn't exist-, there should be a redirect, or
system() within fpcgi is failing to execute /bin/sh.  Period.

mark->
-- 
"Moral cowardice will surely be written as the cause on the death
certificate of what used to be Western Civilization." --James P. Hogan