Garrett D'Amore wrote:

> Bart Smaalders wrote:
>> Garrett D'Amore wrote:
>>
>>
>> Simply stopping the addition of open source software to Solaris
>> in order to meet auditing requirements for /etc files (which we
>> don't meet anyway w/ the stuff we've shipped for years) seems
>> ludicrous.
> 
> I don't think you understand what "derailing" means.  It means that
> the case gets a regular review, because it failed the "obviousness"
> test required for a fast track.
> 
> It does *not* mean that you can't ship the software.  Please don't
> assume that derailing is an automatic failure.
> 

I can assure you I know exactly how and why cases get derailed; it happens
for a wide variety of reasons - some good, some bad.

Derailing every open source putback because it introduces a configuration
file w/o an corresponding administrative tool is the ARC's equivalent of a
work slowdown.  Every time it happens, we spend a few thousand dollars
of Sun's and the community's money/time to no good purpose other than 
theatrics.

Since management has made it clear (by not assigning people to work on
the problem) that writing command line interfaces (eg custom editors) for
every config file in /etc is not a priority for them (and community 
developers
aren't exactly stampeding to follow the ARC's leadership here) for the ARC
to needlessly delay (or cause to be abandoned) every project that ships
such an interface makes no sense at all.

> That said, it may be that just a few too many FOSS projects have come
> our way indicating that because the architecture is good enough for
> Linux, it ought to be good enough for us.

Like it or now, we don't write all the software that's in Solaris.  We 
never have,
and never will.  If we have legitimate needs for auditing config file 
changes,
then let's figure out how to do that in such a way that we don't end up
making every project design and implement custom commands to do so.

> 
> While for any given project this may or may not be true, if we're
> going to abdicate all of our engineering elsewhere, then we ought to
> just close up shop and stop trying to pretend that we are exercising
> even a little control over the whole system, or have any kind of high
> level architectural vision beyond "copy Linux".
> 

> FWIW, I don't disagree that we have a half-baked solution for
> auditing administration.  Far far too many configuration files are
> used where an administrative tool would provide audit (and RBAC!)
> support.
> 
> Yes, there are lots of clever solutions around this problem...
> 
> Anyway, I don't make the rules.  If you want to appeal the policy,
> that's fine, just don't expect to be able to do so in the context of
> a fast-track.

You really don't get it.

We cannot spend the time to write custom commands to edit every
config file for every piece of open source software on the planet.

If you want auditing and RBAC, figure out a way to do so that doesn't
place so heavy a tax on every project that wants to deliver on Solaris.
Rewriting or adding commands to every project is not acceptable -
and is pointless so long as we don't even fund command line interfaces
for all the config files Sun has introduced over the years.

> On an aside, I think it is a total shame that we're completely 
> abdicating everything about Solaris architecture to Linux or other FOSS 
> projects.  If that is the way forward, then perhaps ARC ought to just 
> disband.

If that's how you feel, you know how to do your part. Seriously, there are
very useful roles for the ARC; enforcing ill-considered policies like the
Auditing requirement is NOT one of them.,

- Bart

-- 
Bart Smaalders                  Solaris Kernel Performance
barts at cyber.eng.sun.com              http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."

Reply via email to