shibd not writing to its log files

[Cantor, Scott]

On 7/20/22, 10:21 AM, "Goldberg, Arthur P" <arthur.p.goldberg at mssm.edu> wrote:

> Let me preface this message by saying that I greatly appreciate the thought and work
> that everyone, including you Scott, have put into creating SAML and Shibboleth, making
> them available as open-source technology to the world, and supporting them with
> documentation, bug fixes, and user support. That is a great accomplishment which all of you
> should be proud of. And we at Sinai appreciate our ability to use what you all have produced.

And I appeciate that, but frankly...

>    But I'm offended by your response Scott because it implies that my intention is to criticize your
> work

That is exactly how I took the statement, because you said "if it were my software I wouldn't have done this", as though there aren't tremendously complex layering issues in a system like this, dependencies up and down the stack, exception handling complexities, and fundamentally in portable C/C++ *no* standard logging whatsoever that can be used.

All logging libraries are bad in this space, and this one is only slightly less bad in some ways, and it's even worse in others.

There's also a cost to trying to detect and respond to every possible crazy thing that happens in modern systems. That cost is not always worth it when the condition is so rare that I can't even recall it ever coming up before (on the shibd side) and takes a minute to check for when the obvious symptom of no logging occurs.

So, no, I don't think it's a good use of time, even *if* the software wasn't at the point of obsolescence and replacement with a completely different code base that will replace all the relevant bits.

I appreciate that you didn't mean to offend, and my obviously flippant response was regrettable, but it had been a long, fairly bad day, and I didn't like the tone of your message. Sorry, that's just how I took it.

> (I did not know who wrote the logging library) and that the only alternatives are that either 1) I
> revise the logging library or 2) the software remains as is.

More than likely those are the two alternatives, and neither's likely to happen because all the time available is spent on replacing this, not enhancing it.

> My intention was to initiate a discussion about design, not who does the implementation.

There's a separate list for that, but more to the point there's a more polite way of doing that when you're *not* familiar with the existing code design. Even filing a bug with no judgement attached is fine. I don't get offended by bug reports. I may not fix them, but they're not insults. But there's a bug reporting system for that.

>    WRT the design of error handling by Shibboleth logging I maintain that it would be useful for
> shibd users to receive error messages in the special situation when shibd cannot write to the log
> files. Such errors would certainly have been helpful for me.

I'm sure it would be, but again, that is a pretty uncommon thing that is very obviously recognizeable, so much so that it was the only obvious explanation when you asked to begin with. Honestly, even understanding how in the heck it even happened would be an essential piece of information for judging the value of doing something about it.

> When presenting error handling I start with the old adage Garbage In Garbage Out (GIGO). I
> assert to my students that GIGO is wrong, and that the adage should be replaced with Garbage In
> Helpful Error Messages Out. In my opinion, that principle applies here.

In my experience, many people don't look at logs, don't even try to read or decipher error messages, and just generally make the time spent on that very secondary to other priorities. That sucks, but it's pragmatic when you have to decide where to spend time.

-- Scott