• 1
While I empathise with the "the tooling gave you enough information you could have figured it out yourself" nature of the post (and have been on the receiving end of a bunch of reports like that), it seems to me that 61 lines of output (of which "If you believe $TOOL should be allowed... access on the $FILE_FOR_TOOL by default... then you should report a bug" is most of the volume, which implies to the skim reader it's more important) isn't exactly helping the less-than-expert user understand that it's not working because they're "doing it wrong".

A couple of suggestions:
1. I'd suggest not displaying the catchall information if there are is at least one (significantly) higher confidence option, unless there's some sort of "I don't like the advice, give me something else" command line option (eg, a --verbose, or --generic advice or --show-workarounds). The default advice can always end with a single line that says something like "run $FOO --show-workarounds for more alternatives". (If there's nothing else to suggest then yes maybe show the catch all by default.)

2. The first two options are functionally identical problems ("the file has the wrong label") yet (a) fail to say explicitly "the file has the wrong label", and (b) fail to point out that there are two ways to have it get correct label (ie, "put it in the standard directory" and "manually set the label on the file") rather than, eg, just being to cargo-cult things to do (the third one, the generic work around, is very cargo-cult). Even just starting with "OpenVPN is not permitted to read files labeled $LABEL_ON_PROBLEM_CRT_FILE; it needs a different label" would seriously improve the usability of the advice for someone in a rush. (I know that's what the audit message means, you know that's what the audit message means, but the average user reporting it to bugzilla clearly doesn't: if they did understand, they'd have relabeled without even needing setroubleshoot.)

Just to be clear, I think setroubleshoot is a huge improvement on the pre-setroubleshoot days. But I also thing there's scope to divert more of the "it's broken, please fix" generic reports by having it provide advice it has figured out in a more readable manner (ie, concise, to the point, with specific fixes).


PS: If there's an obvious way that users should be getting those certificates onto the system in such a way that they automatically get labelled correctly, it'd be a really good idea to document that prominently. If every approach requires "do something then run restorecon" then IMHO that's a usability bug, since it's a poor solution to the average use case for using OpenVPN (viz, someone gives you a certificate, you copy it onto your system and try to use it). Just saying.

These are all good ideas, and something we should consider for our next redesign, which should be happening in F21 with full integration into journald. Makeing automatic messages that do not say something stupid is sometimes difficult. But I agree in this case giving the user the option to submit a bug, should be buried.

I also agree that the real bug here is NetworkManager, which I believe the user used to load his Certificate should have fixed the label or copied the Certificate into the ~/.cert or !/.pki directory with the correct label, then the user would never have seen this issue.

  • 1

Log in