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

[Tod Oace]

On Oct 22, 2004, at 09:50, Ed Brown wrote:
> On Fri, 2004-10-22 at 10:07, Wayne wrote:

> I've kind of butted in, and made it my issue too...  (Sorry Tod!)
No problem -- good use of list!

> > We use the "NFS mount method" of running Cfengine here in the SCC. In 
> > other
> > words, All clients are built with automounted cfengine 
> > common(CFINPUTS,
> > master files, etc) and os-specific(bins, libs, etc) directories. They 
> > run
> > cfagent from cron and a shellcommand collects system info from the 
> > clients,
> > which write out to a Cfengine client writable directory. This (NFS 
> > mount)
> > may not be an option for Tod.

Not really an option for me... Some of our systems don't do automounts 
by design, some are behind internal firewalls, I have 12 sites to deal 
with, etc. etc. I'd have a difficult time collecting information from 
ALL systems via NFS. Also I'm trying to use NFS as little as possible 
and I really like not using it for any of my cfengine infrastructure. 
My policy servers already have access to all the systems so I'd really 
like to be able to collect the information onto them.

> > I also had a thought: Add a Cfengine shellcommand to run a logger 
> > command to
> > send a formatted syslog to a MySql DB on a central server. We are set 
> > up
> > here to do that by using a central logger running syslog-ng.

I'll have to take a look at syslog-ng. I've been meaning to do that for 
a while. Yet another thing to do... :)  -Tod

> >  Syslog-ng is
> > much more flexible and feature rich than syslogd. It can send certain 
> > logs
> > (Cfengine ones, i.e.) to a program, such as a MySql loader, in lieu
> > of/addition to a log file. The clients could then interactively SQL 
> > select
> > rows from that DB and parse the info for whatever purpose. Just a 
> > thought.
> > Of course, the clients could just run a Perl-Mysql routine and 
> > directly add
> > info, but that involves write permissions and user control on the DB 
> > side.
> > Syslog-ng provides the standard syslog interface/format.
>
> Very interesting idea.  We are already using syslog-ng on our central
> loghosts, and have a MySQL server available.  And like you say, having
> IT write to the DB server solves the hesitation that Tim Nelson
> expressed, about setting up users and write permissions for all the
> clients. No additional protocols, no additional open ports on the
> network... I like it.
>
> > I don't have my Linux box up, so I can't send "Reply-To" emails to 
> > the list
> > with my Windows/Outlook box. Feel free to respond to the Cfengine 
> > list with
> > any/all/none of this info. I just thought I'd share.
> >
> > -W
>
> I appreciate it, thanks!
> -Ed
>
>
> > -----Original Message-----
> > From: help-cfengine-bounces+sweatt=lanl.gov@gnu.org
> > [mailto:help-cfengine-bounces+sweatt=lanl.gov@gnu.org] On Behalf Of 
> > Ed Brown
> > Sent: Friday, October 22, 2004 8:50 AM
> > To: Mark Burgess
> > Cc: Cfengine Mailing List Help
> > Subject: Re: [Fwd: Re: ${clientip} ?]
> >
> >
> > 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
> >
> >
> >
> > _______________________________________________
> > Help-cfengine mailing list
> > Help-cfengine@gnu.org 
> > http://lists.gnu.org/mailman/listinfo/help-cfengine
>
>
>
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@gnu.org
> http://lists.gnu.org/mailman/listinfo/help-cfengine
--
Tod Oace, Intel Corporation <tod@intel.com>