Create salt-remote-minion (or salt-minion-remote, or salt-minion -r, or whatever)

[blast-hardcheese]

Goal: Manage devices that can't (or shouldn't) have salt installed directly on them using salt-minion in a vim netrw or emacs tramp style way.

Considerations:

• Open a shell when needed, times out when idle for a set amount of time
• Make all (relevant) file operations and command execution (project-wide) go through an exposed salt property (something like __salt__['local.open'], __salt__['local.popen']) (It might not make sense to store salt cache or log files and whatnot remotely)
• Whatever considerations need to be made in terms of configuration of this new minion mode (What configuration file does it default to? How does one run multiple remote minions on the same host?)

Thoughts?

[thatch45]

correct me if I am wrong, but the goal here is basically to allow a minion to control another system's files via an arbitrary network interface?

[blast-hardcheese]

Effectively, yes. The goal, however, is to present the daemon minion in such a way that it doesn't need to be special-cased. It's just a normal minion, except all actions happen over some standard connection (like ssh

-Devon

On Apr 7, 2012, at 10:40, Thomas S Hatch reply@reply.github.com wrote:

correct me if I am wrong, but the goal here is basically to allow a minion to control another system's files via an arbitrary network interface?

---

Reply to this email directly or view it on GitHub: https://github.com/saltstack/salt/issues/1054#issuecomment-5010246

[thatch45]

I don't understand again, you want to use salt functions via ssh without a minion being installed on the client side?

[blast-hardcheese]

Not sure how my message got lost, guessing a github issue.

I think the easiest way to describe what this would do would be to show how you might use it:

salt-proxy:~ user$ salt-minion -i proxy-web05 -r root@10.1.2.3 -g role:webserver -g role:testing -g remoteid:web05.example.com --keepalive 30
root@10.1.2.3's password: ******
16:21:24,447 [salt.minion    ][WARNING ] Starting the Salt Minion
16:21:25,489 [salt.crypt     ][INFO    ] Generating minion key: /etc/salt/pki/minion.pem
.........................................................++
...............................................................++
16:21:34,518 [salt.minion    ][INFO    ] Authentication with master successful!
16:21:34,832 [salt.minion    ][INFO    ] Connection to 10.1.2.3 as "root" established!

On the salt master:

master:~# salt-key -A
Key for proxy-web05 accepted.
master:~# salt -C 'G@role:webserver and G@remoteid:web05 and proxy-web05' pkg.install salt
...

There are some good (I think) arguments to do this: 1) Small footprint deployment Sometimes it doesn't make sense to install a bunch of packages and the python interpreter on a box. For example, I'd like modules and states that could enable me to manage my dd-wrt router's nvram. Getting salt and deps running on that would be unpleasant.

2) Transient administration In the past, it has been advantageous to carry around a deployment-in-a-box (my laptop set up to be anywhere from a simple dhcp server to a PXE server to a Debian Live system for recovery). Managing more than one server that are broken or need administration in a similar way becomes a pain, unless you use cssh, but then you're stuck with cssh. (Great tool, wish it were smart.)

3) Salt bootstrapping Simply saying pkg.install salt-minion would be cake.

4) Easier for users to test salt without diving all the way in Instead of requiring spinning up multiple full VMs just to test salt out, being able to set up salt in a single directory (or on a single server), issuing queries and getting comfortable with deployment would seem to be very easy with a system like this.

5) More flexible It's just another tool, at that point. Instead of thinking "Crap, I wish I had salt right now, but there's not enough time to get a whole salt deployment going here" (New job, troubleshooting stuff for a friend, etc) you can just fire up the environment laid out in case 2 and go.

[blast-hardcheese]

Also, I've tested many minions sharing the same private key; While it's not ideal, it's not a huge drawback given most (all?) of the examples outlined above.

