Hi,
Anyone think this is a good idea? I have found that there are some
exec tasks that I am making that just shell out to ruby to do a one /
two line script in the exec line, was thinking it would be nice to
have an option for exec to tell it to just eval ruby code passed to
it, e.g.
exec {
''eval: code to evaluate'':,
...
}
I know Lane wants users to turn execs into new types over time and I
agree with that philosophy, just thought it would make the type a
little nicer to add this capability to it. Some automated tasks (to
me at this point) don''t seem to warrant a whole new type because they
are so domain/application specific.
Bad idea? Wrong thinking?
- Max
On Mar 9, 2007, at 9:52 AM, Max wrote:> Hi, > > Anyone think this is a good idea? I have found that there are some > exec tasks that I am making that just shell out to ruby to do a one / > two line script in the exec line, was thinking it would be nice to > have an option for exec to tell it to just eval ruby code passed to > it, e.g. > > exec { > ''eval: code to evaluate'':, > ... > } > [...] > Bad idea? Wrong thinking?One interpreter is as good as another; I''ve been planning on supporting multiple interpreters, I just haven''t gotten around to it. I''d accept the patch if one were provided. -- Real freedom lies in wildness, not in civilization. -- Charles Lindbergh --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Will see what I can do :), sorry for mistyping your name in my post, tired Friday. - Max On 3/9/07, Luke Kanies <luke@madstop.com> wrote:> On Mar 9, 2007, at 9:52 AM, Max wrote: > > > Hi, > > > > Anyone think this is a good idea? I have found that there are some > > exec tasks that I am making that just shell out to ruby to do a one / > > two line script in the exec line, was thinking it would be nice to > > have an option for exec to tell it to just eval ruby code passed to > > it, e.g. > > > > exec { > > ''eval: code to evaluate'':, > > ... > > } > > [...] > > Bad idea? Wrong thinking? > > One interpreter is as good as another; I''ve been planning on > supporting multiple interpreters, I just haven''t gotten around to it. > > I''d accept the patch if one were provided. > > -- > Real freedom lies in wildness, not in civilization. -- Charles > Lindbergh > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >
On Fri, Mar 09, 2007 at 10:52:02AM -0500, Max wrote:> Anyone think this is a good idea? I have found that there are some > exec tasks that I am making that just shell out to ruby to do a one / > two line script in the exec line, was thinking it would be nice to > have an option for exec to tell it to just eval ruby code passed to > it, e.g. > > exec { > ''eval: code to evaluate'':, > ... > }I suppose it could be useful in limited circumstances. A quick note on nomenclature, though -- a separate type called perhaps ''eval'' might be better than trying to parse the command or adding a new parameter to the exec type. - Matt
On Apr 16, 2007, at 12:28 AM, Matt Palmer wrote:> On Fri, Mar 09, 2007 at 10:52:02AM -0500, Max wrote: >> Anyone think this is a good idea? I have found that there are some >> exec tasks that I am making that just shell out to ruby to do a one / >> two line script in the exec line, was thinking it would be nice to >> have an option for exec to tell it to just eval ruby code passed to >> it, e.g. >> >> exec { >> ''eval: code to evaluate'':, >> ... >> } > > I suppose it could be useful in limited circumstances. A quick > note on > nomenclature, though -- a separate type called perhaps ''eval'' might be > better than trying to parse the command or adding a new parameter > to the > exec type.I would implement this by just supporting multiple interpreters, with ruby as one of the interpreters. -- A government big enough to give you everything you want is big enough to take from you everything you have. --Gerald R. Ford --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Mon, Apr 16, 2007 at 11:39:54AM -0500, Luke Kanies wrote:> On Apr 16, 2007, at 12:28 AM, Matt Palmer wrote: > > On Fri, Mar 09, 2007 at 10:52:02AM -0500, Max wrote: > >> Anyone think this is a good idea? I have found that there are some > >> exec tasks that I am making that just shell out to ruby to do a one / > >> two line script in the exec line, was thinking it would be nice to > >> have an option for exec to tell it to just eval ruby code passed to > >> it, e.g. > >> > >> exec { > >> ''eval: code to evaluate'':, > >> ... > >> } > > > > I suppose it could be useful in limited circumstances. A quick > > note on > > nomenclature, though -- a separate type called perhaps ''eval'' might be > > better than trying to parse the command or adding a new parameter > > to the > > exec type. > > I would implement this by just supporting multiple interpreters, with > ruby as one of the interpreters.eval { code => "include ''fileutils''; FileUtils.rm_rf(''/'')", language => "ruby" } Perhaps? - Matt -- "Left to themselves, [marketers] would butt-tag us like polar bears to track our buying habits and bombard our phones and emails and computer screens with ads benefitting them and their clients." --- Tsu Dho Nimh, NANAE
On Apr 16, 2007, at 5:12 PM, Matt Palmer wrote:> > eval { > code => "include ''fileutils''; FileUtils.rm_rf(''/'')", > language => "ruby" > } > > Perhaps?I prefer ''interpreter'' to ''language'', because that makes it more clear that we''d just be loading an external interpreter. The interpreter would, I suppose, be searched for in the PATH, with an optional fully qualified binary. I expect I''d even want to use an external ruby interpreter, rather than the one running Puppet, because otherwise you could do, um, scary things with this. -- People are more violently opposed to fur than leather because it is safer to harrass rich women than motorcycle gangs. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
David Lutterkort
2007-Apr-16 22:41 UTC
Re: Add the ability to ''eval'' ruby code in exec type?
On Tue, 2007-04-17 at 08:12 +1000, Matt Palmer wrote:> On Mon, Apr 16, 2007 at 11:39:54AM -0500, Luke Kanies wrote: > > On Apr 16, 2007, at 12:28 AM, Matt Palmer wrote: > > > On Fri, Mar 09, 2007 at 10:52:02AM -0500, Max wrote: > > >> Anyone think this is a good idea? I have found that there are some > > >> exec tasks that I am making that just shell out to ruby to do a one / > > >> two line script in the exec line, was thinking it would be nice to > > >> have an option for exec to tell it to just eval ruby code passed to > > >> it, e.g. > > >> > > >> exec { > > >> ''eval: code to evaluate'':, > > >> ... > > >> } > > > > > > I suppose it could be useful in limited circumstances. A quick > > > note on > > > nomenclature, though -- a separate type called perhaps ''eval'' might be > > > better than trying to parse the command or adding a new parameter > > > to the > > > exec type. > > > > I would implement this by just supporting multiple interpreters, with > > ruby as one of the interpreters. > > eval { > code => "include ''fileutils''; FileUtils.rm_rf(''/'')", > language => "ruby" > } > > Perhaps?Stupid question: why is that so much better than file { "/tmp/myscript": content => "#! /usr/bin/ruby\n include ''fileutils''; FileUtils.rm_rf(''/'')", mode => ... } exec { myscript-exe: command => "/tmp/myscript" } especially if the above is tastefully wrapped in a define ? As for the initial question about eval, I think we should avoid evaluating user''s ruby code inside the puppet process as much as possible. David
On Apr 16, 2007, at 5:41 PM, David Lutterkort wrote:>> >> eval { >> code => "include ''fileutils''; FileUtils.rm_rf(''/'')", >> language => "ruby" >> } >> >> Perhaps? > > Stupid question: why is that so much better than > file { "/tmp/myscript": > content => "#! /usr/bin/ruby\n include ''fileutils''; > FileUtils.rm_rf(''/'')", > mode => ... > } > exec { myscript-exe: > command => "/tmp/myscript" > } > > especially if the above is tastefully wrapped in a define ?It''s not that different, other than the fact that it doesn''t encourage lots of temp files lying around, but I''ve always planned on supporting multiple interpreters, and it just seems to make sense. Why should the shell be treated so differently from all other interpreters? This is certainly cleaner, even if it''s not entirely new functionality.> As for the initial question about eval, I think we should avoid > evaluating user''s ruby code inside the puppet process as much as > possible.I agree. Anyone want to file all of this as an enhancement request? -- The people who are regarded as moral luminaries are those who forego ordinary pleasures themselves and find compensation in interfering with the pleasures of others. -- Bertrand Russell --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Hi, I understand that eval in the context of running code in the Puppet interpreter can be scary, the reason I brought it up was for performance for larger scripts or execution of the same script many times during a Puppet client run. I think the idea of interpreter => ''name'' is definitely best for having strong security and enough syntactic sugar to make it a worthwhile enhancement :). Was just thinking about ways to reduce worries about having a lot of forked/exec''d processes running on puppet clients, but maybe this is really not desirable anyway as it would not encourage people to write new types if exec offered performance benefits like this, and yes, security is an issue. If this were to be done to get performance benefits, it might have to be something like what Cacti does with Cacti daemon (cactid) .. cactid starts a PHP interpreter instance (script server) at the beginning of a polling cycle and communicates with the persistent interpreter (not sure of the protocol used) so that the Cacti PHP-based scripts get fast execution when run across a large number of nodes as they are kept in memory until the polling cycle is done. For Puppet this wouldn''t provide a benefit unless the exec was run for a number of files or the persistent interpreter persisted :p across Puppet runs. All in all as I ramble about it sounds like a lot of work for not much benefit whereas Lukes'' suggestion has not much additional effort and still offers a nice benefit :). - Max On 4/16/07, Luke Kanies <luke@madstop.com> wrote:> > As for the initial question about eval, I think we should avoid > > evaluating user''s ruby code inside the puppet process as much as > > possible. > > I agree. > > Anyone want to file all of this as an enhancement request?
On Apr 16, 2007, at 8:50 PM, Max wrote:> Hi, > > I understand that eval in the context of running code in the Puppet > interpreter can be scary, the reason I brought it up was for > performance for larger scripts or execution of the same script many > times during a Puppet client run.I hadn''t thought about this, but I''d basically say that if you have that kind of problem, write a native type in ruby and be done with it. I''d certainly be willing to support the external daemon thing, if someone can figure out how to do it.> [...] > All in all as I ramble about it sounds like a lot of work for not much > benefit whereas Lukes'' suggestion has not much additional effort and > still offers a nice benefit :).Yeah. Like I said, it''s something I''ve been planning almost since the beginning (I even had a stub ''interpreter'' parameter set up). Now that I think about this, this should be set with ''provider'', not ''interpreter''. That makes it pretty darn easy. -- Now and then an innocent man is sent to the legislature. --Kin Hubbard --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com