Phil, are you by chance running spencer in another CRON Job?
I’m still baffled by the fact that if spencer is disabled (false), that the issue happens. I will toss you a special script which removes spencer from the script to see what is happening here. Baffled I say!
Feel free not to use it, is not like it comes preinstalled with the truenas. You can always schedule trunes to run the tests and then check the results. Beside the code is open, you can edit and check what is doing.
One issue that @wmo brought up, that you can’t protect yourself against by “checking what the code is doing” (paraphrasing), is that the script was pulling code from a repository that Joe doesn’t control, whenever a user updated or installed multi_report. That process means that even Joe can’t be sure what code ends up getting placed on the user’s system.
The repository in question appears stale and may or may not be protected by 2FA.
Depending on the password discipline of the repository’s owner, there is risk of password reuse.
Like most of us, the owner of the repository has at least one email address that is part of (at least) one known breach. Unfortunately, today this is more the norm than anything else.
If passwords contained in the breach are reused on github and/or the email linked to github, that account is essentially breached.
I’m still patiently waiting to understand if there Is something i can do to be deleted from the list of “security issue” you provided days ago. Nor for the respect i have for Joe and for the multi report users.
Because if really i have made some mistakes, i take my responsability part and i will do what I can to fix them
I didn’t claim that your code had any security issues, as I have not reviewed it. I was pointing out that Joe’s situation was that he was extending his trust of others on the internet to his users, while running these other people’s code as root. And I suggested that he warn people that he was doing that.
So, hopefully, your code doesn’t do things like opening files for write as root in its current directory, without first confirming that the current directory isn’t writable by non-root users. A user who could create a symbolic link from that directory could wreak havoc on any file they wanted to.
Thank you and 3.13 will be out hopefully this weekend. I just want to do my best to test for as many different issues could come up, but I’m am 100% certain there will be a new issue, always is.
I completely and 100% agree. While people here may trust what I am doing, there is still trust on the other folks information. I do plan to mitigate most of it but not certain I can mitigate all of it. I think the only way to mitigate it all is to have Multi-Report become part of TrueNAS, something I have wanted for a long time.
@oxyde You have been doing fantastic. You are doing what you can to make the email system just plain work and I know it has not been easy. To mitigate the concern @wmo has, I may need to incorporate the Sendemail.py as a function within Multi-Report. You would do your dastardly deeds, I could review it and hardcode it into Multi-Report. I do know some Python commands like opening, writing, and closing files so I would have some clue as to what I was looking at. I intend to do this with the SMR checking, just make a function and keep it inside Multi-Report. With all that said, I still think you should continue to offer Sendemail.py to the community as others may desire to use it for a personal script.
I have a script which has a complete list of commands used in the Multi-Report script and several of those commands are “privileged”, for example smartctl which is one of the main commands. The goal is to figure out how to get this script to not display commands it cannot perform, so I will be doing what I can to figure this out, or to mitigate what I can over the next few weeks.
I have been wondering this as I’ve been reading along. Does multiple report fill a niche that is already catered for in the enterprise edition? Is this even used in some business settings?
It looks like this is a widely used script, so is it worth suggesting iX adopts the script as a feature request?
Caveat: I do not use multi report, and I don’t understand the technical details of the steps everyone has taken, but I do have a feel for the effort put in and the community benefit to this provides.
Or at least, help out a bit more? Even if they do not want to incorporate it directly, they could submit code via PRs or maintain it?
It clearly is a very popular community script, and “community” seems to be something iX is focusing on now. Renaming the product community edition and doing a podcast is one thing, but why not actually participate in it.
First, thank you for the continued development of this tool. It has been very helpful to me over past years.
I just updated to the latest version 3.1.2 and I see that there are now additional modules that are installed. The Drive_Seltest was automatically installed, but the Sendemail tool was not. Perhaps this is because I am on CORE and it is not needed. I installed it manually nevertheless from the Github site. I noticed that on Github the latest version in 0.09 while the multi_report update shows that 0.13 is available. Unfortunately, the -update option does not update the Sendemail module. Please let me know what I am missing. Thank you!
Version 3.13 will update everything properly. Hopefully I will post it today. It has passed all of my testing, just need to remove some added comments I use for troubleshooting.
WARNING! – AFFECTS SCALE ONLY
Do not upgrade to sendemail.py version 0.13. You may not be able to send email in SCALE.
I recommend you edit the file mr_sendemail.py and change the version number to 0.13 to fake the system out that an upgrade is not required. When version 0.14 comes out, that would replace 0.13 (fake and real). I got lucky, I had an old copy.
Version 0.09 if on my github account if you need it in the meantime, you can grab a copy and edit the version number if needed.
NEW VERSION OF MULTI-REPORT and DRIVE-SELFTEST
I dropping a copy of Multi-Report v3.13 and Drive-Selftest v1.03 on the github site. You should be able to use the -update switch to download and install the new version of Multi-Report. After that if you have automatic update turned on, you will receive those other updates.
AGAIN I SAY, change your version of mr_sendemail.py to version 0.13 if it is version 0.12 or earlier. And I have 0.09 on my github account if you need to grab an older copy.
Meanwhile Joe help me understand whats Is going on for him that make the script fail… For what can be usefull 0.13 for me work without issue on 2 different system.
If someone else encounter problem, following he advice to use an older version for keep MR working, keep at least the 0.12 (on GitHub there are all version)… but due to the security improvement of the 0.13 i would suggest to use that version. In case of problem i’m here to help
@oxyde The issue has been identified as a permissions issue. The new requirements you placed on the script makes it not work for me. I suspect for some people it will work, some it will not work.
I have sent @oxyde an email on this and I’m sure sometime tomorrow he will address it.
If you happen to download version 0.13 and it fails on you as well, the quick fix is to comment out lines 69, 70, and 84 id the python script. (Use a # at the front of the line)
Me not being a permissions expert, I have no idea what I’m doing in this area. If this does become a thing, then this needs to be spelled out in the User Guide.