I’ve noticed an unexpected behavior related to Administrative Access: 1. At some point, RD stopped asking for sudo password 2. I opened Preferences and *un*checked the “Allow Rancher Desktop to acquire administrative credentials (sudo access) 3. RD restarted (VM and k3s) 4. I opened Preferences again and checked the “Allow Rancher Desktop to acquire administrative credentials (sudo access) 5. RD restarted (VM and k3s), but never asked for sudo password It happened before, and I’m not sure what is my current configuration. @fast-garage-66093 macOS Monterey, RD 1.6.2

It will only ask you for the password when it needs it. It is used for different purposes: for vmnet to get a routable IP address, and for creating the

/var/run/docker.sock

socket.

Thank you for the explanation, @fast-garage-66093! It actually proves that my system works as expected.

I do want to remove the sudoers file once we don't use it anymore at all. I'm not convinced removing the socket helps with anything, but once we have the privileged helper it should be simple enough to do on shutdown of the app

Oh, I’m glad I checked - the Factory Reset set my CPUs to 2, dropping from 18. But left RAM unchanged, I think; 6GB. If you compute these numbers, from OS resources, I have 10 cores/20 threads and 128GB RAM in this box. Hope this helps

It left the RAM at 6 because that is the default 😄

once we have the privileged helper…

Ah, yes indeed, you’ll only ask for root permission once for that helper, and won’t need them anymore.

That is the idea of factory-reset: all custom settings are discarded; the configuration is like a fresh install

Right, that’s how I understand it. Red font helps, too

I just argued again this morning that the factory reset should not by default delete cached Kubernetes images because they are not custom settings; just additional content that is downloaded at a later time. Deleting it doesn't reset anything because it will just be replaced again with identical content when needed

I agree with that; it helps to save bandwidth and does not test patience of those users with slow or intermittent Internet connections. The content is identical to the level of enforcement; in my co people started using Nexus development Docker repos that allow redeployment, for production, thus version/tag meant nothing because the content could and did change. Worst experience I ever had. But of course we trust GCR to not change the content without changing tags, or else the whole world will be broken :)

Well, it is the package owner you have to trust... You can use sha256 checksums instead of tags in your image names, if you want to be sure

Of course, we do that in some cases. Tags can be moved, checksums, good luck with that