Upgrade Forwarder

Linux upgrades are an in-place package install, and they are yours to drive. Unlike Windows, there is no upgrade button in the web app and no API for it: the package manager does the work, and whatever already orchestrates your patching is the right tool to reach for.

/etc/stairwell/config.json survives the upgrade, so the host keeps its environment and identity. You do not re-register and you do not re-supply a token.

The examples below use 2.5.1, the current release. Check Linux Forwarder Downloads before you copy them; a version number in a doc is stale the moment we ship.

One host

RHEL, Rocky, Alma (7, 8, 9, 10) -- match the elN in the filename to your major release, not to your kernel:

curl -LO https://downloads.stairwell.com/linux/2.5.1/stairwell-2.5.1-1.el8.amd64.rpm
sudo rpm -U stairwell-2.5.1-1.el8.amd64.rpm

Debian and Ubuntu (20.04, 22.04, 24.04):

curl -LO https://downloads.stairwell.com/linux/2.5.1/stairwell-2.5.1-1.amd64.deb
sudo apt install ./stairwell-2.5.1-1.amd64.deb

RHEL 6, which is end of life and receives no security updates, still has a package:

curl -LO https://downloads.stairwell.com/linux/2.5.1/stairwell-2.5.1-1.el6.amd64.rpm
sudo rpm -U stairwell-2.5.1-1.el6.amd64.rpm

Check it took

The service restarts on its own after the package installs. Confirm it did:

sudo systemctl status stairwell.service
# or, on RHEL 6
sudo service stairwell status

journalctl -u stairwell.service -f
# or, on RHEL 6
sudo tail -f /var/log/stairwell/fileshipper.log

A running service is necessary but not sufficient. The check that matters is that the asset keeps checking in and keeps sending sightings; a forwarder that restarted into a broken configuration looks healthy from systemctl alone. See Linux Troubleshooting if the unit is up and nothing arrives.

A fleet, with Ansible

Idempotent, parallel, and version-pinned, which is what you want when the alternative is 3,000 SSH sessions.

---
- name: Upgrade Stairwell Forwarder
  hosts: linux_hosts
  become: yes

  vars:
    stairwell_version: "2.5.1"

  tasks:
    - name: Download latest package for RHEL
      get_url:
        url: "https://downloads.stairwell.com/linux/{{ stairwell_version }}/stairwell-{{ stairwell_version }}-1.el8.amd64.rpm"
        dest: "/tmp/stairwell.rpm"
      when: ansible_os_family == "RedHat"

    - name: Upgrade package (RHEL)
      yum:
        name: "/tmp/stairwell.rpm"
        state: latest
      when: ansible_os_family == "RedHat"

    - name: Download latest package for Debian/Ubuntu
      get_url:
        url: "https://downloads.stairwell.com/linux/{{ stairwell_version }}/stairwell-{{ stairwell_version }}-1.amd64.deb"
        dest: "/tmp/stairwell.deb"
      when: ansible_os_family == "Debian"

    - name: Upgrade package (Debian/Ubuntu)
      apt:
        deb: "/tmp/stairwell.deb"
        state: latest
      when: ansible_os_family == "Debian"

    - name: Restart Stairwell service
      systemd:
        name: stairwell.service
        state: restarted

The playbook as written pulls the el8 RPM for every RedHat-family host. If your estate spans RHEL 7 through 10, derive the elN from ansible_distribution_major_version rather than hardcoding it, or you will install the wrong package on the machines you were least sure about.

A fleet, through your own mirror

If you already run an internal YUM or APT mirror, this is the least-effort option, because Stairwell stops being a special case and becomes another package in the monthly patch cycle.

1. Mirror the .rpm or .deb files into your repository.
2. Add the repo configuration -- /etc/yum.repos.d/stairwell.repo on RHEL, /etc/apt/sources.list.d/stairwell.list on Debian.
3. Upgrade on your normal schedule:

# RHEL / Rocky / Alma
sudo yum update stairwell

# Debian / Ubuntu
sudo apt upgrade stairwell

A fleet, in the cloud

For autoscaling groups and instances that refresh often, drive it from your provisioning path -- cloud-init, Terraform, or a run-command API:

aws ssm send-command \
  --targets "Key=tag:Role,Values=stairwell-forwarder" \
  --document-name "AWS-RunShellScript" \
  --comment "Upgrade Stairwell Forwarder to v2.5.1" \
  --parameters 'commands=[
    "curl -LO https://downloads.stairwell.com/linux/2.5.1/stairwell-2.5.1-1.amd64.deb",
    "sudo apt install -y ./stairwell-2.5.1-1.amd64.deb",
    "sudo systemctl restart stairwell.service"
  ]'

Where instances are short-lived, baking the current package into the image is usually better than upgrading in place. The instance then arrives current and never needs a second visit.

Before you upgrade everything

Confirm the whole fleet moved

ansible all -m shell -a "stairwell --version"

Or read it off the platform: upgraded assets report their version on the asset page, which is the same view your auditors will ask for later. Anything still on the old version is a host your automation could not reach, and that is worth knowing for reasons beyond this upgrade.

What should I read next?

• Linux Forwarder Downloads, for the current release and its prerequisites.
• Linux Troubleshooting, if a host goes quiet afterwards.
• Uninstall the Linux Forwarder, for the rare case an upgrade needs to become a reinstall.