Cannot get isapi-wsgi working on Win Server 2008

[Jamie Jackson]

I'm using iwhelper (ISAPIWSGIHelper) to facilitate setup, and it works fine on win2007. However, on the target win server 2008 server, it's like the handler mapping is not there at all. It just responds as normal, showing the index.html, and doesn't show me the message that it would if it were handled by isapi-wsgi.

Any ideas as to how to troubleshoot?

Do any of you have this running on Win Server 2008?

Thanks,

Jamie

[Jason R. Coombs]

Yes. Isapi-wsgi is confirmed running on all modern versions of Windows, including Server 2008, Server 2008 R2, and Windows 7. For all of these later versions, you must have the IIS 6 Metabase Compatibility feature installed. That is probably the issue. Can you double-check you have that feature installed and report back if that doesn’t fix it?

 

--
You received this message because you are subscribed to the Google Groups "isapi_wsgi-dev" group.
To post to this group, send email to isapi_w...@googlegroups.com.
To unsubscribe from this group, send email to isapi_wsgi-de...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/isapi_wsgi-dev?hl=en.

[Jamie Jackson]

Okay, so I've tried the whole thing from start to finish maybe a dozen times, all with the same result--the handler didn't seem hooked up to IIS at all.

Now, today, I did it yet another time, and I got different results--a 500 error from IIS, but it does show that the handler was attempted ("Handler: ISAPI-WSGI").

So now, at least IIS is trying to forward the request, which is good. Unfortunately, now I've got this other error. I set the permissions wide open on the whole virtualenv directory, but same result.

Oh, and FWIW, I looked at the IIS 6 Metabase Compatibility feature, and it was already installed.

Have any idea where to go from here? I'm trying nginx with fastcgi right now, in the meantime.

Thanks,

Jamie

[Jason R. Coombs]

I recently did an install to Windows Server 2008 R2, and ran into a number of issues. From scratch, here are some of the things I had to make sure I got right:

 

1)      Match 32-bit and 64-bit Python/IIS. If you have a 64-bit IIS, you probably also need 64-bit Python (or configure the app pool for 32-bit apps; I chose the former with success).

2)      Make sure Python is installed for all users. To double-check this, there should be a pythonXX.dll in \windows\system32.

3)      You may need the Visual Studio 2008 redistributable (or 2008 SP1 redistributable) for the proper word size (I used 64-bit). I think I installed both, but the SP1 was sufficient (?).

 

When I was troubleshooting, I found that using the Dependency Walker tool was helpful. After installing, I would run it on the _app.dll and make sure it was able to load without errors. It was errors here that suggested I needed the Visual Studio redistributables.

 

Also, I always check the Application Event Log. It doesn’t always have helpful error messages, but sometimes it does.

 

Perhaps some of these suggestions will help.

 

Regards,

Jason

[Randy Syring]

Jamie,

Do you have a different Win 2008 box you can test?  Even just in a virtual machine maybe?

--------------------------------------
Randy Syring
Intelicom
Direct: 502-276-0459
Office: 502-212-9913

For the wages of sin is death, but the
free gift of God is eternal life in 
Christ Jesus our Lord (Rom 6:23)

[Jamie Jackson]

Jason,

Good suggestions, thanks. Of all these, I've got a hunch about #3 and Dependency Walker. I had no idea how to begin to troubleshoot the dll. I would never have thought of any VS dependencies or "word size" (whatever that means).

I'll give this a shot, and report back.

Thanks,

Jamie 

[pyt...@bdurham.com]

Hi Jamie,

 

Have you checked the Windows event logs to see if there are any clues in there?

 

Disclosure: I'm new to isapi-wsgi and this is a guess based on experience with other IIS related software and not based on anything I've read in the isapi-wsgi documentation.

 

Malcolm

 

[Jamie Jackson]

Okay, still not working, but here are a few more bits of info:

I tried out Dependency Walker (cool tool!), and saw that a couple dependencies were missing:

• IESHIMS.DLL 
• Solved by adding "%ProgramFiles%\Internet Explorer" to the PATH
• LINKINFO.DLL 
• Solved by Installing "Desktop Experience" feature

