We’re seeing 404 | Not Found on the latest LibreNMS. We use a virtual host directive as the web server hosts other content as part of a tools/info service on the same host -
Component | Version
--------- | -------
LibreNMS | 1.65-29-g32f72bc1a
DB Schema | 2020_06_23_00522_alter_availability_perc_column (170)
PHP | 7.2.24-0ubuntu0.18.04.6
Python | 3.6.9
MySQL | 10.1.44-MariaDB-0ubuntu0.18.04.1
RRDTool | 1.7.0
SNMP | NET-SNMP 5.7.3
[OK] Composer Version: 1.10.8
[OK] Dependencies up-to-date.
[OK] Database connection successful
[OK] Database schema correct
[WARN] Your local git contains modified files, this could prevent automatic updates.
You can fix this with ./scripts/github-remove
We’ve followed the
Sub-directory Support instructions to set this up.
This is what it gets when the LibreNMS instance is presented as part of an iframe -
Even visiting the URL manually (
http://x.x.x.x/librenms) returns the same thing.
Just to add, it worked yesterday!
Do you have base_url set?
Yes, the base URL is set.
$config["base_url"] = '/librenms/';
As I said, the sub-domain instructions have been followed, and in-fact, this host was working perfectly until today.
Has something changed with the daily.sh, which might affect it?
Any other ideas?
If I visit /librenms/overview, or /librenms/devices directly, it works. It doesn’t work from the login page, however.
Try setting full
No, I’m afraid that makes no difference.
Did yours work last week too?
Yes it did.
I noticed this issue after having restarted the services while upgrading oxidized.
LibreNMS is running behind a reverse proxy with a subbdirectory.
Have played with all parameters I could find in the documentation.
Forcing the URL manually seems to work but has than issues with related files like images and .js files.
Forcing DirectoryIndex manually works, seems not to be a web server (apache2.4) configuration issue.
@MoraPora Thanks for confirming. Same here.
Seems to suggest something in the daily.sh updates has broken it. IMHO.
Same issue here.
I’m also running LibreNMS with Apache in a subdirectory.
Was able to restore librenms by reinstalling the last version and importing the database.
Seems to work fine now.
APP_DIR=librenms or whatever your directory is in .env
That setting didn’t work for me.
Why would we need to make these changes? As I said, it worked last Thursday, and was broken on Friday.
Might the change to
Laravel 7.x had an affect? It does seem to coincide with when it broke, and the 404 error isn’t an Apache one.
I have no idea. The Laravel 7 change could have had an effect, but I don’t know why. There was no mention in the upgrade notes.
If anyone can figure this out that would be great.
You can also try rolling back your install. And if it is production, I suggest the monthly release.
i’m seeing the same problem.
http://x.x.x.x/librenms/index.php seems to work fine. The laravel log shows the following:
#0 /srv/librenms/vendor/laravel/framework/src/Illuminate/Foundation/helpers.php(44): Illuminate\Foundation\Application->abort(404, ‘’, Array)
#1 /srv/librenms/app/Http/Controllers/LegacyController.php(56): abort(404)
#2 [internal function]: App\Http\Controllers\LegacyController->index(Object(Illuminate\Http\Request), Object(Illuminate\Session\Store))
#3 /srv/librenms/vendor/laravel/framework/src/Illuminate/Routing/Controller.php(54): call_user_func_array(Array, Array)
#4 /srv/librenms/vendor/laravel/framework/src/Illuminate/Routing/ControllerDispatcher.php(45): Illuminate\Routing\Controller->callAction(‘index’, Array)
#5 /srv/librenms/vendor/laravel/framework/src/Illuminate/Routing/Route.php(239): Illuminate\Routing\ControllerDispatcher->dispatch(Object(Illuminate\Routing\Route), Object(App\Http\Controllers\LegacyController), ‘index’)
#6 /srv/librenms/vendor/laravel/framework/src/Illuminate/Routing/Route.php(196): Illuminate\Routing\Route->runController()
#7 /srv/librenms/vendor/laravel/framework/src/Illuminate/Routing/Router.php(685): Illuminate\Routing\Route->run()
Well I’m not particularly sure how this LegacyController is supposed to work at all anyway. If you look around line 56, you’ll see that it’s setting
$vars['page'] = basename($vars['page'] ?? ''); despite
$vars never being set anywhere before in this scope. It’s always going to abort with a 404.
Without going too far in LegacyControllers history, I found where this controller likely stopped working properly in
https://github.com/librenms/librenms/commit/daf451cef7646775475cc8705addf89bd6f314b1#diff-b8006b3a21d1ef1181131ff59bffbcea and in fact this is warned about in the pull request where the index method was created: https://github.com/librenms/librenms/commit/9ede688d1350804f228bbe189792f68bb54844fd#diff-b8006b3a21d1ef1181131ff59bffbcea but seemingly ignored.
I guess the million dollar question is then: Why is the index route getting sent to LegacyController when it should be getting sent to OverviewController. Interestingly enough, you can resolve this issue by doing
sudo -u librenms php artisan route:clear. The dashboard loads just fine if the routes aren’t cached. If you then cache them again, you’ll get a 404 on the index page.
I’ve put that command into an /etc/cron.hourly script for now, until the code can be fixed. Even the ‘stable’ (monthly) release experiences the issue.
If you get a 404 what do you see it trying to access in the apache logs?