# camp_sysinfo client

Audit scripts for servers and workstations, sending the results as a report (YAML for Unix, JSON for Windows) for additional processing by CAMP. This repository holds two clients that share one report contract.

| Directory | Contents |
|---|---|
| `unix/` | The Unix client (Debian/Devuan, FreeBSD, OPNsense), Perl; installer, sensors, transports. See `unix/README.md`. |
| `windows/` | The Windows client (PowerShell 5.1), installed from `sysinfo-client-windows.zip`, with a Subversion checkout of `windows/` as the backup route. See `windows/README.md`. |
| `Documentation/` | `Spec.md`, the specification of both clients (§7 is Windows). |
| `tools/` | `make_release` (tarball and zip) and `compare_reports`; see `tools/README.md`. |
| `t/` | The tests: `t/*.t` for Unix (`prove t/` from this directory), `t/windows/` for Windows. |
| `server/`, `reference/`, `WorkingNotes/` | Server-side upload script, the v3.7.1 reference copy, and working notes. |

A host checks out or downloads only the directory for its own platform: a Unix host checks out `^/testing/unix` or `^/stable/unix` (or a tag's `unix/`) into `/opt/camp/sysinfo_client`, or unpacks the tarball, which is built from `unix/`. Everything else stays at the repository root and is never installed on a host.

## Release channels (tarball and zip)

Hosts that install from a downloaded file instead of Subversion follow one of two channels. The examples use `example.org`; substitute your own release server.

| Channel | Location | Used by |
| --- | --- | --- |
| stable | `https://example.org/sysinfo_client/` | every production host |
| testing | `https://example.org/sysinfo_client/testing/` | the permanent beta hosts only |

Each location holds the same file names: `sysinfo-client.tgz` and `sysinfo-client.tgz.sha256` (Unix), `sysinfo-client-windows.zip` and `sysinfo-client-windows.zip.sha256` (Windows), and the seed file. Build the files with `tools/make_release testing` for the testing location and `tools/make_release stable` for the stable one (see `tools/README.md`), then upload each set to its own location. The client has no built-in release URLs. A Unix host gets `update.url` and `update.sha256_url` from the seed it was installed with (or by editing its config), so publish one seed for each channel, with the matching URLs, and install beta hosts with `setup --seed <testing seed>`. The `--url` and `--sha256-url` options of `sysinfo_update` override the config. Windows has no automatic update, so a Windows beta host simply downloads from the testing location when it is upgraded by hand.

## Branches and releases

Development happens on `^/trunk`. A release is a tag (`^/tags/vX.Y.Z`), which never changes and is what the tarball and the Windows zip are built from. Promotion goes trunk, then tag, then `^/testing`, then `^/stable`: each of `testing` and `stable` is removed and re-created as a copy (`svn rm`, then `svn cp`), the first from the tag and the second from `^/testing` once testing is complete. Permanent beta machines follow `^/testing/unix` and all other svn-based Unix machines `^/stable/unix`. The `unix/` layout reaches `^/testing` first and, once testing is correct, `^/stable`. Each host that follows `^/stable` is then switched by hand, as a planned project, with `svn switch --ignore-ancestry ^/stable/unix`.