samba - Aug 2022 - samba-tool error messages: what needs fixing most?

hi,

If you have used samba-tool, you will be aware that it often reports 
simple problems with long messages talking about exceptions and line 
numbers and file names and all-caps error codes. Sometimes, well, 
usually, these messages turn out to mean something like "bad username or 
password" or "samba.example.com is not a real address".

Every so often (but less often than you'd expect) somebody has the 
genius idea that samba-tool could just describe the underlying issue, 
and refrain from the detailed account of subsequent woe. Even Samba 
Developers have that idea, sometimes, but then they look and think "no, 
too hard" and get back to debugging clustered inter-forest symlink 
tevent races with S4U2SELF SPOOLSS ntlmssp_states (or winbind for the 
extremophiles). But NOW I, fully sober, have decided to *actually* try. 
Which leads to the question in the subject: which messages need fixing?

So *please* reply to this message with a samba-tool line that says 
something really stupid, and suggest a better message.

It won't be possible to fix every example, and I will try to be 
cautious. It is worse to hide real problems than to expose everyone to 
horrible noise.


Q: But won't this break the Application Search-engine Interface (ASI)? 
How will we be able to find old posts on stac^H^H^H^H 
https://lists.samba.org that quote the old nonsensical message?

A: Yes. ASI stability is never guaranteed. But you can always get the 
old traceback by appending -d3 to your samba-tool line.

Q: But I like things the way they are. It makes me look like that guy in 
the Matrix.

A: You don't want to look like that guy. Also, try -d10.

Q: When?

A: 4.18, and don't expect too much.


cheers,
Douglas

On Wed, Aug 24, 2022 at 01:22:55PM +1200, Douglas Bagnall via samba-technical
wrote:
>hi,
>
>If you have used samba-tool, you will be aware that it often reports 
>simple problems with long messages talking about exceptions and line 
>numbers and file names and all-caps error codes. Sometimes, well, 
>usually, these messages turn out to mean something like "bad username 
>or password" or "samba.example.com is not a real address".
>
>Every so often (but less often than you'd expect) somebody has the 
>genius idea that samba-tool could just describe the underlying issue, 
>and refrain from the detailed account of subsequent woe. Even Samba 
>Developers have that idea, sometimes, but then they look and think 
>"no, too hard" and get back to debugging clustered inter-forest 
>symlink tevent races with S4U2SELF SPOOLSS ntlmssp_states (or winbind 
>for the extremophiles). But NOW I, fully sober, have decided to 
>*actually* try. Which leads to the question in the subject: which 
>messages need fixing?
>
>So *please* reply to this message with a samba-tool line that says 
>something really stupid, and suggest a better message.
>
>It won't be possible to fix every example, and I will try to be 
>cautious. It is worse to hide real problems than to expose everyone to 
>horrible noise.
>
>
>Q: But won't this break the Application Search-engine Interface (ASI)? 
>How will we be able to find old posts on stac^H^H^H^H 
>https://lists.samba.org that quote the old nonsensical message?
>
>A: Yes. ASI stability is never guaranteed. But you can always get the 
>old traceback by appending -d3 to your samba-tool line.
>
>Q: But I like things the way they are. It makes me look like that guy 
>in the Matrix.
>
>A: You don't want to look like that guy. Also, try -d10.
>
>Q: When?
>
>A: 4.18, and don't expect too much.
Woo hoo ! Douglas !!! Thanks so much for taking
this on ! This would be a wonderful improvement
for our usability.

>?
>?>?>?Q: But won't this break the Application Search-engine
Interface (ASI)?
>?How will we be able to find old posts on stac^H^H^H^H
>?https://lists.samba.org?that quote the old nonsensical message?
>?
>?A: Yes. ASI stability is never guaranteed. But you can always get the
>?old traceback by appending -d3 to your samba-tool line.
>?
>?
Maybe this is what the answer here already says, but as to the questionposed it
seems to me that you don't have to give up one to have the other.
The "new" message could simply and plainly give the direct answer, as
you suggest, and then provide the "old" more technical response
followingthe new message. This would also have the benefit of providing the
moredetailed low level response in the event that for some unforeseen reasonthe
problem was something other than the simple answer.
Still further, and along these lines, it would also seem that your proposalneed
not be limited to case where there is only one possible simple problemat the
root of the error message. In a case where there are severalpossibilities those
could be suggested as just that -- potential issues, andthen also followed by
the full existing error text.
Not to complicate the endeavor, but this also could be an opportunity tosimply
better communicate the detailed low level message.
All in all however, I think that however you decide to implement yourproposal
the end end result will be very much welcomed by theSamba user community. Thank
you for taking it on.