[eejit]

Ah, I wished I'd found this thread a few hours ago :-)

My workaround for the "NULL variable value - Line 11 of resource file" error was to fill in the blank $USER*$ values by entering dummy values for Windows AD, Telegram and Pushover in NEMS SST. After a restart my notification emails started getting through.

Earlier in the thread someone mentioned not seeing any entries in /var/log/sendemail. That is because there is a typo in the NConf > Misccommands > notify_host_by_email command - it is trying to log to /var/log/sendmail which fails because of lack of permission. Changing the command line's "-l" parameter to /var/log/sendemail gets the logging working.

[baggins]

Okay, the patch has been rolled out.

Please type: sudo nems-quickfix

Then, open NEMS SST and press "Save".

Let me know if this has fixed the issue for you. Thanks all!

I can report that the patch corrects the problem.

Take note that the nagios3 service needs to be restarted as well.

Thanks for the patch!

BR

[Robbie Ferguson]

Just a heads up, as per the changelog, the "sendmail" log typo has already been patched. No need to fix this manually - the patch rolls out automatically with nems-quickfix or just waiting 24 hours.

Thanks all!!!

[baggins]

Earlier in the thread someone mentioned not seeing any entries in /var/log/sendemail. That is because there is a typo in the NConf > Misccommands > notify_host_by_email command - it is trying to log to /var/log/sendmail which fails because of lack of permission. Changing the command line's "-l" parameter to /var/log/sendemail gets the logging working.

That is indeed the case.
However, in /etc/nems/global/conf/global/misccommands.cfg the logfile is defined as /var/log/sendemail. In NConf it is incorrect as you state.

That being said, I did not change anything and I can see entries in the sendemail log file...

BR

[Robbie Ferguson]

Good catch, baggins. I'll fix that in the next release. Regardless of what NConf says, the command will be correct as the nightly fixes automatically patches the file. See https://github.com/Cat5TV/nems-scripts/c...c223b4e66d

[Robbie Ferguson]

**********
THIS ISSUE HAS BEEN FIXED
**********
If you are still experiencing this issue, please do the following:
1) sudo nems-quickfix
2) Open NEMS SST and press "Save"
3) sudo systemctl restart nagios3

All NEMS Linux servers will be automatically patched. If your system does not receive the patch, please make sure your network settings are correct (ie., you have a default gateway specified) on your NEMS Linux server.

Thank you to all participants in this thread both for your help and your patience as we worked together to find and fix this issue.

Robbie // Bald Nerd

[BrendonKoz]

Hello Robbie,

Is there any version numbering bump anywhere in the shell or UI to verify the update succeeded properly? I think it failed last night for me, but worked this morning (after a power cycle). Since I'm not yet 100% certain my notification settings are properly configured I can't be certain a forced failure to prompt a notification will be a good update verification.

[Robbie Ferguson]

Hi BrendonKoz,
The fix for this was a patch rollout, not a point release. Therefore, if it fails one day, it'll self-remedy the next - so no worries. I built NEMS to be reliable and self-correcting.

To be sure, just type: sudo nems-update

If you see errors, let me know. If you don't, just follow the next step (Press "Save" on NEMS SST in this case, then restart either the Nagios service or reboot the NEMS Server).

Note that unlike nems-quickfix, nems-update shows the output of the update - hence why I say, you can do that if in doubt. Though if you already ran nems-quickfix and all is well, it is entirely redundant to run nems-update.  :p

Let us know how it goes.

[BrendonKoz]

That command verified that my 2nd round of nems-quickfix from this morning ran fine. I didn't realize it was not a point fix release (since you mentioned you'd been running v1.3.1 I thought you simply pushed that version live, my mistake!). Thanks!

[Robbie Ferguson]

:) Nope. In trying to replicate the problem originally, I'd reverted my own development server to 1.3 (public release) rather than the 1.3.1 development release it was running. Turned out that had nothing to do with why I couldn't replicate the problem. It was because during development, I'd filled in all the fields in NEMS SST (which "hid" the bug from me). So reverting had the effect anyways, since it meant NEMS SST was empty :)

The wording can be confusing. Hopefully this helps:
nems-update - will check github for any changes to nems components and update them.

nems-quickfix - a sophisticated call wrapper for nems-update. This runs a nems-update, then runs any patches that are included in that update. Usually this happens automatically overnight - but can be a quick ... hence "quickfix" ... way to force your server to have all updates and all patches.

nems-upgrade - this is when we have new point releases. As opposed to patches (ie., fixes), an upgrade is generally new features. Unlike nems-update, a nems-upgrade has to be run manually by the user (I don't force users to upgrade if they don't want to).

Thanks,
Robbie