New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Status: 500 Internal Server Error #431
Comments
Bug still there > tested branch: master feeds.conf
|
@everloop2 can you still see this issue? |
I have the same behaviour as described in the 2nd syslog:
LuCi will not open any page, but stop with "500 internal server error". Happens for me on a PI3 with a self-compiled branch "SAm0815_Hedy-alpha" (checked out today, 2017-12-26 15:00) for TARGET=brcm2708-bcm2710). As a quick workaround, changing the file
the line
to
makes LuCi accessible again. Running "ubus call system board" from the commandline returns a nice looking set of values (including a non-empty entry for "hostname"), so I guess, there must be a problem with lua and the ubus library. |
so it seems that this is a problem with the ubus-object for these boards |
for reference on a TPlink WR1043 boardinfo looks like:
|
think this might have been fixed by freifunk-berlin/firmware-packages@d8a9c5e#diff-1190ed871db168151a64d3f9bd15b0ce |
Looks quite similar on a RasPi:
|
About the owm.lua issue:
|
@torte71 @everloop2 if this problem still exists in 0.3.0 or 1.0.0(-rc1) there should be a separate issue for OWM. Having both issues here will not work out. @torte71 putting this raw lua in place of the precompiled usr/lib/lua/owm.lua will give the linenumbers and exact postion in code, as you have found. |
You can use ``` as the introducing and outroducing signs, they have to stand alone in their line.
|
I didn't come across this issue building branches |
@kehugter : It only shows up after you completed the wizard. |
I did it several times without any issue. I filled only the mandatory information. |
Weird... I'll do some builds next week, when I am back from journey - maybe this was indeed fixed in the meantime. |
@kehugter : The wizard has to be completed (fill in ip range, etc.) until you get to the save&reboot button. After the reboot you'll see the error. Or to shorten it a bit: As soon as the file /etc/config/ffwizard contains the line "option runbefore 'true'" in the "settings" section, it shows up. (Checked with hedy-1.0.0-rc1, "default" and "vpn03") |
Found it. ubus requires its ACL-config files not being group-readable (see line 406): In our image, the file "/usr/share/acl.d/luci-base.json" has 0664 mode, but needs 0644. And the 500-internal-server error is gone. |
As I can see Kathleen-0.3.0 had ubus-2015-05-25. The code dealing with the permission-check was added to ubus on "Thu, 18 Jun 2015 18:01:17 +0100", so after Kathleen-0.3.0 release. This check was adapted to LuCI (master and lede-17.01 branch) in openwrt/luci@81e80c4. So who is changing these permissions? thanks for finding this bug and its cause. |
on my CPE210 (Freifunk Berlin Hedy 1.0.0-rc1 ffb48ca) I can't confirm this finding.
it seems to be "ar71xx-generic Build #582" ran on "buildslave02.berlin.freifunk.net". dmesg gives:
can you check on your boxes? |
CPE 210 (Hedy 1.0.0-rc1 7f42122 ) is too like svens.
|
makes me wonder ... 2 different builds at exact the same time, but with different revisions ???? |
In our luci-base package the installation is handled by "/openwrt/feeds/luci/luci.mk" (line 169..): So the file mode depends on the default file mode of the build-machine - or is there a trick to get those filemodes via "git"? |
@torte71 git will also take care of the permissions. |
notunnel CPE 210 (Hedy 1.0.0-rc1 7f42122 ), seems "ar71xx-generic Build #580" ran on "buildslave02.berlin.freifunk.net"
same, same but different! interesting. |
@SvenRoederer : Just checked out via "git clone git://github.com/openwrt/luci" (https as well), and "usr/share/acl.d/luci-base.json" has 0664 mode. |
@torte71 different here:
|
gaga...
|
|
In fact: Update the build wiki, or change the makefile? |
just another check: "ar71xx-generic Build #587"; 'Freifunk Berlin Hedy 1.0.0-rc1 5c1dc9d'; build on "wg1337"
|
@torte71 checking out after setting "umask 0002" results in wrong permissions of checkout:
|
I checked all my routers unfortunately it's the same revision, same rights, same version. |
I'd like to check with a build from buildslave1 before thinking of next steps. |
As it seems to be intermittent (in some builds) and is very likely not caused by the firmware itself, I'll remove the "Hedy-1.0.0" Milestone. |
setting umask to 0022 before compiling helps did a clean build for CPE210_v2 (SAm0815_experimental) -> @ luci got: Status: 500 Internal Server Error -> checked umask afterwards: showed 0002 have seen this bug on every build i did after "Kathleen-0.3.0" |
The openwrt files fetched via "git" already need the correct permissions. openwrt/luci#1521 freifunk-berlin#431
If the openwrt files are fetched using "git" on systems with "umask 002", they get checked out with group-writable permission. This finally leads to a "500 internal server error" when accessing luci pages, because of wrong permissions of /usr/share/acl.d/luci-base.json. See OpenWrt: "Builds with umask != 022 are known to be broken": openwrt/luci#1521 (comment) Bugreport and details, how these wrong permissions end up in the image: freifunk-berlin#431
Is this issue resolved? There were no more complaints. |
db18699 batctl: Fix parsing of optional debug table command parameters a1e1020 luci-app-bmx7: refactory, multiple fixes and add topology graph a31ebca Merge pull request #429 from ecsv/batadv-2018.4 9345df9 luci-app-bmx7: update version, dependencies and maintainer a7d7f4b luci-app-bmx7: fix bmx7-info script's indentation 3e259f8 luci-app-bmx7: fix bmx7-info script's "$info" call 3264d15 Merge pull request #431 from rogerpueyo/p4u/luci-app-bmx7/refactory 940d621 Merge branch 'p4u/luci-app-bmx7/refactory' b6815d5 luci-app-bmx6: Fix URL of network topology JSON file 9bc518e Merge pull request #433 from rogerpueyo/bmx6-graph 2cc3c50 luci-app-bmx6: Fix corner case in bmx6-info?tunnels a7c4479 Merge pull request #435 from rogerpueyo/bmx6-graph-tunnels 6c63383 luci-app-bmx6: Avoid race condition in bmx6json.lua get() 2c9f89c hnetd: add compatiblity with openssl 1.1.x fce1287 luci-app-bmx7: show mDNS menu if available f438333 Merge pull request #438 from cotequeiroz/hnetd_openssl-1.1 29d4160 Merge pull request #437 from rogerpueyo/luci-app-bmx6-graph-sys-exec
If the openwrt files are fetched using "git" on systems with "umask 002", they get checked out with group-writable permission. This finally leads to a "500 internal server error" when accessing luci pages, because of wrong permissions of /usr/share/acl.d/luci-base.json. See OpenWrt: "Builds with umask != 022 are known to be broken": openwrt/luci#1521 (comment) Bugreport and details, how these wrong permissions end up in the image: #431
If the openwrt files are fetched using "git" on systems with "umask 002", they get checked out with group-writable permission. This finally leads to a "500 internal server error" when accessing luci pages, because of wrong permissions of /usr/share/acl.d/luci-base.json. See OpenWrt: "Builds with umask != 022 are known to be broken": openwrt/luci#1521 (comment) Bugreport and details, how these wrong permissions end up in the image: #431 cherry-pick from master (47eedf5)
If the openwrt files are fetched using "git" on systems with "umask 002", they get checked out with group-writable permission. This finally leads to a "500 internal server error" when accessing luci pages, because of wrong permissions of /usr/share/acl.d/luci-base.json. See OpenWrt: "Builds with umask != 022 are known to be broken": openwrt/luci#1521 (comment) Bugreport and details, how these wrong permissions end up in the image: #431 cherry-pick from master (47eedf5)
If the openwrt files are fetched using "git" on systems with "umask 002", they get checked out with group-writable permission. This finally leads to a "500 internal server error" when accessing luci pages, because of wrong permissions of /usr/share/acl.d/luci-base.json. See OpenWrt: "Builds with umask != 022 are known to be broken": openwrt/luci#1521 (comment) Bugreport and details, how these wrong permissions end up in the image: #431 cherry-pick from master (47eedf5)
tried and did not work / already fixed: https://dev.openwrt.org/ticket/19752
Hostname: cottbus-lausi36
Model: Arcor 803 (Easybox803, https://wiki.openwrt.org/toh/astoria/arv752dpw22)
Firmware Version: Freifunk Berlin Hedy 1.0.0-olsrd0903-alpha 9a4fd73 r3205-59508e3 / LuCI lede-17.01 branch (git-17.051.53299-a100738)
Kernel Version: 4.4.50
Syslog:
/usr/lib/lua/luci/dispatcher.lua:380: Failed to execute function dispatcher target for entry '/'.
The called action terminated with an exception:
/usr/lib/lua/luci/dispatcher.lua:380: Failed to execute function dispatcher target for entry '/freifunk'.
The called action terminated with an exception:
/usr/lib/lua/luci/dispatcher.lua:380: Failed to execute template dispatcher target for entry '/freifunk/index'.
The called action terminated with an exception:
/usr/lib/lua/luci/template.lua:55: Failed to execute template 'freifunk/index'.
A runtime error occured: /usr/lib/lua/luci/template.lua:55: Failed to execute template 'header'.
A runtime error occured: /usr/lib/lua/luci/template.lua:55: Failed to execute template 'themes/bootstrap/header'.
A runtime error occured: [string "/usr/lib/lua/luci/view/themes/bootstrap/hea..."]:150: attempt to index local 'boardinfo' (a nil value)
stack traceback:
[C]: in function 'assert'
/usr/lib/lua/luci/dispatcher.lua:380: in function 'dispatch'
/usr/lib/lua/luci/dispatcher.lua:109: in function </usr/lib/lua/luci/dispatcher.lua:108>
Syslog:
/usr/lib/lua/luci/dispatcher.lua:380: Failed to execute call dispatcher target for entry '/owm.json'.
The called action terminated with an exception:
?:0: attempt to index field 'iwdata' (a nil value)
stack traceback:
[C]: in function 'assert'
/usr/lib/lua/luci/dispatcher.lua:380: in function 'dispatch'
/usr/lib/lua/luci/dispatcher.lua:109: in function </usr/lib/lua/luci/dispatcher.lua:108>
The text was updated successfully, but these errors were encountered: