Graphical Web UI

[Gamerboy59]

Hello,
I created a web user interface for managing the rpxy instance. It's made with Laravel and Bootstrap. I've included most configuration variations I guess. As a future feature, I thought of adding phpACME support for managing ssl certificates if this won't be of the domain of rpxy itself.
Maybe you can check it out and let me know what you think. We can further test and add/fix missing logic. Once you think it's good to share, maybe you can add a link to your readme so people will get to know it more easily.
https://github.com/Gamerboy59/rpxy-webui

[junkurihara]

Hi @Gamerboy59 !

That's great. Yes, I will check it.

For ACME, I am actually planning to integrate the automated certificate management process with rpxy (maybe as optional feature in the context of Rust). But external manager sounds reasonable for users who needs certs in PEM-based files.

[Gamerboy59]

If you integrate ACME (I think specifically letsencrypt) into rpxy natively, maybe it would be sufficient to allow users to export these certificates as PEM-files. I think a different cert manager for more or less the same functionality would be just extra maintenance effort and will be barely used. If users want to use certificates they optained outside the acme process (e.g. bought somewhere), the webui could offer a function where they can import those.

[Gamerboy59]

It looks like PHP can't do the conversion natively as I suggested above. OpenSSL would be required to be installed and accessible by the webserver and can then be used by some php libraries.

[paulocoghi]

@Gamerboy59 first of all, thank you for the rpxy-webui project! I would like to cordially add some questions and suggestions.

What is the need behind the requirement of nodejs, since it is originally made on PHP/Laravel? If it is because of some front-end requirements, the front-end can be pre-bundled in development phase and eliminate the need of NodeJS in production.

After removing NodeJS from the equation you can go one step further, packaging rpxy-webui into a single binary executable by using static-php-cli, making a lot easier to distribute, install and use rpxy-webui.

Lastly, since we expect the database to be small in such a scenario of proxy management (just a few KBs for each proxy information), it makes more sense to use an embedded database like SQLite, which Laravel has native compatibility, instead of MySQL/MariaDB.

Using SQLite and a single binary executable makes rpxy-webui completely autonomous, with zero pre-requisites from the final user to be able to use it.

I hope my suggestions help your project to grow 🙂

[Gamerboy59]

Thanks for your comment, @paulocoghi !
Like you supposed, NodeJS is required because of the frontend. Once all features are tested more thoroughly, my plan is to not only pre-bundle nodejs artifacts but also vendor files and thus also make composer redundand for the user, too.
Regarding the database, I'll have a look into how to handle the constraints to make it compatible with sqlite.

Do you plan to host the rpxy-webui in a container or why do you prefer a binary? I initially designed it for use in basic shared hosting environments, where typically all the PHP modules required by Laravel are pre-installed, and a MySQL database is also generally available.

Waiting for feedback from @junkurihara too and then maybe a beta version, ready to deploy, can be released.

[paulocoghi]

@Gamerboy59 Thanks for the feedback!

Do you plan to host the rpxy-webui in a container or why do you prefer a binary?

I normally install softwares like rpxy and rpxy-webui on the host, not on the containers/VMs. And this is why I choose the ones which are single binaries.

Regarding the database, I'll have a look into how to handle the constraints to make it compatible with sqlite.

If you are using Eloquent ORM, then you can switch databases by changing just a few lines on the configuration, and the rest should be transparent.

[Gamerboy59]

I normally install softwares like rpxy and rpxy-webui on the host, not on the containers/VMs. And this is why I choose the ones which are single binaries.

I'll check if GitHub Actions support the generation of such binaries. My first attempt generated a huge file which is inconvenient.

If you are using Eloquent ORM, then you can switch databases by changing just a few lines on the configuration, and the rest should be transparent.

Yes, Eloquent is used. You can already change the db_connection to SQLite in your .env if you want. I just remember there were some cascading functionalities not support by SQLite so I need to test if it works well before adding it to the description.

[paulocoghi]

I'll check if GitHub Actions support the generation of such binaries. My first attempt generated a huge file which is inconvenient.

