>> Today, me having to explictly model every chunk of my syslog.conf would
be massive overspecification. Tommorow, I have to explictly model every
chunk of my syslog.conf so that I can prove that I'm meeting my logging
conformance requirements to my auditors.
this is an excellent point. I've seen a lot of "I dont want to use [x]
because you don't flesh out [n]" and then "I don't want to use [x] because
there's too much emphasis on [n] which I dont use and dont want the
overhead". The problem with not providing all the details is someone
will say, I need to use this for [something you didn't think of that
requires a lot of odds and ends] - if you capture 90% of the
required data, you can solve 0% of their problem. When you do this for
one company, the odds are you can do a reasonable job of estimating what
those needs are, but you can never guess the needs of all other
unknown companies.
I'd like to see an extensible model that can be partially implemented,
based on your choice. So maybe syslog (for example) is a
drop-in module that you can choose to use or leave off if you don't want
it. A model element such as syslog could also exist in multiple modular
components, so you can implement a simple syslog model or an advanced
extension that gives you all the details, your choice. It should also be
easily extensible (by network guys), so that if a fully detailed syslog
model doesn't exist, you can define it and share it with the community.
So, one other thing that I'm trying to absorb from other posts - what are
the pros and cons for (1) let the network elements/devices specify the
model - which would be different for different devices/vendors, or (2)
make a general model into which all devices/vendors can be fit. I think
I'm reading some preferences one way or the other, but what is the logic
for one over the other? It seems to me that:
(1) is good because your model can be more explicit, less confusing,
probably easier to automate from; but is bad because you lose the ability
to do comparisons between different devices/vendors
(2) is good because you can do across the network
audits/comparisons/reporting, regardless of device type/vendor, but is bad
because you end up force-fitting some devices into your model, which
complicates automation for those devices down the road
On Wed, 13 Apr 2005, Andrew Fort wrote:
> On 4/13/05, Daniel Hagerty <hag@linnaean.org> wrote:
> > > A common point I've noticed in recent replies to this thread is "yeah
> > > so maybe we don't need to store/manage every last minute detail
> > > centrally. But, we need to know enough to _configure the network_".
> > > And that's the important point. We have to be able to configure it
> >
> > One of the evil details that shows up in this part, at least for
> > more generalized system administration, is that what is and is not
> > minute detail changes from day to day.
>
> Of course! I would therefore argue that complete specification is
> necessary if you have a requirement to meet changing requirements
> retrospectively. If your requirements are less formal (or less
> paranoid), you can probably do without it. What other problems am I
> missing?
>
> -andrew
>
>
Follow-Ups:
References:
|
|
