Why can’t we use sudo in fireball mode?
This works in fireball mode:
- command: “sudo su -l -c ‘echo hello’ {{ username }}”
This errors out:
- command: “echo hello”
sudo_user: “{{ username }}”
sudo: true
This doesn’t fail, but doesn’t run as the indicated user:
- command: “touch /tmp/foo.txt”
sudo_user: “{{ username }}”
Is this a matter of “not implemented yet” or “will not be implementing”?
thanks,
Bryan
So fireball runs as the user you lay down the fireball as, because most of our sudo logic has been to deal with running sudo over SSH.
Fireball was named somewhat in gest because it’s a “1-2” kind of maneuver like a fireball in a 2D fighting game. You set up the fireball in a previous play
and then it’s available for later.
I can see it possibly being done later, but I have some other plans to cleanup fireball mode first.
There’s really no reason it needs to use 0mq anymore, and could be a basic socket server and be just as fast, and needs to chunk file transmissions (for large file transfer) – those are things I think we’d be doing first.
Honestly, for most folks, SSH is fast enough, so I’m seeing less people using fireball than used to be – but I’m sure we’ll keep it around, but I definitely want to reduce the number of dependencies it requires.
–Michael
OK, I’ll remove our dependence on fireball mode. Not a big deal. Local connection is even faster than fireball, so this will probably give me a good incentive to set up a proper pull mode implementation, which has other benefits.
thanks,
Bryan
you can also start multiple fireball peers running as different
users, with sudo_user. not ideal, but definitely useful in small
doses.
also sprach Bryan Larsen <bryan@larsen.st> [2013.06.28.2031 +0200]: