Hi Yadin,
Cosign module crashes IIS pools when it cannot instantiate itself or
communicate with Cosign server. Cosign module starts when IIS starts  -
check configuration settings: application host config for <section
name="cosign" overrideModeDefault="Allow" />, iis schemas for cosign schema
in inetsrv, check if your server has access to cosign servers on cosign
port ( 6663 for Umich servers).
And I would recommend to rewrite cosign module in .Net and make cosign
module do not crash IIS and make configuration more flexible -
configuration per web application but not one configuration for IIS.
Thanks,
Konstantin.

On Wed, Aug 5, 2015 at 2:34 PM, Yadin Flammer <y...@psu.edu> wrote:

> All that does is take it longer to fail.  The server is unresponsive
> until the pool dies and then you get the 503.  The indication is that
> IIS 8.5 is trying to use all modules in the pool even when the module
> are not actually called by the site?  I'll try putting in the full
> configuration but it's very much not expected that if a module is not
> being called that it would be crashing the pool because there is no
> config for it...  If that's actually what's happening, it would seem an
> enhancement is called for in the module to prevent this instability from
> taking down a whole server.
>
> -------------------------------------------------------------------
>    Yadin Flammer - Systems Administrator
>    College of Arts&  Architecture, Penn State University
>    220 Borland Building              Office Phone: 814-865-0990
>    University Park, PA 16802         Help Desk:    814-865-AAIT
>    Email: y...@psu.edu               Dept. Fax:    814-863-6227
>
> On 8/5/2015 2:23 PM, Stucky, David wrote:
> > Yadin,
> >
> >  From my experience the Cosign module frequently crashes the application
> pool, normally not more than 5 times per min.  I believe in IIS 7 the
> default for Rapid Fail Protection is 5 failures in 5mins.  I know at one
> time I set a server to 100 failures in 5mins, because known security scans
> were causing 50+ failures in 5mins every time they ran.  It may not be the
> best/correct solution, but it would be interesting to see if increasing the
> Rapid Fail Protection setting on the application pool will eventually allow
> it to at least start and stay running.  If it is a true
> configuration/compatibly issue, I would assume increasing the rapid fail
> protection past 100 failures will not help.  Under normal operation you
> should not have to set Rapid Fail Protection that high.
> >
> > Thanks...
> > David Stucky
> >
> > -----Original Message-----
> > From: Yadin Flammer [mailto:y...@psu.edu]
> > Sent: Wednesday, August 5, 2015 9:48 AM
> > To: Chris S. Motch <c...@psu.edu>; cosign-discuss@lists.sourceforge.net
> > Subject: Re: [Cosign-discuss] Dies on IIS 8.5
> >
> > Chris,
> >
> > Thanks for the suggestion, but MSXML has been in every version of
> Windows since 2003, so I'm not sure why this would have been an issue for
> you, or how you could have gotten it to install on 2012 given compatibility
> of the 12 year old download for version 6.  This wasn't a concern in 2008
> for exactly the reason that it's in the OS already, and I find nothing
> about it being removed from 2012.  Do you have any further info on that?
> >
> > Thanks,
> > Yadin
> >
> > -------------------------------------------------------------------
> >     Yadin Flammer - Systems Administrator
> >     College of Arts&  Architecture, Penn State University
> >     220 Borland Building              Office Phone: 814-865-0990
> >     University Park, PA 16802         Help Desk:    814-865-AAIT
> >     Email: y...@psu.edu               Dept. Fax:    814-863-6227
> >
> > On 8/5/2015 7:28 AM, Chris S. Motch wrote:
> >> Yadin,
> >>
> >> I remember having a similar issue and discovering I needed to install
> MSXML which is the Microsoft XML parser.  A list of versions can be found
> here https://support.microsoft.com/en-us/kb/269238.  I suspect that might
> be your issue if you do not have this installed already.
> >>
> >> Chris Motch
> >>
> >> -----Original Message-----
> >> From: Yadin Flammer [mailto:y...@psu.edu]
> >> Sent: Tuesday, August 4, 2015 3:12 PM
> >> To: cosign-discuss@lists.sourceforge.net
> >> Subject: [Cosign-discuss] Dies on IIS 8.5
> >>
> >> I'm trying to put Cosign on server 2012R2 for the first time, and I'm
> hitting a fatal issue right out of the gate.  As soon as the module is
> registered, IIS no longer works as the app pool dies as soon as it tries to
> service a http request.  I have not even configured a site to use cosign
> yet, so the appearance is the module is not compatible with IIS 8.5?
> >>
> >> Steps taken:
> >> Download 3.1.1 zip for IIS7 from
> >> http://cosign.sourceforge.net/download.shtml
> >> Copy the src/Cosign_Schema.xml file into
> >> C:\Windows\System32\inetsrv\config\schema
> >> Copy the x64 CosignModule.dll file into C:\Windows\System32\inetsrv
> Open an administrative command prompt and change directory to
> c:\windows\system32\inetsrv.
> >> Enter this command:
> >> appcmd install module /name:"Cosign"
> >> /image:"%windir%\system32\inetsrv\CosignModule.dll"
> >>
> >> At that point, the expectation is that the webserver just keeps working
> as it has been as Cosign isn't even involved yet. Unfortunately, as I said
> the app pool dies because cosign causes a fatal issue.  From the Event
> Viewer:
> >>
> >> Application: The Module name Cosign path
> C:\Windows\system32\inetsrv\CosignModule.dll returned an error from
> registration.  The data is the error.
> >> System: Application pool 'DefaultAppPool' is being automatically
> disabled due to a series of failures in the process(es) serving that
> application pool.
> >>
> >> Not real helpful other than confirming what was obvious, Cosign is
> killing the app pool so the server is dead until the module is removed.
> >>
> >> I noted some things changed in the instructions, so I then added the
> x86 .dll to SysWOW64\inetsrv, uinstalled the module, and reinstalled with
> appcmd install module /name:"Cosign" /image:"CosignModule.dll"
> >>
> >> Unfortunately this made no change, the app pool still dies as soon as a
> page request is made over http.  Is it really supposed to be the case the
> x64 module goes in the 32bit directory and vice versa?
> >> Why is the module causing the app pool to crash out before it's even
> active in a configuration?
> >>
> >> Thanks!
> >> Yadin
> >>
> >> --
> >> -------------------------------------------------------------------
> >>      Yadin Flammer - Systems Administrator
> >>      College of Arts&  Architecture, Penn State University
> >>      220 Borland Building              Office Phone: 814-865-0990
> >>      University Park, PA 16802         Help Desk:    814-865-AAIT
> >>      Email: y...@psu.edu               Dept. Fax:    814-863-6227
> >>
> >>
> >> ----------------------------------------------------------------------
> >> -------- _______________________________________________
> >> Cosign-discuss mailing list
> >> Cosign-discuss@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/cosign-discuss
> >
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Cosign-discuss mailing list
> > Cosign-discuss@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/cosign-discuss
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Cosign-discuss mailing list
> Cosign-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/cosign-discuss
>
------------------------------------------------------------------------------
_______________________________________________
Cosign-discuss mailing list
Cosign-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cosign-discuss

Reply via email to