SVI/ProxmoxVE
1
0
Fork 0
mirror of https://github.com/community-scripts/ProxmoxVE.git synced 2026-07-28 08:42:37 -04:00
Code Issues 2.6k Packages Projects Releases 10 Wiki Activity

Allow to skip network connectivity check routine #1595

New Issue
Closed
opened 2025-11-20 05:13:00 -05:00 by saavagebueno · 3 comments
saavagebueno commented 2025-11-20 05:13:00 -05:00
Owner
Copy Link

Originally created by @noquierouser on GitHub (Jul 29, 2025).

🌟 Briefly describe the feature

Add an option to skip network connectivity check routine during creation or on failure

📝 Detailed description

My organization's firewall has a policy that blocks all ping requests and responses, regardless of DNS resolution. That means that I can't install scripts anymore, because all of them fail at the LXC container customization stage, when network connectivity is checked.

Looking at the latest commits, I can tell that a change introduced in commit #6142 changed the way network is checked, that doesn't allow to continue despite having no connectivity, as it was before. This means that, prior to this change, I was still able to continue the installation process, despite not having ping responses available.

So, instead of requesting the old behavior to be reinstated, maybe there could be an option to skip network connectivity check routines, or maybe, to allow to continue if pings fail.

💡 Why is this useful?

This could allow to install and deploy scripts in heavily secure environments, where ping is disabled, but internet connectivity is available and known to be working.

Originally created by @noquierouser on GitHub (Jul 29, 2025). ### 🌟 Briefly describe the feature Add an option to skip network connectivity check routine during creation or on failure ### 📝 Detailed description My organization's firewall has a policy that blocks all ping requests and responses, regardless of DNS resolution. That means that I can't install scripts anymore, because all of them fail at the LXC container customization stage, when network connectivity is checked. Looking at the latest commits, I can tell that a change introduced in commit #6142 changed the way network is checked, that doesn't allow to continue despite having no connectivity, as it was before. This means that, prior to this change, I was still able to continue the installation process, despite not having ping responses available. So, instead of requesting the old behavior to be reinstated, maybe there could be an option to skip network connectivity check routines, or maybe, to allow to continue if pings fail. ### 💡 Why is this useful? This could allow to install and deploy scripts in heavily secure environments, where ping is disabled, but internet connectivity is available and known to be working.
saavagebueno added the enhancement label 2025-11-20 05:13:00 -05:00
saavagebueno commented 2025-11-20 05:13:01 -05:00
Author
Owner
Copy Link

@tremor021 commented on GitHub (Jul 29, 2025):

Your problem is missing a word "Homelab"

@tremor021 commented on GitHub (Jul 29, 2025): Your problem is missing a word "Homelab"
saavagebueno commented 2025-11-20 05:13:01 -05:00
Author
Owner
Copy Link

@michelroegl-brunner commented on GitHub (Jul 30, 2025):

People in Homelabs (wich this scripts are made for) would just ignore all errors and we would get flooded with issues again.

This will not get changed.
When you need/want anything else, just fork the repo and remove/add what you need.

@michelroegl-brunner commented on GitHub (Jul 30, 2025): People in Homelabs (wich this scripts are made for) would just ignore all errors and we would get flooded with issues again. This will not get changed. When you need/want anything else, just fork the repo and remove/add what you need.
saavagebueno commented 2025-11-20 05:13:02 -05:00
Author
Owner
Copy Link

@noquierouser commented on GitHub (Jul 30, 2025):

Hi @michelroegl-brunner,

I completely understand the concern about users indiscriminately ignoring errors. However, I'd like to point out that there are legitimate use cases even in homelab environments:

  • ISPs that block ICMP due to their own security policies
  • Users in shared spaces (apartments, small offices) without control over network configuration
  • Non-profit community organizations that depend on shared infrastructure (as is my case)

I see this topic was already addressed in #6172, which suggests this isn't an isolated case.

Knowing all this, would you consider implementing an option with intentional high friction? Something like requiring an environment variable prior to running the script, similar to what PHP Composer does with allowing to run composer as superuser. This would make any risk explicit to the user, who would deliberately have to set this variable prior to running the script, while maintaining the majority of the use cases intact.

Alternatively, implementing fallback checks (curl/wget) when ping fails could solve the problem without compromising security as well, but maybe this might not apply to all possible cases and might end up being a maintenance nightmare on itself.

Regarding the suggested fork, as far as I can tell, the hardcoded URLs in the scripts make this kind of impractical. Is there documentation for maintaining a functional fork?

I really appreciate the work you do on this project. My intention is to find a solution that benefits everyone without compromising support quality.

@noquierouser commented on GitHub (Jul 30, 2025): Hi @michelroegl-brunner, I completely understand the concern about users indiscriminately ignoring errors. However, I'd like to point out that there are legitimate use cases even in homelab environments: - ISPs that block ICMP due to their own security policies - Users in shared spaces (apartments, small offices) without control over network configuration - Non-profit community organizations that depend on shared infrastructure (as is my case) I see this topic was already addressed in #6172, which suggests this isn't an isolated case. Knowing all this, would you consider implementing an option with **intentional high friction**? Something like requiring an environment variable prior to running the script, similar to [what PHP Composer does with allowing to run composer as superuser](https://getcomposer.org/doc/03-cli.md#composer-allow-superuser). This would make any risk explicit to the user, who would deliberately have to set this variable prior to running the script, while maintaining the majority of the use cases intact. Alternatively, implementing fallback checks (curl/wget) when ping fails could solve the problem without compromising security as well, but maybe this might not apply to all possible cases and might end up being a maintenance nightmare on itself. Regarding the suggested fork, as far as I can tell, the hardcoded URLs in the scripts make this kind of impractical. Is there documentation for maintaining a functional fork? I really appreciate the work you do on this project. My intention is to find a solution that benefits everyone without compromising support quality.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
🛑 Failure to comply with the guidelines
breaking change
bug
bug
bugfix
deferred
delete script
dependencies
enhancement
external
feature
github
help wanted
Implemented in VED waiting push to Main
in project pipeline
invalid
investigation
json
maintenance
new script
new script
nice to have
not a script issue
not planned
organization
pull-request
Mirrored from GitHub Pull Request
 question
refactor
rename script
security
update script
website
wontdo
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
saavagebueno
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SVI/ProxmoxVE#1595
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?