Re: [Cosign-discuss] Dies on IIS 8.5
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
[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
Re: [Cosign-discuss] Cosign on Ubuntu 14 doesn't work?
Not yet. I was starting to wonder about that as I see apache2 went from 2.2.x to 2.4.x and I'm seeing a lot of changes were made that cause other issues, like all the default directory locations seem to have changed, so it's not unreasonable that the compiled cosign needs to be recompiled I guess... --- Yadin Flammer - Systems Administrator College of Arts Architecture, Penn State University 228 Borland Building Office Phone: 814-865-0990 University Park, PA 16802 Dept. Phone: 814-865-1571 Email: y...@psu.edu Dept. Fax:814-863-6227 On 9/29/2014 5:13 PM, Phil Pishioneri wrote: On 9/29/14 3:58 PM, Yadin Flammer wrote: I just upgraded a system running Ubuntu server 12 LTS to 14, and now apache can't start because the cosign module is no good apparently: ... Is this a known problem? Unknown to me. Do I need to upgrade to Cosign 3.2 because 3.1.2 doesn't work on Ubuntu 14 for some reason? Any advice is appreciated. Did you try rebuilding the 3.1.2 module on the upgraded system? -Phil -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk ___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
Re: [Cosign-discuss] 404 issue
Ah, yes it does. To try to compensate as we do with Drupal, I tried
each of these (not together) in the .htaccess before it's default
conditions and neither helped.
RewriteCond %{REQUEST_URI} !^/cosign/
RewriteCond %{REQUEST_URI} !=/cosign/valid
---
Yadin Flammer - Systems Administrator
College of Arts Architecture, Penn State University
228 Borland Building Office Phone: 814-865-0990
University Park, PA 16802 Dept. Phone: 814-865-1571
Email: y...@psu.edu Dept. Fax:814-863-6227
On 4/30/2014 4:08 PM, Liam Hoekenga wrote:
Does Omeka use mod_rewrite? I've seen instances of overly broad
rewrite rules in drupal and wordpress break cosign.
Liam
On Mon, Apr 28, 2014 at 11:09 PM, Yadin Flammer y...@psu.edu
mailto:y...@psu.edu wrote:
Enabled. Why do you ask?
---
Yadin Flammer - Systems Administrator
College of Arts Architecture, Penn State University
228 Borland Building Office Phone:814-865-0990
tel:814-865-0990
University Park, PA 16802 Dept. Phone:814-865-1571
tel:814-865-1571
Email:y...@psu.edu mailto:y...@psu.eduDept.
Fax:814-863-6227 tel:814-863-6227
On 4/28/14 10:15 PM, Liam Hoekenga wrote:
Mod_rewrite?
On Monday, April 28, 2014, Yadin Flammer y...@psu.edu
mailto:y...@psu.edu wrote:
Nope
---
Yadin Flammer - Systems Administrator
College of Arts Architecture, Penn State University
228 Borland Building Office Phone:814-865-0990
tel:814-865-0990
University Park, PA 16802 Dept. Phone:814-865-1571
tel:814-865-1571
Email:y...@psu.eduDept. Fax:814-863-6227
tel:814-863-6227
On 4/28/14 6:58 PM, Chris Hecker wrote:
Selinux?
Chris
On Apr 28, 2014 3:47 PM, Yadin Flammer y...@psu.edu wrote:
Hello all.
So I have set up cosign tons of times, but suddently I
have a new system
that I can't get working for some reason. It seems to
be working except
that when the valid response comes back from the
redirect server the
session is keeping the token in the url so the webserver
spits out a 404
/cosign/valid?cosign-omeka.arts.psu.edu
http://cosign-omeka.arts.psu.edu=yJ1xzSWDxCS1abPifxVeBzJ8JYMOHFNPAraQ9g4Z+av7AZMZLxblwOkZ7pqJinznqnRrcc31o3d4gYYMMnPqFAQZiPWVA4L1qxMh-wiuh3aeIokGRTnXIWa4tJKuhttps://omeka.arts.psu.edu/admin
is not a valid URL.
Yep that's not a valid url alright, but why it is trying
to find that
whole thing rather than just the requested url like it
should be? I
can't for the life of me find anything out of place with
this setup
compared to my others. Ideas?
I note one thing, there are no files being written to
the /filters
directory. Not sure if that helps point out the issue.
Permissions
look right... but I thought that being messed up gave a
503 not a 404
so I think it's something else?
drwxrwxr-x 2 www-data www-data 4096 Apr 24 15:27 filter
The only other guess I have is that it's an issue with
the way the web
application at that location works (Omeka). When I hit
that url
normally, I see the address change to /admin/users/login
which is not a
real location so I'm guessing it's virtual in sql land.
Now I'd hope
that it wouldn't matter and cosign would just hand me to
the server at
the given url and the web app would take it from there
as normal, but
maybe that's not the case? And am I right that if I
have /admin
protected everything under that is protected? Changing
the protected
location to /admin/users/login didn't help for what it's
worth.
Location /cosign/valid
SetHandlercosign
CosignProtected Off
Allow from all
Satisfy any
/Location
Location /admin
CosignProtected On
CosignAllowPublicAccess Off
AuthType Cosign
/Location
Thanks!
Yadin
--
---
Yadin Flammer - Systems Administrator
College of Arts Architecture, Penn State University
228
Re: [Cosign-discuss] 404 issue
Nope --- Yadin Flammer - Systems Administrator College of Arts Architecture, Penn State University 228 Borland Building Office Phone: 814-865-0990 University Park, PA 16802 Dept. Phone: 814-865-1571 Email: y...@psu.edu Dept. Fax:814-863-6227 On 4/28/14 6:58 PM, Chris Hecker wrote: Selinux? Chris On Apr 28, 2014 3:47 PM, Yadin Flammer y...@psu.edu mailto:y...@psu.edu wrote: Hello all. So I have set up cosign tons of times, but suddently I have a new system that I can't get working for some reason. It seems to be working except that when the valid response comes back from the redirect server the session is keeping the token in the url so the webserver spits out a 404 /cosign/valid?cosign-omeka.arts.psu.edu http://cosign-omeka.arts.psu.edu=yJ1xzSWDxCS1abPifxVeBzJ8JYMOHFNPAraQ9g4Z+av7AZMZLxblwOkZ7pqJinznqnRrcc31o3d4gYYMMnPqFAQZiPWVA4L1qxMh-wiuh3aeIokGRTnXIWa4tJKuhttps://omeka.arts.psu.edu/admin is not a valid URL. Yep that's not a valid url alright, but why it is trying to find that whole thing rather than just the requested url like it should be? I can't for the life of me find anything out of place with this setup compared to my others. Ideas? I note one thing, there are no files being written to the /filters directory. Not sure if that helps point out the issue. Permissions look right... but I thought that being messed up gave a 503 not a 404 so I think it's something else? drwxrwxr-x 2 www-data www-data 4096 Apr 24 15:27 filter The only other guess I have is that it's an issue with the way the web application at that location works (Omeka). When I hit that url normally, I see the address change to /admin/users/login which is not a real location so I'm guessing it's virtual in sql land. Now I'd hope that it wouldn't matter and cosign would just hand me to the server at the given url and the web app would take it from there as normal, but maybe that's not the case? And am I right that if I have /admin protected everything under that is protected? Changing the protected location to /admin/users/login didn't help for what it's worth. Location /cosign/valid SetHandlercosign CosignProtected Off Allow from all Satisfy any /Location Location /admin CosignProtected On CosignAllowPublicAccess Off AuthType Cosign /Location Thanks! Yadin -- --- Yadin Flammer - Systems Administrator College of Arts Architecture, Penn State University 228 Borland Building Office Phone: 814-865-0990 tel:814-865-0990 University Park, PA 16802 Dept. Phone: 814-865-1571 Email: y...@psu.edu mailto:y...@psu.edu Dept. Fax: 814-863-6227 tel:814-863-6227 -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net mailto:Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
[Cosign-discuss] 503 on Ubuntu
Ubuntu 12 server apache2 cosign 3.1.2 http and https work fine, but as soon as I include the cosign config https comes back after sign in as unavailable service. URL after sign in is that long valid?cosign string so it would appear auth is working, but cosign on this webserver is not. I can find no info on where any useful logs would be written to tell me why it's unavailable. As far as I can tell the cosign module is active, and yet it's not available for some reason. Setup mirrors what we do on Red Hat but it's not working on Ubuntu for some reason. Nothing in the apache2 error log or ssl error log or the syslog Ideas where to look? Yadin -- --- Yadin Flammer - Systems Administrator College of Arts Architecture, Penn State University 228 Borland Building Office Phone: 814-865-0990 University Park, PA 16802 Dept. Phone: 814-865-1571 Email: y...@psu.edu Dept. Fax:814-863-6227 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
Re: [Cosign-discuss] 503 on Ubuntu
Using standard settings I always use there, shouldn't be an issue AFAIK. LocationMatch /cosign CosignProtected On CosignAllowPublicAccess Off AuthType Cosign /LocationMatch Location /cosign/valid SetHandlercosign CosignProtected Off Allow from all Satisfy any /Location CosignProtected On CosignAllowpublicAccess Off On 2/25/2013 1:15 PM, Andrew Mortensen wrote: On Feb 25, 2013, at 12:55 PM, Yadin Flammer y...@psu.edu wrote: Ubuntu 12 server apache2 cosign 3.1.2 http and https work fine, but as soon as I include the cosign config https comes back after sign in as unavailable service. URL after sign in is that long valid?cosign string so it would appear auth is working, but cosign on this webserver is not. If the query string is *very* long, it's likely you have the /cosign/valid path cosign-protected. It should not be protected. Make sure you have this somewhere in your vhost's configuration: Location /cosign/valid SetHandler cosign CosignProtected Off Allow from all Satisfy any /Location If you already have that, make sure you don't have the docroot protected using Location, e.g.: Location / ... CosignProtected On ... /Location Using the above will override the /cosign/valid Location context. To protect the docroot, use Directory with the actual local path to the docroot instead, e.g.: Directory /usr/local/share/www-root/ ... CosignProtected On ... /Directory andrew -- --- Yadin Flammer - Systems Administrator College of Arts Architecture, Penn State University 228 Borland Building Office Phone: 814-865-0990 University Park, PA 16802 Dept. Phone: 814-865-1571 Email: y...@psu.edu Dept. Fax:814-863-6227 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
Re: [Cosign-discuss] 503 on Ubuntu
I think we're likely on to something. /var/cosign does not exist. Does this mean the installer failed in some way, or would this have been created somewhere else based on the OS and apache2 implementation? If it was somewhere else, how would one find it? When you talk about the temp files, would that be in that missing directory as well? As a development note, it might be good to add some logging for these instances so as to not have mystery situations, even if highly unusual. Thanks! Yadin --- Yadin Flammer - Systems Administrator College of Arts Architecture, Penn State University 228 Borland Building Office Phone: 814-865-0990 University Park, PA 16802 Dept. Phone: 814-865-1571 Email: y...@psu.edu Dept. Fax:814-863-6227 On 2/25/13 10:51 PM, Andrew Mortensen wrote: On Feb 25, 2013, at 3:32 PM, Yadin Flammery...@psu.edu wrote: Well normally that block is required for cosign to work properly, though that's likely because we're normally dealing with Drupal sites which are public and login is to get editor access, and it's not doing anything in this case. Regardless, removing that block does not resolve the Service Temporarily Unavailable response. There are a number of reasons mod_cosign will respond to the client with a 503, but most of them have log messages associated with them. After looking through the code, I've found a handful of places where no message is logged when returning Service Temporarily Unavailable, and in all cases they're related to errors encountered when attempting to check the cookie: * the httpd user doesn't have read/write/execute rights to the filterdb directory (/var/cosign/filter by default); * a gettimeofday call fails when preparing to check the cached cookie in the filterdb directory; * kerberos ticket retrieval is configured, but the module couldn't create a temp file to store the data; * proxy cookie retrieval is configured, but the module couldn't create a temp file to store the data The only message emitted when the filter can't connect to any weblogin server is Unable to connect to any Cosign server. Hope this helps. andrew On 2/25/2013 3:27 PM, Andrew Mortensen wrote: On Feb 25, 2013, at 3:07 PM, Yadin Flammery...@psu.edu wrote: Using standard settings I always use there, shouldn't be an issue AFAIK. LocationMatch /cosign CosignProtected On CosignAllowPublicAccess Off AuthType Cosign /LocationMatch Are you really serving protected content out of a /cosign directory? You've already got vhost-global cosign-protection enabled below. This seems like the problem to me. If you delete the above block, does the 503 go away? andrew Location /cosign/valid SetHandlercosign CosignProtected Off Allow from all Satisfy any /Location CosignProtected On CosignAllowpublicAccess Off On 2/25/2013 1:15 PM, Andrew Mortensen wrote: On Feb 25, 2013, at 12:55 PM, Yadin Flammery...@psu.edu wrote: Ubuntu 12 server apache2 cosign 3.1.2 http and https work fine, but as soon as I include the cosign config https comes back after sign in as unavailable service. URL after sign in is that long valid?cosign string so it would appear auth is working, but cosign on this webserver is not. If the query string is *very* long, it's likely you have the /cosign/valid path cosign-protected. It should not be protected. Make sure you have this somewhere in your vhost's configuration: Location /cosign/valid SetHandler cosign CosignProtected Off Allow from all Satisfy any /Location If you already have that, make sure you don't have the docroot protected using Location, e.g.: Location / ... CosignProtected On ... /Location Using the above will override the /cosign/valid Location context. To protect the docroot, use Directory with the actual local path to the docroot instead, e.g.: Directory /usr/local/share/www-root/ ... CosignProtected On ... /Directory andrew -- --- Yadin Flammer - Systems Administrator College of Arts Architecture, Penn State University 228 Borland Building Office Phone: 814-865-0990 University Park, PA 16802 Dept. Phone: 814-865-1571 Email: y...@psu.edu Dept. Fax:814-863-6227 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss -- --- Yadin Flammer - Systems
Re: [Cosign-discuss] 503 on Ubuntu
Well I found the note on making that directory I missed, my bad, but that still doesn't fix the issue. As a double check I blew permissions on that directory wide open and I still get the service unavailable issue. :/var/cosign$ ls -la total 12 drwxr-xr-x 3 root root 4096 Feb 25 23:06 . drwxr-xr-x 15 root root 4096 Feb 25 23:06 .. drwxrwxrwx 2 www-data root 4096 Feb 25 23:06 filter date command returns proper time as expected in proper time zone. Any other ideas? Yadin --- Yadin Flammer - Systems Administrator College of Arts Architecture, Penn State University 228 Borland Building Office Phone: 814-865-0990 University Park, PA 16802 Dept. Phone: 814-865-1571 Email: y...@psu.edu Dept. Fax:814-863-6227 On 2/25/13 11:05 PM, Yadin Flammer wrote: I think we're likely on to something. /var/cosign does not exist. Does this mean the installer failed in some way, or would this have been created somewhere else based on the OS and apache2 implementation? If it was somewhere else, how would one find it? When you talk about the temp files, would that be in that missing directory as well? As a development note, it might be good to add some logging for these instances so as to not have mystery situations, even if highly unusual. Thanks! Yadin --- Yadin Flammer - Systems Administrator College of Arts Architecture, Penn State University 228 Borland Building Office Phone: 814-865-0990 University Park, PA 16802 Dept. Phone: 814-865-1571 Email:y...@psu.eduDept. Fax:814-863-6227 On 2/25/13 10:51 PM, Andrew Mortensen wrote: On Feb 25, 2013, at 3:32 PM, Yadin Flammery...@psu.edu wrote: Well normally that block is required for cosign to work properly, though that's likely because we're normally dealing with Drupal sites which are public and login is to get editor access, and it's not doing anything in this case. Regardless, removing that block does not resolve the Service Temporarily Unavailable response. There are a number of reasons mod_cosign will respond to the client with a 503, but most of them have log messages associated with them. After looking through the code, I've found a handful of places where no message is logged when returning Service Temporarily Unavailable, and in all cases they're related to errors encountered when attempting to check the cookie: * the httpd user doesn't have read/write/execute rights to the filterdb directory (/var/cosign/filter by default); * a gettimeofday call fails when preparing to check the cached cookie in the filterdb directory; * kerberos ticket retrieval is configured, but the module couldn't create a temp file to store the data; * proxy cookie retrieval is configured, but the module couldn't create a temp file to store the data The only message emitted when the filter can't connect to any weblogin server is Unable to connect to any Cosign server. Hope this helps. andrew On 2/25/2013 3:27 PM, Andrew Mortensen wrote: On Feb 25, 2013, at 3:07 PM, Yadin Flammery...@psu.edu wrote: Using standard settings I always use there, shouldn't be an issue AFAIK. LocationMatch /cosign CosignProtected On CosignAllowPublicAccess Off AuthType Cosign /LocationMatch Are you really serving protected content out of a /cosign directory? You've already got vhost-global cosign-protection enabled below. This seems like the problem to me. If you delete the above block, does the 503 go away? andrew Location /cosign/valid SetHandlercosign CosignProtected Off Allow from all Satisfy any /Location CosignProtected On CosignAllowpublicAccess Off On 2/25/2013 1:15 PM, Andrew Mortensen wrote: On Feb 25, 2013, at 12:55 PM, Yadin Flammery...@psu.edu wrote: Ubuntu 12 server apache2 cosign 3.1.2 http and https work fine, but as soon as I include the cosign config https comes back after sign in as unavailable service. URL after sign in is that long valid?cosign string so it would appear auth is working, but cosign on this webserver is not. If the query string is *very* long, it's likely you have the /cosign/valid path cosign-protected. It should not be protected. Make sure you have this somewhere in your vhost's configuration: Location /cosign/valid SetHandler cosign CosignProtected Off Allow from all Satisfy any /Location If you already have that, make sure you don't have the docroot protected using Location, e.g.: Location / ... CosignProtected On ... /Location Using the above will override the /cosign/valid Location context. To protect the docroot, use Directory with the actual local path to the docroot instead, e.g.: Directory /usr/local/share/www-root/ ... CosignProtected
Re: [Cosign-discuss] 503 on Ubuntu
You my friend get the prize! Well ok share with Andrew since he did point out the missing directory ;) Turns out the .ca-bundle extension we use on Red Hat for the combined root and intermediate cert file simply doesn't work right on Ubuntu, I had to give it a .crt extension and then it worked as expected! Ok I'm sure that's not a completely accurate statement as to why it wasn't working with a different extension, and there's probably something else I'm overlooking in the configs, but suffice to say it was cert related :) Given that was the reason but there was nothing in the logs to point at a cert issue, I don't know if this is something logging for cosign could catch or if this would be something to improve in ssl's logging. Thanks to you both for the assist! Yadin --- Yadin Flammer - Systems Administrator College of Arts Architecture, Penn State University 228 Borland Building Office Phone: 814-865-0990 University Park, PA 16802 Dept. Phone: 814-865-1571 Email: y...@psu.edu Dept. Fax:814-863-6227 On 2/25/13 11:45 PM, Preeyakorn Slawski wrote: My system has different environment, but it had the same issue. It might be worth checking the cosign server log if there is an SSL problem. On my server, it was fixed by installing the root CA and intermediate certs which match those of the cosign server. preeyakorn *From:*Yadin Flammer [mailto:y...@psu.edu] *Sent:* Monday, February 25, 2013 11:27 PM *To:* cosign-discuss@lists.sourceforge.net *Subject:* Re: [Cosign-discuss] 503 on Ubuntu Well I found the note on making that directory I missed, my bad, but that still doesn't fix the issue. As a double check I blew permissions on that directory wide open and I still get the service unavailable issue. :/var/cosign$ ls -la total 12 drwxr-xr-x 3 root root 4096 Feb 25 23:06 . drwxr-xr-x 15 root root 4096 Feb 25 23:06 .. drwxrwxrwx 2 www-data root 4096 Feb 25 23:06 filter date command returns proper time as expected in proper time zone. Any other ideas? Yadin --- Yadin Flammer - Systems Administrator College of Arts Architecture, Penn State University 228 Borland Building Office Phone: 814-865-0990 University Park, PA 16802 Dept. Phone: 814-865-1571 Email:y...@psu.edu mailto:y...@psu.eduDept. Fax: 814-863-6227 On 2/25/13 11:05 PM, Yadin Flammer wrote: I think we're likely on to something. /var/cosign does not exist. Does this mean the installer failed in some way, or would this have been created somewhere else based on the OS and apache2 implementation? If it was somewhere else, how would one find it? When you talk about the temp files, would that be in that missing directory as well? As a development note, it might be good to add some logging for these instances so as to not have mystery situations, even if highly unusual. Thanks! Yadin --- Yadin Flammer - Systems Administrator College of Arts Architecture, Penn State University 228 Borland Building Office Phone: 814-865-0990 University Park, PA 16802 Dept. Phone: 814-865-1571 Email:y...@psu.edu mailto:y...@psu.eduDept. Fax: 814-863-6227 On 2/25/13 10:51 PM, Andrew Mortensen wrote: On Feb 25, 2013, at 3:32 PM, Yadin Flammery...@psu.edu mailto:y...@psu.edu wrote: Well normally that block is required for cosign to work properly, though that's likely because we're normally dealing with Drupal sites which are public and login is to get editor access, and it's not doing anything in this case. Regardless, removing that block does not resolve the Service Temporarily Unavailable response. There are a number of reasons mod_cosign will respond to the client with a 503, but most of them have log messages associated with them. After looking through the code, I've found a handful of places where no message is logged when returning Service Temporarily Unavailable, and in all cases they're related to errors encountered when attempting to check the cookie: * the httpd user doesn't have read/write/execute rights to the filterdb directory (/var/cosign/filter by default); * a gettimeofday call fails when preparing to check the cached cookie in the filterdb directory; * kerberos ticket retrieval is configured, but the module couldn't create a temp file to store the data; * proxy cookie retrieval is configured, but the module couldn't create a temp file to store the data The only message emitted when the filter can't connect to any weblogin server is Unable to connect to any Cosign server. Hope this helps. andrew On 2/25/2013 3:27 PM, Andrew Mortensen wrote: On Feb 25, 2013, at 3:07 PM
Re: [Cosign-discuss] Fixed 503 error with Win v3.1.0rc2 - now have the service is unavailable
How often was the app pool shutting down causing the 503 error? On our Footprints server this happens any time Webaccess is in a degraded state. Basically, if the cosign module can't communicate quickly with Webaccess, then it shuts down. I'd call that a bug because in my mind the module should be more tolerant and simply give a timeout error while the gateway is degraded rather than shutting down so we then have to go into IIS and manually restart the app pool. Outside of that, I haven't seen an issue with that system, but that is running 2008 32 bit, not 2008 R2 which I have been unable to get to use cosign thus far. On R2 the app pool shuts down the instant the site is hit the first time, the module simply does not run. I'd love to hear how you got it to work at all as 3.1 fails the same way for me, but it sounds like you had 3.0 running at first? If 3.0 use to work for you but then stopped and just instant fails, I'm wondering if this is the result of changes they made not to long ago on the Webaccess side which seems to have caused compatibility and stability/performance issues for a lot of people/ sites. Yadin --- Yadin Flammer - Systems Administrator College of Arts Architecture, Penn State University 228 Borland Building Office Phone: 814-865-0990 University Park, PA 16802 Dept. Phone: 814-865-1571 Email: y...@psu.edu Dept. Fax:814-863-6227 From: Jeremy Poletto jpole...@psu.edu Date: Thu, 15 Sep 2011 10:20:12 -0400 To: cosign-discuss@lists.sourceforge.net Subject: [Cosign-discuss] Fixed 503 error with Win v3.1.0rc2 - now have the service is unavailable We are running the IIS7 Cosign Module on Server 2008R2 SP1. We are located at Penn State which is implementing Cosign in their WebAccess Single Sign-on solution. We are using Cosign to protect our helpdesk system, powered by Numara Footprints. I'm not sure what started it, but as described in Yadin Flammer's post, we were getting a 503 error with a stopped app pool and error message. After app pool rapid fail, we would essentially have to reboot to fix. Then it was intermittent as to how long it would last till the pool would stop again. As suggested, we downloaded Cosign Module version 3.1.0rc2. That has fixed the errors popping up in the Windows Application Log and stopped the pool from crashing. However, now we have the issue posted by Chris Motch where just about every person - when first logging in through WebAccess/Cosign - gets met with the the service is unavailable blank page. Two things seem to be consistent: 1. When they get this page, if the user hits the refresh button or back key on the browser, they continue to our helpdesk site as if nothing is wrong. This is currently our only horrible workaround. 2. It seems to happen when a user first goes to our protected site in a cache cleared browser session. If the user previously used WebAccess/Cosign to go to another protected site here on campus, such as ITS Downloads, and then proceeds to our helpdesk they do NOT receive the error. I'm at a loss as to what to do. We have many endusers that go to this site to submit tickets for assistance. They are met with an error page and usually don't try to refresh or continue in any way. This is making us look bad to our customers. To implement the new version, I simply replaced the CosignModule.dll and the cosign_schema.xml with the newer version. Did I need to do something else? Was I supposed to do anything with this CosignModule.pdb file? Any help would be appreciated, Thanks, JP -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/__ _ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
Re: [Cosign-discuss] 503 and stopped app pool
Am I to gather that the main release 3.03 simply does not work in 2008 R2? I¹m seeing there are significant configuration and behavioral differences in IIS from 2008, and when I try to make things match up they invariably revert themselves. The DefaultAppPool for example is set to Classic and ApplicationPoolIdentity instead of Integrated and NetworkService like in 2008. Trying to change those only sticks for a short while, then it reverts itself back. I¹ve also at one person¹s recommendation tried to disable 32bit applications in the pool, but invariably that re-enables itself as well. This does of course lead me to question if there are huge bugs in IIS in R2, or if there are other forces at work reverting these that I¹m not aware of. I also find that having the validation key under the cosign section added to the applicationHost.config causes the 503 to go away because it causes the module to become unregistered and therefore not used. If I have this line in place but leave it as the example instead of setting it for our location, then it doesn¹t unload the module, but the app pool shutdown and 503 issue continues. So yea... Any other ideas or do I need to just move to the beta 3.1 because it¹s more stable than the release 3.03? The rapid fail doesn¹t do anything unfortunately, other than make the failure take longer and fill the event viewer. Thanks, Yadin On 8/26/11 9:31 AM, Stucky, David d...@psu.edu wrote: Yadin, Sounds like you are having the same issues on Win 2008 R2 that we were seeing. One temporary quick fix is to increase the specific Application Pool¹s Rapid-Fail Protection settings under Advanced Settings. We ended up with 100 Maximum Failures in a 5min Failure Interval. You could just disable Rapid-Fail, but that would be a bad idea. The better long term fix is to get your hands on Cosign Module 3.1.0 RC2. This release candidate has seemed to fixed our problems with Cosign crashing the IIS 7.5 application pool. It is my understanding that an official updated production release is coming. Thanks David Stucky, CISSP, GSEC Systems Security Analyst Office of Human Resources Information Systems 503 James M. Elliott Building 814-865-4049 d...@psu.edu From: Yadin Flammer [mailto:y...@psu.edu] Sent: Thursday, August 25, 2011 6:47 PM To: cosign-discuss@lists.sourceforge.net Subject: [Cosign-discuss] 503 and stopped app pool I¹m at a loss what is happening as I set this server up in the same method as another that works fine. The only difference is this is 2008 R2 and the other is 2008, so 64bit vs 32bit. When I hit the site, it eventually spits back a 503. I then go to IIS and find the defaultapppool is stopped. The event log says cosignmodule.dll failed to load the data is in the error, whatever that is supposed to mean. I¹m trying to figure out why the module is failing to load and causing the apppool to die. The system log mentions it reported a listener channel failure, again whatever that means. Any thoughts where I can get more detail what is failing? Thanks, Yadin --- Yadin Flammer - Systems Administrator College of Arts Architecture, Penn State University 228 Borland Building Office Phone: 814-865-0990 University Park, PA 16802 Dept. Phone: 814-865-1571 Email: y...@psu.edu Dept. Fax:814-863-6227 --- Yadin Flammer - Systems Administrator College of Arts Architecture, Penn State University 228 Borland Building Office Phone: 814-865-0990 University Park, PA 16802 Dept. Phone: 814-865-1571 Email: y...@psu.edu Dept. Fax:814-863-6227 -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss
Re: [Cosign-discuss] 503 and stopped app pool
Well unfortunately 3.1 doesn¹t change anything, it still doesn¹t work. I also tried the 32bit module on a whim and same issue. I¹m totally lost as to why it ³fails to load² when you hit the website and shuts down the default app pool causing a 503. Is there any log that will tell me something more useful than ³the data is in the error²? On 8/26/11 12:09 PM, Yadin Flammer y...@psu.edu wrote: Am I to gather that the main release 3.03 simply does not work in 2008 R2? I¹m seeing there are significant configuration and behavioral differences in IIS from 2008, and when I try to make things match up they invariably revert themselves. The DefaultAppPool for example is set to Classic and ApplicationPoolIdentity instead of Integrated and NetworkService like in 2008. Trying to change those only sticks for a short while, then it reverts itself back. I¹ve also at one person¹s recommendation tried to disable 32bit applications in the pool, but invariably that re-enables itself as well. This does of course lead me to question if there are huge bugs in IIS in R2, or if there are other forces at work reverting these that I¹m not aware of. I also find that having the validation key under the cosign section added to the applicationHost.config causes the 503 to go away because it causes the module to become unregistered and therefore not used. If I have this line in place but leave it as the example instead of setting it for our location, then it doesn¹t unload the module, but the app pool shutdown and 503 issue continues. So yea... Any other ideas or do I need to just move to the beta 3.1 because it¹s more stable than the release 3.03? The rapid fail doesn¹t do anything unfortunately, other than make the failure take longer and fill the event viewer. Thanks, Yadin On 8/26/11 9:31 AM, Stucky, David d...@psu.edu wrote: Yadin, Sounds like you are having the same issues on Win 2008 R2 that we were seeing. One temporary quick fix is to increase the specific Application Pool¹s Rapid-Fail Protection settings under Advanced Settings. We ended up with 100 Maximum Failures in a 5min Failure Interval. You could just disable Rapid-Fail, but that would be a bad idea. The better long term fix is to get your hands on Cosign Module 3.1.0 RC2. This release candidate has seemed to fixed our problems with Cosign crashing the IIS 7.5 application pool. It is my understanding that an official updated production release is coming. Thanks David Stucky, CISSP, GSEC Systems Security Analyst Office of Human Resources Information Systems 503 James M. Elliott Building 814-865-4049 d...@psu.edu From: Yadin Flammer [mailto:y...@psu.edu] Sent: Thursday, August 25, 2011 6:47 PM To: cosign-discuss@lists.sourceforge.net Subject: [Cosign-discuss] 503 and stopped app pool I¹m at a loss what is happening as I set this server up in the same method as another that works fine. The only difference is this is 2008 R2 and the other is 2008, so 64bit vs 32bit. When I hit the site, it eventually spits back a 503. I then go to IIS and find the defaultapppool is stopped. The event log says cosignmodule.dll failed to load the data is in the error, whatever that is supposed to mean. I¹m trying to figure out why the module is failing to load and causing the apppool to die. The system log mentions it reported a listener channel failure, again whatever that means. Any thoughts where I can get more detail what is failing? Thanks, Yadin --- Yadin Flammer - Systems Administrator College of Arts Architecture, Penn State University 228 Borland Building Office Phone: 814-865-0990 University Park, PA 16802 Dept. Phone: 814-865-1571 Email: y...@psu.edu Dept. Fax:814-863-6227 --- Yadin Flammer - Systems Administrator College of Arts Architecture, Penn State University 228 Borland Building Office Phone: 814-865-0990 University Park, PA 16802 Dept. Phone: 814-865-1571 Email: y...@psu.edu Dept. Fax:814-863-6227 -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ Cosign-discuss mailing list Cosign-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cosign-discuss --- Yadin Flammer - Systems Administrator College of Arts Architecture, Penn State University 228 Borland Building Office Phone: 814
