Re: [Fwd: Re: ${clientip} ?]

[Ed Brown]

You're right, cfengine copy is a simpler solution for collecting files
to a central location than scp, but it does require that cfservd be
running on all the clients, something we don't do now.  And it requires
that the datafile to be collected be generated by a process not coupled
with the collection process.  I'm not very clear about remote methods,
but my thought was that they might be a way to connect to a remote
server, run commands there, and return data, all within cfengine, not
even necessarily involving file transfers. 

I don't know about Tod's purposes, but I think Tim's comment about
updating a central database is really the right direction for what I had
in mind, which is to have a single location for a variety of info(system
stats, hardware info, installed packages/versions...).  Cfengine could
distribute and run the script to do this, or a module could provide even
tighter coupling, to take advantage of defined classes, or to define
other classes...  

thanks,
Ed




On Fri, 2004-10-22 at 00:44, Mark Burgess wrote:
> I do not understand the logic of using scp here. copy is still
> a better solution in that case. I am not sure why you need a remote
> method here at all. If you are collecting a file and simply wwant
> to copy it to a hostname dependenent place, but put the hostname
> in the destination file?
> 
> control:
> 
>  rhost = ( a:b:c )
> 
> copy:
> 
>  /from dest=$(rhost)-copy server=$(rhost)
> 
> M
> 
> On Thu, Oct 21, 2004 at 04:21:48PM -0700, Tod Oace wrote:
> > On Oct 21, 2004, at 16:12, Ed Brown wrote:
> > 
> > >I assume you are talking about 'remote methods'?
> > 
> > Yep!
> > 
> > >There's not much info in the documentation about it yet, but it sure 
> > >sounds complex, if not to say convoluted.
> > 
> > Possibly. I don't have any opinion on that yet.
> > 
> > >For one, I'm guessing it requires that cfservd be running everywhere.
> > 
> > I don't think so. If I understand it correctly the method call contacts 
> > a cfservd which then runs cfagent, runs the method and then returns 
> > results back to the caller. I just want to collect information on my 
> > cfengine servers which are already running cfservd. I don't think the 
> > method call tries to contact a cfservd on the client system.
> > 
> > I haven't tried the remote stuff yet. I'm just doing local calls while 
> > I develop my module. And right now I'm trying to figure out why this 
> > isn't matching infotype = syslog (to prevent "../filename"):
> > 
> > classes:
> >         valid_infotype = ( Regcmp("^[A-Za-z0-9]*$","${infotype}") )
> > 
> > "^.*$" works but anything I try with "^[...]*$" doesn't. But...this is 
> > a separate issue.
> > 
> > >When I've considered data gathering schemes, I always end up back at 
> > >the idea of scp-ing info back to the server, or somewhere, an idea 
> > >with its own limitations and problems.  I'd be interested in hearing 
> > >if you are able to use cfengine for this.
> > 
> > Yeah, I'll probably have to do that if I can't make remote methods 
> > work. It still looks to me like it will, although I'm noticing ReadFile 
> > produced a bunch of nul padding. So I'll have to figure that out too. 
> > But aside from that I was able to copy up a file. Locally anyway.  -Tod
> > 
> > >-Ed
> > >
> > >
> > >On Thu, 2004-10-21 at 16:02, Tod Oace wrote:
> > >>>(Dang, I don't understand lists that don't set the reply-to field to 
> > >>>go
> > >>>to the list.  To me, that's the whole point of a list, the 
> > >>>discussion,
> > >>>not to get private answers to questions, unless appropriate for some
> > >>>reason...)
> > >>
> > >>Oh, and that case here's my reply to the list:
> > >>
> > >>>From: Ed Brown <ebrown@lanl.gov>
> > >>>Date: October 21, 2004 14:56:55 PDT
> > >>>To: Tod Oace <tod.r.oace@intel.com>
> > >>>Subject: Re: ${clientip} ?
> > >>>
> > >>>
> > >>>Where I get stuck right away when considering something like this is
> > >>>the
> > >>>question of how to get information from the client to the server.  
> > >>>It's
> > >>>backwards to the normal flow of cfengine.  Did you already have a
> > >>>mechanism for this in mind?
> > >>
> > >>Yeah... A Cfengine method call. There's even an example in the
> > >>reference manual passing the first part of /etc/passwd:
> > >>
> > >>http://www.cfengine.org/docs/cfengine-Reference.html#methods
> > >>
> > >>search for: ReadFile("/etc/passwd"
> > >>
> > >>So I *think* that takes care of the communication mechanism. I'm 
> > >>toying
> > >>with it now. But I'm also thinking about the step after that.  -Tod
> > >>
> > >>
> > >>>-Ed
> > >>>
> > >>>
> > >>>On Thu, 2004-10-21 at 15:41, Tod Oace wrote:
> > >>>>I'm hoping to create a method to collect small bits of information
> > >>>>from
> > >>>>systems onto my cfengine servers. It seems like this will work fine
> > >>>>but
> > >>>>I'd also like to prevent systems from being able to clobber each
> > >>>>others' bits of information.
> > >>>>
> > >>>>I think what I want is to stash information into files named
> > >>>>.../somedirectory/${clientip}/${infotype} where ${infotype} comes 
> > >>>>from
> > >>>>the client and ${clientip} is defined on the server end. But I'm
> > >>>>unable
> > >>>>to find a variable like ${clientip}. I see forcereplyto but that's
> > >>>>defined by the client.
> > >>>>
> > >>>>I would like this in order to collect and analyze files before I put
> > >>>>them under central cfengine control. I don't really need information
> > >>>>sandboxes for that kind of temporary information, but there is some
> > >>>>other system information I would like to protectection for. Stuff
> > >>>>defined on the systems that I want persistent across system builds.
> > >>>>Any
> > >>>>ideas?
> > >>>>
> > >>>>
> > >>>_______________________________________________
> > >>>Help-cfengine mailing list
> > >>>Help-cfengine@gnu.org
> > >>>http://lists.gnu.org/mailman/listinfo/help-cfengine
> > >>>
> > >
> > >
> > -- 
> > Tod Oace, Intel Corporation <tod@intel.com>
> > 
> > 
> > 
> > _______________________________________________
> > Help-cfengine mailing list
> > Help-cfengine@gnu.org
> > http://lists.gnu.org/mailman/listinfo/help-cfengine