Medium Flame:Re: fPCGI vs. Windows 2003 ==>> bottom post

[Robert Haussmann]

[...]

> It's not a filePro issue, Tony.  It's a Windows issue.  Specifically
> something in either Server 2003 or IIS 6.0, or a combination 
> thereof.  This
> is specific to the CGI environment, and fPCGI as a product 
> notwithstanding,
> that's not fP-Tech's fault.
> 
> Given the -exact- same server (W2K3/IIS6), -any- software 
> running through
> IIS would encounter this issue.
> 

First, let me give public thanks to Mark on this issue.  He worked with
me for a number of hours tonight to help troubleshoot this issue.
He even wrote two programs on the fly to help narrow down the problem
(see below).  Thanks Mark!

> The problem and responsibility isn't fP-Tech's, it's Microsoft's.  And
> their uhm..."Knowledge Base" apparently doesn't cover this, 
> despite the
> fact they maintain one after a fashion.
> 
> This is like trying to hold fP-Tech or the fP community 
> responsible for the
> development decisions of RH, SCO, Apache, etc.  It's just not their
> problem, and no amount of testing they could have done would 
> -fix- the fact
> that Mickeysoft managed to break their own software again.  
> All they could
> do is put a warning out.  M$ needs to fix it.

The above is correct.  For those of you that want the details:

We use Windows/IIS as a web server, but have our filePro files on 
a Netware 6.0 server.  This is the root of the issue.

In Win2K/IIS5, you can specify that a certain IIS directory is
a "subsite", and create an "application" that runs under a specified
username/password.   In this setup, we can specify an account that
is 1) part of a Win2K domain and 2) set up under Netware (with the same
password) such that when a request is made to the "subsite", IIS will
login with this username and password, and execute the login script
on the Novell server, which maps a drive (F: in our case) to make
filePro happy (PFDSK=F).  fPCGI then calls rclerk, which has an 
environment that contains a mapped F: drive, and everything works.

It *appears* that win2K3 operates differently.  For each subsite, you
can specify an "application pool", that has a specific username/password
assigned.  The difference, however, appears that while the application
pool will *authenticate* to a Netware server, it does not execute the
login script and does not map drives.  So while the subsite in this
case can use a UNC that points to the Netware server, it cannot use
a drive that might get mapped in the login script.  As such, rclerk
fails.

To be fair, Microsoft has not made it a secret that they are doing
away with mapped drive access in many realms.  Everying seems to be
going the way of UNC.  While this complicates certain situations
(such as this one), it give the user a lot of freedom in others.
Which is better--who's to say?

So the bottom line appears to be that filePro will not work on
Win2K3 using fPCGI, OneGate, or any other CGI engine when 
accessing a non-local drive.  Unless, of course, filePro gives us
the option of using UNC's rather than drive letters. 

That being said--how difficult would it be for fPTech to 
make the next version of filePro respect UNC's as well as drive
mappings?  E.g., PFDSK=\\servername\vol\directory\subdir ?

Bob