Uninstall fleetd remotely

[noahtalerman]

For the following dogfood issue: fleetdm/confidential#9685

• Update guide to cater towards IT admins that only have remote access (not physical) to the computer
• Add a new uninstall fleetd script for macOS to dogfood. Link to this script from the guide
• Move uninstall fleetd (aka cleanup) scripts for Windows and Linux from orbit/ to it-and-security (dogfood) because we're not using these anywhere else in the code

[noahtalerman]

@allenhouchins do you know what happens if I add a comment like this before the shebang? Will this "just work"?

[noahtalerman]

Hmm, it looks like the linux-uninstall-fleetd.sh script won't uninstall all of fleetd (Fleet Desktop, Orbit, and osquery). It looks like it just stops Orbit.

@allenhouchins when you get the chance, can you please run the script on an enrolled Linux host to help me check?

#!/bin/bash

# Please don't delete. This script is referenced in the guide here: https://fleetdm.com/guides/how-to-uninstall-fleetd

sudo systemctl stop orbit.service
sudo systemctl disable orbit.service
sudo rm -rf /var/lib/orbit /opt/orbit /var/log/orbit /usr/local/bin/orbit /etc/default/orbit /usr/lib/systemd/system/orbit.service /opt/orbit

[lucasmrod]

Hmm, it looks like the linux-uninstall-fleetd.sh script won't uninstall all of fleetd (Fleet Desktop, Orbit, and osquery). It looks like it just stops Orbit.

@allenhouchins when you get the chance, can you please run the script on an enrolled Linux host to help me check?

#!/bin/bash

# Please don't delete. This script is referenced in the guide here: https://fleetdm.com/guides/how-to-uninstall-fleetd

sudo systemctl stop orbit.service
sudo systemctl disable orbit.service
sudo rm -rf /var/lib/orbit /opt/orbit /var/log/orbit /usr/local/bin/orbit /etc/default/orbit /usr/lib/systemd/system/orbit.service /opt/orbit

AFAICS, similarly to the macOS script, the script has to run asynchronously otherwise the script itself may be killed at the first sudo systemctl stop orbit.service.

[noahtalerman]

AFAICS, similarly to the macOS script, the script has to run asynchronously otherwise the script itself may be killed at the first sudo systemctl stop orbit.service.

@lucasmrod dang. Does this mean we can't run these macOS & Linux scripts from Fleet to remove fleetd from hosts?

[lucasmrod]

AFAICS, similarly to the macOS script, the script has to run asynchronously otherwise the script itself may be killed at the first sudo systemctl stop orbit.service.

@lucasmrod dang. Does this mean we can't run these macOS & Linux scripts from Fleet to remove fleetd from hosts?

Scripts it-and-security/lib/macos/scripts/macos-uninstall-fleetd.sh and it-and-security/lib/windows/scripts/windows-uninstall-fleetd.ps1 seem that already support the "asynchronous" mode to be able to run the script from Fleet.
The one for Linux needs to be updated to do a similar approach.

PS: Also there's some duplication of scripts in orbit/tools/cleanup, scripts/mdm/ and it-and-security/lib/{windows|linux}/scripts. If possible, we should have one version that we can continue to iterate and improve.

PSS: For Windows it seems we have two scripts, one for removing fleetd (scripts/mdm/windows/windows-remove-fleetd.ps1) and one for unenrolling the device from the MDM server (scripts/mdm/windows/windows-unenroll-mdm.ps1), maybe it should all be put in the remove one?.

[noahtalerman]

The one for Linux needs to be updated to do a similar approach.

Ah, got it. Marking this PR as draft until we figure this out.

PS: Also there's some duplication of scripts in orbit/tools/cleanup, scripts/mdm/ and it-and-security/lib/{windows|linux}/scripts.

I saw that! But chose to wait to deduplicate to change less now. But now I'm thinking you, Lucas, and I can hop on a call to figure that out. I scheduled some time for us next week.

PSS: For Windows it seems we have two scripts, one for removing fleetd (scripts/mdm/windows/windows-remove-fleetd.ps1) and one for unenrolling the device from the MDM server (scripts/mdm/windows/windows-unenroll-mdm.ps1), maybe it should all be put in the remove one?.

I think we can come back to this. That said, I also think we can move these to it-and-security/ so they get touched more during dogfooding and, thus, we can improve them faster.

[allenhouchins]

@noahtalerman there are quite a few changes I'll want to make before putting these in our it-and-security folder. For example, the macOS one is referencing GITHUB_ACTIONS, the script names don't follow our naming convention, they have passwords as strings instead of secrets, etc. Can this hang out as a draft for a few days until I can address those changes?