3 ms·
I wanted to leave the original post unsullied by my ragy commentary: They are listing this as "operational" but the steps they are outlining here are not a pro
by JohnMakin 2y ago
I wanted to leave the original post unsullied by my ragy commentary:
They are listing this as "operational" but the steps they are outlining here are not a proper solution for this problem! I cannot sudo on my work macs. How can a severe problem like this go on for more than a week? This has completely shut down my local development. I'm mad at the situation more than anything, but also a big middle finger to mac OS for not allowing me, a somewhat mature professional adult with expertise in stuff like this, what I want on my machine. My new workstation orders are not going to be macs. Good job!
The worst part is, even if you go with the extremely user-hostile un-minimizable prompt wants you to do, which is delete a bunch of files, the popup will still spam you until you are able to follow the instructions on the remediation that docker provided! Completely FUBAR
- nikau 2y agoTurn off updates, test things first
- JojoFatsani 2y agoJohn, it's really pretty easy to fix: Take a deep breath. Uninstall docker, including from homebrew if you've ever used that to install it. Reboot Download newest ARM version from Docker. Install it. Reboot again. You should be good.
- JohnMakin 2y agoIf it wasn’t clear in my original post, I have to solve this for a fleet of machines. I’ve taken many breaths today, but thanks for your condescending concern. And as I said, for people with typical machine access in an org, this is a completely unacceptable solution. Anything that requires sudo access and a pasted bash script in a doc is a completely unacceptable solution. You cannot turn around and call this solved.
- honestSysAdmin 2y agoWhat you can do is have a cron job that continuously polls one or more URLs looking for tarballs with Git repos accompanied by GnuPG or Signify signatures. The primary idea is that the tarballs are only unpacked and executed if the signatures are valid and anything received by the machines is only executed after the hashes and signatures are successfully logged, this prevents (or at least documents) any abuse on the part of the IT team. Inside the tarballs are Salt, Ansible, and/or shell commands. In addition to a cron job, we had an active pubsub listener on each machine to poke this process. You can do this on macOS too, or at least, modern macOS "should" be able to do this. We did this on a large fleet of user machines (laptops) running Windows 10/11, macOS, and Linux.
- zdragnar 2y agoOn an entirely separate tangent... Why are you remotely managing macs? That seems like a cluster of nightmarish proportions without even getting to this issue. If you don't trust people, give them Windows and use the tools that have been around for decades for this.
- smithcoin 2y agoRemote management is a requirement for SOC other compliance frameworks.
- hedora 2y agoThat doesn’t sound right. Most of SOC compliance boils down to having a plan to check enterprisey checkboxes. So, you pay someone that can write a report explaining how the boxes will be checked in a way that minimizes the blast radius of security theater stuff like broken approaches to remote management. Consider fixing your soc compliance plan. Anyway, assuming the remote management tool has root, you can use brew to install docker desktop from the cli.
- ghxst 2y agoIn principle yes. The implementation however is rarely defined (if you have examples, feel free to share). In my experience it's by choice that companies use compliance to turn their dev environments into a micromanaged hell that engineers hate working in (our company went through multiple compliance certifications including SOC1 and SOC2).
- zdragnar 2y agoNot at the level John was talking about. My last company had SOC 2 and yes, there was remote management, but the developers still had admin access to their machines, and didn't need some BOFH to use docker.
- darth_avocado 2y agoI agree that requiring sudo access may not work for some orgs at a user level. But it also seems unusual that you need to solve this for a fleet of machines and yet are not allowed sudo access.
- JohnMakin 2y agoI dont know how it could be less obvious that I manage other users’ devices, and yes, I can escalate my permissions fine, but rolling this out to a distributed fleet of machines, some of which may not be remotely in the same timezone, is not quite as easy - there are many situations where sudo is not granted by default to a workstation. I’m amazed people find this surprising in this thread.
- danaris 2y agoIf you're managing Macs on anything like an official basis, why are you not using any of the various tools that exist to enable and streamline that? Macs have built-in device management tools, and there are third-party solutions like JAMF that can definitely run scripts like what's needed to fix Docker, as root, including reboots if necessary. It really sounds like the primary problem you're experiencing is not what Macs allow, nor even the shoddiness of the Docker solution (which I will not attempt to defend, I agree they should have something more robust), but your company's policies that put you in a position of responsibility but no power.
- JohnMakin 2y agosometimes you deal with contractors that you don’t have such explicit and unrestricted access to their devices. but yes, being in a position of responsibility and no power is basically the IT sysadmin’s creed, and that is not even my official role, just one I am forced to play a lot.
- danaris 2y agoAnd this is a problem with company policies, not with the design of macOS or Docker. I'm sorry, but there's just no sane system design that can make up for such abjectly counterproductive policies, no matter how common they may be.
- theamk 2y agoIf you are in the org with managed macs, you should not be doing this yourself, your IT (or security, or whomever manages your computer) should be creating a script and adding it to whatever secure script runner they deployed to user machines. Or even better, automatically fixing this. If you are in the org where your IT cannot do this, and the same IT took away your "sudo" access, then there is nothing you can do. Even if there were a hacky way, it would be against policies, so do it by the book and wait for IT to fix it for you. If you are on important and urgent project, escalate via official channels. If you are not on important project, relax and don't forget to write "I could not do anything because I am blocked on IT" in all of your status reports. If the previous paragraph makes your blood boil or makes you want to cry, consider working for a different company which either gives autonomy to developers or has better IT.
- dacryn 2y agoI have literally switched to a lower paying job because of IT issues at a previous firm. The extra headaches was not worth it to me. It doesn't help IT was full of Microsoft fanboys over there who saw Macs as a nuisance and did barely any testing on them of their updates
- JohnMakin 2y ago> should be creating a script and adding it to whatever secure script runner they deployed to user machines. Or even better, automatically fixing this. It may surprise you to learn that a lot of orgs have critically understaffed or unknowledgeable IT teams. Yea, I could "solve" world hunger by simply feeding everyone, but how do I actually do that? I am the crititcally understaffed "IT" that has to fix it for you. And now it's urgent because local development has basically halted on tons of devices for a variety of weird and undocumented reasons. I am trying to communicate to you that rolling out a "fix" for this type of thing to a distributed fleet is not trivial at all. For a typical IT sysadmin this is one of the most annoying possible things, at the worst possible time too (post holiday), and that's not even my official role! I just have to play it a lot. Also, I think you're severely underestimating how complicated it is managing a remote fleet of devices under current compliance and security standards across the industry. You're talking from the perspective of a dev that gets mad they can't have unlimited access to the prod db with a single ticket, I think, but the reality is these things are not easy to roll out on the fly under specific circumstances. Good for you that you found a company that fits your needs/whims and isnt bound by these same kinds of restrictions. I'm also not making any commentary on whether any of this is sane at all, just that I am the guy at the short end of the stick that has to deal with it and I'm (justifiably) pissed off about it.
- soraminazuki 2y agoJudging from the fact that all the workaround does is reinstall a privileged daemon, you needed root to install Docker in the first place. Why are you outraged that you need root again to reinstall? Moreover, how is that even a macOS problem? Being outraged that you need to invoke administrative privileges on a development machine seems unreasonable to me. You can't get far with that kind of restriction.
- JohnMakin 2y agobecause modern macOs does not gracefully allow true root, without hacking, in a way that doesnt solve compliance requirements?
- soraminazuki 2y agomacOS obviously has the capability to reinstall Docker. If your company is preventing you from upgrading to the fixed version in timely manner, that's your company's responsibility.
- JohnMakin 2y agoPerhaps you should inform yourself about the actual problem/proposed solution here - the issue isnt installing a fresh new version, it’s the uninstallation steps required to even get there in the first place. and no, mac os will not let me do this, even when I follow the prompts. docker’s elevated permission scripted solution is the only thing that has worked yet.
- soraminazuki 2y agoLooking at the incident page, the bash solution was superseded by a proper release the next day. And the linked document specifically instructs to "update directly through the app" if possible [1]. So uninstall not working is completely news for most people reading this thread. Even the title of this thread, "Docker Desktop Broken on Mac OS Update for over a Week," isn't substantiated anywhere else. But even if it is required to manually stop and remove the two daemons, shouldn't that be doable using any device management solution? Perhaps using something like Jamf Self Service? Because it otherwise wouldn't be possible to deploy any changes without that kind of capability. [1]: https://docs.docker.com/desktop/cert-revoke-solution/ https://docs.docker.com/desktop/cert-revoke-solution/
- gunian 2y agoused to have a gig where local dev worked on all machines except mine lol if it is only broken when Docker messes up horrible but not the worst it could be if perspective helps in this situation :)
- JohnMakin 2y agoNot having sudo on a work managed mac is so completely common that I struggle to take anyone seriously that argues otherwise and I'll just leave that comment here
- theamk 2y agoMy sample of 3 shows the Macs in big corp has some way to temporary get sudo. Some sort of proprietary app you run that grants you permissions for a period of time. Sometimes there is a text field for "reason", but no one ever reads it.
- dacryn 2y agoA work managed mac without a sort of helpdesk that can help you fix an update issue of approved software is equally unserious. I have never had sudo on a work managed device, but always had a phone number to call for exactly these types of issues. Explain the problem, point them to the fix. They look it up internally, call me back half an hour later, take over the machine and perform the procedure. Is it frictionless? No. Is it impossible? No, just part of dealing with corporate IT.
- JohnMakin 2y agoImagine I am the corporate IT here. I don’t even need docker desktop! I’m switching to something else. This is now a huge unnecessary pain that still has yet to be explained.