[GH-ISSUE #68] Use standard community scripts to install local, LXC or VM

kerem commented

2026-03-02 15:47:30 +03:00

Owner

Originally created by @DAE51D on GitHub (Feb 22, 2026).
Original GitHub issue: https://github.com/PegaProx/project-pegaprox/issues/68

First of all, #TIL about your project and I'm blown away at how incredible it is. How I never heard about it until now is equally crazy to me 😄

But what also baffles me is why you don't leverage the standard Proxmox Community scripts mechanism
https://community-scripts.github.io/ProxmoxVE/scripts

These are literally designed to install things locally, build LXCs or VMs...

In my mind, I keep thinking, "There must be some method to their madness in NOT using this?" But TBH for the life of me, I can't figure out what that would be (you literally even have a bash installer too -- what I ran ON my proxmox node myself)

I look forward to watching this project evolve (and honestly it's astonishing how far and robust it is currently!)

I'm sure you hear this all the time, but THIS is the GUI that Proxmox VE needs and deserves. That archaic 1990's looking garbage they still have in a version 9.1 service is embarrassing honestly. So you're doing the Lord's work really here. 😉

Originally created by @DAE51D on GitHub (Feb 22, 2026). Original GitHub issue: https://github.com/PegaProx/project-pegaprox/issues/68 First of all, #TIL about your project and I'm blown away at how incredible it is. How I never heard about it until now is equally crazy to me 😄 But what also baffles me is why you don't leverage the standard Proxmox Community scripts mechanism https://community-scripts.github.io/ProxmoxVE/scripts These are literally designed to install things locally, build LXCs or VMs... In my mind, I keep thinking, "There must be some method to their madness in NOT using this?" But TBH for the life of me, I can't figure out what that would be (you literally even have a bash installer too -- what I ran ON my proxmox node myself) I look forward to watching this project evolve (and honestly it's astonishing how far and robust it is currently!) I'm sure you hear this all the time, but THIS is the GUI that Proxmox VE needs and deserves. That archaic 1990's looking garbage they still have in a version 9.1 service is embarrassing honestly. So you're doing the Lord's work really here. 😉

kerem commented

2026-03-02 15:47:31 +03:00

Author

Owner

@3DJupp commented on GitHub (Feb 22, 2026):

Agree on that, would appreciate a working Community Script for that tool. It should be able to face the installation and upgrade paths.

@3DJupp commented on GitHub (Feb 22, 2026): Agree on that, would appreciate a working Community Script for that tool. It should be able to face the installation and upgrade paths.

kerem commented

2026-03-02 15:47:31 +03:00

Author

Owner

@abyss1 commented on GitHub (Feb 23, 2026):

Can I counter this , using Proxmox in an enterprise setting alot of the community scripts are useless , or even undesired breaking ISO rules and what not. I would sure make it an option but fpr people running multiple large clusters the community scripts are a nono , or even blocked due to security concerns or rules...

Besides the point that alot of the install LXCs with home automation and home dashboards etc :) I am pretty sure a tool like these would target companies first and home use second, I would think so anyways :)

So in short , I am not saying not to support it , but also not turn it on by default. It should be a choise, but also adds complexity outside of their own code as thaey will have to develop to support other peoples code...if this makes any sense :)

I wouldnt wanne let some of thoose scripts run over my georedudant 100+ nodes proxmox clusters anyways :)

@abyss1 commented on GitHub (Feb 23, 2026): Can I counter this , using Proxmox in an enterprise setting alot of the community scripts are useless , or even undesired breaking ISO rules and what not. I would sure make it an option but fpr people running multiple large clusters the community scripts are a nono , or even blocked due to security concerns or rules... Besides the point that alot of the install LXCs with home automation and home dashboards etc :) I am pretty sure a tool like these would target companies first and home use second, I would think so anyways :) So in short , I am not saying not to support it , but also not turn it on by default. It should be a choise, but also adds complexity outside of their own code as thaey will have to develop to support other peoples code...if this makes any sense :) I wouldnt wanne let some of thoose scripts run over my georedudant 100+ nodes proxmox clusters anyways :)

kerem commented

2026-03-02 15:47:31 +03:00

Author

Owner

@ISCOzmurph commented on GitHub (Feb 23, 2026):

I think community helper scripts validates the projects they list in some way... This project does NOT meet simple standards. This is NOT an open-source project and does not have an auditable security impact.

@ISCOzmurph commented on GitHub (Feb 23, 2026): I think community helper scripts validates the projects they list in some way... This project does NOT meet simple standards. This is NOT an open-source project and does not have an auditable security impact.

kerem commented

2026-03-02 15:47:31 +03:00

Author

Owner

@DAE51D commented on GitHub (Feb 23, 2026):

This project does NOT meet simple standards. This is NOT an open-source project and does not have an auditable security impact.

Huh? how is this "AGPL-3.0 license" not open source? And how is it not auditable; you're literally in their Github repo and can see all the code right here? 😕