After this, I get:

"Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module."

This points to "IEFRAME.DLL." (Is this a dealbreaker? Do I need to fix this?)

Anyway, what I'm left with is the same 500 Error (under my signature). Which corresponds to the following in the event viewer:

The description for Event ID 4097 from source ISAPI Filter or Extension cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event: 

Failed to import callback module '_loader'

The system cannot find the file specified.

Let me know if you have any ideas.

Thanks,

Jamie

Error Summary

HTTP Error 500.0 - Internal Server Error

The page cannot be displayed because an internal server error has occurred.

Detailed Error Information

Module IsapiModule

Notification ExecuteRequestHandler

Handler ISAPI-WSGI

Error Code 0x80004005

Requested URL http://jjfake.localhost:82/

Physical Path C:\inetpub\satelliteEligibility2\wwwroot

Logon Method Anonymous

Logon User Anonymous

Most likely causes:

    IIS received the request; however, an internal error occurred during the processing of the request. The root cause of this error depends on which module handles the request and what was happening in the worker process when this error occurred.

    IIS was not able to access the web.config file for the Web site or application. This can occur if the NTFS permissions are set incorrectly.

    IIS was not able to process configuration for the Web site or application.

    The authenticated user does not have permission to use this DLL.

    The request is mapped to a managed handler but the .NET Extensibility Feature is not installed.

Things you can try:

    Ensure that the NTFS permissions for the web.config file are correct and allow access to the Web server's machine account.

    Check the event logs to see if any additional information was logged.

    Verify the permissions for the DLL.

    Install the .NET Extensibility feature if the request is mapped to a managed handler.

    Create a tracing rule to track failed requests for this HTTP status code. For more information about creating a tracing rule for failed requests, click here.

[Jason R. Coombs]

When I ran into the issue with IESHIMS.DLL, I was able to bypass the error by installing one of the Visual Studio 2008 redistributables. Ultimately, I did not need to include Internet Explorer in the path.

 

You can probably disregard any warnings about delay-load modules. I found once the errors were resolved, I no longer needed to fuss with the dependency walker.

 

The error you’re getting in the event viewer sounds to me like it’s unable to find _loader.py (but I may be interpreting it incorrectly). This suggests to me that perhaps there is something referenced by _loader.py that’s not readable by the IUSR or App pool identity.

 

When I’m troubleshooting, I often go back to the “test” example in \Python\Lib\site-packages\isapi\samples\test.py. I copy it to \inetpub\wwwroot, install it, and then confirm that it’s working through localhost/PyISAPITest. If it’s not working, then you still have ISAPI binary problems. If that works, then you can start to focus on the specifics of your Python app and its dependencies (or possibly isapi-wsgi/isapiwsgihelper).

 

Hope that helps.

[Mark Hammond]

On 16/08/2011 4:30 AM, Jamie Jackson wrote:
> Okay, still not working, but here are a few more bits of info:

...

> Failed to import callback module '_loader'
> The system cannot find the file specified.

This came up here recently - see
http://groups.google.com/group/isapi_wsgi-dev/browse_thread/thread/16f99d20a3e0ddf0
- while it doesn't seem to have a resolution, it does have about
everything I can contribute to the problem...

HTH,

Mark

[Randy Syring]

FWIW, the resolution was there:

http://code.google.com/p/isapi-wsgi/issues/detail?id=10

Trying to load 32-bit DLLs in a 64 bit app pool.

--------------------------------------
Randy Syring
Intelicom
Direct: 502-276-0459
Office: 502-212-9913

For the wages of sin is death, but the
free gift of God is eternal life in
Christ Jesus our Lord (Rom 6:23)

[Jamie Jackson]

