Symantec / Blue Coat ProxySG Integration

Versus manages ProxySG (SGOS) appliances the way an operator does — over the SGOS CLI via SSH — because SGOS has no automation API for system operations. Onboard a proxy with its SSH credential, and Versus reads its version, installed systems and failover state, backs up its configuration, lets Diagnostics AutoPilot probe it, and upgrades it with two built-in workflows.

Onboarding

1. Inventory → Devices → Add Device, vendor Symantec / Blue Coat ProxySG (group Web Proxy — Secure Web Gateway). The device type is Web Proxy / Secure Web Gateway.
2. Credential: an SSH login with privileged (enable) access. If the enable password differs from the login password, add it to the device's extra config as enable_password.
3. Site: proxies on a customer LAN are reached through the site's Versus collector, exactly like every other on-prem vendor — no inbound access to the proxy is needed.
4. Test connection runs show version and show failover and returns the SGOS version, release ID, model, serial and failover role.

What Versus reads: show version, show installed-systems, show failover, show status, show health-checks, show configuration expanded.

Inventory, backups and diagnostics

• Version and failover role (Master / Standby) appear on the device card; a failover group shows its virtual IP.
• Backups — on demand from the device page or on the scheduled backup run — capture show configuration expanded as a text backup with the SGOS version in the header.
• Diagnostics AutoPilot gets a native bluecoat probe family: health, failover (ha), status (stats), installed systems (objects) and health checks (events), so triage of an incident touching a proxy reads the box directly. Python Script steps reach a proxy with versus.run_ssh(device_id, 'show status') or versus.probe(device_id, 'health').

How an SGOS upgrade works — and how Versus drives it

A ProxySG keeps up to five installed systems. load upgrade pulls the new image over HTTP(S) from the appliance's configured upgrade-path URL, installs it into an empty slot (or replaces the oldest unlocked, non-running system) and makes it the default; restart upgrade boots into it. Versus therefore serves the image to the proxy:

• Upload the .bcsi image to Firmware Images (filenames like sgos_7.3.14.1_267215.bcsi are recognised; the version and release ID are parsed from the name).
• The Download & Install step points upgrade-path at a signed, time-limited Versus URL for that image (/api/firmware-images/<id>/download/?token=…, valid six hours, bound to that image). The proxy must be able to reach Versus over HTTPS — set VERSUS_PUBLIC_URL on the Versus service (it falls back to the collector update origin) or give the step an explicit image_url on any web server the proxy can reach.

Built-in workflows (Workflows › category Web Proxy / Secure Web Gateway)

Blue Coat ProxySG Rolling Upgrade — for independent proxies behind a load balancer / WCCP / PBR, or a single standalone appliance:

1. Check ProxySG State — version, free or replaceable slots, failover state on every member; validates the selected image; marks members already on the target version so later steps skip them.
2. Backup Configuration on every member.
3. Approval.
4. Then, one proxy at a time: confirm a system slot → load upgrade → restart upgrade (Versus waits for the box to go down and come back, through the collector when there is one) → verify the running version, failover state and health checks. The next member starts only after the previous one is verified.

Blue Coat ProxySG Failover Group Upgrade — for a VRRP-style failover group with one Master:

1. Check state, confirm exactly one Master, back up every member, approval.
2. Pass 1 — Standby member(s): slot → install → restart → verify, then confirm the Standby rejoined the group.
3. Approval before the Master — its restart fails the virtual IP over to the already-upgraded Standby.
4. Pass 2 — Master: the same four steps, then a final group check.

Roles are read live from show failover at each step, so the run targets whichever member is Standby now. A proxy that already runs the image's version is never upgraded twice: the state check marks it, every later step skips it, and a re-run after a failure finishes only what is left.

Run inputs

Step options worth knowing

• Confirm System Slot — delete_oldest deletes the oldest unlocked, non-running, non-default system first; by default the step only confirms SGOS has somewhere to install.
• Download & Install — image_url (with {filename}), versus_url, and timeout_seconds (default 30 minutes for the download plus install).
• Restart — down_timeout / up_timeout (defaults 3 and 15 minutes).
• Check ProxySG State — allow_reinstall forces a reinstall of a member already on the target version.

Limits

• Everything runs over the CLI; the SSH credential must reach enable.
• The proxy needs HTTPS reachability to Versus (or to your image_url host) to pull the image — there is no push install in SGOS.
• Failover groups are upgraded Standby first; the Master's restart is a real failover, so run it in a change window.