Luci offers only a 'download' file

Hi, after updating to the TOS 5.2.3, for some reasons, I just lost my luci gui access :slight_smile: All I get on main gui page is file called: download (doesn’t matter if http or https).

This file contains:

#!/usr/bin/lua
require “luci.cacheloader”
require “luci.sgi.cgi”
luci.dispatcher.indexcache = “/tmp/luci-indexcache”
luci.sgi.cgi.run()

That seems to be the same as is in: /www/cgi-bin/luci.

Here is my lighttpd.conf

server.modules = (
)

server.document-root = “/www”
server.upload-dirs = ( “/tmp” )
server.errorlog = “/var/log/lighttpd/error.log”
server.max-read-idle = 90
server.pid-file = “/var/run/lighttpd.pid”
#server.username = “http”
#server.groupname = “www-data”

index-file.names = ( “index.php”, “index.html”,
“index.htm”, “default.htm”,
)

static-file.exclude-extensions = ( “.php”, “.pl”, “.fcgi” )

Options that are useful but not always necessary:

#server.chroot = “/”
#server.port = 81
server.bind = “192.168.1.1”
#server.tag = “lighttpd”
#server.errorlog-use-syslog = “enable”
#server.network-backend = “writev”

listen on IPv6

#$SERVER[“socket”] == “[::]:80” { }

Use IPv6 if available

#include_shell “/usr/share/lighttpd/use-ipv6.pl”

#dir-listing.encoding = “utf-8”
#server.dir-listing = “enable”

include “/etc/lighttpd/mime.conf”
include “/etc/lighttpd/modules.d/.load"
include "/etc/lighttpd/conf.d/
.conf”

and /etc/lighttpd/modules.d/30-cgi.load

server.modules += ( “mod_cgi” )
cgi.assign = ( “.pl” => “/usr/bin/perl”,
“.cgi” => “/usr/bin/perl”,
“.rb” => “/usr/bin/ruby”,
“.erb” => “/usr/bin/eruby”,
“.py” => “/usr/bin/python” )

Reforis works well. Log is silent. I run only lighttpd for every web service. I did try to remove cache from local web browsers and lua cache file on turris as well. Reboot did not help either. Lua seems to be working though since everything else that depends on it works fine.
I personally don’t have much experiences with luci debugging.
Similar topics:

Any ideas?

I don’t understand the query very much, does the Luci interface not start or is it another problem — web server ??


local ?? 192.168.xx.xx/cgi-bin/luci


#!/usr/bin/lua …OR… #!/www/cgi-bin/luci ???

/www/cgi-bin/luci  

#!/usr/bin/lua
require "luci.cacheloader"
require "luci.sgi.cgi"
luci.dispatcher.indexcache = "/tmp/luci-indexcache"
luci.sgi.cgi.run()

/etc/lighttpd/lighttpd.conf

/etc/lighttpd/lighttpd.conf … no problobel … I think
server.document-root = “/www”
server.upload-dirs = ( “/tmp” )

Souhrn

server.errorlog = “/var/log/lighttpd/error.log”
server.max-read-idle = 90
server.pid-file = “/var/run/lighttpd.pid”
#server.username = “http”
#server.groupname = “www-data”

index-file.names            = ( "index.php", "index.html",
                                "index.htm", "default.htm",
                              )

static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )

### Options that are useful but not always necessary:
#server.chroot               = "/"
#server.port                 = 81
#server.bind                 = "localhost"
#server.tag                  = "lighttpd"
#server.errorlog-use-syslog  = "enable"
#server.network-backend      = "writev"

# listen on IPv6
$SERVER["socket"] == "[::]:80" {  }

### Use IPv6 if available
#include_shell "/usr/share/lighttpd/use-ipv6.pl"

#dir-listing.encoding        = "utf-8"
#server.dir-listing          = "enable"

include "/etc/lighttpd/mime.conf"
include "/etc/lighttpd/modules.d/*.load"
include "/etc/lighttpd/conf.d/*.conf"

So tl’dr of the problem is this: Accessing web interface on the Turris IP gives me only an option of downloading a file called: download however I don’t see the login page (clearing browser cache doesn’t help at all).

It seems that webserver is actually fine since I can access reforis.

Turris IP you think ?? 192.168.x.x … OR … 192.168.x.x/cgi-bin/luci … ??

It’s https://192.168.1.1/cgi-bin/luci and that gives me only a file called download.

As far as I know, the login form does not know https protocol. Http behaves the same when logging in ?

Yes - even with http it doesn’t work as I’ve mentioned at the very first description of that problem.

Rather than worry about analyzing an isolated problem, I would rather go back to the last functional snapshot and repeat the upgrade process. Or better yet, start a clean installation of TOS 5.x.x