Unattended install

[LukeAllinson]

I love the hardware sensors script and it works nicely on my MS-01 on v8 and v9.

I am in the process of creating an ansible playbook to automate the build/configuration of my proxmox nodes and I'd like to be able to incorporate the script into it. Currently, the script is interactive for a few choices:

• CPU cores (all or average)
• Zero speed fans (yes or no)
• Temperature unit (C or F)
• System information (yes or no)

Could you please add the ability to specify additional [optional] cmd-line arguments to set these options so that the script runs without prompting for input?
Obviously the existing arguments should remain mandatory (i.e. the install mode), but if any of the others are specified then it should not stop the script to prompt. Conversely if any optional arguments are omitted, the script should stop and prompt as it does now for an answer.

I'm happy to have a crack at this myself when I get some free time, but I will confess that bash-scripting is not my primary area of expertise so my code is unlikely to be especially elegant. If I do before you get to it yourself I'll fork the repo.

[Meliox]

Hello,

This approach could certainly be useful, but I’m hesitant to implement it. The script works by modifying files based on content matching, which introduces some risk. Each time Proxmox updates its packages, the changes would be overwritten and would need to be reapplied. More importantly, there’s no guarantee of compatibility after an update—any change on Proxmox’s side could potentially break the implementation.

An overall mockup concept suggested by Ai.

#!/bin/bash

# Default values (empty = will prompt later)
cpu_mode=""
zero_fans=""
temp_unit=""
sysinfo=""

usage() {
  echo "Usage: $0 [-c all|average] [-f yes|no] [-t C|F] [-s yes|no]"
  exit 1
}

while getopts ":c:f:t:s:" opt; do
  case $opt in
    c) cpu_mode="$OPTARG" ;;   # CPU cores: all or average
    f) zero_fans="$OPTARG" ;;  # Zero speed fans: yes or no
    t) temp_unit="$OPTARG" ;;  # Temperature unit: C or F
    s) sysinfo="$OPTARG" ;;    # System info: yes or no
    \?) usage ;;
  esac
done

# Prompt only if not supplied
if [[ -z "$cpu_mode" ]]; then
  read -rp "CPU cores (all or average): " cpu_mode
fi

if [[ -z "$zero_fans" ]]; then
  read -rp "Zero speed fans (yes or no): " zero_fans
fi

if [[ -z "$temp_unit" ]]; then
  read -rp "Temperature unit (C or F): " temp_unit
fi

if [[ -z "$sysinfo" ]]; then
  read -rp "System information (yes or no): " sysinfo
fi

# --- Example of using the chosen values ---
echo "CPU cores mode:   $cpu_mode"
echo "Zero speed fans:  $zero_fans"
echo "Temperature unit: $temp_unit"
echo "System info:      $sysinfo"

[LukeAllinson]

I appreciate you taking the time to respond.
I agree that there is a risk, however doesn't that risk exist regardless?
All this is changing is how the script is called, not how the underlying code changes are applied.

I am not planning to use this frequently; it is a mini-project to standardise my home-lab setup so for me at least, the risk is low.
I fully understand your position though, and I am thankful of the time and effort that you put into creating and maintaining the script in the first place.

I'll close this issue for now.

[Meliox]

You are absolutely right - always important to understand the use case and potential downside. I will keep this open should I decide to make it or if someone else provides a PR for it. It is quite simple to do. Thanks for the suggestion.

[free-pmx]

Hello folks, maintainer of free-pmx-no-subscription project here.

Long story short, I originally started shipping my tailored package to, amongst other things, remove "just the UI nags", but since got asked to add features that would require me to add patches that I would rather not want to include.

The benefit of the patching approach is that:

• patches can be made to be idempotent; and
• fail gracefully; and
• auto-apply on upgrades; and
• if it does not apply, then user gets stock functionality back; and
• multiple versions of underlying files to patch can be supported with single patch-set; and
• patchset can be easily enhanced when needed.

Why did I chip in here? I went ahead and made a standalone PoC "patch-only" tool from it now, tailored to the specific use request to patch "just one extra file" on their own, i.e. without having to introduce it to my set of patches.

Now I went to look for already existing projects which could benefit. Yours would not only fit the bill, as it appears to be basically patching a JS and PM file from pve-manager, but someone already filed an Issue (this one) essentially asking for it to be unattented - which is the primary benefit coming out from the bullet points above - it can be done with the approach.

I had a quick glance and it can certainly be done with your mods here. My question basically is, if you would be interested in this approach and then:

• either just want to fork the PoC repo and make it your own; or
• have me add extra features that would make the patching more robust and universal (e.g. reverse apply patch, check integrity since last patch, etc.)

If you are interested, the good starting point is the README, my discussion with the first person using it to inject own JS snippet (and where it came from) and basically - feel free to ask any other questions.

Why am I doing this? Because I like to maintain one thing and have it do its thing reasonably well, i.e. I am more interested in the patching tool per se, not even in the original "no nag" patches. If more parties are interested, I will simply reduce my original patching tool to set of "no-nag" patch definitions and let everyone ship their own definitions.

Extra bonus for user at this point is that the patching tool installs/uninstalls cleanly with a .deb package and there is reproducible build of it in the GitHub actions, so that it can be trusted by users. If I were to update the make the tool truly universal, this would allow for easy reviews since the patching code would need little changes and only thing to review is the diff of old and new patchset.

I am happy to make the tool pick up patches from e.g. /usr/local/ as well as /usr/share/, so that patches could also be made into .deb packages of your own. I am aware current users of no-nag already use it fully automated with Ansible, directly downloading the .deb and checking its digest to match that of reproducible build. I can assist with the same for a "3rd party" patchset, but by all means, even if you just fork it as-is now, I have no issues at all.

Cheers!