Feature Request: Userscripts in webUI

[Dunuin]

Hi,

Sometimes I really wish there would be some user-customizable buttons in the webUI. I do a lot of scripting to automate my PVE server but it is quite annoying to run all that scripts though the console. It would be so much more comfortable, if I could run these scripts by pressing a button in the webUI.
We already got hook scripts that can be placed in the snippets storage, so PVE tasks can make use of hooks for automation. My idea would be that we could place scripts in the snippets storage and call them something like "userscript_SomeName.bash" or "userscript_SomeOtherName.sh". PVE could then scan the snippet storage for files starting with "userscript_" to see if there are userscripts present and if they are, PVE could show some buttons in the webUI to make those scripts executable.
The webUI header got a lot of empty space. Would be really nice if they could show up there like this:


I know that this wouldn't be that easy to implement, as you probably also would need to check permissions, add new privileges so it could be limited which users are allowed to run which scripts and so on. Maybe parsing of scripts for metadata so the script could specify a name that should be shown in the webUI, needed privilege and similar. Maybe different script states or scripts that allow arguments so running script for a node would pass the node name to the script and so on...

But I would really like to see that. I got so much tasks I need to run scripts for:

• mounting filesystems
• unlocking encrypted pools/partitions
• bulk starting/stopping guests in an specific order
• disabling/enabling multiple storages at once
• booting/stopping other servers though IPMI
• unlocking encryption of remote server
• bulk manual backups
• switching between performance modes (underclocking CPU and changing CPU governor to save electricity when no running VMs actually needs that much power)
• ...

Would be so much more convenient.

Does such a feature request already exist in the bugtracker or should I create a new one?
Someone else finds this useful or am I the only person here that heavily cusatomizes its PVE nodes?

 

[BassT]

+1

 

[LnxBil]

Someone else finds this useful or am I the only person here that heavily cusatomizes its PVE nodes?

Our solution to this problem is to have a special VM that does all the clusterwide automation for us with scripts similar to your's.

 

[Dunuin]

Our solution to this problem is to have a special VM that does all the clusterwide automation for us with scripts similar to your's.

Yes, got an orchestrator VM on my todo list and maybe I will even embed my webUIs in an iframe so I can add a custom tool bar at the top of the webUI to easily interact with the orchestrator VM to tell it to do stuff on the PVE nodes.

 

[DaniMa]

Hello I've just seen your reply @Dunuin, was your idea adding an iframe to the proxmox GUI? I've been looking for that for a while because I want to make a VM that uses Ansible to create VM on Proxmox and I was about to make a web page with a form for that but i really wanted to make the form appear on the proxmox GUI instead of using the virtual machine itself.

 

[ReanimationXP]

Bump, this is a great idea. I'd like to see it taken a step further even. Being able to add these as part of a container deployment, or apply them to multiple nodes from a repo for that type of node, (or in other words, a userscript for applying userscripts to a node type) would be awesome too.

I'm already kind of flabbergasted that given the existence of the helper script community, that Proxmox itself doesn't have the ability to load a repo of community scripts and present them as creatable, deployable, one-click-installs for different types of nodes, i.e. Immich. As part of the script it could present a small basic config in the UI, asking for basic settings, port, hostname, etc, then create a container and any necessary interface configs based on your answers.

 

[gfngfn256]

I'm already kind of flabbergasted that given the existence of the helper script community, that Proxmox itself doesn't have the ability to load a repo of community scripts and present them as creatable, deployable, one-click-installs

I really hope that this is NEVER incorporated into PVE!

First off, those helper scripts have nothing todo with PVE itself, and should definitely not be condoned or supported by Proxmox itself.

Community-driven user scripts - while useful as a learning tool for some, are highly & wildly abused by others as a one-click job-done approach. These often lead in a broken result rather than a working one. Search these forums & others for similar.

As a rule - you should never run ANY downloaded script on your system - without fully understanding what that script is doing!

Now someone suggests incorporating, some community/enthusiast/forum-driven script directly as a repo accessible in PVE? Really?
I honestly hope this idea does not gain any traction or interest.

 

[Johannes S]

Bump, this is a great idea.

It's really not for all the reasons pointed out by @gfngfn256

I'd like to see it taken a step further even. Being able to add these as part of a container deployment, or apply them to multiple nodes from a repo for that type of node, (or in other words, a userscript for applying userscripts to a node type) would be awesome too.

Why? For the usecase of deploying a certain application to a certain vm there is already a "one step and done"-solution which is also working outside of ProxmoxVE : Using docker-compose, podman or some other application container deployment tool. To be honest for more home users who just want to run some services I would even say that a NAS OS like OpenMediaVault or UnRaid with docker support is more suited (much less maintenance needed) than ProxmoxVE. I might be a hypocrite though, since I'm using ProxmoxVE myself in my homelab But I try to use it as a learning plattform for trying out stuff too. If you don't want it but just want to do home automation, hosting nextcloud or a media server for your family or flatmates or have a next cloud for your friends, the NAS solution is much less hassle and maintenance and also needs much less knowledge.

I really hope that this is NEVER incorporated into PVE!
First off, those helper scripts have nothing todo with PVE itself, and should definitely not be condoned or supported by Proxmox itself.

Agreed.

Community-driven user scripts - while useful as a learning tool for some, are highly & wildly abused by others as a one-click job-done approach. These often lead in a broken result rather than a working one. Search these forums & others for similar.

Exactly, in my opinion the existence of the helper scripts is kind of a tragedy. Tteck was a quite gifted sysadmin and shell programmer so a lot can be learnt from reading and tweaking his scripts. But they are mostly used for the opposite (one-click-job-done), for which already exists a better, more universal solution-> docker compose, podman pods etc. Please don't take this as a diss against tteck: He is not to blame how people uses his scripts and he obviouvsly knew what he did and which limits his scripts had and how to work with that,. Sadly a large part of the reddit crowd don't know and also don't want't to change this. That's at least my impression from my unregulary lurking, if some of you happen to be a regular in /r/homelab or /r/proxmox I'm happy to challenge my prejudices!

As a rule - you should never run ANY downloaded script on your system - without fully understanding what that script is doing!

To be fair this is also true for docker-compose files, but on the other hand at least in theory if you get them from the coresponding softwares website (e.G. paperless-nginx, Jellyfin etc) or a trustworthy registry it's more likely it's not a version with malicious "bonus features" made by an attacker.

Now someone suggests incorporating, some community/enthusiast/forum-driven script directly as a repo accessible in PVE? Really?
I honestly hope this idea does not gain any traction or interest.

This is (sadly) nothing new, there were already past discussions on simliar requests:

S

Thread 'Is there a mod repository ? How to make mods ?'

Dec 22, 2024

Hi,

I would like the VM creation dialog to display the exact QM command line that a particular config will run.

I would also like to export and import this whole config using simple copy and pasting of a single line of text

And I thought I could mod my proxmox install and maybe post the mod on this forum ?

• shodan
• Replies: 37
• Forum: Proxmox VE: Installation and configuration

Or this one:

A

Thread 'Urgent suggestion: Tteck Scripts for Proxmox'

Nov 2, 2024

Hello

I wanted to take a moment to express my appreciation for the incredible work your team does in developing Proxmox. and this what encourge me suggest this idea.

One of the most valuable tools in the Proxmox ecosystem, for myself and many others, is the Tteck scripts. These scripts play a crucial role in enhancing the usability of Linux Containers (LXCs), making their creation and management much more efficient.

After reading Tteck’s recent announcement regarding the future of the scripts (found here: Tteck Announcement), I felt a profound sense of concern for both Tteck and...

• adrymax
• Replies: 4
• Forum: Proxmox VE: Installation and configuration

