openwrt
Luci collections add luci-lighttpd
The PR is based on #6591 so check only the last commit.
Turris Omnia and Gl.Inet use the Lighttpd webserver. But for the Luci we need to add some configuration. In order to help users who also want to use the Lighttpd the new package luci-lighttpd would be helpful.
For the TurrisOS there is a task Add package luci-lighttpd
I haven't looked into the whole thing in detail now. But while we are at it, that we want to run the LuCI on other web servers. Then we should have a package naming convention.
luci-www: Contains all packages that are common to all LuCI installations independent of the used webserver.
luci-light -> luci-uhttpd: Dependencies (at least luci-www and uhttpd) and configuration files to run LuCI with uhttpd.
luci-nginx: dependencies (at least luci-www and nginx) and configuration files to run LuCI with nginx
luci-lighttpd: dependencies (at least luci-www and lighttpd) and configuration files to run LuCI with lighttpd
luci-ssl-openssl -> luci-uhttpd-openssl: dependencie to luci-uhttpd
luci-ssl -> luci-uhttpd-mbedtls: dependencie to luci-uhttpd
luci-ssl-nginx -> luci-nginx-openssl: dependencie to luci-nginx
I agree with you and also thought about this. But here some thoughts that stopped me:
- Just to clarify: The luci-www package that I proposed contains a single file /www/index.html. The package needs to be installed by default but firmware manufactures may choice to not use it and use their own admin panel instead (e.g. Turris reForris)
- The luci-light is already existing package and some firmwares may already have it configured in scripts. We may rename it as well but that's probably better to do in next releases.
Basically there shouldn't be any luci-SOME_WEBSERVER packages. In ideal world the Luci should work out of the box with any webserver. The purpose of the luci-light and luci-nginx is to add a dependency to mod-ubus and ucode. Instead we can simplify this by just adding the mod-ubus just to uhttpd and nginx packages. They are anyway small.
The only difference is luci-lighttpd that adds a config file to Lighttpd. The config file is small and basically it just makes the Lighttpd to be started as root. It's a difficult topic about how to make this properly and was discussed before https://github.com/openwrt/luci/issues/734#issuecomment-283769760 In fact I think that the luci should be started on own port and additionally a proxy should be placed before. But just for today to simplify things the luci-lighttpd should be very helpful.
1. Just to clarify: The luci-www package that I proposed contains a single file /www/index.html. The package needs to be installed by default but firmware manufactures may choice to not use it and use their own admin panel instead (e.g. Turris reForris)
This is a problem of downstream. Regardless, they can build their own package that has luci-www as a dependency and then delete the file in a pre-install script of their new package and replace it with their own.
2. The luci-light is already existing package and some firmwares may already have it configured in scripts. We may rename it as well but that's probably better to do in next releases.
There we can use the PROVIDE:= feature of openwrt to set an alternative name so that we can still use luci-light to install the package.
Basically there shouldn't be any luci-SOME_WEBSERVER packages. In ideal world the Luci should work out of the box with any webserver. The purpose of the luci-light and luci-nginx is to add a dependency to mod-ubus and ucode. Instead we can simplify this by just adding the mod-ubus just to uhttpd and nginx packages. They are anyway small.
LuCI should work with any web server, but you need additional packages and configuration to make it work on them. That's why I think it's not bad if I can simply type luci-ngnix and the LuCI runs.
they can build their own package that has luci-www as a dependency and then delete the file in a pre-install script
If this can work then I probably can drop the commit with extracting of the luci-www. Still this looks confusing to me when one package removes files from another.
they can build their own package that has luci-www as a dependency and then delete the file in a pre-install script
If this can work then I probably can drop the commit with extracting of the luci-www. Still this looks confusing to me when one package removes files from another.
We don't have to delete it. We can move it with a postfix.
For example index.html.luci-base. And if we delete the package that moved this file, we could move index.html.lubi-base to the correct location again.
Nice trick. That's just for me the luci-www seems more easier to implement (it's already), understand and use.