Am I the only one that seems to be having an issue of being kicked out of my installation after some unknown amount of time? This issue seems to have reared it’s ugly head after the update last week on the 18th. If anyone here can provide some insight on how to correct my installation I’d appreciate it… when I get kicked it takes me back to the login screen and has a big red bar at the bottom and says “Ooops… something went wrong”.
I have performed the requested actions and we’ll see if that will fix my issues… one other thing that I’ve noticed is that I now get the errors below when I run the “./validate.php” script whereas I didn’t have them before. I run the commands and everything seems to be fine as they don’t show up again when I run “./validate.php” afterwards. However they’ll come back tomorrow… anything that you can provide to me on this would be very much appreciated.
sudo chown -R librenms:librenms /mnt/librenms
sudo setfacl -d -m g::rwx /mnt/librenms/rrd /mnt/librenms/logs /mnt/librenms/bootstrap/cache/ /mnt/librenms/storage/
sudo chmod -R ug=rwX /mnt/librenms/rrd /mnt/librenms/logs /mnt/librenms/bootstrap/cache/ /mnt/librenms/storage/
What error do you get in validate.php?
This is the error that I get after running ./validate.php, once I run the suggestions to correct it and then run ./validate.php again they’re not present… however, if I wait say 5 to 10 minutes and run ./validate.php again… the errors reappear.
Since Remember Me is now fixed, checking that box will prevent the main session timeout from logging you out. However the legacy session may still expire. We are working to remove the legacy session, but there is a lot to do.
Thanks for getting back to me on this, so the errors that I’m seeing, should I be worried about them? In the past whenever I’d run ./validate.php I wouldn’t get these errors… are you stating that you’re working on them and they’ll eventually be worked out in a pull of a new code base? I suppose what I’m trying to identify here is whether or not my system is running in a healthy state or if it’s degraded. I very much like this product and have spend an immense amount of time getting it to where I have it today. I’m the only person on my team who works on this and I feel since I’ve stood it up, configured it, maintain it, etc. that I have a duty to the others that I work with to make sure that it status up and running in an optimal state.
Thanks for your time,
Regards,
Scott Nerone
We have error’d on the side of caution with the chown output.
Once the legacy php session is removed, users will be able to change php-fpm/apache to run as the librenms user and prevent permissions issues arising from that.
I’m not all that sure that I follow what you’re trying to tell me, wish that I didn’t have to respond to you in such fashion. Is there something on my end that I should do to “remove the legacy php session” or is this something that will take place as the system updates to the next codebase?
This is what I get when I run ./validate.php & ./daily.sh, I haven’t seen the ./discovery-wrapper.py error before so I’ve kicked that off and see what it will do… truthyfully, this thing has been running fine without me having to do anything for a good while now but these errors make me a bit uneasy…
I’m saying that validate message will keep happening and you can’t resolve it until the LibreNMS code changes are fully complete.
But you don’t have to keep running the chown commands unless you see an issue, which generally shouldn’t happen after you run them once.
Perfect, thanks for getting back with me on this.
-SNerone