The log files may not have shown the transition from 200 to 500 this time as they were from the last upgrade. The previous logs contained that transition.
Here is the output from the reconfigure_nagios.sh, the warning at the end is normal and expected:
Thanks for running the reconfigure. I just wanted to make sure it ran without any errors.
The only thing left to do it to rerun the upgrade and capture the errors so we can see what is going on.
Or, you can open up a support ticket by sending an email to [email protected] with a link to this post for reference.
That way we can gather more information from the server to help out in this issue.
Be sure to check out our Knowledgebase for helpful articles and solutions!
I discovered if I chmod -R 750 /usr/local/nagiosxi/html as sort of a anvil on the head of the issue, the upgrade works correctly. I've tired to narrow down the specific directory/file that causes the problem, but so far no luck. Any ideas? Its worth noting in the past, upgrades worked with no issues.
I figured it out, and I am at a loss.
/usr/local/nagiosxi/html/includes/phpmailer/PHPMailerAutoload.php gets created with 0600 permissions. I changed it to 0640 and the install completed. No other changes were made. I.. don't understand.
I wasn't ignoring you when you said "capture the errors", it's just that there were no more errors to capture. I pretty much posted everything I had, from the upgrade.log to the apache logs I have.
That said, I guess the PHPMailer alert in the apache logs wasn't a false alarm. Although I'm really not understanding how that breaks this install such a substantial fashion. And this is a new file, it didnt exist before the upgrade, so I'm even more confused as to why this only seems to be isolated to me.
finally, it seems the ndo2db binary in /usr/local/nagios/bin/ was created 700 so wouldnt start, so the permissions on that were wonky also. No idea why. Changing that fixed it and I now have a functional test system. Now I get to do all of this on prod.
I don't know if the creation of those files as 600 and that affecting the upgrade is understandable behavior, but if would be cool if something could check for that in the future. This one was a headache.
That is the strange thing, I saw the errors but I checked the permissions and they are the same on a few of my systems so that is why I didn't think it was the cause of the failure.
The ndo2db permissions are strange, are all of the binaries set to 700?
What are the umask settings on your server.
Run umask as root and post the output.
Be sure to check out our Knowledgebase for helpful articles and solutions!
I was more confused as to why a phpmailer script's permissions could cause apache to issue a 500 error during a curl.
NDO permissions: They are not, only ndo2db was set to 700. The remaining updated files were 775 or 755, hence my confusion.
umask is currently 0077, which is what our security settings require. During the installation however, I changed it to 0022 after the first failure, just to rule that out.
