Vector Server Pkg Laravel Package

Product Decisions This Supports

• Build vs. buy on privileged plumbing. The package owns install, uninstall, service control and certificate sync for Vector Hub, so we don't staff a bespoke installer. v2.0.2 moves that plumbing behind a root-owned VectorHubCtl wrapper — the vendor is absorbing the hardening burden instead of pushing it onto every deployment. That strengthens the case for staying on the package rather than forking.
• Security and compliance roadmap. Privilege separation (root-owned wrapper + sudoers rule, vector-hub group-scoped cert reads) plus stricter install-time validation (rejecting insecure_download, tighter URL/host/path checks) are directly quotable in security questionnaires, pen-test remediation notes and SOC2/ISO evidence. Treat as a roadmap checkbox, not a feature.
• Release and upgrade policy. v2.0.2 is explicitly "action required" — a manual root step after upgrading. That's a support-cost decision: we need a published runbook, a pre-flight check, and a call on whether auto-updates must be gated for on-prem customers.
• Public contract stability. InstallVectorHubJob now requires an explicit install or uninstall action. That is a breaking change for any internal code or customer automation dispatching it, and it drives a decision on whether this job should be part of our supported surface at all.
• Deployment topology and support matrix. Requiring root at install time narrows the addressable environments. Informs what we claim in docs, marketplace listings and packaging.
• Supply-chain posture for procurement. Rejecting insecure downloads is a concrete, checkable statement in enterprise procurement review — useful for unblocking deals in regulated accounts.

When to Consider This Package

Adopt when:

• You ship Vector Hub as part of an rConfig deployment and want vendor-maintained install/service/cert lifecycle instead of in-house scripts.
• You can grant root at install time and accept a privileged, root-owned wrapper and sudoers rule on the host — normal for on-prem network tooling.
• You need auditable, least-privilege operations for a security-sensitive integration; the wrapper model and group-scoped cert reads are the selling point, not an afterthought.
• Your customers are on-prem/enterprise where "run this once as root" is an acceptable runbook step.

Look elsewhere / don't adopt when:

• The target is unprivileged shared hosting, rootless containers or PaaS where you cannot install a sudoers rule — v2.0.2 makes root mandatory.
• You need drop-in upgrades with no manual operator step; the post-upgrade root command breaks unattended update flows.
• You have custom code dispatching InstallVectorHubJob and no capacity to migrate to the explicit action parameter now.
• The integration's value doesn't justify host-level privilege — prefer a narrower, user-space API-only integration.

How to Pitch It (Stakeholders)

Executives: v2.0.2 is a security-hardening release, not a feature release. It removes direct bash/systemctl execution from the web tier and replaces it with a narrowly-scoped, root-owned wrapper, and it tightens install-time validation so insecure downloads are rejected. Net effect: smaller blast radius if the web application is compromised, and cleaner answers in security reviews and procurement. The cost is one manual root step per upgraded host — we should fold that into the upgrade runbook and support docs before we announce the release, and be clear that unattended upgrades now need a privileged hook.

Engineering: two things to action. (1) Run rconfig:vector-hub-install-helper as root after upgrading — it installs the VectorHubCtl wrapper and sudoers rule and adds the web user to the vector-hub group; without it, install, uninstall and service actions fail. (2) InstallVectorHubJob now takes an explicit install or uninstall action — audit every dispatcher, including customer scripts. SyncHubCertsJob now runs as the web user and reads certs via group membership, so group setup is a hard dependency, not a nicety. Finally, review existing install configurations against the stricter URL/host/path validation and the insecure_download rejection before rollout, since previously-accepted configs may now be refused.