Multi-Report

Do note that the automatic update is not mandatory, hence you can validate what to run as root with cron.

It would make sense to mirror the dependency scripts into your repo, rather than relying on direct installation of a third party script, at least this allows you (@joeschmuck ) to verify that you are happy with any dependency updates that you publish.

3 Likes

Given this I would be very interested to hear a similar evaluation of TrueNAS-Report and if there is anything in your estimation that could be improved from a security standpoint.

@wmo
You make some very valid point. I will address those when i return home today.

In the meantime, and this is sincere, if sdisk, sgdisk and smr script were not downloaded, besides needing to run the script as a privledged user, what other security issues are there. And is there a better way to run a few privileged commands?

Thankyou for an honest and critical review. It isn’t fun to hear but i hear you.

2 Likes

Joe,
Just wanted to say ā€˜thanks’ for all the work you have done with this script. It has really helped me keep tabs of my system over the years.
BTW- the update worked flawlessly- using Truenas 13 core.
Really appreciate it!
Thanks!

2 Likes

@wmo
Now that I am home, I can address some of the issues you noted.

Nope, I did not hear about that but I did just look it up, seems like a large set of vulnerabilities and not just for TrueNAS. The problem here is if we didn’t have hackers, software would run faster, security would not be an issue. But hackers are here, I’ve had my identity stolen about 6 years ago, really sucked! and countless times personal information has been taken. These problems will not go away unless we start taking off fingers for each offense. You can’t use a keyboard if you have no fingers :slight_smile: (I am partially joking)

First the Downloads:

  1. sgdisk and gdisk were both from the FreeBSD repository, I personally retrieved them and built them on TrueNAS 13.x. They are only used to obtain a copy of the partition table, something a person made a request for. This was only needed for CORE, as SCALE has these two preinstalled. CORE is going away so this will not be an issue in Version 3.2.
  2. The SMR script, yes I agree that there is a security risk there. To help reduce that I will incorporate the essence of that script into Multi-Report in Version 3.2. It is only a small script to examine the drive model numbers, fairly easy to address.
  3. Sendemail.py download, well that could have been solved by iXsystems by simply replacing the sendmail program with the new fixed version which came out 6 months ago, and still can be applied to 25.04 if they desire, but I was told by iXsystems that they will not bring it back due to security concerns, which if it is a security concern, why does it still exist and being used by the BSD/Linux community? Exim and many others had the exact same security issue (from Dec 2023), they all plugged the hole in 2024. Personally I would love to see sendmail return as it worked very well and while @oxyde has done a fantastic job trying to fill this gap for us, It is probably something he will not want to support long term, even if he thinks it is okay. A more permanent long term solution is desired.

Actually I take this very seriously which is why I have always said that I desire the best product I can create, and this includes a safe script. I am the only one who has access to my Github account, I considered sharing however that left me open to others making a change I would not feel comfortable with and I can be picky at atimes. Having a significant security background myself for the past 43 years, I am trying to ensure there is no security or data safety issues. And it doesn’t matter if it is a corporation or Little Dickey at home with his/her 2TB of storage, it is all important to someone. I am not an IT person so security from an IT perspective is limited to what the US Government requirements are on classified systems, of which back in the 1990’s I was a computer security officer for my command. Times have drastically changed since then. This is no where near what a true Security Officer’s level of knowledge is today, but I have been to a lot of training over the past 30+ years, several times a year. But I do fully understand the level of trust I have by the community here.

And I hope you realize that I take this seriously which is why Version 3.2 will have limited security risks and plenty of Warnings, Cautions, Notes included. Should I include ā€œUse at your own riskā€? I personally do that with anything I get for free off the internet, for example ā€œMacrium or Acronisā€ free versions, it is a risk regardless of how large or small a company is. TrueNAS is also a risk. And while we all hope the risk is minimal, it is a risk.

Please understand, I’m not taking offence to your postings other than saying that it was reckless, I am taking them and using them as constructive advice, even though the tone of the messages really didn’t feel that way.

Version 3.13 will be out hopefully this weekend to address the update issues, which I do not see as critical, just a pain in the neck.

Version 3.2 I will start working on afterwards. However realize that there will remain some risk based on what I understand right now with the need for a privileged account. I will have to think about how to approach this.

Bill, if you have further concerns, please let me know, but please do not make this a finger pointing and/or hostel environment. There is no room for that on the forums. I am here with the best of intentions and to help the community if I can and factual data is good for me to use. I even respond well to informed opinions.

Cheers

11 Likes

Very good reply. We understand that iX is a business, and has to keep focused on enterprise customers to pay the bills, but we poor souls that have to make do with the Community version do appreciate the effort you and @oxyde put into making the script work again - and without any help from iX.

2 Likes

Can’t help but chime in to clear up some obvious confusion on the removal of sendmail. The sendmail that was being used was NOT the upstream sendmail that everyone thinks it is. It was a shell script, that called a python script that we (iXsystems) wrote years ago. That python script simply wrapped around our mail.send API.

The traditional sendmail program was never used. We removed a faux sendmail. It was named ā€œsendmailā€ since that was the standard MTA for freeBSD. Debian, however, doesn’t ship with sendmail, it ships with exim as its MTA. As you all quickly found, it seems to be locked down out of the box to not even allow mails to be sent externally.

Either way, I thought it would be best to clarify everyones perception on what ā€œsendmailā€ is in this context.

EDIT: The faux sendmail was added to sudoers configuration file as a script that could be called by ANYBODY as root with NO PASSWORD. So when we got some embargoed reports from ZDI about some hacking, we did a quick review of our code (before they gave us the official reports) and immediately found this to be a significant (frankly ā€œnoobā€) mistake on our side.

7 Likes

I really appreciate you providing that information, that is a big difference from my trouble ticket response. The root thing makes a lot of sense to pull it.

1 Like

If I recall correctly …

(Hello Joe - all working: my email subject is ā€œSMART test results for TrueNAS - all is wellā€ and the script is running just like it used to run. I was getting, and I am still getting, the text sections. No errors).

1 Like

@E_B Thanks for the feedback. Hope they keep working without issue.

@joeschmuck

The script is working from cron on one server and while it works on the other no emails are being sent. Does it make a difference what type or how the dataset was setup?

On the system that is sending emails from cron, the dataset is set to POSIX for ACL type with Owner and Group as root and the cron job is set to run as root.

On the system that is not sending email from cron the dataset is set to SMB/NFSv4 for ACL with Owner and Group set to apps and the cronjob is set to run as root.

The script on both used to work before the latest Truenas update which removed their insecure wrapper (fake sendmail) script. So I’m thinking it is an issue with the particular setup on the system that won’t send emails from cron for your script.

Just for be sure: from cron before run the multi report you cd into the folder?
Did you grab anything/some log from the sendemail folder? If yes i can give It a look

@PhilD13 Read the Multi-Report Quick Start Guide, it specifies the CRON command line data required. As @oxyde stated, it could be your CRON setup. The other things you listed should have nothing to do with the script running or not. And it does need to be a privileged account. I will be working the security angle in the near future to do what I can to reduce that concern.

1 Like

@joeschmuck

Apologies for the delay. I was clearing the driveway from the weather yesterday and some of the delay was I wanted to try some tests based off of the config file compare. The cron path is significantly the same on both systems and follows the general guidelines suggested in the instruction files for the script. The only differences were what I posted earlier for the datasets. The paths to the script are correct and scripts have been on the same path and cron setup since I first installed your script on Bluefin on both servers.

/mnt/mypool/general/scripts/multi_report.sh

/mnt/mypool/Phil-Neo1/scripts/multi_report.sh

@oxyde If the email does not get sent from cron, then there is no sendmail_log file created. If the email is sent then a sendmail_log file is created. Other than a minor expected differences, the sendmail log files from both systems are essentially the same. The one that is sending emails does show a soft error: >> Soft warning: something wrong with 1 or more attachments, check logs for more info >> recorded at the end of the file. The soft error does not appear to be significant at this time as emails are being sent from this system, but I don’t know yet what is causing the error. If you want to see them, I’m happy to post or provide them.

Each system cron is set to run at midnight (0 0 * * *), and are run as root user. stdout and stderr are both unchecked and script enabled is checked. Like others until the recent update of Truenas, I have not had any issues with either system running the script.

I ran a compare of the two systems config files. While they are not significantly different in configuration (reflecting the individual systems/drives/paths) there was an area that is different, and it appears the issue lies in this area.

