The IRC discussion that led to the creation of this project.
(14:26:36) spike: talking of puppet for a moment how would you see an integration with a ticketing system(14:26:46) spike: because that’s a project I’m working on
(14:27:01) laen: Cool. Which ticketing system?
(14:27:18) spike: it’s based on trac
(14:27:30) icblenke: pure ruby all around eh?
(14:27:33) spike: ehehe
(14:27:42) f3ew: spike why?
(14:27:56) spike: why what? why I’m working on such thing?
(14:28:14) f3ew: why integrate puppet and a ticketing system?
(14:28:17) laen: spike: Is this ticketing for change control, or ticketing for defect tracking?
(14:28:47) laen: (Do you want puppet changes to generate change control tickets, or do you want to write puppet code in response to bug requests?)
(14:29:02) spike: f3ew: integrating management decisions with support requests and similar, and management interventions
(14:29:15) spike: so I can automatically record that on day X I did that on machine Y
(14:29:26) spike: so far I’ve put together an svn repo which is interfaced with trac by defaul
(14:29:41) spike: so when I upload configs changes are tracked on a timeline and recorded
(14:29:57) spike: then clients fetch the config file and u know the rest of the story
(14:30:24) icblenke: puppet records the transactions of all changes…
(14:30:36) spike: and once I got this to talk xml I can put together a client side of this thing, so clients can inform servers when things actually took place and so on
(14:30:55) spike: icblenke: has it got a frontend to them? are they searcheable? presentable to management?
(14:31:11) spike: see, I’m working on something that could be compared to syslog-ng
(14:31:12) icblenke: spike: dunno. haven’t managed to get it up and running here yet.
(14:31:27) spike: where events are those of control applications, like cfengine, nagios, munin and so on
(14:31:43) icblenke: spike: sounds like a message bus.
(14:31:51) f3ew goes al;ll twitchy
(14:32:17) icblenke: spike: not XMPP?
(14:32:23) spike: icblenke: sort of, plus the presentation part, so events are recorded properly and easily accessible
(14:32:35) icblenke: spike: opensourced?
(14:32:50) spike: what? this thing I’m writing?
(14:32:53) icblenke: yeah.
(14:32:55) f3ew: spike what about do one thing, do it well?
(14:33:05) spike: yup, sure, gpl
(14:33:10) icblenke: excellent.
(14:33:16) spike: f3ew: what about doing one thing at the time and do it well?
(14:33:23) spike: and do to things and put them together
(14:33:36) icblenke: luke has talked about integrating stats and interfacing with such things.
(14:33:45) laen: spike: Very nice.
(14:33:47) spike: I need both of the things, the msg bus, and the presentation layer, both arent dependent
(14:34:15) spike: trac, considering it’s integration with wiki and tracking system seemed to me the best base
(14:34:37) laen: (Does trac have an XMLRPC interface?)
(14:34:38) spike: I will have to edit and keep ur puppets config under revision control anyway
(14:34:41) icblenke: some people are using syslog-ng as a system bus, luke mentioned that too. I’m partial to XMPP, or a message bus with queues and publish/subscribe.
(14:35:04) laen: The problem with XMPP is that it necessarily means daemons, doesn’t it?
(14:35:06) icblenke: spike: a pupppet<>trac bridge would be awesome.
(14:35:24) laen: (I mean, there’s sendxmpp on the clients, but the server processes must always be running..)
(14:35:30) icblenke: laen: it does. that’s why I like the idea of something like a pluggable mcp running on every node.
(14:35:43) icblenke: http://ian.blenke.com/mcp/
(14:36:25) icblenke: luke has mentioned that he wants something like an event loop on every node at some point in the near future.
(14:37:10) spike: don’t u use apps like nagios?
(14:37:21) spike: or munin/cacti
(14:37:28) icblenke: we use a heavily modified version of netsaint here (pre nagios), but yeah.
(14:39:10) icblenke: a programmatic message bus is one of the big missing pieces in system administration.
(14:39:28) spike: trac xmlrpc support is being worked one
(14:39:34) spike: (sorry was on the phone)
(14:40:03) spike: and yes, I dont wanna force ppl to get extra server stuff listening, so xlmrpc looked fine
(14:40:35) f3ew: Hmmm, so if I understand correctly, spike is implementing an interface between trac and puppet?
(14:42:01) spike: f3ew: I think we went over this lots time ago in #security, you never saw the point of it :)
(14:42:15) icblenke: well, spike is implementing a message bus, by the sound of things.
(14:42:30) icblenke: with a visualization system
(14:42:42) spike: f3ew: nope, what I’m working on is a sort of prelude/BASE thingie but for "administration/management events", not security ones
(14:43:07) f3ew: hmmm
(14:43:12) spike: that thing should understand things like puppet, nagios, monit, munin
(14:43:14) icblenke: spike: oddly enough, that’s what I’m working on here.
(14:43:14) f3ew: I remember that discussion
(14:43:19) spike: :)
(14:43:28) laen: Me too! :)
(14:43:34) spike: ahahah
(14:43:38) f3ew still doesn’t see the design of the system
(14:43:44) icblenke: see. it’s a big missing piece that every SA is looking for.
(14:44:06) laen: Definitely. Event management is both important, and sucks.
(14:44:25) spike: we’re too crazy after security to focus on management imho
(14:44:31) laen: Right now I’m trying to bolt together syslog-ng, logsurfer, and SEC.
(14:44:43) icblenke: ick.
(14:44:46) f3ew: Would this be analogous to a fancy pipe + cron system (with a lot more flexibility)?
(14:44:54) icblenke: yes.
(14:44:57) f3ew: ah
(14:45:02) f3ew: that makes sense
(14:45:04) spike: laen: how’s going with SEC? I’ve never seen the point and stuck to swatch
(14:45:25) f3ew: abstraction helps
(14:45:26) f3ew: :)
(14:45:36) spike: :)
(14:46:00) f3ew bills spike for the three hours spent discussing the stuff
(14:46:05) spike: ehehe
(14:46:23) laen: Well… I’m starting to think I should’ve stuck with logsurfer.
(14:46:37) spike notes down "fancy pipe + cron system (with a lot more flexibility)" for later use
(14:47:02) laen: What I really want is to take a stream of events, distill them down to "events", then tag the events with certain string that then get routed appropriately.
(14:47:19) f3ew: aka, a fancy pipe :)
(14:47:24) laen: Right.
(14:47:50) laen: I’m trying to get SEC to do the distilling and tagging part.
(14:48:19) f3ew: So you need a router for events, with flexibility to modify event signals and route based on (1) destination, (2) origin, (3) message content
(14:49:07) laen: (And the content of other messages through the stream).
(14:49:13) icblenke: with a flexible ruleset for defining the routes.
(14:49:26) laen: Like, one Invalid login isn’t a problem. 1/s is.
(14:49:27) icblenke: (with filtering and rewriting, potentially)
(14:49:31) f3ew: icblenke that is what defines the router :)
(14:49:39) icblenke: or just make filtering and rewriting destinations to route through.
(14:50:01) f3ew: (4) event count
(14:50:04) laen: spike: So you want a way for puppet to generate events about what it’s doing, and have those events feed into trac?
(14:50:10) f3ew: and (5) lack of events
(14:50:22) icblenke: SOA seems excessive to me. ESB looked interesting. but all of that complexity…
(14:50:36) laen: Also, an NTP synchronization failure is only a problem if it doesn’t re-sync within a few minutes. So I want to know about the contents of other messages around it.
(14:50:36) f3ew: no login attempts at ~ 9 am is a bad thing
(14:50:40) laen: SEC is good for that, as is logsurfer..
(14:50:54) spike: laen: yeah, that’s what I was asking about initially. if there was any implemented interface to send the msg out somewhere
(14:50:55) laen: ..The rules get a bit complicated, though. :/
(14:51:07) spike: laen: I guess I could use Actions, but it’d be an horrible workaround
(14:51:16) spike: something at a lower level would definitely much better
(14:51:17) f3ew: spike there is a logging interface
(14:51:31) spike: oh, yeah
(14:51:34) f3ew: lkanies had some design ideas, you might want to talk to him
(14:51:39) icblenke: this also feeds into stats collection.
(14:51:45) icblenke: where is luke today?
(14:51:50) f3ew: though both of us dislike XML
(14:51:53) f3ew: he was here
(14:52:03) icblenke: I’m not realy big on XML either.
(14:52:10) f3ew: lkanies ok, time to brush my teeth :)
(14:52:11) f3ew: * docelic has quit ("Leaving")
(14:52:11) f3ew: laen facter?
(14:52:11) spike: how would you do it then?
(14:52:29) spike: IPC I mean
(14:52:46) f3ew: a fixed delimiter and simple text messages
(14:52:55) icblenke: or yaml
(14:53:05) f3ew: XML is not human readable, and parsing it is painful
(14:53:26) icblenke: yaml is good for that
(14:56:35) icblenke: straight marshalled ruby objects would be the easiest, as YAML has weird corner cases from what I’ve heard.
(14:56:58) icblenke: which really leads to DRb…
(14:57:20) icblenke: luke chose XML-RPC for the genericness of it though. I can’t argue with keeping the message bus open.
(14:57:33) f3ew: yeah
(14:58:00) icblenke: YAML is "open enough" in my book.
(14:58:07) f3ew: OTOH, funny thing
(14:58:35) f3ew: friend at Y! told me today that a new programmer wanted to get all their logs rewritten in XML for easier machine parsing
(14:58:51) icblenke: hah
(14:58:52) spike: :D
(14:59:07) lkanies is back
(14:59:14) lkanies: i was on my bicycle :)
(14:59:14) f3ew: slight problem is that grep doesn’t work with that
(14:59:15) spike wonders about some many ppl having friends @ Y! lately
(14:59:18) f3ew: wb Luke
(14:59:20) spike: s/some/so/
(14:59:21) icblenke: luke returns!
(14:59:34) spike: well, I’m off to the pub, guinness time
(14:59:38) lkanies: i definitely have been thinking about events, ticketing, etc.
(14:59:43) spike: c u later guys, thanks for pointers and comments
(14:59:44) icblenke: we were discussing an event message bus
(14:59:44) lkanies: spike: eh? bad timing…
(14:59:55) f3ew: spike Yahoo! offices are like… 3 km away, and quite a few of the LUG members I know are there
(14:59:56) lkanies: can you wait two minutes?
(15:00:02) icblenke: spike: we’ll be here when you come back ;)
(15:00:25) lkanies: i just wanted to point out, puppet already thinks in terms of events and i have a plan for how to integrate with a ticketing system
(15:00:27) spike: icblenke: emh, yeah, I already have some probs articulating meaningful statements :)
(15:00:36) spike: but I’ll stick around few minutes more
(15:00:39) spike listens to lkanies
(15:00:49) f3ew fills spike with caffeine
(15:00:54) lkanies: and, i’m thinking of using microformats (microformats.org) to define the simple formats of the objects that i want to pass around
(15:01:21) f3ew RTFMs
(15:01:37) lkanies: so, you define a bunch of simple, ad-hoc formats for things like events, log messages, etc., and other people can easily understand them and read/generate them
(15:01:46) icblenke: ooh. neat.
(15:01:59) spike: cool
(15:02:25) spike: I’ll read up on mf.org, that sounds a big improvement for my thingie too
(15:02:35) spike: lkanies: does it happen u know/use/like trac?
(15:02:41) lkanies: plus i’m tagging all of these things i’m generating, so my log messages and events and metrics or whatever are all tagged with 1) the path to the object that generated them (e.g., /webserver/apache/service=apache) and all of the other crap that puppet things is useful (e.g., os, ip address, node name, different classes, etc.)
(15:02:46) spike: or are you more a perl guy and was thinking of twiki?
(15:02:47) laen: Hey, microformats is neat.
(15:02:53) lkanies: spike: yeah, i use it, but definitely "use", not develop
(15:02:58) lkanies: i barely use it, in other words
(15:03:09) lkanies: https://reductivelabs.com/trac/puppet
(15:03:40) f3ew: Looks good
(15:03:43) spike: cool
(15:03:46) lkanies: yeah, the microformats guys aren’t going to know what hit them—they’re thinking all this interactive crap for person-to-person comm, and i’m going to build all the node-to-node stuff instead
(15:03:54) icblenke: heh
(15:04:00) spike: ehehe
(15:04:06) lkanies: i went to the web 2.0 con in oct to try to find out more about how i can take a lot of the really coold stuff they’re doing and apply it to my tools
(15:04:12) f3ew: lkanies what is the difference?
(15:04:15) lkanies: and i found plenty of stuff to do
(15:04:27) lkanies: f3ew: there is no difference except in how you think about it
(15:04:30) f3ew: It is still a bit verbose
(15:04:56) f3ew: lkanies I don’t see a difference between two systems (biological and electroic) communicating
(15:05:10) lkanies: and no one is really even thinking about trying to apply it all to computers
(15:05:16) lkanies: f3ew: they aren’t different, that’s my point
(15:05:28) lkanies: i can just directly apply their ideas to computer shit, and it will seem all revolutionary
(15:05:39) spike: well, really off now. later guys
(15:05:41) f3ew: Now, how can we make that less verbose
(15:05:46) lkanies: spike: ok
(15:05:52) f3ew: or maybe we don’t need to
(15:05:58) lkanies: i’m around all the time, and feel free to hit the list with longer discussions
(15:05:59) f3ew: we don’t
(15:06:02) lkanies: f3ew: which "that"?
(15:06:07) f3ew figures it out
(15:06:14) f3ew: the message formats
(15:06:32) lkanies: ah
(15:06:38) icblenke: microformats looks like well formatted html instead of XML.
(15:06:38) spike: lkanies: tnx much, I’ll stay tuned and report back, it’s likely I’ve to learn much from you guys, I’m already rethinking a couple of things now that I hit mf and yaml
(15:06:44) spike: – off
(15:06:52) lkanies: heh
(15:07:34) lkanies: ok, i better grab some lunch (it’s 1500 here), i just wanted to pop in since i could hear people talking about me :)
(16:19:02) spike: so, I was drinking and discussing of this…
(16:19:33) spike: I have to look at mf, but this guy came up with some nice idea, even if that sounds a bit too "portable"
(16:19:49) icblenke: that is?
(16:19:59) f3ew: what? mf?
(16:20:05) spike: icblenke: using syslog
(16:20:05) f3ew: or something else?
(16:20:15) f3ew: spike we already did that :)
(16:20:19) spike: MicroFormat
(16:20:22) f3ew: does anyone have channel logs?
(16:21:04) icblenke: syslog-ng is commonly used for it right now.
(16:21:08) spike: well, if you build a bus system, u then have to let other apps to use it, so u’re likely to patch them if they don’t do it
(16:21:10) f3ew: (we discussed syslog, not mf)
(16:21:21) f3ew: yeah
(16:21:36) spike: the thing is, what’s the point of patching an app to write to syslog, when it can send the event to some server with xmlrpc?
(16:21:37) f3ew: the alternative is to use a bus ,-> program interface conversion app
(16:21:50) icblenke: I’m thinking more of a syslong-ng "plugin" that converts all messages there into events on the event bus.
(16:21:54) f3ew: assuming your apps support xml-rpc
(16:22:04) f3ew: none of mine do
(16:22:17) icblenke: syslog is one direction.
(16:22:19) spike: u have to write a patch anyway, so why would you write it to let it log to syslog, and then work on syslog to get ur stuff messaged remotely and parse from log fails?
(16:22:26) spike: yeah, ok
(16:22:37) spike: icblenke: u then need to patch nagios to write to syslog
(16:22:49) f3ew: because I have an excwellent logging infrastructure
(16:22:50) spike: becuase atm it doesnt, at least, not events like mail alert, it logs different stuff
(16:22:53) icblenke: spike: or you need to patch nagios to write to the event bus.
(16:23:08) f3ew: and I have stuff logging there
(16:23:27) f3ew <3 syslog
(16:23:28) spike: yeah, whatever it is, u still need to patch nagios.so which patch would be better? once that let it log everything to syslog, or something that send the events with xml-rpc
(16:23:28) icblenke: the event bus also needs "stat sinks" that record stat messages over time into rrd databases for later display
(16:24:01) f3ew: spike I have a logging infrastructure
(16:24:09) f3ew: |logger if you want to
(16:24:15) icblenke: least common denominator…
(16:24:51) icblenke: sure, you can use syslog for all of it.
(16:25:06) f3ew: Well, getting apps to log to syslog is easier than patching everything to do xml-rpc
(16:25:31) f3ew: xml-rpc is also network heavy, which is important to me
(16:25:36) icblenke: however, you don’t have a true message bus, with bidirectional communication or queues.
(16:25:40) spike: ok, so that would be your rute? write something capable or routing messages, and for clients write patches that logs whatever u want to syslog, and then force the user to mess with syslog to log that stuff to ur bus thingie?
(16:25:55) f3ew: uh, no
(16:25:58) icblenke: I’m stuck with a larger problem
(16:26:00) spike: yeah, just receiving suffice
(16:26:04) f3ew: syslog is one component of my bus
(16:26:08) icblenke: my network is widely distributed behind firewalls I don’t run.
(16:26:13) f3ew: ah
(16:26:23) icblenke: the only guarantees I have are that I can ssh to hosts and they can send out SMTP mail.
(16:26:41) icblenke: everything else requires much cajoling of customers to permit things through.
(16:26:54) icblenke: so, I’m stuck writing my own SMTP based message bus
(16:27:05) icblenke: at the moment, I call it "feed/eat"
(16:27:27) icblenke: Events are trigged at the edge by cron jobs and applications.
(16:27:40) f3ew: Ok, so we have very different requirements
(16:27:47) icblenke: for example, flow-capture triggers a script every minute telling me what flow file to chop up and send
(16:27:59) f3ew: yup
(16:28:25) icblenke: right. I can cram YAML over SMTP and encrypt it end to end. that’s what I’m doing now.
(16:28:37) f3ew: Ok, we need (1) a XML-RPC thing for those who need buizzword compliance
(16:29:17) f3ew: (2) a non-rpc scriptableasync channel capable of being tunneled over other protocols
(16:29:40) icblenke: Base64.encode64(cipher.update(Zlib::Deflate.deflate(object.to_yaml( :Indent => 2, :UseHeader => true, :UseVersion => true, :ExplicitTypes => true, :UseFold => true, :UseBlock => true ),9))+cipher.final)
(16:29:54) spike: lkanies: u there?
(16:30:05) spike: lkanies: what would you use as IPC protocol? xml-rpc?
(16:30:13) icblenke: that’s what he uses now.
(16:30:17) spike: oh, k
(16:30:20) spike: didnt get that
(16:30:21) f3ew: spike Look at what icblenke needs
(16:30:35) spike: this is getting really harder :), I’m besides half-way drunk :)
(16:30:49) spike: and my english isnt that good in normal conditions, not to mention brain activity :)
(16:30:50) icblenke: what I plan on doing soon is this:
(16:31:10) laen: spike: What country are you from/in ?
(16:31:21) spike: laen: .uk atm
(16:31:32) icblenke: one central "master" sshing to every remote node, opening a channel to do DRb over stdin/stdout. bidirectional.
(16:31:56) spike: laen: should be .uk for quite a while I hope
(16:32:09) f3ew: icblenke Look at worst case scenario
(16:32:15) f3ew: you have to work over SMTP
(16:32:25) spike: laen: I’m from .it, tho, just moved here recently. u? .us if I got it correctly, eh?
(16:32:43) laen: Yeah, .or.us.
(16:33:11) spike echos f3ew on "wrong part of the world"
(16:34:36) icblenke: worse case I have one way SMTP
(16:34:47) f3ew: yes
(16:35:19) icblenke: which is ok, but doesn’t help me when message get "lost" and should be re-sent.
(16:35:44) icblenke: you don’t want holes to appear in logs or stats from missing messages.
(16:35:57) icblenke: Feed and Eat synchronize using a sequence number.
(16:36:13) icblenke: but, ideally, I want a rolling queue and a producer/consumer model.
(16:36:19) icblenke: with guaranteed delivery.
(16:36:30) icblenke: ie, a message bus.
(16:36:31) f3ew: yeah
(16:36:36) f3ew: SMTP is not reliable
(16:36:50) f3ew: but if you only get 2 way SMTP?
(16:36:56) spike: I dont want to get this thing too big… bah, neither to define a bad design
(16:37:11) spike: messing with syslogs sounds much of a requirement for any installation
(16:37:39) spike: adding a plugin to app X to let app X sending events over xml-rpc sounds less burden for the "user"
(16:38:00) spike: and a few apps can already do that, while the other part would be of harder implementation
(16:40:55) icblenke: you can always tunnel syslog over the event bus later
(16:41:30) icblenke: least common denominator suggests using syslog
(16:42:02) icblenke: in a large farm of servers, however, it’s often best to churn what data you can at the edge and only send in summaries to the stats and alerting collectors.
(16:42:12) icblenke: (large farm meaning more than 1000)
(16:42:36) spike: this wouldnt be lots of traffic anyway
(16:42:51) icblenke: Also, ssh tunnelling for my message bus means I get to have 1000 open outbound ssh connections from the central master. Ouch.
(16:43:01) spike: remember this are events u want to read about, so they must reduced in number anyway
(16:43:11) spike: like lowering snort false-positive
(16:43:31) spike: as long as ur reporting events app triggers too many of them u will end up not reading ‘em
(16:43:54) icblenke: so you’re thinking of processing syslog messages at the end and sending a summary at another syslog level to the collector?
(16:45:05) icblenke: s/end/edge/
(16:45:22) spike: nah, since u’re writing the patch for the app, u’re gonna define that what’s good to be sent and what not
(16:45:57) spike: less info to process, easier to keep it better organized per patch
(16:46:04) icblenke: snort was our first message bus. the raw volume of mail heading in from the collectors.. mindboggling.
(17:00:41) f3ew: spike If you have centralised syslog collectors, syslog is a good thing choice
(17:01:01) f3ew: If you don’t, and you are willing to maintain your own patch and source trees, xml-rpc
(17:01:54) spike: f3ew: I have, other users might havent. anyway, if I had not patch anything because they all already log to syslog properly, of course I’d go that way
(17:02:17) spike: but since I have to patch applications anyway to let them log interesting events to syslog, why not going directly with xml-rpc
(17:02:30) spike: why passing from syslog at all, virtually adding more burden to the system
(17:02:33) f3ew: spike If applications log, that can go to syslog
(17:04:00) icblenke: also remember that syslog isn’t guaranteed delivery for most folks.
(17:04:11) icblenke: syslog messages do get lost.
(17:04:45) f3ew: Well, that is pretty rare
(17:06:58) icblenke: depends on your volume.
(17:07:11) icblenke: and your syslog daemon.
(17:07:24) icblenke: and if you use UDP, there’s that too.
(17:17:17) f3ew: and your network
(17:39:57) mattimustang [n=mflanaga@o2rosock0a.optus.net.au] entered the room.
(18:11:00) glut left the room (quit: Dead socket).
(18:18:56) glut [i=glut@no.suid.pl] entered the room.
(18:21:01) lkanies: i’m around now
(18:21:15) lkanies: but looks like i missed the conversation
(18:21:29) lkanies: f3ew: i have channel logs, btw
(18:23:27) lkanies: i don’t think syslog is rich enough to be a sufficient logging format—i need a few more fields than syslog provides
(18:24:00) lkanies: i mean, sure, i could encode my data into syslog and then parse it back out, and i’ll support that (i already do), but why default to that?
(18:24:29) spike: so what would you suggest? patching third party app you want to plug-in to send xml-rpc stuff to ur server?
(18:25:09) spike: it’s a bit annoying, but can’t find any other solution. it’s not even easy to maintain the code at some degree, if they heavily change something for example
(18:25:45) lkanies: you mean to get other apps logging via the same system?
(18:26:04) lkanies: i’m not really that concerned about that part of the problem right now, since i’m more focused on just making puppet itself do what makes sense
(18:26:18) spike: yeah, sorry, talking of what I’m working one. I need puppet as nagios to send events to it
(18:26:30) spike: s/one/on/
(18:26:42) lkanies: i want to hook puppet up to the rest of the fabric whenever possible, but i’m willing to expend more effort to make puppet better
(18:26:50) lkanies: what do you mean by "events"?
(18:27:01) lkanies: nagios doesn’t really accept events, does it?
(18:27:50) spike: things appening that are considered worth to see, ie, traffic spike exceeding threshold X, or critical service going down (speaking of nagios)
(18:28:05) spike: nagios has got an Action thingie who gets event data on stdin
(18:28:29) spike: so u can actually plugin nagios into my thing simply coding an action that does the formatting and send the event to the xmlrpc server
(18:28:53) spike: same for munin. there things also for svn, to track commits and similar
(18:29:09) lkanies: ah
(18:29:29) lkanies: yeah, i already plan on creating an xmlrpc server to run on my nagios server, so i can "talk to" nagios
(18:29:44) lkanies: nagios is a PITA to connect to anything else, and i want to do things like generate its configs from remote systems
(18:30:10) lkanies: so, i’ll have an xmlrpc server, and clients will be able to connect to it and say, "please monitor X service on me"
(18:30:23) spike: oh, cool
(18:30:27) lkanies: "and here are the groups i’m in"
(18:30:31) lkanies: etc.
(18:31:07) lkanies: in other words, i’m already planning on wrapping a lot of nagios with my own stuff, so yeah, that’s probably what i would choose in this case
(18:34:43) lkanies: i’ve already used cfengine to generate my nagios configs (using naginator, https://reductivelabs.com/projects/naginator/)
(18:34:58) spike: yep, I remember that one
(18:35:11) spike: we had a sort of similar discussion in #cfengine some time ago
(18:35:13) lkanies: but it absolutely sucked generating the configs at the edge and then pushing them back up; so, i figure i’ll just pass that same info up, and generate them centrally
(18:35:15) lkanies: ah, right
(18:36:21) lkanies: ok, i better go help prepare for the holiday tomorrow
$Id: start.page 6 2006-07-02 20:05:14Z luke $