The Community Scripts are just a whiptail wrapper often around a Github repository; case in point. So instead of their own curl install one-liner, it would be the community script that would handle building the LXC (or VM) template and installing onto that rather than the user having to do all that work or download some pre-built image that also has to be maintained. Furthermore the scripts assist in updating so the end user uses the same command update to update the OS and service.

I disagree with @abyss1 on both the "community scripts are useless" (for the above reason, it's nothing more than a wrapper to the code and a way to install services easier; they aren't inherently any more or less secure than rolling your own). And also disagree Pegaprox is for enterprise users; in fact I'd say the opposite. Have you ever looked at Hyper-V? It's ugly AF 😬 ... As a "home user", I hate the outdated "flutter" Proxmox VE web GUI and want an interface I use multiple times per day to be not only aesthetically pleasing but functional and more importantly maintained and updated. In the few years I've used VE, that GUI and UX has remained fairly stagnant.

Not to deviate too far from this, but look at the default Android app
https://play.google.com/store/apps/details?id=com.proxmox.app.pve_flutter_frontend
Then look at this well maintained and updated modern version (well worth paying for by the way)
https://play.google.com/store/apps/details?id=itss.proxmate.ios

A UI/UX is the first impression a user has, is the selling point, and a LOT will be forgiven if bugs are found if the UI looks good vs if it is all jenky. Trust me.

@DAE51D commented on GitHub (Feb 23, 2026): > This project does NOT meet simple standards. This is NOT an open-source project and does not have an auditable security impact. Huh? how is this "AGPL-3.0 license" not open source? And how is it not auditable; you're literally in their Github repo and can see all the code right here? 😕 The Community Scripts are just a whiptail wrapper often around a Github repository; case in point. So instead of their own `curl` install one-liner, it would be the community script that would handle building the LXC (or VM) template and installing onto that rather than the user having to do all that work or download some pre-built image that also has to be maintained. Furthermore the scripts assist in updating so the end user uses the same command `update` to update the OS and service. I disagree with @abyss1 on both the "community scripts are useless" (for the above reason, it's nothing more than a wrapper to the code and a way to install services easier; they aren't inherently any more or less secure than rolling your own). And also disagree Pegaprox is for enterprise users; in fact I'd say the opposite. Have you ever looked at Hyper-V? It's ugly AF 😬 ... As a "home user", I hate the outdated "flutter" Proxmox VE web GUI and want an interface I use multiple times per day to be not only aesthetically pleasing but functional and more importantly maintained and updated. In the few years I've used VE, that GUI and UX has remained fairly stagnant. Not to deviate too far from this, but look at the default Android app https://play.google.com/store/apps/details?id=com.proxmox.app.pve_flutter_frontend Then look at this well maintained and updated modern version (well worth paying for by the way) https://play.google.com/store/apps/details?id=itss.proxmate.ios A UI/UX is the first impression a user has, is the selling point, and a LOT will be forgiven if bugs are found if the UI looks good vs if it is all jenky. Trust me.

kerem commented

2026-03-02 15:47:31 +03:00

Author

Owner

@ISCOzmurph commented on GitHub (Feb 23, 2026):

Established in issue #75, I was wrong, it is technically AGPL compliant.

It is confusing, all of the main files are "pre-compiled" -- build-stepped and minified. This is typically kept out of repositories and instead we'd provide a /src/ and instructions on build process. In this repository, all of the source code is actually in a 30k line HTML file called index.html.original -- not where one would expect to look for a react app.

So, the existence of that monolith makes it technically AGPL compliant. When I said that, I had not found that file and thought the repository only contained the obfuscated pre-built code, which, again, should not be contained in a repo.

I really don't have high standards. This is pretty simple stuff that I'm complaining about. In its current state, it is unmaintainable.

So, while it complies with AGPL by the letter, since they do have a trashcan full of the actual source code, it does not comply with the spirit of AGPL.

Furthermore, I have no way of knowing that the code that runs on my system is indeed the source code contained within index.html.original -- that is a very big problem. I cannot run this in my production environment.