The way I envision using this would be having a master running on my laptop, with maybe 5 or 10 keys already accepted (even if they're all the same one). This way I can just say salt 'proxy*' or salt proxy01 and just be on my way.

[thatch45]

I think I follow, this is an interesting concept. The problem I see is that I am not sure how to run modules remotely like this yet. This will require some chewing.

[blast-hardcheese]

The big feature here would be multiple "remote" minions running on the same machine. Having them coexist without clobbering would be crucial. All access would have to be abstracted out and able to be overridden globally. I've started looking at every place open() is used, seeing if they could just be replaced, or if retooling would be required. The os module would need to be proxied as well, which seems hairy.

[thatch45]

Yes, I think that the core design might just not facilitate it, but I am brainstorming some ideas. I am wondering if we can find a way to reduce execution data to a binary, or a portable package of some sort

[thatch45]

@blast-hardcheese what kind of systems are you looking at doing this too? I just got salt working with bbfreeze, so that we could, create a binary salt-minion that comes loaded with all of the needed deps and toss it on any needed system. Then we could have the salt-minon blob installed on systems which now don't need to have python, zeromq etc installed

[blast-hardcheese]

The immediate goal for me would be my dd-wrt, since managing hosts and static leases and dns options is a huge pain currently. I've gotten to the point where I'd rather just leave old entries in there than try and edit the nvram by hand again. (I've written scripts to do this, but nothing sufficiently extensible or modular, since a script like that in a vacuum is effectively useless.) I'd really like to accomplish this with state mappings, something along the lines of:

ddwrt:
    leases:
        00:11:22:33:44:55:
            - name:salt01
            - ipaddr: 192.168.0.123
    portmaps:
        - 22: tcp:salt01:22
        - 80: tcp:scyther:80
        - 1025: udp:bogus:1025

but the big problem is I don't have persistent storage on my ddwrt (or processes, for that matter. I'm never really sure what actions are going to kill things I'm counting on).

[thatch45]

Ahh, yes, and since salt is based on running python files and not direct command and file management we would need to have more minion code on the router. I am wondering what version of glibc the dd-wrt has, and if we could build a cross compiler for it that would have the right paths...

[thatch45]

yes, that makes sense. I will keep thinking about ways to handle this stuff

[blast-hardcheese]

I think it's pretty ambitious, looking at how many instances of os and open there are. An addition to make the "os" module RPC would be quite an endeavor, I think. Everything else could be fairly straightforward given things like StringIO and whatnot.

That being said, it might be easier to just start small, implementing only what is necessary. A simple ack search produced 55 instances of os.*, (ack -ho '\bos\.([a-zA-Z0-9._]+)' | sort | uniq for the curious), and all fairly standard. I think this gets easier with a simplifying assumption of ssh not existing on Windows, at which point there are a fairly small set of utilities you can use to approximate a lot of this functionality. I'm thinking of only counting on what's included with busybox, since that has a pretty extensive reach.

Additionally, we wouldn't have to change anything happening locally, so that might only mean changing things in modules and states. This would mean introducing a new layer on top of "os", and best practices associated with it. I think it's ambitious, but possibly doable without a huge amount of effort.

[blast-hardcheese]

Also, I think attempting to compile specialized salt binaries is going in the opposite direction of what I was thinking of. It would definitely work, but it means more tweaking just to try and get salt to work correctly. Full systems provide stuff like real job management, daemons, persistent storage, etc. Part of the goal was to shift the minion to a machine that can actually manage this kind of stuff, to make it maximally flexible.

[thatch45]

I think I am understanding what you are going for, I will definitely be interested in seeing more about how you think this can be done!

[blast-hardcheese]

Me too :)

[thatch45]

I think that we have figured this concept out, I am going to lean on bbfreeze to pull it off I think

[adiroiban]

Here is a gist with some ideas of how to implement a saltless minion over telnet / ssh

https://gist.github.com/adiroiban/5168770

---

These are just state definitions on a real minion that are proxy to another system.

My target is to configure a dd-wrt router (with read/write filesystem) and a Cisco router/switch over ssh/telnet.

Cheers

[zatricky]

As with @adiroiban, I'm interested in having SALT manage Cisco and MikroTik switches and routers. These devices are programmable and communication can happen over ssh and telnet - but they most certainly cannot run a salt minion service directly. In fact they can't even run python code directly either.

Effectively, a proxy service needs to translate the instructions in SALT into the ssh/telnet commands required to configure the device appropriately.

However, this doesn't seem compatible with the description given so far in this issue.

[lrhazi]

should be closed with reference to? or is this different?

http://docs.saltstack.com/en/latest/topics/topology/proxyminion/index.html

[adiroiban]

Yes. I think we are good. Thanks!

[zatricky]

Agreed. Thanks!

[wt]

Should this be closed?

[rallytime]

Yeah, I think so. Thanks everyone!

[chenull]

Link to documentation for proxy minons above is now invalid. and this page is still the first to show when we google about this particular topic

Here is the new link for Salt Proxy Minions Docs https://docs.saltstack.com/en/latest/topics/proxyminion/index.html