Unfortunately, the handler seems to be ignored if I allow 32 bit in the app pool. (Just shows the index.html I've got in there.)

--
You received this message because you are subscribed to the Google Groups "isapi_wsgi-dev" group.

To post to this group, send email to isapi_wsgi-dev@googlegroups.com.
To unsubscribe from this group, send email to isapi_wsgi-dev+unsubscribe@googlegroups.com.

[Randy Syring]

Do you have 64 bit or 32 bit python?

--------------------------------------
Randy Syring
Intelicom
Direct: 502-276-0459
Office: 502-212-9913

For the wages of sin is death, but the
free gift of God is eternal life in 
Christ Jesus our Lord (Rom 6:23)

To post to this group, send email to isapi_w...@googlegroups.com.
To unsubscribe from this group, send email to isapi_wsgi-de...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/isapi_wsgi-dev?hl=en.

--
You received this message because you are subscribed to the Google Groups "isapi_wsgi-dev" group.

To post to this group, send email to isapi_w...@googlegroups.com.
To unsubscribe from this group, send email to isapi_wsgi-de...@googlegroups.com.

[Jamie Jackson]

See below.

On Mon, Aug 15, 2011 at 5:41 PM, Jason R. Coombs <jar...@jaraco.com> wrote:

When I ran into the issue with IESHIMS.DLL, I was able to bypass the error by installing one of the Visual Studio 2008 redistributables. Ultimately, I did not need to include Internet Explorer in the path.

 

You can probably disregard any warnings about delay-load modules. I found once the errors were resolved, I no longer needed to fuss with the dependency walker.

 

The error you’re getting in the event viewer sounds to me like it’s unable to find _loader.py (but I may be interpreting it incorrectly). This suggests to me that perhaps there is something referenced by _loader.py that’s not readable by the IUSR or App pool identity.

 

When I’m troubleshooting, I often go back to the “test” example in \Python\Lib\site-packages\isapi\samples\test.py. I copy it to \inetpub\wwwroot, install it,

What do you mean by "install it?"

 

and then confirm that it’s working through localhost/PyISAPITest. If it’s not working, then you still have ISAPI binary problems. If that works, then you can start to focus on the specifics of your Python app and its dependencies (or possibly isapi-wsgi/isapiwsgihelper).

One thing that's interesting is that if I replace the _loader.py's code with the code from isapi\samples\test.py, I get its response in the browser: "The root of this site is at...'

I find this weird, but I'm no expert. Anyway, if, at the top of that working code, I put "import isapi_wsgi", I'm back to the 500 errors.

Is this a clue?

[Jamie Jackson]

I installed 64 bit python 2.7 to start fresh, and upon which to base my test virtualenvs.

[Jason R. Coombs]

By “install it”, I mean run “python test.py install” (and it will create the hook DLL and register the script map for test.py on /PyISAPITest in the Default Web Site).

 

But you’ve managed to capture the problem a different way – by replacing _loader.py with the contents from test.py, you’ve essentially done the same thing.

 

And the fact that it’s working means your IIS/ISAPI/Python environment is set up correctly. Good job!

 

Also, adding the “import isapi_wsgi” causing the 500 indicates almost certainly that the IIS user is unable to read that package. I would double-check the permissions on Python\Lib\site-packages\isapi-wsgi*. Also, if isapi-wsgi is installed as a zipped egg (a single file and not a directory), I’ve seen the IIS identity not have permission to expand that zip file somewhere (necessary for some packages). More likely, though, it’s just a permissions issue.

 

Another very useful technique at this point (now that your Python environment is being invoked) is to add “import win32traceutil” at the top of the hook script. This will redirect all output to a special global buffer so you can view it in another process. Then, it a separate command-line window, run “python -m win32traceutil” and it will echo all messages that come into that buffer… so you can see any errors or output.

[Jamie Jackson]

Thanks for the tips, Jason. Please see below...

On Tue, Aug 16, 2011 at 11:16 AM, Jason R. Coombs <jar...@jaraco.com> wrote:

By “install it”, I mean run “python test.py install” (and it will create the hook DLL and register the script map for test.py on /PyISAPITest in the Default Web Site).

 

But you’ve managed to capture the problem a different way – by replacing _loader.py with the contents from test.py, you’ve essentially done the same thing.

 

And the fact that it’s working means your IIS/ISAPI/Python environment is set up correctly. Good job!

 

Also, adding the “import isapi_wsgi” causing the 500 indicates almost certainly that the IIS user is unable to read that package. I would double-check the permissions on Python\Lib\site-packages\isapi-wsgi*. Also, if isapi-wsgi is installed as a zipped egg (a single file and not a directory), I’ve seen the IIS identity not have permission to expand that zip file somewhere (necessary for some packages). More likely, though, it’s just a permissions issue.

FWIW:

• I had installed isapi_wsgi via pip, and it's in a bona fide directory.
• I ensured IIS_IUSRS had read/execute permissions on the whole virtualenv.
• If I create a user with the same credentials as IIS_IUSRS, and run the test.py code from cmd, it has no problem importing isapi_wsgi.

 

Another very useful technique at this point (now that your Python environment is being invoked) is to add “import win32traceutil” at the top of the hook script. This will redirect all output to a special global buffer so you can view it in another process. Then, it a separate command-line window, run “python -m win32traceutil” and it will echo all messages that come into that buffer… so you can see any errors or output.

That is very cool, and I can see the trace if I run from the command line. However, I can't seem to get anything in the buffer when I hit it in the browser, even when I get test.py's "The root of this site is at C:\inetpub\satelliteEligibility2\wwwroot". It would be pretty helpful if I could see what IIS was doing, but I don't know why it won't write output to the buffer.

[Mark Hammond]

On 17/08/2011 2:43 AM, Jamie Jackson wrote:
...

> * I had installed isapi_wsgi via pip, and it's in a bona fide directory.
> * I ensured IIS_IUSRS had read/execute permissions on the whole
> virtualenv.

I suspect the virtualenv is going to be the problem - when Python is
loaded by the IIS process, Python probably can't find that virtualenv -
it will end up looking in the reistry for the install path and attempt
to import from there - but that isn't going to be your virtualenv.

With win32traceutil in place, print your sys.path - I suspect you will
find directories other than what you expect. The simplest way forward
is probably to just install isapi_wsgi is your main Python install.

HTH,

Mark

[Jason R. Coombs]

The whole point of ISAPIWSGIHelper is to support isapi-wsgi using
virtualenvs... and I'm pretty sure I've tried it once before and it worked
for me.

I wonder if ISAPIWSGIHelper runs the activate_this.py script to activate the
virtualenv. If it doesn't, that might be something it could do.

In the meantime, Mark is probably right that the easiest thing would be to
install isapi-wsgi (and other dependencies) in the global site-packages.

> -----Original Message-----
> From: isapi_w...@googlegroups.com [mailto:isapi_wsgi-
> d...@googlegroups.com] On Behalf Of Mark Hammond
> Sent: Tuesday, 16 August, 2011 18:24
> To: isapi_w...@googlegroups.com
> Cc: Jamie Jackson
> Subject: Re: Cannot get isapi-wsgi working on Win Server 2008
>

> --
> You received this message because you are subscribed to the Google Groups
> "isapi_wsgi-dev" group.
> To post to this group, send email to isapi_w...@googlegroups.com.
> To unsubscribe from this group, send email to isapi_wsgi-

> dev+uns...@googlegroups.com.

[Randy Syring]

For clarification, ISAPIWSGIHelper (IWH) and isapi-wsgi should be installed with the system python:

> ISAPIWSGIHelper should be installed in python's site-packages directory, not in a virtualenv.

http://pypi.python.org/pypi/ISAPIWSGIHelper

Once you have the virtualenv setup and have used IWH to create the isapi-wsgi directory, then there are lines in the appinit.py file that takes care of putting the virtualenv you setup on the path:

# If you have isapi-wsgi installed in a different location or are not using
# a virtualenv, you CAN SAFELY MODIFY OR DELETE THE FOLLOWING TWO LINES.
from iwhelper.utils import prepend_site_dir
prepend_site_dir(__file__, '..', 'Lib', 'site-packages')

--------------------------------------
Randy Syring
Intelicom
Direct: 502-276-0459
Office: 502-212-9913

For the wages of sin is death, but the
free gift of God is eternal life in 
Christ Jesus our Lord (Rom 6:23)