The discussions got more heated than they should (I myself wasn't exactly innocent to be honest) since some people didn't liked that idea very much and other community members blamed them to be part of "development bureaucracy" to prevent integrating new features. Please notice, that no members of Proxmox Server Solutions GmbH (the official "development buerocracy" if you want to use that term) participated in that debates (propably a good idea on their part) so don't take that diskussions for more than bickering between community members. But the most important pro- and contra- arguments should be clear.

I myself still think it's a bad idea for all the reasons mentioned in this and the other threads. For example one argument was, that a mod system would allow to disable security features which are not needed in the opinion of the administrator. Now I might be an old Unix neckbeard but that's quite a dangerous idea in my book: If a security feature shouldn't be disabled in the mormal system it also shouldn't be disabled via a mod or script. And if there is actually a reason, why one might want to disable such a feature than this possibility should be included in the actual software without needing a mod or script for that.

But of course I'm happy to discuss this again, but please for the love of Turing or Lovelace not with "arguments" made up with a LLM aka ChatGPT

 

[guruevi]

@ReanimationXP: most of what you need is here:
https://docs.ansible.com/ansible/latest/collections/community/general/proxmox_module.html
Which is just a layer on top of Proxmoxer which itself is a full implementation of the API.

If you want to coordinate the hardware management itself, look into RedFish or the vendor specific Linux package (eg. Dell, SuperMicro have Debian management integrations).

Proxmox is an ‘appliance’ not a general purpose OS, just like VMware.

 

[mrjcleaver]

I really hope that this is NEVER incorporated into PVE!

First off, those helper scripts have nothing todo with PVE itself, and should definitely not be condoned or supported by Proxmox itself.

Community-driven user scripts - while useful as a learning tool for some, are highly & wildly abused by others as a one-click job-done approach. These often lead in a broken result rather than a working one. Search these forums & others for similar.

As a rule - you should never run ANY downloaded script on your system - without fully understanding what that script is doing!

Now someone suggests incorporating, some community/enthusiast/forum-driven script directly as a repo accessible in PVE? Really?
I honestly hope this idea does not gain any traction or interest.

Let's keep two ask separate.

1. The ability for an administrator to add to their own UI the scripts that they need
2. The availability and encouragement of community-scripts (especially unvetted ones) from making it onto a typical PVE instance.

The OP is advocating for the former. The origin of such a script was not specified.

And yes, I have various scripts that I would like to invoke on my PVE instance UI.

Martin.

 

[guruevi]

My suggestion would be to use Semaphore UI in an LXC container if you really want a GUI to invoke your scripts against Proxmox nodes. Inserting things into the GUI, especially since you're likely not in a position to 'fix' those things when there is a change is asking for trouble. Then people will open posts here "why doesn't this update work" when its your own scripts that cause the issues.

Here is an idea, tie a hookscript to a dummy guest, then you can run whatever you want by starting the guest.

 

[gfngfn256]

The OP is advocating for the former. The origin of such a script was not specified.

As you can see my comment was written to:

I'm already kind of flabbergasted that given the existence of the helper script community, that Proxmox itself doesn't have the ability to load a repo of community scripts and present them as creatable, deployable ..........

NOT to the OP who started this thread - whom I know would never advocate incorporating third-party/community scripts into PVE/GUI itself.

BTW I actually would also appreciate (like the OP) that personal scripts (definition here of personal; that the user understands, has created & is familiar with and realizes are not an integral part of PVE & takes responsibility as such) to be given some custom access in the GUI. I have a number of my own scripts that I run periodically & wouldn't mind if they were available in the GUI.

The obvious down-side here is, that enough users will end up copying & pasting scripts from the WWW wilderness & integrating them (easily) into PVE - and then breaking their systems - search these forums!

 

[mrjcleaver]

...

The obvious down-side here is, that enough users will end up copying & pasting scripts from the WWW wilderness & integrating them (easily) into PVE - and then breaking their systems - search these forums!

Well, true, though if those scripts were individually hosted in Github, had issues lists and were cloned via git then at least we'd have a decent improvement cycle around them.

 

[Johannes S]

Well, true, though if those scripts were individually hosted in Github, had issues lists and were cloned via git then at least we'd have a decent improvement cycle around them.

Well, the community helper scripts are already on github and it doesn't help much in regard to the issues pointed out by @gfngfn256

 

[mrjcleaver]

ok, well:
> you should never run ANY downloaded script on your system - without fully understanding what that script is doing!

I downloaded pve. I have no clue how most of it works.

It's a flippant point, but fundamentally of course it's open source, which only works if there is a quality interaction around the code. Which I assume there is around the core of PVE and not around the contributions. Pasting code divorces it from origin. Users using need to be encouraged to talk about what they see.

As much as we might hate a script-kiddie approach, a professional UI would not only make it easier to to find and clone those scripts it would also drive the human or quality interaction process around them to rate everything and drive patches, pull requests and revocations of bad scripts.

Just my 2c.

 

[alexskysilk]

It's a flippant point, but fundamentally of course it's open source

The source is not the relevant part, insofar that makes a software trustworthy or not. theres plenty of open source malware.

The admonition here is not to run software you found on the internet without knowing what it does- expecially if it has access to the root of your OS.

 

[guruevi]

There is also nothing preventing you from putting in a menu system in ~/.bash_profile so when you login to the GUI and open a terminal you can then perform certain actions, I’ve done this before the nVIDIA driver integration. Your community script is also allowed to patch the HTML and add plugins.

There is lots that can be done, ‘someone’ has to do it, making it the ‘job’ of the maintainers of the main project is asking for some level of support for your specific flavor of community scripts (which there are more than a few ‘out there’). Again, there is an API and a Python interface which ‘someone’ could make an HTML interface for with a few dozen lines of code. My personal favorite would be to change the shell to something like fish and use its programmable autocomplete.

 

[ReanimationXP]

ok, well:
> you should never run ANY downloaded script on your system - without fully understanding what that script is doing!

I downloaded pve. I have no clue how most of it works.

It's a flippant point, but fundamentally of course it's open source, which only works if there is a quality interaction around the code. Which I assume there is around the core of PVE and not around the contributions. Pasting code divorces it from origin. Users using need to be encouraged to talk about what they see.

As much as we might hate a script-kiddie approach, a professional UI would not only make it easier to to find and clone those scripts it would also drive the human or quality interaction process around them to rate everything and drive patches, pull requests and revocations of bad scripts.

Just my 2c.

Oh look, someone applying rational thought instead of just being contrarian and toxic for no reason. Shocking. I will not be wasting my time on these forums. With comments like these it's no wonder the existing UI is an obtuse nightmare compared to even VMWare, which wasn't great to begin with. OP and my suggestions give Proxmox a chance to stand out among its' competitors, but we wouldn't want that - someone might inject malware into the easily-readable script rather than the project's source code!

 

[LnxBil]

With comments like these it's no wonder the existing UI is an obtuse nightmare compared to even VMWare

Would you care to comment further on that? I for myself think PVE UI is different but much better and (for me) more intuitive than VMware's. A lot of features I have to tweak are more accessible.