This is how my setup is done --> https://github.com/as365n4/arm64_Debian_ADSB_Receiver_Setup_for_FlightAware
Since it is my “test” rig, I haven’t bothered with installing tar1090 or Dump1090-OpenLayers3 mod as I do on my “production” rigs.
That’s really strange … so the offending aliasing of / can only be in:
cat /etc/lighttpd/88-dump1090-fa-statcache.conf
It really shouldn’t be but let’s check nonetheless.
cat /etc/lighttpd/conf-available/88-dump1090-fa-statcache.conf returned
# The stat cache must be disabled, as aircraft.json changes
# frequently and lighttpd's stat cache often ends up with the
# wrong content length.
server.stat-cache-engine = "disable"
cat /etc/lighttpd/conf-available/90-javascript-alias.conf returned
alias.url += ("/javascript" => "/usr/share/javascript")
Pretty much out of ideas …
ls -l /etc/lighttpd/conf-enabled/
cat /etc/lighttpd/conf-enabled/*
Maybe it’s not symlinks but files for some reason there was a bug … with tar1090 actually some time ago 
As i’m pretty sure you don’t need it, remove the js conf
sudo rm /etc/lighttpd/conf-available/90-javascript-alias.conf
sudo systemctl restart lighttpd
Then check the log again.
thankfully I only moved 90-javascript-alias.conf instead of deleting it, as lighttpd was now complaing that 90-javascript-alias.conf was missing in addition to that “(mod_alias.c.70) url.alias: /dump1090-fa/' will never match as /’ matched first” error message, so I put it back.
As I did the update yesterday there was a lenghty text message displayed explaing the break-up of lighttpd into several submodules, but unfortunately I took no copy of it. And the Debian Package Tracker has no useful info either in this regard. 
ls -l /etc/lighttpd/conf-enabled/ returned
total 0
lrwxrwxrwx 1 root root 47 Nov 1 10:06 88-dump1090-fa-statcache.conf -> ../conf-available/88-dump1090-fa-statcache.conf
lrwxrwxrwx 1 root root 37 Nov 1 10:06 89-dump1090-fa.conf -> ../conf-available/89-dump1090-fa.conf
lrwxrwxrwx 1 root root 42 Oct 31 23:13 90-javascript-alias.conf -> ../conf-available/90-javascript-alias.conf
and cat /etc/lighttpd/conf-enabled/ returned
# The stat cache must be disabled, as aircraft.json changes
# frequently and lighttpd's stat cache often ends up with the
# wrong content length.
server.stat-cache-engine = "disable"
# Allows access to the static files that provide the dump1090 map view,
# and also to the dynamically-generated json parts that contain aircraft
# data and are periodically written by the dump1090 daemon.
# Enable alias module
#
## This module is normally already enabled in lighttpd, so you should not
## need to uncommment this line.
## There are some cases (e.g. when installing this on a Raspberry Pi
## that runs PiHole) in which the module has been removed from the
## default configuration, and the dump1090-fa web interface no longer
## loads properly.
## If this is what you are experiencing, or if you see messages in your
## error log like:
## (server.c.1493) WARNING: unknown config-key: alias.url (ignored)
## then uncommenting this line and then restarting lighttpd could fix
## the issue.
## This is not enabled by default as standard lighttpd will not start if
## modules are loaded multiple times.
#
# server.modules += ( "mod_alias" )
alias.url += (
"/dump1090-fa/data/" => "/run/dump1090-fa/",
"/dump1090-fa/" => "/usr/share/dump1090-fa/html/"
)
# redirect the slash-less URL
url.redirect += (
"^/dump1090-fa$" => "/dump1090-fa/"
)
# Listen on port 8080 and serve the map there, too.
$SERVER["socket"] == ":8080" {
alias.url += (
"/data/" => "/run/dump1090-fa/",
"/" => "/usr/share/dump1090-fa/html/"
)
}
# Add CORS header
server.modules += ( "mod_setenv" )
$HTTP["url"] =~ "^/dump1090-fa/data/.*\.json$" {
setenv.set-response-header = ( "Access-Control-Allow-Origin" => "*" )
}
# Uncomment this section to enable SSL traffic (HTTPS) - especially useful
# for .dev domains
## Listen on 8443 for SSL connections
#server.modules += ( "mod_openssl" )
#$HTTP["host"] == "piaware.example.com" {
# $SERVER["socket"] == ":8443" {
# ssl.engine = "enable"
# ssl.pemfile = "/etc/ssl/certs/combined.pem"
# ssl.ca-file = "/etc/ssl/certs/fullchain.cer"
# ssl.honor-cipher-order = "enable"
# ssl.cipher-list = "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH"
# ssl.use-sslv2 = "disable"
# ssl.use-sslv3 = "disable"
#
# alias.url += (
# "/data/" => "/run/dump1090-fa/",
# "/" => "/usr/share/dump1090-fa/html/"
# )
# }
#}
#
## Redirect HTTP to HTTPS
#$HTTP["scheme"] == "http" {
# $HTTP["host"] =~ ".*" {
# url.redirect = (".*" => "https://%0$0")
# }
#}
alias.url += ("/javascript" => "/usr/share/javascript")
Oh … i meant:
sudo rm /etc/lighttpd/conf-enabled/90-javascript-alias.conf
wrong folder …
Anyhow … it really shouldn’t have any effect.
No clue what’s going on.
Didn’t quite realize you were on testing.
The lighttpd shipped in Debian testing is currently just broken, pretty sure.
One has to be on bullseye/sid as the kernel in buster is so hopelessly outdated (4.19).
For best performance on Rockchip and especially Allwinner H6 based SBC a Kernel 5.8 or higher is a must. And Vanilla Debian defaults automatically to bullseye/sid when installed directly from Debian sources.
I have checked Debian Changelog for lighttpd and you might be right that it is just broken as they seem to do some restructuring on the package itself…
lighttpd (1.4.56~rc7-1) unstable; urgency=medium
- Upload to unstable.
- drop mod_authn_dbi.so from debian/not-installed
– Helmut Grohne <> Sat, 07 Nov 2020 11:03:57 +0100
lighttpd (1.4.56~rc7-0+exp2) experimental; urgency=medium
[ Glenn Strauss ]
- build lighttpd base against Nettle
- split off package lighttpd-mod-openssl
- split off package lighttpd-mod-deflate
- merge lighttpd-mod-cml and lighttpd-mod-magnet into lighttpd-modules-lua
- replace mod_compress with mod_deflate
- build with brotli support; replace bzip2 support
- separate package for each TLS module
mod_openssl, mod_mbedtls, mod_nss, mod_wolfssl- new package lighttpd-modules-dbi with mod_authn_dbi, mod_vhostdb_dbi
- document deprecated modules: mod_authn_mysql, mod_mysql_vhost
- remove libattr1-dev dependency
[ Helmut Grohne ]
- remove mod_deflate from the default configuration
[ Glenn Strauss ]
- lighttpd.conf enable HTTP/2 feature
[ Helmut Grohne ]
- use the system libxxhash instead of our vendor copy
– Helmut Grohne <> Thu, 05 Nov 2020 20:18:08 +0100
lighttpd (1.4.56~rc7-0+exp1) experimental; urgency=medium
- New upstream version 1.4.56~rc7
– Helmut Grohne <> Tue, 03 Nov 2020 05:51:40 +0100
lighttpd (1.4.56~rc2-0+exp1) experimental; urgency=medium
- fix php-fpm socket path.
Thanks to Joe Nahmias <> (Closes: #973300)- New upstream version 1.4.56~rc2
- Update debian/copyright
- Drop all patches - all applied upstream
- mod_compress is merged into mod_deflate
- Skip installing mod_authn_dbi for now
- load-all-modules test skips deprecated mod_vhost_mysql
– Helmut Grohne <> Mon, 02 Nov 2020 19:54:18 +0100
So apparently it doesn’t handle the configuration for the extra port very well in the new version. (let’s hope they fix that)
Removing the $SERVER["socket"] section fixes the issue.
I’d recommend to use nginx anyhow, to make it easier i provide config files that can be included when using tar1090: https://github.com/wiedehopf/tar1090#tar1090
(it’s displayed at the end of the script if nginx is installed)
Note tar1090 doesn’t play too well with that lighttpd version either … (just yet anyway, i might add some work-arounds).
sudo rm /etc/lighttpd/conf-enabled/95-tar1090-otherport.conf
This fixes it mostly … it will still show lots of warnings but it should work.
1 Like
Cool stuff, many thanks for the tip and easy fix.
I’ve commented out the “Listen on port 8080” section in 89-dump1090-fa.conf and restarted lighttpd and the map is back.
Issues do not get fixed if they do not get reported. Please consider reporting issues upstream. Thank you from a lighttpd developer who happened to find this page with an out-of-the-blue random search.
That is an error in the user-configuration, not in lighttpd. The most-specific matches need to be listed before the more general matches.
You can run lighttpd -f /etc/lighttpd/lighttpd.conf -p to print out the entire configuration as it is parsed by lighttpd. Then you can identity the place(s) with alias.url ordering issues.
The lighttpd documentation provides some examples how to use variables to share configuration in different scopes. The examples might give you ideas how to more easily manage the list of aliases.
No it’s not, it’s a regression, the same config file worked fine before.
Reduced reproducing config file:
alias.url += (
"/dump1090-fa/data/" => "/run/dump1090-fa/",
"/dump1090-fa/" => "/usr/share/dump1090-fa/html/"
)
# Listen on port 8080 and serve the map there, too.
$SERVER["socket"] == ":8080" {
alias.url += (
"/data/" => "/run/dump1090-fa/",
"/" => "/usr/share/dump1090-fa/html/"
)
}
lighttpd[3046773]: 2020-11-11 22:52:54: (mod_alias.c.70) url.alias: `/dump1090-fa/' will never match as `/' matched first
lighttpd[3046773]: 2020-11-11 22:52:54: (server.c.1484) Configuration of plugins failed. Going down.
The issue seems to be that somehow the $SERVER["socket"] == ":8080" { block gets processed first?
Just tried to make this a bug report but your bugtracker didn’t allow me to create an account as no email was sent for activation.
As a feature request / bug report:
server.modules += ( "mod_setenv" )
server.modules += ( "mod_setenv" )
This leads to mod_setenv not working correctly.
It would be much better if a module being loaded twice would just be ignored, that way if 2 programs which enable lighttpd configurations both need that module they can safely activate it without causing it to not work properly.
Yes, that does appear to be a bug. I hope to have a fix upstream later today, but due to availability issues of others, Debian will probably pick up the fix the first week of Dec.
1 Like
It takes some time for bugfixes to trickle down, actually i would’ve expected it to take longer.
So optimally even the reverse should work as you often have multiple programs using configuration files.
If one of them defines / on port 8080, the next configuration file should also work despite / already being aliased (for port 8080).
Pretty sure that’s the previous behaviour.
Thanks for taking a look.
FYI: The lighttpd bug was part of an improper optimization attempt that was reverted in development a year ago. Fix: https://git.lighttpd.net/lighttpd/lighttpd1.4/commit/c16c6a8f8ffc3b2bfadca338de5aa3afbe99c0d2
Quick clarification: lighttpd 1.4.56 has not yet been released and this fix will be part of it.
The Debian testing and unstable branches have lighttpd 1.4.56~rc7 (release candidate 7) and the Debian testing and unstable branches are able to pick up changes more quickly than the Debian stable branch.
lighttpd 1.4.56 is available in Debian unstable and Debian testing. It includes the fix for the issue reported here.
2 Likes
Just did the update and it works. 
Many thanks for the hard work and effort in fixing this bug. 
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.