TL;DR: how a react repository should look: source code, build steps.
How this repository looks:
"Compiled" code (oh and btw pinky promise the compiled code is from the code we included in that index.html.original that's squirreled away.)

@ISCOzmurph commented on GitHub (Feb 23, 2026): Established in issue #75, I was wrong, it is _technically_ AGPL compliant. It is confusing, all of the main files are "pre-compiled" -- build-stepped and minified. This is typically kept out of repositories and instead we'd provide a /src/ and instructions on build process. In this repository, all of the source code is actually in a 30k line HTML file called index.html.original -- not where one would expect to look for a react app. So, the existence of that monolith makes it _technically_ AGPL compliant. When I said that, I had not found that file and thought the repository only contained the obfuscated pre-built code, which, again, should not be contained in a repo. I really don't have high standards. This is pretty simple stuff that I'm complaining about. In its current state, it is unmaintainable. So, while it complies with AGPL by the letter, since they do have a trashcan full of the actual source code, it does not comply with the spirit of AGPL. Furthermore, I have no way of knowing that the code that runs on my system is indeed the source code contained within index.html.original -- that is a very big problem. I cannot run this in my production environment. TL;DR: how a react repository should look: source code, build steps. How this repository looks: "Compiled" code (oh and btw pinky promise the compiled code is from the code we included in that index.html.original that's squirreled away.)

kerem commented

2026-03-02 15:47:31 +03:00

Author

Owner

@mkellermann97 commented on GitHub (Feb 23, 2026):

@ISCOzmurph Thanks for the follow-up. This discussion belongs in #75 rather than here, so let's keep this issue on topic.

You raise a fair point about reproducible builds – it's something we want to improve.
As noted in the source header, splitting into proper components is already on our roadmap.
We're a small team and prioritize features our users need, but we appreciate the feedback.
That said, calling our codebase a "trashcan" isn't constructive.

We're happy to discuss project structure improvements in a dedicated issue or PR.
Regards,
Marcus

@mkellermann97 commented on GitHub (Feb 23, 2026): @ISCOzmurph Thanks for the follow-up. This discussion belongs in #75 rather than here, so let's keep this issue on topic. You raise a fair point about reproducible builds – it's something we want to improve. As noted in the source header, splitting into proper components is already on our roadmap. We're a small team and prioritize features our users need, but we appreciate the feedback. That said, calling our codebase a "trashcan" isn't constructive. We're happy to discuss project structure improvements in a dedicated issue or PR. Regards, Marcus

kerem commented

2026-03-02 15:47:31 +03:00

Author

Owner

@DAE51D commented on GitHub (Feb 23, 2026):

@mkellermann97 I may be misinterpreting what @ISCOzmurph said about "trashcan" but I read that as "it's a huge 30k line minified JS that's basically unusable to a developer looking to read what the code is doing" (TBF I haven't looked at said file to validate this either)... the wording could have been better, but I don't think he meant it as a reflection on your team or your excellent work here.

BUT since you are here, any comment on my OP as to why you guys chose NOT to use the community scripts (yet)?

@DAE51D commented on GitHub (Feb 23, 2026): @mkellermann97 I may be misinterpreting what @ISCOzmurph said about "trashcan" but I read that as "it's a huge 30k line minified JS that's basically unusable to a developer looking to read what the code is doing" (TBF I haven't looked at said file to validate this either)... the wording could have been better, but I don't think he meant it as a reflection on your team or your excellent work here. BUT since you are here, any comment on my OP as to why you guys chose NOT to use the community scripts (yet)?

kerem commented

2026-03-02 15:47:31 +03:00

Author

Owner

@ISCOzmurph commented on GitHub (Feb 23, 2026):

@mkellermann97
Didn't mean to disrespect the codebase calling it a trashcan, just pointing out where the actual source code exists in the repo! It's literally tossed away and not used! Not that your code is trash, you've clearly got a useful base here!

Please find my PR, I have done a simple reorganization and if you would please merge it and we can move forward with a maintainable codebase!

@ISCOzmurph commented on GitHub (Feb 23, 2026): @mkellermann97 Didn't mean to disrespect the codebase calling it a trashcan, just pointing out where the actual source code exists in the repo! It's literally tossed away and not used! Not that your code is trash, you've clearly got a useful base here! Please find my PR, I have done a simple reorganization and if you would please merge it and we can move forward with a maintainable codebase!

kerem commented

2026-03-02 15:47:31 +03:00

Author

Owner

@mkellermann97 commented on GitHub (Feb 23, 2026):

@ISCOzmurph
Ah okay, I misunderstood – sorry about that! I've checked out your PR and it looks solid. Thanks for putting that together. We'll review it (other two's are sleeping already) and get back to you.

Regards,
Marcus

@mkellermann97 commented on GitHub (Feb 23, 2026): @ISCOzmurph Ah okay, I misunderstood – sorry about that! I've checked out your PR and it looks solid. Thanks for putting that together. We'll review it (other two's are sleeping already) and get back to you. Regards, Marcus

kerem commented

2026-03-02 15:47:31 +03:00

Author

Owner

@ISCOzmurph commented on GitHub (Feb 23, 2026):

@mkellermann97 no no, it's my mistake, I'm obnoxious and abrasive. But I mean well and I think I can help this project live up to its potential.

edit: and for why I commented on this issue, the community helper scripts do have particular standards and the project in its current state do not meet those standards. Those standards are easy, they just take a bit of experience.

@ISCOzmurph commented on GitHub (Feb 23, 2026): @mkellermann97 no no, it's my mistake, I'm obnoxious and abrasive. But I mean well and I think I can help this project live up to its potential. edit: and for why I commented on this issue, the community helper scripts do have particular standards and the project in its current state do not meet those standards. Those standards are easy, they just take a bit of experience.

Rows
Columns

[GH-ISSUE #68] Use standard community scripts to install local, LXC or VM #47