mirceaulinic/salt-sproxy

This system is a standalone proxy execution framework for network automation, enabling remote device management without requiring a persistent Salt Master or Proxy Minion. It provides a CLI tool and API client to execute commands against network devices via SSH or various roster backends like NetBox and Ansible. The system supports multiple targeting methods and integrates with existing Salt infrastructure through custom execution modules and runners.

Users can now use the Ansible Roster to manage network devices via Salt-sproxy. This change introduces a new example directory containing a sample Ansible inventory (roster) and corresponding Salt pillar files for Junos and EOS devices. The example demonstrates how to configure the Salt master to load the roster file and use the 'ansible' proxy roster type, enabling integration with Ansible's inventory system for device targeting and pillar data loading.

examples/ansible · high confidence

A new execution module, \salt\_sproxy/\_modules/netbox.py\, is introduced to query NetBox. The module requires the \pynetbox\ library and provides functions to filter and retrieve data from NetBox endpoints, supporting authentication via API tokens and private keys.

_salt\_sproxy/\modules · high confidence

Added a new example demonstrating how to use the NetBox roster integration with salt-sproxy. The change includes a README with setup instructions, a master configuration file, and pillar files for Junos and EOS devices. The example also provides a Docker-based quick start option that defaults to the public demo instance at netbox.live.

examples/netbox · high confidence

Added a new example in the \examples/salt\_api\ directory demonstrating how to configure the Salt Master and API for proxy execution. This includes a \master\ configuration file enabling the CherryPy REST interface on port 8080 with disabled SSL, alongside pillar files (\top.sls\, \dummy.sls\, \junos.sls\) that define proxy types (dummy and NAPALM) for different targets. A \README.rst\ provides step-by-step instructions for setting up the environment, configuring external authentication, and executing commands via the REST API.

_examples/salt\api · high confidence

Added the examples/napalm directory containing a README and pillar configuration files (junos.sls, top.sls) that demonstrate how to use salt-sproxy with network devices via NAPALM. The example includes instructions for a standard setup and an alternative Docker-based setup for easier configuration management.

examples/napalm · high confidence

The examples directory now includes new configuration files and documentation for various use cases. Users can now find ready-to-use examples for Linux proxy setups using Netmiko, NetBox roster integration, Salt API interactions, and Pillar roster configurations. These examples provide practical templates for common deployment scenarios, helping users understand how to configure different roster modules and proxy types.

examples · medium confidence

A new example for using the salt-sapi functionality is now available, demonstrating how to execute commands against both dummy and real network devices via the Salt API. The example includes configuration files (master, pillar, and top.sls) and a README with step-by-step instructions for setting up the environment, starting the Salt Master and API, and making HTTP requests to run proxy commands.

_examples/salt\sapi · high confidence

The repository was initialized with essential configuration and documentation files, including .editorconfig, .pylintrc, .readthedocs.yml, and a Makefile. A comprehensive README was added to explain the tool's purpose and usage, alongside a CONTRIBUTING guide and CODE\_OF\_CONDUCT. The project structure was further defined with a setup.py for package distribution, a Dockerfile for containerization, and a sample roster file for device targeting.

(repo-wide) · high confidence

Users can now manage remote machines over SSH using a new SSH Proxy Minion and its associated executor. The proxy module handles SSH connections, supporting configuration options such as host, port, user, password, private key paths, timeouts, sudo, TTY, remote port forwarding, and host key verification settings (including \ignore\_host\_keys\ and \no\_host\_keys\). The executor allows Salt functions to be invoked on the remote host via SSH, enabling remote command execution and state management through the proxy interface.

_salt\_sproxy/\proxy · high confidence

Added a new Salt Runner (salt\_sproxy/\_runners/proxy.py) that allows executing arbitrary commands on network devices not managed via a Proxy or regular Minion. This runner connects to collect Grains, compile the Pillar, and execute commands, supporting features like batch execution, progress bars, and returner integration.

