3 ms·

John, 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

John, 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 ago
If 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 ago
  What 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 ago
  On 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 ago
    Remote management is a requirement for SOC other compliance frameworks.
    - hedora 2y ago
      That 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 ago
      In 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 ago
      Not 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 ago
  I 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 ago
    I 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 ago
      If 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 ago
        sometimes 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 ago
        And 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 ago
  If 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 ago
    I 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.

JohnMakin 2y ago

If 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 ago
What 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 ago
On 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 ago
  Remote management is a requirement for SOC other compliance frameworks.
  - hedora 2y ago
    That 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 ago
    In 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 ago
    Not 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 ago
I 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 ago
  I 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 ago
    If 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 ago
      sometimes 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 ago
        And 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 ago
If 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 ago
  I 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.