Rancher Desktop needs an uninstallation process

[adamkpickering]

Rancher Desktop Version

0.7.0-beta

Rancher Desktop K8s Version

N/A

What operating system are you using?

Other Linux

Operating System / Build Version

Pop OS 20.04

What CPU architecture are you using?

x64

Windows User Only

No response

Actual Behavior

The symlinks in ~/.local/bin for things like kubectl and helm are left behind after Rancher Desktop is uninstalled, pointing to nonexistent files in /opt. Seen on Pop OS but this is probably is an issue on more than just Linux.

Steps to Reproduce

1. Install Rancher Desktop as .deb
2. Run Rancher Desktop
3. Verify that kubectl works, and points to the file it is supposed to in /opt/rancher-desktop
4. Shut down Rancher Desktop
5. Uninstall Rancher Desktop
6. Run ls -l ~/.local/bin/kubectl, notice how it is a broken symlink

Result

Symlinks are broken and left behind upon uninstall.

Expected Behavior

Symlinks should be removed so as not to clutter the system. There are a few ways to do this but we should discuss this issue in order to figure out what the best way is.

Additional Information

No response

[adamkpickering]

This discussion was created by converting issue #1066 into a discussion. The above text is the body of that issue.

After some discussion with the team, it was determined that there are more things to think about than dangling symlinks when uninstalling Rancher Desktop. Jan brought up the fact that the data volume, which can contain a great deal of data, is also left behind when RD is uninstalled.

The ideal way to address this issue would be to create any resources RD needs at install time, and to remove any resources pertaining to it at uninstall time. The mechanism I have in mind for this is install/uninstall scripts as are present in .deb/.rpm packages. However, this is not an option because:

• RD works on multiple platforms that all have different ways of installing/uninstalling.
• Some packaging formats (AppImage for example) don't have any install/uninstall process.
• This would require root access, which we don't necessarily have. @mook-as would you mind clarifying this? In retrospect I'm not sure I fully understood your point.

There are two other possibilities that were brought up:

1. Have a separate program from RD whose purpose is to uninstall RD. It can take care of cleaning up any resources that RD created/used.
2. Bake the clean up process into the factory reset button. We can then put a note in the uninstall section of the documentation that tells users to factory reset RD before uninstalling it to keep their system clean.

There may be other paths we can take. What do you all think?

[mook-as]

Sure thing! We have:

• Windows: NSIS setup (so we have an uninstaller that can run things); this may be an administrator instead of the normal system user, who probably doesn't have access to the user account.
• Mac: disk image; no opportunity to run things (it's just a file delete)
  • If we really need it, we can switch to *.pkg to support install / uninstall scripts, though that should be avoided if possible.
• Linux: We have:
  • AppImage: like a mac app bundle, we don't get an opportunity to run anything when the user just deletes files off the disk.
  • RPM: We can run pre/post/preun/postun scripts; however, those are run as root, whereas the data is per-user (and we don't know which user on a multi-user system.
  • Deb: similar to RPM.

[janvogt]

As a macOS user I'm used to check how to uninstall a programm before I first install it. This is because the OS unfortunately does a very bad job of standardizing this process. Many apps don't care at all which leads to a messy system over time, so I try to avoid such apps as much as possible. However, there are a few ways to support uninstallation for a macOS apps. So, I thought it might help if I share the ones I know together with examples (ranked by my personal preference in decreasing order):

• Probably not an option here: Moving the app bundle into the trash just works because everything is contained in the bundle. If you want to delete the configuration as well, you can use something like AppCleaner.
• A menu item that allows to uninstall the app like the Zoom Client
• A uninstall script shipped in the disc image like Virtual Box
• A (potentially user researched) list of steps that need to be taken like Nix on Mac sometimes also as script. The bad thing is, you never know if it's correct for the version you've installed.
• No information whatsoever. AFAICT this is the current state here(?)

As a sidenote: I believe it's the bad uninstall experience for macOS users, where the distaste for *.pkg originated from. Such an app essentially tells me as a first impression "Hi, I will be all over the place". Of course, any disk image *.app can do very much the same on first launch, but inexplicably to me it still feels better. So I tend to agree with @mook-as that a *.pkg should be avoided.

[janvogt]

N.B. https://docs.rancherdesktop.io/installation#uninstalling-rancher-desktop-on-macos is not sufficient, since it clearly can't uninstall setup done by sudo.

[jsoref]

Can we at least fix those uninstallation steps, they're clearly wrong, and it seems like it'd be fairly easy to write instructions, something like:

1. Run:

   ls -l /usr/local/bin | grep 'Rancher Desktop.app'
   

2. Use sudo rm to delete the files that point to the deleted app...

[mattfarina]

An uninstallation process across platforms would be great. But, it's not a hard requirement for 1.0. Many apps don't uninstall data when they are removed. I've experienced this on Mac, Windows, and Linux. Though, I think Windows does a better job cleaning up with uninstallers accessible via Add/Remove programs.

When we do provide better cleanup we can implement it differently per platform and add it one platform at a time.

[rak-phillip]

At the very least, I think it would be nice to document some post-uninstall steps for each platform so that people can know what to clean up.

[jsoref]

Fwiw, we generally use brew on macOS and I think that gives it at least a bit of an uninstall option.

Another thing it could do is be shimy and instead of using a symlink called helm, create a script called helm which looked for a symlink called helm-symlink as a sibling to itself, if it found that and it was valid, run it, otherwise, find itself in the path and then find the next helm in the path that isn't itself (or take its directory out of the path and try running that). This of course wouldn't work great if there were two similar shimy scripts for the same program both in path, but...

[adamkpickering]

Coming back to this now, I feel I have more clarity about it. For simplicity's sake, the uninstall process should be as cross-platform as possible. That means that we cannot depend on any package manager or installer wizard to do uninstallation, since those things are not present for every format we distribute RD in. For example, the AppImage version of RD is just a file the user makes executable and runs.

I think that the simplest uninstallation process is:

1. Factory reset. If this doesn't already wipe all (non-application-code) traces of RD off the system, it should.
2. Do the distribution-dependent uninstallation. This could be running the uninstall wizard, running apt remove, or just deleting a file. This is made simpler by the fact that you don't have to worry about removing all of the things that RD may have changed about the system at runtime.

[alex-ander-is]

It's been a couple more years, any update on this issue?
Guys, I'm pretty sure you know what you are installing (copying to the system), so just clean-up things you've added there. I don't believe you have no idea what your software is doing. Even AppCleaner and so can find many related resources, can't you?