Have you tried to generate the binary based on the common combination? It provides 30 of the 50 most used php extensions, and the final binary (without your project's code) uses only 7.5MB.

[paulocoghi]

Yes, Eloquent is used. You can already change the db_connection to SQLite in your .env if you want.

It would be interesting if SQLite is already defined as the default database, internally and transparently, because it makes the final executable natively independent of any external database

[Gamerboy59]

It would be interesting if SQLite is already defined as the default database, internally and transparently, because it makes the final executable natively independent of any external database

This is already the default if you copy the .env.default. I'll make it more clear in the README.md that using mysql as database is optional but for this I have to test some queries. Eloquent supports all these database drivers but their feature set is not identical even though it's one interface for all.

Have you tried to generate the binary based on the common combination? It provides 30 of the 50 most used php extensions, and the final binary (without your project's code) uses only 7.5MB.

Thanks for that hint. I just downloaded theirs (for fpm) and it seems to work. However, I wonder how this is connected to rpxy-webui? If I understand this static-php-project correctly, it doesn't really matter if you use their pre-compiled php-binaries or the ones of your OS distributions' package manager. Since it is just the php runtime, you still need the webserver and the webroot of the webserver is where you put the laravel webapp.

[paulocoghi]

Since it is just the php runtime, you still need the webserver and the webroot of the webserver is where you put the laravel webapp

This is a really important point and maybe my suggestion about providing rpxy-webui as a single autonomous binary is unrealistic in this case.

There is one last approach which combines a lightweight php runtime (FrankenPHP) with an embedded web server (caddy) that is fully compatible with Laravel and is also based on static-php-cli, but I don't want to create a burden on you (I'm just an enthusiastic user of rpxy).

In the end, my main feedback is that server applications (like rpxy, rpxy-webui, dnsdist, bind, etc) are better designed when provided as a single binary. But the underlying language/framework plays a big role on this.

Like when using NodeJS (packaging with pkg) or Go/Crystal (compiled), with or without a framework, achieve this is a lot easier. That's it 😉

This doesn't mean there isn't an audience for solutions which depend on an interpreter. There is and it's fine. Independent of anything, I appreciate your effort @Gamerboy59 🙂

[Gamerboy59]

There is one last approach which combines a lightweight php runtime (FrankenPHP) with an embedded web server (caddy) that is fully compatible with Laravel and is also based on static-php-cli, but I don't want to create a burden on you (I'm just an enthusiastic user of rpxy).

I do really appreciate your efforts to find a solution. In my view, shipping a webserver and everything is just out of scope of this managing webapp instance. It would require me to constantly update the binaries, even if the code of rpxy-webui didn't change, just to update the dependend applications. The best I can think of right now is to build .deb and .rpm packages which define dependencies to a webserver and php for the OS's package manager but there's also many contraints (what is if there is already a manually compiled php version available because the user doesn't want the php from distribution?) and thus is actually out of scope for any webapp in my opinion, too.

In the end, my main feedback is that server applications (like rpxy, rpxy-webui, dnsdist, bind, etc) are better designed when provided as a single binary. But the underlying language/framework plays a big role on this.

It is more convenient, I agree, but this convenience comes at a high sysadmin management effort.
One last thing which comes to my mind to at least partially solve this, is if @junkurihara adds a webserver feature like a config for the webroot and a socket path for php-fpm so you only have to download rpxy-webui to this webroot and start the portable php-binary. It requires significant change to this project though, so I don't know if it is really a possible way to go.

[junkurihara]

Sorry for my delayed responses, and thanks for your fruitful discussion!

Honestly I've never write and use php. So I am not familiar with how to run the project in various environment with different dependencies. But I think that as @paulocoghi mentioned and the discussion is going on, shipping rpxy-webui as a single executable binary is better for users. Also specifically in cases of users of container-based systems, a self-contained container image including rpxy and rpxy-webui sounds nice as well.

One last thing which comes to my mind to at least partially solve this, is if @junkurihara adds a webserver feature like a config for the webroot and a socket path for php-fpm so you only have to download rpxy-webui to this webroot and start the portable php-binary. It requires significant change to this project though, so I don't know if it is really a possible way to go.

Hmm it sounds really tough to newly integrate such function with rpxy. I also think having web servers inside rpxy violates the design principle: rpxy should be as simple and tiny (and fast :-)) as possible to be used with various infrastructure, e.g., raspberry-pi, (self-hosted) CDN edge servers, etc. So I think that although web management interfaces are really useful (and of course welcome for me!), it should be separeted from rpxy.

