Universal agent installer via curl bash

[logicminds]

📦 OpenVox Agent Universal Installer – Proposal Summary

🎯 Purpose

The goal of this project is to provide a unified, cross-platform installation experience for the openvox-agent across major operating systems (Linux, macOS, Windows). It allows users to install and configure the agent with a single command tailored to their environment, reducing friction and ensuring consistency in deployments.

---

🧩 Design Overview

The installation system uses a universal wrapper script (install.sh or equivalent) that detects the platform and delegates to the appropriate OS-specific install script. Each script:

• Installs the agent using native package managers or installers (apt, dnf, msiexec, installer)
• Imports GPG keys or handles certificates
• Configures repository metadata as needed
• Offers to symlink common tools (puppet, facter, pxp-agent) into $PATH

🧠 Core Design Principles

• 🛠️ Platform-native installation (no Docker dependencies)
• 💡 Auto-detection of OS and architecture
• ✅ User-friendly prompts with safe defaults
• 🔒 Use of official signing keys for trust
• 🧪 Testable via GitHub Actions and local Bats framework

---

🖥️ Supported Platforms

OS Family	Versions Supported	Installer Format
Debian	10, 11, 12	.deb + APT repo
Ubuntu	18.04, 20.04, 22.04, 24.04	.deb + APT repo
RHEL-based	RHEL 7–10, Rocky, Alma, Amazon Linux, SLES	.rpm + YUM/DNF repo
Fedora	36, 40, 41, 42	.rpm + DNF repo
macOS	Ventura+ on Apple Silicon	.dmg with .pkg
Windows	Windows 10, 11, Server (x64)	.msi installer

---

📦 Deliverables

• install.sh – universal wrapper script (except windows)
• install-openvox-deb.sh – for Debian/Ubuntu
• install-openvox-rpm.sh – for RedHat-based distros
• install-openvox-mac.sh – for macOS
• install-openvox-windows.ps1 – for Windows
• GitHub Actions CI with container matrix testing (Debian, Ubuntu, RHEL variants)
• Bats test framework with mocked local repo/host environment

---

🧪 Testing & Validation

• GitHub Actions matrix tests for all Linux platforms using Docker containers
• macOS and Windows tested via native runners in CI
• Local testing supported via:
  • run-local-test.sh (Linux Bats)
  • HTTPS mocking using python3 -m http.server
  • Certificate validation override (or trust install)

---

🧰 How It's Used

✅ One-Liner (Universal Install)

# linux, Mac
curl -fsSL https://raw.githubusercontent.com/voxpupuli/openvox-install/main/install.sh | bash -s -- 8 openvox-agent

or when published officially

curl -fsSL https://voxpupuli.com/install.sh | bash -s -- 8 openvox-agent

🪟 Windows

powershell -NoProfile -ExecutionPolicy Bypass -Command "iwr -useb https://raw.githubusercontent.com/voxpupuli/openvox-install/main/install-openvox-windows.ps1 | iex"

or

powershell -NoProfile -ExecutionPolicy Bypass -Command "iwr -useb https://voxpupuli.com/install-openvox-windows.ps1 | iex"

---

🔧 Maintenance Plan

• Scripts hosted in voxpupuli/openvox-install
• Raw GitHub URLs used for live delivery
• CI runs on every push and PR to validate OS compatibility
• Community-supported with release tagging and version pinning

---

🧭 Intended Use Cases

• Easy onboarding for new agents
• Testing internal agent behavior across supported systems

Working POC (code only)

I have created a working POC but the scripts will need to be hosted somewhere either via github or vox site.

[jstraw]

I am personally against curl bash entirely it introduces a major security flaw into a flow around an application designed for security. https://lukespademan.com/blog/the-dangers-of-curlbash/ (among other posts about it)

While I know hosting it on github pages or osuosl s3 buckets limit the ability to execute on the flaw, it's still a bad practice that a good systems person is going to look at and think is indicative of openvox's security design and planning.

[logicminds]

My intention was to follow the steps of docker and provide a optional convenient method for those wanting to try openvox. Folks in secure environments would never allow installation from the internet and host their own repos on artifactory or similar. This is for those folks with homelabs, docker, or other that want something quick. They can choose to inspect the scripts if they want.

If security is a concern we just label it as such and let people decide for themselves by provide the manual and other methods of installation.

These scripts are similar to the existing pe_repo scripts though. I don't know if pe_repo was able to be forked. But I could see these scripts become part of a openvox_repo module or something where the installation server url is on-prem. I don't have any stats but I always felt the internal curl-bash installation method was the easiest and most used when dealing with PE infra clients.

In summary there should be several ways to install the agent, each one with a different use case.

[jstraw]

I am ok with it if there's a big red warning box saying the security issues and not for production.