Enhancing Global Setup Scripts #3280
Replies: 3 comments
-
My thoughts Enhancing Global Set-UpsI don't use tags, but others may, so might be a nice to have, but I think the time to deploy the options is not worth it because It will probably not be used to match. Default Setup PreferencesI would love to see this, would use it to set the storage option right away. But matching the IP and LXC ID, is not possible, your router gives the IP, this had noting to do with the script. Automated Reverse Proxy & Dashboard SetupIt might be a nice to have, but I think it's difficult to do, and maybe not even possible in all scenarios. Enhancing Password and Access ManagementHard no from me. And why enable SSH on a lot/all of your containers? Thanks for sharing your ideas, gives me and hopefully others an opportunity to think and share their thoughts and ideas. |
Beta Was this translation helpful? Give feedback.
-
Thank you for your detailed feedback on my suggestions. I appreciate your insights and the opportunity to discuss these ideas further.
You raise valid points about the complexity of managing IP and LXC ID matching across multiple network devices and subnets. I agree that it might be more work than it's worth, but not totally impossible. I have a similar setup to yours, but I still maintain the IP & LXC matching. Each virtual network interface has its own subnet with permissions that I configure directly in my OpenWRT router. For example, public services could be on vmbr0 on subnet 10.0.0.0 and private services on 10.1.1.1. This would require the additional step of being able to create default option presets per network interface.
What's your preferred reverse proxy? Personally, I use Nginx Proxy Manager (NPM), but I'm eager to switch to Traefik because it allows you to define your reverse proxy via code (YAML). In theory, using the information already available in the helper script definition could dynamically construct your reverse proxy rules. All you would have to provide during setup would be the sub/domain you're using for the service. On a related note, I want to switch from NPM because it has bugs with the access list feature. I cannot create access lists that allow certain URLs to be available only from local network requests or requests from machines on my Tailscale network. Additionally, NPM requires a subdomain for everything I reverse proxy, but I prefer using a single domain with locations (e.g., alexanderjerome.com/paperless or alexanderjerome.com/plex). Traefik handles these features better out of the box and, if configured properly, could integrate directly with Proxmox containers. I still have to explore this further to understand the challenges.
Agreed, but I was thinking about using open-source secrets management for storing API keys, SSH keys, etc., rather than a password manager like Bitwarden. While I use the Vaultwarden helper script with Passkeys and TOTP features, it doesn't integrate directly into dev environments. Bitwarden/Vaultwarden doesn't sync SSH configuration files, API keys stored in environment variables, GPG keys, etc. Infisical or another open-source secrets management solution could provide a streamlined, accessible, 2FA-enabled means to secure access methods and integrate them into the installation script, especially considering that the helper scripts already allow the user to enable root access and set a password. Centralized secrets management would also mean that if I have to re-roll an API key, I don't have to edit the environment variables across multiple VMs, as that sync would be managed by the secrets manager. While many people using these scripts are primarily home-lab enthusiasts, I think a helper script for an open-source secrets manager would be a great addition, especially if it integrates with the installation or post-installation process of a helper script.
I often use containers as dev environments, so I SSH into them through my code editor. For persistent services like Paperless, I may need to edit configuration files or use an FTP application like Filezilla to upload/download files in a container or on my NAS. VS Code's Remote Explorer extension makes it easy to edit code directly on the container, but when working on different clients, you often need to retrieve your access keys from an existing machine, which adds extra steps. The global configuration options in the install scripts already allow enabling remote root access, so integrating a self-hosted secrets manager isn't too far off. You could also have the install script allow you to create another non-root user for access or preconfigure the root access to only work using specific keys stored in your secrets manager.
I mentioned this because we already tag containers with "proxmox-helper-scripts," and organizing them by functional categories becomes helpful when running many containers. For instance, I could have multiple Docker LXCs installed via the helper script with different names, so the "docker" tag could help identify the purpose of the container when not using the default hostname. The information is already in the page structure, so adding a tag based on the script's category wouldn't be too much of a stretch. You can sort how your containers are listed under the Datacenter view.
Agreed, notes can be modified after installation. But having initial notes contain the description, port number, and other details from the helper-scripts description can prevent context switching and make the initial notes more informative and relevant to the service. If a helper script is ever delisted from the website, at least the initial description and notes are still in your container's note section. At the very least, a hyperlink that takes you directly to the helper-scripts entry on the GitHub page is easier than going to the page and searching for the script. For example, here I simply modified the HTML of the note for Mafl to include a hyperlink to the Proxmox helper script page for the service: It's not a huge modification, but it goes a long way in helping go directly to relevant information from within the Proxmox web UI. It's also worth mentioning that although I really appreciated the new website, it had to be taken down due to large amounts of traffic. I'm willing to bet a good chunk of that traffick was due to people having to go to the website to reference documentation for scripts they already installed. Having the information from the website regarding the container directly inside the containers notes could reduce excess traffic and improve the odds of returning to that elegeant UI (kudos to the web designer). Below, a screenshot of how the Notes section would look if the HTML was integrated directly into the container's notes section. And, as you can see, the "proxmox-helper-scripts" tag can overwhelm the view if it's the only tag present. I changed the tags default color to a darker one in an attempt to make it stand out less in comparison to other tags. Overall, you raise great points about not over-complicating the setup process, and I've definitely heard the feedback that I tend to want to do so. But, I see that the initial work of simplifying processes can go a long way: as a developer and Proxmox enthusiast with ADHD, I'm focused on reducing context switching and deploying services quickly across multiple machines and making it quicker and easier for me to do my work. Streamlined, repeatable processes are invaluable for those of us with executive function challenges, and what I like about the helper scripts is that they really help make learning Proxmox a much more approachable, friendly and immediately useful endeavor. I'd like to see that aspect of it grow so more people warm up to self-hosting instead of relying on the good-will of mega corporations. I know my suggestions won't be what everybody needs, but I'm sure a few people would appreciate being able to streamline their preferred configurations and minor adjustments to improve quick access. Happy to help however I can! TLDR: the helper-scripts are awesome and lets continue to make them more so. |
Beta Was this translation helpful? Give feedback.
-
This is what sets the description in each app Lines 640 to 652 in 6e6a86a How would you propose modifying this to display what you're suggesting without rewriting the entire codebase? |
Beta Was this translation helpful? Give feedback.
-
Greetings! This is my first time posting here, but I was inspired to finally share some suggestions that have been brewing in my brain for the past year or so that I've been using these scripts. Thanks @tteck and the community for all your contributions, these scripts have been so helpful for myself and for others that I've shown them to. Below I detail some of these suggestions, and yes I did use AI to help me word the suggestions. Please let me know if you have any feedback, or if you have any complimentary ideas that may specifically apply to the effect of global script configurations.
Enhancing Global Set-Ups
The current tagging system for containers and VMs in the Proxmox Helper Scripts only includes the tag "proxmox-helper-scripts". It would be more informative and organized to have additional tags indicating the script category each container or VM belongs to, such as "Document - Notes" for the paperless-ngx container or "Server - Networking" for the nginx proxy manager container. Furthermore, the Notes section in the container summary lacks detailed information about the container or VM, making it difficult for users to quickly access important details without referring back to the GitHub page.
Proposed Solutions:
Default Setup Preferences
Users often have default settings they like to repeat across most containers, such as:
Proposed Solutions:
Automated Reverse Proxy & Dashboard Setup
Automating the configuration of reverse proxies, such as Traefik, and setting up dashboards can be streamlined by utilizing normalized formatting for port numbers in the container descriptions. However, users often need to refer back to the helper scripts GitHub page to find the necessary information, which can be inefficient and disruptive to the workflow.
Proposed Solutions:
Enhancing Password and Access Management
Managing passwords and access across multiple containers and services can be challenging and time-consuming. Implementing a centralized password and access management system would greatly improve security and ease of use for users. Additionally, it can be cumbersome to set-up SSH access from personal dev machines when we need to use our hosted services.
Proposed Solutions:
Beta Was this translation helpful? Give feedback.
All reactions