_salt\_sproxy/\runners · high confidence

Adds the \salt-sproxy\ CLI tool and \salt-sapi\ API client, enabling users to execute Salt functions on network devices via a standalone proxy without requiring a running Master or Proxy Minion. The \salt-sapi\ client exposes \sproxy\ and \sproxy\_async\ methods on the NetapiClient, while the CLI supports options for roster files, static execution, and asynchronous execution.

_salt\sproxy · high confidence

The salt-sproxy tool now supports multiple roster backends for discovering and targeting devices. Users can now use an Ansible inventory file, a NetBox instance, an arbitrary SLS file, or Salt Pillar data as the source of truth for device lists. Each roster module integrates with the existing targeting engine, allowing users to select their preferred infrastructure source via the \--roster\ option.

_salt\_sproxy/\roster · high confidence

Added a new integration test script (tests/run/cli.sh) and supporting configuration files (tests/run/master, tests/run/roster) that validate Salt SProxy command-line operations. The tests verify various targeting methods (grain, roster, cache), batch execution with percentage-based sizing, invasive targeting, and execution through the Salt API (salt-sapi). The test environment also configures the master with specific roster and proxy settings, including disabling the ESXI grain module to address a known issue.

tests · high confidence

The project's dependency files have been updated to newer versions of several tools. In requirements-dev.txt, tox is upgraded to 4.6.4, black to 23.10.1, pylint to 2.9.6, SaltPylint to 2023.8.3, and CherryPy to 18.9.0. Additionally, docs/requirements.txt now includes sphinx, sphinx-rtd-theme, and sphinxcontrib-napoleon for documentation builds, while requirements.txt explicitly lists six, salt, and progressbar2 as core dependencies.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 54 → 56 (+1.8)
• Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 65 → 79 (+14.6)
• Architecture 100 → 100 (+0.0)
• Maturity 43 → 43 (+0.0)
• Readiness 58 → 53 (-4.6)
• Security 68 → 79 (+11.8)

• Dependency hygiene not measured — dependency manifest found but not parsed for hygiene
• Duplicated block (11 lines × 2) (salt_sproxy/_roster/init.py)
• Duplicated block (11 lines × 2) (salt_sproxy/_roster/init.py)
• Duplicated block (12 lines × 2) (salt_sproxy/_roster/init.py)
• Duplicated block (16 lines × 3) (salt_sproxy/cli.py)
• Duplicated block (6 lines × 2) (salt_sproxy/_modules/netbox.py)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• Medium CVE: [GHSA redacted] (requirements-dev.txt)
• Medium IaC: CKV_DOCKER_3 (Dockerfile)
• Medium IaC: CKV_DOCKER_6 (Dockerfile)
• No exposed public API
• The 'Usage Examples' section lists links to 101, NAPALM, Ansible, NetBox, Salt API, salt-sapi, Pillar Roster, and File Roster modules but does not mention the main installation or configuration path. (examples/README.rst)
• …and 1 more

• Dependency hygiene PARTLY measured — Python dependencies read, no exact pin to grade for currency
• Documentation: no installation or build instructions (docs/install.rst)
• Documentation: no project overview (docs/index.rst)
• Duplicated block (10 lines × 4) (salt_sproxy/_roster/init.py)
• Duplicated block (13 lines × 2) (salt_sproxy/_roster/init.py)
• Duplicated block (13 lines × 2) (salt_sproxy/_roster/init.py)
• Duplicated block (14 lines × 2) (salt_sproxy/_roster/init.py)
• Duplicated block (18–23 lines × 3) (salt_sproxy/cli.py)
• Duplicated block (6 lines × 2) (salt_sproxy/_modules/netbox.py)
• Duplicated block (7 lines × 2) (salt_sproxy/_modules/netbox.py)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• …and 16 more

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

mirceaulinic/salt-sproxy was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.