Forum: CFEngine Help
Subject: Re: CFEngine viable alternative to Kaseya?
Author: sauer
Link to topic: https://cfengine.com/forum/read.php?3,24177,24204#msg-24204
You should be able to remotely execute scripts without pre-loading them into
the policy. It just takes some creativity. :)
I've recently been toying with a simple script deployment structure which would
basically use a specific class prefix (say, runscript_) to trigger fetching and
execution of an arbitrary script in a given directory. The policy will be
something along the lines of:
vars:
"scriptdir" string => "/var/cfengine/scriptbase";
classes:
"need_script" classmatch => "runscript_*";
files:
get_script::
"$(scriptdir)/$(sed.thescript)"
ifvarclass => "runscript_$(thescript)",
classes => if_ok("have_script"),
copy_from => scriptfetch("$(sed.thescript)");
commands:
need_script&!get_script::
"/usr/bin/sed -n 's/^runscript_\\(.*\\)/=thescript=\\1/p'
$(sys.workdir)/state/allclasses.txt"
classes => if_ok("get_script"),
module => "true";
have_script&!(script_ok|script_bad)::
"$(scriptdir)/$(sed.thescript)"
classes => if_else("script_ok", "script_bad"),
ifvarclass => "runscript_$(sed.thescript)"
So, given a script named "fix_ssh". You'd put fix_ssh in your scripts location
on the master. You'd then execute "cf_runagent -Drunscript_fix_ssh -H
targethost". On targethost, the runscript_fix_ssh class would be converted to
a variable named thescript with a value of fix_ssh by the sed command promise.
And then the command would be run.
But I should note that I haven't tested this at all (ok, I tested the sed
command / module and execution of the resulting variable). And there's more to
it than this; I'd probably actually set the need_script class in a common
bundle in promises.cf, and use that class to alter both the include and
bundle_sequence so that the rest of the policy wouldn't run; just this. And
the scriptfetch bundle would need defined, as well as making sure the
permissions of that directory are safe (and maybe that the directory is emptied
if need_script is not defined). And there's should be some better logging of
the script's output, as well as reporting of status. But this should get
someone started. ;)
Oh, and it's worth noting that it's generally a bad idea to take user input and
convert it to a command to execute, but this should be pretty safe since the
script is being copied from the master - which should be trusted - and the path
would have to be a valid class name (or gets canonified), so it couldn't
contain directories 'n such (though one could easily, say, change the first _
to a / in the sed statement).
It's also worth noting that there should be no one-shot activities in a
properly-managed CFEngine environment. If you have a problem to solve, it
should be solved in such a way that it'll automatically be fixed upon
reoccurence. You do that by developing a proper CFEngine policy, not by
writing a one-off script. But sometimes theory and practice diverge when
unreasonable timelines are presented. "Fix it now" may trump "ideally, this
would be a policy". :/
_______________________________________________
Help-cfengine mailing list
[email protected]
https://cfengine.org/mailman/listinfo/help-cfengine
