The cosign login server was designed to work in a Unix-like
environment. I'm not sure how many of the system-level API calls
would work in Windows, but I would imagine significant portions,
especially for cosignd and monsterd, would have to be re-written to
work in a Windows server enviro
2008/10/23 Jarod Malestein <[EMAIL PROTECTED]>:
> As far as which flavor Linux, that is entirely up to you and what
> meets your neds. At U-M, we use a customized distribution of Linux.
> As to what others are using, and their experiences, I'll leave it to
> them to describe any problems or gotch
I wrote a couple months ago about this problem and got no answer, so I
worked around it, however someone else has now contacted me with it so I
guess it is time to try again and see if anyone has any suggestions.
In the apache ssl error log, I am getting " access to / failed, reason:
verificati
On 23 Oct 2008, at 13:31, John Schubert wrote:
> This used to work in apache 2.0 and 1.3 so I am guessing apache
> actually
> changed something, but I have had no success so far finding any
> answers.
> If there is any other info I can provide that would aid in
> troubleshooting this, I would b
Since I am not a programmer, an pointers to where you had to make
changes for 1.3 would be helpful and/or pointers to apache docs you used
before. I am happy to attempt to muck around in the code, just don't
expect anything pretty from me. :)
-John
Wesley Craig wrote:
> On 23 Oct 2008, at 13:3
A question for anyone running production cosignd/authN servers with
multiple replicating hosts using a round-robin: how do you handle
failures?
For example: do you have documented procedures for your staff to
immediately remove down hosts from the round-robin, or do you weather
the potent
On 23 Oct 2008, at 13:58, John Schubert wrote:
> Since I am not a programmer, an pointers to where you had to make
> changes for 1.3 would be helpful and/or pointers to apache docs you
> used before. I am happy to attempt to muck around in the code, just
> don't expect anything pretty from me
* Jorj Bauer <[EMAIL PROTECTED]> [2008-10-23 20:08]:
> A question for anyone running production cosignd/authN servers with
> multiple replicating hosts using a round-robin: how do you handle
> failures?
>
> For example: do you have documented procedures for your staff to
> immediately remove
Since DNS changes can take a while to propagate, we do not remove down
hosts from the round-robin. Instead, we bring up a new network
interface on one of the other hosts, with the IP address the down host
was using. cosign's replication is not explicitly designed to deal with
this type of s
On 23 Oct 2008, at 16:28, Mark Montague wrote:
> The cosign filters are good at dealing with cosignd hosts that are
> down, so the main reason we move the IP address to another machine
> is so that some percentage of users don't get a "Server not
> responding" error in their web browsers when
In short: DNS round robin is load distribution (at best) and provides
nothing for failover or high availability.
I'm well aware of this; that's primarily why I'm asking what people do
for their installations. I'm curious how institutions mitigate the
risk of RR DNS causing service hangs. If
11 matches
Mail list logo