[Gamerboy59]

Also specifically in cases of users of container-based systems, a self-contained container image including rpxy and rpxy-webui sounds nice as well.

@junkurihara I've included a Dockerfile which builds a ready to use docker image including php and webserver. The resulting image is over 600MB on disk which is too big to distribute.
@paulocoghi I've added pre-compiled archives to github as well as removed mysql from the install instructions.

I've had a look again at the binary option but this is still not going to be a good option in my opinion. The webserver is around 20MB, the php binary another 15MB including all required modules and then some additional runtime dependencies of around 10MB which makes a 45MB binary. That's way too big for an application of about 1MB size. PHP is just not made to be distributed with a full stack. I should have created rpxy-webui in Go, Lua or something else more light if it should be a binary. Now it's nearly impossible to convert though.

[Gamerboy59]

I started building packages for the system's manager which one the one hand requires the installation of apache24 as only webserver choice currently but on the other hand pretty automatically serves the webapp without the burden to manage the full tech stack.
You can download it here: RedHat/Rocky/Alma-9 and Debian/Ubuntu
Please let me know your feedback, @paulocoghi.
These packages could theoretically also ship along with rpxy as a system service. Is that something you would consider @junkurihara ?

[Gamerboy59]

Do you prefer packages or docker containers? Adding the at time of compilation most current rpxy binary should be doable, too, so it'd one package or container for all.

[Gamerboy59]

Before I start adding the ACME stuff (display cert, import custom etc.), can somebody test the current version? Would appreciate any feedback. If there is anything making the deployment of it a hurdle to you, let me know so I can see what can be improved. Right now this webapp can be deployed as shared hosting, docker container and distribution package (will add information about this to the README.md soon).

[junkurihara]

Do you prefer packages or docker containers? Adding the at time of compilation most current rpxy binary should be doable, too, so it'd one package or container for all.

Just for my case, a docker container is preferable.

But rpxy-webui is being developed not for developers (i.e., me :-)) but for sysadmins. So I am not sure if docker containers is a better choice for them than packages, honestly.

[junkurihara]

I added the link to rpxy-webui in README.md of develop branch 😃

[Gamerboy59]

I added the link to rpxy-webui in README.md of develop branch 😃

Thank you. :)
I've added a docker compose file to bring up both services simultaniously. It isn't working oob though because the Docker Image of rpxy-webui needs to be generated in advance and I think there are still permission issues for the rpxy.toml file on your image, when the config file is mounted through a volume.
I'll soon add the packages to a distribution place like launchpad to automatically push updates through it and likely thus make it a preffered option for sysadmins who don't run a container cluster.

[paulocoghi]

@Gamerboy59 thanks a lot for you great contribution!

I recommend providing a way to install without depending on docker as most as possible, in the same way we don't need docker to install rpxy.

But it's fine to also provide a docker compose file

[Gamerboy59]

@paulocoghi thanks for your comment.
The .rpm and .deb packages work well without docker, they integrate as native system service, so they are right on your disk without another abstraction layer. I think, this will be my preferred choice of distribution from now on because you can very easily update with yum update or apt update and everything should be updated automatically.
I'll maintain the docker files additionally so people who already run containers can use it but, especially in kubernetes clusters, it doesn't really make sense to use it, also from technical aspects, because you'd have an ingress-controller, which is basically a reverse-proxy that forwards to rpxy (which is also a reverse-proxy). So there's two reverse-proxies chained which undermines the purpose of rpxy to be a fast and light app in my opinion.

Right now the distribution packages work in a way that /rpxy-webui is added as a global configuration which is accessible from every place the webserver is configured for (default is all interfaces, also public). My idea for the next release is to add some form of a dialog-box to the installer where you can select to configure rpxy-webui as an additional, internal vHost, instead of a global configuration, and automatically add a upstream entry for rpxy to forward to this internal vHost. This makes rpxy listen for port 80 and port 443 on the public interface and if you access the default domain at http://<domain>/rpxy-webui, rpxy will forward this to the internal vHost (located at maybe http://localhost:8080).