On the system that works the auto updates are configured as this on the system that works:
External_SMART_Testing=ā€œtrueā€
Check_For_Updates=ā€œtrueā€
Automatic_MR_Update=ā€œfalseā€
Automatic_Sendemail_Update=ā€œfalseā€
Automatic_Selftest_Update=ā€œfalseā€
spencer_enable=ā€œtrueā€

On the system that will not send email the settings for the same are:
External_SMART_Testing=ā€œtrueā€
Check_For_Updates=ā€œtrueā€
Automatic_MR_Update=ā€œtrueā€
Automatic_Sendemail_Update=ā€œtrueā€
Automatic_Selftest_Update=ā€œfalseā€
spencer_enable=ā€œfalseā€

On the system that won’t send an email from cron, If I change the spencer_enable="true" , then the script will send the email.

On the system that sends email, if I set spencer_enable="false" , then the script will not send an email.

I ran tests on both systems by directly running the cron task manually from the GUI, and having the Truenas GUI run the cron task automatically by setting a time a minute from present time so it would auto run the script with no interaction by me. I also ran the script manually with a ssh session, both from a linux (fedora) command line and powertoys (windows) command line.

Clearly an attachment issue.

I want to understand this clearly as I am confused, You had Snow? I got some of that white fluffy stuff this morning when I woke up, it was on the roofs. the last time we had snow was in 1994 I think, been a while. No need to shovel, it was a dusting. I live a few miles north of the Florida border, snow here is rare.

Back to the topic at hand, are you saying that one system, works fine with spencer enabled and one system works fin with spencer disabled? Or if you have spencer disabled on both then all works fine?

And don’t kill yourself moving that white fluffy stuff, had a friend thinking he was a young man, he was in his early 50’s and put himself in the ground. After that I decided it was time to seriously consider retirement.

Got it! I turned Off spencer and have the error.

Working the solution and it should be quick. Look for an email shortly.

Edit: I thought I had the error, it looked like it until the email finally showed up.

We can troubleshoot this in a message vice here and then report the findings when we figure it out. Nope, couldn’t be something simple like an attachment issue. Although I do think it is an attachment problem on my end.

Sounds good. You figured it out but yes if the spencer option is turned off the email does not get sent on either system and if the spencer option is turned on then the email does get sent on both systems.

I grew up in Baton Rouge and never saw much more than a dusting or maybe an an inch or two that melted when the sun came out. Moved to Wisconsin for work and after 30 years there retired and moved back to be warm and get out of the snow. We live near Lafayette now and what does it do? Snow 9 inches of heavy wet snowman snow, deeper in drifts, then the temp went down to 3 degrees overnight with Hoar frost on everything this morning. Reminded us of Wisconsin this morning. Still have some appropriate cold weather gear and boots, a couple snow shovels and the tractor loader. Did the driveway with the tractor and minor cleanup with the shovels. Learned in Wisconsin how to move snow without killing oneself or tearing up the gravel/scarring up the concrete drive. I actually enjoyed being out in the sun in 28-30 degrees and clearing the snow.

@PhilD13 thanks for the detailed explanation!
The sendemail log related to the ā€œsoft errorā€ should show what attachment couldn’t be managed, and the exception raised… this can be usefull to isolate what’s going on.
In the same way, the purpose of this message Is ā€œok, something wrong with an attachment, i warning you but show must go onā€, so i expect that the script shouldn’t fail entirely (not sending email at all)… And the fact that no log Is generated when you don’t receive the email put me to think that the sendemail hasn’t been neither invoked (or at least fails from beginning, before generating the file). @joeschmuck don’t know if i’m already late and you have debugged the problem, in case let me know if i can do something

Joe was able to reproduce the issue on his end by enabling or disabling the spencer script.

I have confirmed both servers will send the email when spencer is enabled and cron is set to send on a schedule. However, this morning the server that has not been having an issue failed to send an email and the one that has been failing to send an email sent one. Though the settings are now the same in both servers to use the spencer script.

I think the soft error is from the spencer file attachment. It’s the only attachment listed in the sendmail log. I agree I don’t think raising an minor error would stop mail being sent.

Based on above I suppose there could be a race condition where stuff in the /tmp directory gets deleted before the email gets sent and the email faults trying to get a now non existent file, but this is just speculation right now.