Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Luci collections add luci-lighttpd #6596

Draft
wants to merge 5 commits into
base: master
Choose a base branch
from
Draft

Luci collections add luci-lighttpd #6596

wants to merge 5 commits into from

Conversation

stokito
Copy link
Contributor

@stokito stokito commented Sep 25, 2023 •
edited
Loading

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

@stokito
luci-base: index.html use HTML5
ed33b99 
This simplifies HTML but also make it smaller.

Signed-off-by: Sergey Ponomarev <[email protected]>
@stokito
luci-base: separate luci-www for redirection
9fb51cc 
The default /www/index.html is used to redirect to /cgi-bin/luci.
Router manufactures often have their own admin panel.
So they have to override the default index.html.
Instead make a separate package.

Signed-off-by: Sergey Ponomarev <[email protected]>
@stokito
luci-ssl-nginx: use luci-nginx dependency
b2f26cf 
Simplify dependencies

Signed-off-by: Sergey Ponomarev <[email protected]>
@stokito
luci: make the package to not depend on uhttpd
d5608cb 
The luci depends on luci-light.
The luci-light adds a dependency to uhttpd.
But also it declares some set of apps.
The luci package also adds one luci-app-opkg.

This all is very confusing.
So here a simplification:
* the luci package now only declare a set of standard apps including the luci-app-opkg
* the luci-light will only depend on the luci and add uhttpd.

After the change the luci-light will also install luci-app-opkg.

This also simplifies luci-nginx.

Signed-off-by: Sergey Ponomarev <[email protected]>
@stokito
collections: add luci-lighttpd
e437924 
Some firmwares like Turris and Gl.Inet use Lighttpd for Luci.

The mod_alias is often used so we need to set luci alias paths.

The lighttpd use own user but for Luci we need root user.
That's why the server.username is overridden to empty.
When removing the package it will be rolled back to use the default lighttpd user.
But the log file was created with root.
We should remove it manually to allow the lighttpd user to recreate it.

We also need to enable CGI for the cgi-bin folder.

Signed-off-by: Sergey Ponomarev <[email protected]>
@stokito stokito changed the title Luci collections lightttpd Luci collections add luci-lightttpd Sep 25, 2023
@feckert
Copy link
Member

feckert commented Sep 26, 2023 •
edited
Loading

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

@stokito
Copy link
Contributor Author

stokito commented Sep 26, 2023 •
edited
Loading

I agree with you and also thought about this. But here some thoughts that stopped me:

  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)
  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.

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
#734 (comment)
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.

@feckert
Copy link
Member

feckert commented Sep 28, 2023 

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.

@stokito
Copy link
Contributor Author

stokito commented Sep 28, 2023

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.

@feckert
Copy link
Member

feckert commented Oct 4, 2023

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.

@stokito
Copy link
Contributor Author

stokito commented Oct 4, 2023

Nice trick. That's just for me the luci-www seems more easier to implement (it's already), understand and use.

@systemcrash systemcrash changed the title Luci collections add luci-lightttpd Luci collections add luci-lighttpd Dec 4, 2023
@systemcrash systemcrash added feature pull request adding a new feature depends on other pr pull request depends on another pull request labels Dec 5, 2023
@systemcrash systemcrash marked this pull request as draft December 30, 2023 02:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@raenye raenye raenye left review comments

Assignees
No one assigned
Labels
depends on other pr pull request depends on another pull request feature pull request adding a new feature
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@stokito @feckert @raenye @systemcrash