An open discussion list for topics related to the eduGAIN interfederation service.

[Chris Phillips <Chris.Phillips AT canarie.ca>]

Problem detection is a solved problem in the Nagios world. Maybe leverage
it's flap detection technique or the whole thing as the engine and
interface with it via APIs or other mechanisms?

Leveraging the notion of requiring multiple failures before truly
declaring a problem would be valuable. Having a '3 strikes and your down'
assessment model is better than single error and your down one. It allows
a soft failure of intermittent connectivity to be absorbed and avoid the
alerts that were seen I suspect.

Nagios is also multi-node capable so that could be leveraged as well, but
may be overkill if the soft failure approach improves things.

C



On 2017-09-20, 3:41 AM, "Miroslav Milinovic" <miro AT srce.hr> wrote:

>Miro is reading this thread and traveling this and next week :-)
>
>BTW the error is registered, e.g. for this SP visit
>
>https://monitor.edugain.org/coco/?show=list_sp_tests
>
>and set the filters CoCo found and IsChanged  to "All"
>
>You'll see "Error fetching PrivacyStatementURL" on September 2.
>
>As I wrote earlier we are working on improvements and any (concrete)
>suggestion from users/interested parties would be much appreciated.
>
>Miro
>
>On 19-Sep-17 14:11, Ioannis Kakavas wrote:
>> Hi Peter,
>> 
>> On 19/09/2017 02:51 ??, Peter Schober wrote:
>>> * Lukas Hämmerle <lukas.haemmerle AT switch.ch> [2017-09-19 13:26]:
>>>> The CoCo monitor has sent out quite a few of those false positive
>>>>check
>>>> mails in the past weeks. Some of them then ended also up in the
>>>>eduGAIN
>>>> e-Science Support ticket queue because SP admins were asking us what
>>>>was
>>>> wrong with their SP.
>>>
>>> Then why not tell them that this was a mistake and that there is
>>> nothing wrong with their entity? (If that's in fact the case.)
>>> If you can send out emails claiming someone else did something wrong
>>> you can always send apologies, too, no?
>> 
>> I would argue this is not necessary.
>> 
>>> (I don't insist on any apologies, though, what I want is clear
>>> answers, and ones that don't take 2 weeks for already sent error
>>> reports.)
>>>
>>>> My guess is that the CoCo check failed to download the privacy
>>>> statement due to some temporary connectivity issues.
>>>
>>> From the URL I previously sent this can be ruled out for the entity in
>>> question: In all paged results available here there's not a single
>>> error of any kind, AFAICT:
>>>
>>> 
>>>https://monitor.edugain.org/coco/?f_id_sp=1447&f_entityID=vetuc&f_coc_fo
>>>und=1&f_last_seen=1&page=1&f_order=ts+desc&show=list_sp_tests&f_is_chang
>>>ed=1
>>>
>>>> However, only the admins of the CoCo monitor might know more for
>>>> sure.
>>>
>>> The SP said asking at <monitor AT edugain.org> "didn't work" (I have not
>>> checked back with them what they meant with that, specifically) and
>>> that asking at <edugain AT geant.org> next they got Ioannis telling that
>>> their entity is "probably" fine (I'm retranslating from German into
>> 
>> My reply was :
>> 
>>  "Thank you for the notification. As you also concluded we cannot see
>> any issue with your SP being compliant to the Code of Conduct. We have
>> forwarded this to the responsible team for the monitoring infrastructure
>> and we will let you know if we get any additional feedback. "
>> 
>> 
>> To which the entity administrator replied something along the lines of
>> "thanks for the feedback we won't change anything. If you hear some
>> additional feedback, let us know" . You can ask them for the verbatim
>> answer.
>> 
>> Miro didn't have any additional feedback, other than that they are
>> working on enhancements and they will get back to us if/when they have
>> news.
>> 
>> 
>> Given the above and the communication we had with the administrator, I
>> don't see why we left them hanging or why they should be still waiting
>> for something. We closed the ticket, but I would have nothing against
>> sending them an email to let them know that we didn't get any additional
>> feedback and we still think this was a false positive ( even apologize
>> on behalf of the monitoring service for it ).
>> 
>>> English here, I don't have the reply at hand verbatim) and that this
>>> will be looked into.
>>> Hence me asking two weeks after the notification what the verdict is.
>>>
>>>> Miro and team (who are operating the CoCo monitor) are informed
>>>> already about this issues. Also about the suggestion to improve the
>>>> emails to include the cause of why the check supposedly failed.
>>>
>>> Yes, adding the error itself to the message is certainly necessary.
>>> And avoiding sending false positives to entity owners in the first
>>> place, but we all make mistakes and that's an issue *if* someone told
>>> them that this indeed was a mistake on behalf of the eduGAIN monitor
>>> and not their own fault. (I can live with the fault being mine, too.)
>> 
>> I agree it would be great to get rid of all those pesky false positives
>> but we should make do with what we have. As Lukas said, we have
>> forwarded the feedback to the service owner.
>> 
>>>
>>> Finally, I wasn't aware the eduGAIN monitor contacted entity owners
>>> directly at all (but I may have missed that since I wasn't able to
>>> attend recent eduGAIN SG meetings) and did not involve the federation
>>> operator in any of this. When the answer to questions about the error
>>> report is "ask your federation operator" anyway (i.e., the stagtegy is
>>> to play this via the hierarchy when it's convenient) why not always
>>> communicate through the federation operator, or at least let the fedop
>>> know there /are/ issues with some of its entities, e.g. in Cc: ?
>> 
>> +1 , I guess Miro is reading this.
>> 
>> 
>> Cheers,
>> Ioannis
>> 
>>>
>>> Maybe that's not an option for federations with dozens or even
>>> hundreds of SPs in eduGAIN. OTOH as a fedop I take it upon me to
>>> curate and produce proper, error-free, rich federation metadata, so I
>>> certainly want to know if any of my entities fail to conform to
>>> published specs!
>>>
>>> Best regards,
>>> -peter
>>>
>>

Attachment: smime.p7s
Description: S/MIME cryptographic signature