Users upgrading from versions before auto-updates will now be prompted
to enable the new automatic update feature. The prompt defaults to 'Yes'
for convenience but allows users to opt-out if they prefer manual updates.
The prompt only appears when:
- Upgrading or reinstalling an existing installation
- The auto-update timer doesn't already exist
- Not running with --enable-auto-updates flag
- Not running in a container environment
- Add systemd timer for daily update checks (2-6 AM window)
- Create pulse-auto-update.sh script with safe rollback on failure
- Add --enable-auto-updates flag to install script
- Prompt users during fresh install to enable auto-updates
- Respect autoUpdateEnabled flag in system.json
- Only install stable releases, never RCs
- Full logging to systemd journal
- Tested and verified working in container
The install script now provides convenient management options:
- --reset: Stops Pulse, removes config/data, restarts with fresh config
- --uninstall: Completely removes Pulse from the system
Also simplified the post-install message to show these one-liner commands instead of listing manual steps.
The version comparison function was attempting numeric comparisons on version parts containing RC suffixes (e.g., "0-rc" from "4.8.0-rc.2"), causing an "unbound variable" error due to set -u.
Now properly strips and handles pre-release suffixes separately, allowing correct comparison of RC versions.
Addresses discussion #344 comment from RLSinRFV
Users now see clear instructions for:
- Resetting configuration to start fresh (keeping Pulse installed)
- Complete removal of Pulse (uninstall everything)
This helps users who need to troubleshoot or start over with a clean slate.
- Changed from showing just percentage to "X.X GB free of Y.Y GB (Z% used)"
- Much more useful for users to see actual available space
- Applies to both Quick and Advanced installation modes
addresses #352
quick mode now:
- shows available network bridges and prompts for selection
- shows available storage pools with usage info and prompts for selection
- properly handles cases where defaults (vmbr0, local-lvm) don't exist
- gives clear error messages when no bridges or storage pools are found
this ensures users always see what's available and can make informed choices
even in quick mode, preventing installation failures due to missing defaults
addresses #352
the installer now:
- detects the actual default network interface (not just vmbr*)
- uses the first available bridge if default isn't a bridge
- prompts user to select a bridge when vmbr0 doesn't exist
- shows helpful messages when no bridges are detected
this fixes issues on systems with non-standard network configurations
where vmbr0 doesn't exist or isn't the default gateway
Initialize RC_VERSION to empty string before assignment to prevent
'unbound variable' errors when running with set -u. This ensures
the RC update option is shown when running a stable version.
The version detection regex now captures the full version string including
pre-release suffixes like -rc.1, -beta.2, etc. This prevents the script
from offering to update to a version that's already installed.
- Fixed safe_read function to properly handle TTY availability
- Added proper error handling for compare_versions return codes
- Script no longer exits silently when selecting menu options
The update and reinstall cases in the menu were missing exit statements,
causing the script to continue running after completion and hit the fresh
install path. This made it appear as if nothing happened when selecting
menu options.
Added exit 0 after print_completion for both update and reinstall cases.
Removed debug output now that the issue is resolved.
- Simplified safe_read function to properly handle TTY input when script is piped
- Added error check if no option is selected
The menu now correctly reads user input when running:
curl -sSL .../install.sh | bash
The script now properly detects update scenarios by checking for:
- Existing binary at /opt/pulse/bin/pulse or /opt/pulse/pulse
- Existing config directory at /etc/pulse
- --version flag being specified
This prevents the annoying port prompt when running updates or installing specific versions.
The menu now only shows update options for versions different from
the currently installed version. This prevents confusing situations
where users can 'update' to the version they already have.
- Redirect apt-get update/install stderr to /dev/null to hide GPG warnings
- Suppress systemctl enable output (Created symlink message)
- Suppress systemctl daemon-reload output
- Makes the installation output cleaner and less scary for users
The remove option now:
- Removes symlink at /usr/local/bin/pulse
- Asks before removing config/data in /etc/pulse
- Asks before removing the pulse user account
- Cleans up log files
- Removes all possible service file variations
- Runs systemctl daemon-reload after service removal
The install script was exiting when --version flag was used due to set -e
and compare_versions returning 2 for downgrades. Now properly captures
the return value and also detects the correct service name.
- Says 'Updating to' when installing a newer version
- Says 'Downgrading to' when installing an older version
- Says 'Reinstalling' when installing the same version
- Says 'Installing' when current version is unknown
Added version comparison function to determine the right action word.
The install script was failing with 'unbound variable' error after completing an update because FRONTEND_PORT is only set during fresh installations. Now extracts port from service file or uses default.
The install script was using 'set -e' which caused it to exit when grep didn't find updateChannel in system.json. Added '|| true' to prevent early exit.
Also improved version detection with fallback when GitHub API is rate-limited.
addresses #350 - removes the pre-v4 installation check that was causing false positives when .env files were accidentally placed in /opt/pulse. V3 is no longer supported.
- Detect non-TTY environments when running with --in-container
- Automatically select appropriate update based on configured channel
- Prevents hanging on menu prompt in ProxmoxVE deployments
- Users now see both stable and RC versions when updating
- Menu dynamically adjusts based on available versions
- Users can choose which version to install regardless of their update channel setting
- Addresses confusion about automatic RC updates
Previous fix wasn't working properly - the menu showed but couldn't read input.
Now properly detects if we can write to /dev/tty to determine if interaction
is possible, even when stdin is piped from curl.
The script was detecting piped input and automatically going into non-interactive mode,
preventing users from choosing between Quick and Advanced installation modes.
Now checks if /dev/tty is available even when stdin is piped, allowing interaction
through the terminal for curl-based installations while still supporting truly
non-interactive environments (like automation scripts without any TTY).
- Add safe_read function to handle both TTY and non-TTY input
- Fix --in-container mode to skip prompts when no TTY available
- Allows installation via piped curl command on Proxmox hosts
- Install script now prompts for custom port (default: 7655)
- Can skip prompt with FRONTEND_PORT environment variable
- Fixed incorrect port configuration instructions in UI
- Updated documentation to reflect new installation options
- Fixed FAQ.md references to pulse-backend (should be pulse)
addresses #110
- Added comprehensive PORT_CONFIGURATION.md guide
- Updated CONFIGURATION.md to clarify .env is for auth only
- Install script no longer loads .env for environment variables
- Documented proper port configuration methods (systemd, system.json)
- Added port config guide to README documentation section
addresses #110 - helps users understand where to configure ports
- Auto-detects Proxmox VE hosts and creates LXC containers
- Quick mode with sensible defaults (1GB RAM, 4GB disk)
- Advanced mode for full customization
- Automatic cleanup on failure
- Simple 'update' command in containers
- Improved error handling and network detection
- Professional, clean output without verbose noise
- Docker detection to prevent container-in-container
- Removed all references to community scripts
This is now the primary recommended installation method.
Users now have two options when creating the LXC container:
1. Quick mode - Uses optimized defaults for production (2GB RAM, 16GB disk, etc)
2. Advanced mode - Full control over all settings like the community script
Advanced mode allows customization of:
- Memory, CPU cores, CPU limits, swap
- Static IP vs DHCP
- DNS servers
- Firewall settings
- Privileged vs unprivileged
- Auto-start on boot
- Startup order
This gives users the best of both worlds - quick setup with good defaults
or full control when needed.
- Increased default RAM to 2GB (handles 50+ nodes)
- Increased default disk to 16GB (logs and metrics storage)
- Added CPU limit to prevent resource hogging
- Added 512MB swap for memory flexibility
- Enabled firewall on network interface
- Set startup order to 99 (after critical services)
- Configure UTC timezone for consistent logging
- Optimize sysctl settings for monitoring workload
- Added clear documentation of optimizations applied
The installer now detects when running on a Proxmox VE host and automatically:
- Creates a new LXC container with user-specified settings
- Installs Pulse inside the container
- Prevents unsafe installation directly on PVE hosts
This eliminates dependency on community scripts while ensuring proper isolation.
The installer was installing Go and Node.js even for binary installations.
Now it only installs curl and wget which are needed to download the release.
Move service stop to happen before attempting to copy the binary file.
This prevents the error when the binary is still in use by the running service.
Added 2-second delay to ensure process fully releases the file.
- ProxmoxVE community script uses pulse-backend.service
- Our install script now detects and preserves existing service name
- Removed pulse-backend.service from pre-v4 detection (it's used by v4 too)
- Install script stops the correct service during upgrades
- New installs use 'pulse', existing use whatever they have
This ensures compatibility with all deployment methods without breaking changes.
The service name pulse-backend.service is used by both v4 and pre-v4 installations,
so it's not a reliable indicator. Only check for Node.js artifacts (package.json,
node_modules, etc) which are exclusive to pre-v4 versions.