add upload_logs command

[nlef]

Added bot command /upload_logs
the command is added automatically to the text of error messages for easy loading of logs
@CODeRUS @feadot pls test this)

[CODeRUS]

please add command itself and empty newline after:

command
command output
empty newline

[CODeRUS]

also as it not using sudo, might need checking result of dmesg grab. if no permissions, need to ask user to unrestrict dmesg calls by:

Creating a file /etc/sysctl.d/51-dmesg-restrict.conf with content:

kernel.dmesg_restrict = 0

and reboot. Or issue sudo sysctl kernel.dmesg_restrict=0

[CODeRUS]

любо

[feadot]

Вообще мужчины!

[xdadrm]

@nlef @CODeRUS

while it is likely useful for many to get their logs analyzed automatically, I personally prefer not to send logs anywhere - not automatically nor by accident. I believe it would be good to have such features configurable.

If you're open to it I could take a stab at that - perhaps (ab)using the 'hidden_bot_commands' or a new 'disable_bot_commands' and submit a PR ?

Спасибо !

[aka13-404]

@xdadrm I agree with your sentiment in general. The question is though, in what extent you consider sending logs a problem. I would expect, that upload in an archive should be a problem in that case as well.

Another question is, what do you consider protection enough of sending/not-sending of the logs. If we are talking of not sending/uploading them anywhere by accident, hidden_bot_commands should be covering your usecase. Considering pasting an entire command by hand into the chat with the bot a likely accident and protecting users against it sounds like unnecessary overhead.

You can copy-paste a curl command into your linux instance by accident, which would upload your private keys to some remote server, and yet I doubt that a lot of users expect protection against such copy-pasting.

Please elaborate in which extend you want the protection to be available, and what measures you want to implement for it.

[xdadrm]

@aka13-404 thanks for your thoughtful response.

Simply clicking on "Upload logs to analyzer /upload_logs" in a notification will trigger the upload, that's the main culprit.

I was envisioning disabling the /upload_logs altogether, including the removal of mentions in notifications. Abusing hidden_bot_commands to achieve that could be an option (if hidden, then also disable the commandm or at the very least disable the link in the notification).

A cleaner but more involved approach could be to introduce a new config option such as disable_bot_commands, that would be used to turn off features one does not want, for example shutown.

[aka13-404]

That is a good point, I totally forgot it popping up.
But that is an issue with the inconsistency of the confirmation need. Like how /shutdown and /reboot require confirmation, macros have require_confirmation_macro, but then some stuff does not.

Do you feel that if there would be a list of stuff needing confirmation, like there is a list for hiding macros, a la
needs_confirmation: power, shutdown, reboot, upload_logs would cover your concerns?
I kinda don't want to remove it from the crash message, because we use the analyzer as the main tool in our support group in tg, where people come with issues and problems, and it simplifies the process a lot.

I also at the same time don't want different behaviour for different entities in "hidden_bot_commands", and don't want to baloon the config with a whole new option, which would have different behaviour for different entities again - would be pretty stupid having the command disabled, but it appear in the crash message.

[xdadrm]

Thanks again for sharing your thoughts, I completely follow your thinking.
I myself forgot the possibility of asking for a confirmation, and indeed, having that before actually uploading would be sufficient.

Both needs_confirmation, like disable_bot_commands, would add bloat to the config - and so while that functionality would be appealing, probably not worth the effort.

Even making hidden_bot_commands accept something like :
power = hides the command
power* = hides and disables the command (and mentions in notifications)
power? = hides and requires confirmation

would add (unnecessary) complexity ...

[aka13-404]

Eh, we already have the macro thing going on, and the same separation with bot_commands and macro_commands on the notification side, so it would only be logical to have the same for confirmation, that's justifiable, I think.

Feel free to take a stab at it, if you feel it, but we discussed this internally, and it makes sense to both of us. I created a ticket #345 to track progress/discussions in it. If you don't feel like it, we discussed it internally, and it makes sense to both of us, and it's going to be implemented sooner than later.

[xdadrm]

That looks great to me - thanks a lot !
I'll have a look at how to best implement that, you might be much faster than me though :)