I hope this makes a bit sense what I just wrote. ;) sorry if I expressed this a bit unclear

[Gamerboy59]

Hi :)
rpxy-webui now supports acme as well as importing custom certificates. It also converts the imported certificate to PKCS8 if it isn't in this format already.
Additionally, I consider adding the rpxy binary to the RPM and DEB distribution packages. Adding them as a system service simplifies the upgrades by a lot in my opinion. Of course, this risks that the distribution packages lack behind the github release but it's actually quite common to be the case with distribution packages so I don't see a big problem here. If the difference between rpxy and rpxy-webui is too big, it's likely not going to work anyways. Including the binary would require just one command (like apt-get install rpxy or dnf install rpxy) to install a working instance and service of rpxy including the webinterface. What are your thoughts about this?

[paulocoghi]

Good news @Gamerboy59 !

Adding them as a system service simplifies the upgrades by a lot in my opinion.

Fully agree on this one!

---

Including the binary would require just one command (like apt-get install rpxy or dnf install rpxy) to install a working instance and service of rpxy including the webinterface. What are your thoughts about this?

I suggest to have distribution packages for both rpxy and rpxy-webui and, when asking to install rpxy-webui, you can set rpxy as a dependency of it to be automatically installed.

[Gamerboy59]

Thanks for your answer @paulocoghi. Good idea to seperate rpxy and rpxy-webui into two packages and relate them.
rpxy-webui will have rpxy as requirement while rpxy will only recommend rpxy-webui. Thus rpxy can also be installed without rpxy-webui but rpxy-webui not without rpxy.
I can create the necessary distribution packages for Debian/Ubuntu, RedHat/Rocky/Alma etc. and probably also a FreeBSD port and pkg. Is creating distribution packages of rpxy something you want to take care of @junkurihara or should I build them along with the webinterface?

[junkurihara]

Hi, sorry for my delayed reply.

Thanks @paulocoghi and @Gamerboy59 for your discussion!

rpxy-webui now supports acme as well as importing custom certificates. It also converts the imported certificate to PKCS8 if it isn't in this format already.

That's a good news! Good job 👍

Additionally, I consider adding the rpxy binary to the RPM and DEB distribution packages.

Yes, I think it is a nice idea.

I suggest to have distribution packages for both rpxy and rpxy-webui and, when asking to install rpxy-webui, you can set rpxy as a dependency of it to be automatically installed.

I agree with this opinion :-)

I have never built RPM / DEB packages and used rpxy as a system services like systemd (I always use it as a container). So it would take time if I built and publish packages by myself. If you are okay, please go ahead to build and publish both rpxy and rpxy-webui packages.

[Gamerboy59]

If you are okay, please go ahead to build and publish both rpxy and rpxy-webui packages.

I'm setting up a pipeline to build rpxy packages for RPM and DEB based distributions. rpxy-webui packages are already available but I'll add an installer dialog.

[Gamerboy59]

As mentioned in #182, I've setup a page with instructions: https://rpxy.gamerboy59.dev/

[junkurihara]

with instructions: https://rpxy.gamerboy59.dev/

Awesome! That's seems really helpful for users.

BTW I think current configuration documentation, i.e., README.md and example-config.toml seems messy for new users. So, in addition to the @Gamerboy59 's site, maybe we also need to host another site for configuration? Fortunately to test TLS with rpxy, I already owned rpxy.net, org, and io. So maybe with them, should we prepare such a site?

[Gamerboy59]

Hi @junkurihara Thanks for your comment. I'm glad you like the first version of my package-site.
It's good to have the domain names secured and on hand. I really think we you make the documentation more clear. The README.md has some good example but the example-config.toml is difficult to understand if you use rpxy for the first time. I propose we either use Github Pages to host the site or, since it comes with quite some limitations, I can host the docs as well. Do you think of a more inclusive documentation or more like a one-pager for each release and probably a changelog additonally?

[junkurihara]

Hi @Gamerboy59 , thanks for the comment 😄

Yes, GitHub Pages are promising options. I will try to make a website on another repo!

Do you think of a more inclusive documentation or more like a one-pager for each release and probably a changelog additonally?

I think the inclusive documentation seems better, it is tough to make it though.