Brian Utterback wrote:
>
>
> James Carlson wrote:
>
>> Creating a separate tiny root package allows the owner of a system
>> with writable RBAC files but without a writable '/usr' to install the
>> necessary bits to make this feature work. If it's done as you're
>> suggesting, as a single 'usr'
James Carlson wrote:
> Darren J Moffat writes:
>> James Carlson wrote:
>>> I think it's a bit of teak polishing. Either will work fine, neither
>>> appears to me to have architectural significance, and if the project
>>> and/or consolidation team have a preference, go for that.
>> I think this doe
James Carlson wrote:
> Darren J Moffat writes:
>>> So, do I take the lack of further comment as assent? Is the plan to
>>> simply add a line to exec_attr and forgo the *r package?
>> That is my strong preference but it seems no other ARC members are
>> either listening or have an opinion on this
The case was approved with only a single package and separate
integration into ON. Does anybody care enough to want to re-open the
case, or are we really just talking about getting IPS guidance for the
future?
Nicolas Williams wrote:
> [Good points about splitting pkgs vs. spanning consolidatio
I care enough to want to see the root package added to this case.
-Norm
Brian Utterback wrote:
> The case was approved with only a single package and separate
> integration into ON. Does anybody care enough to want to re-open the
> case, or are we really just talking about getting IPS guida
Brian Utterback wrote:
>
>
> Darren J Moffat wrote:
>
>> I'd like to hear from other ARC members on this but I feel that
>> introducing a root package just for updating exec_attr is wasteful,
>> even though it does mean putbacks to two consolidations.
>>
>
> So, do I take the lack of further
[Good points about splitting pkgs vs. spanning consolidations elided.]
Perhaps the best answer is: do as always until IPS is delivered and SVR4
packaging dead. "As always" here would probably be the c-team's
preference. The root pkg name should probably be Volatile.
Nico
--
Garrett D'Amore wrote:
> I doubt anyone cares enough to reopen the case. The details of this
> issue (particularly whether the rbac is delivered as a separate root
> package or as part of a stock ON package) IMO fall below the threshold
> of ARC review.
Specifically, it is up to Brian and his
Norm Jacobs wrote:
> orphaning that may occur. There are several components in SFW that
> already deliver root packages with RBAC entries.
But only one (SUNWmkcdr) delivers nothing else. What do you see as the
problem here?
--
blu
There are two rules in life:
Rule 1- Don't tell people eve
This case was approved in today's PSARC meeting.
Brian Utterback wrote:
> I am sponsoring the following fast-track for Martina Tomisova. This case
> proposes to integrate the ngrep open-source utility into the SFW
> consolidation.
> A patch binding is requested.
>
> Template Version: @(#)sac_ne
Brian Utterback wrote:
> The case was approved with only a single package and separate
> integration into ON. Does anybody care enough to want to re-open the
> case, or are we really just talking about getting IPS guidance for the
> future?
I doubt anyone cares enough to reopen the case. The d
Brian Utterback wrote:
>
>
> Norm Jacobs wrote:
>
>> orphaning that may occur. There are several components in SFW that
>> already deliver root packages with RBAC entries.
>
> But only one (SUNWmkcdr) delivers nothing else. What do you see as the
> problem here?
>
In this particular case, I doub
Darren J Moffat wrote:
> Brian Utterback wrote:
>>
>>
>> James Carlson wrote:
>>
>>> Creating a separate tiny root package allows the owner of a system
>>> with writable RBAC files but without a writable '/usr' to install the
>>> necessary bits to make this feature work. If it's done as you're
>>>
Norm Jacobs wrote:
> Brian Utterback wrote:
>>
>>
>> Norm Jacobs wrote:
>>
>>> orphaning that may occur. There are several components in SFW that
>>> already deliver root packages with RBAC entries.
>>
>> But only one (SUNWmkcdr) delivers nothing else. What do you see as
>> the problem here?
>>
James Carlson wrote:
> so I don't see what the extended discussion and
> appeal to other members to comment is about.
>
As I said, violent agreement. I was just trying to make sure there
weren't any unresolved conflicts, and there weren't.
--
blu
There are two rules in life:
Rule 1- Don't t
Darren J Moffat writes:
> What I suggested is that the exec_attr entry be intgrated into the
> master exec_attr file in ON $SRC/lib/libsecdb/exec_attr.txt. That file
> is delivered from an ON root package.
Ah, ok. In that case, it's truly six of one and half dozen of
another.
You're talking a
James Carlson wrote:
> Creating a separate tiny root package allows the owner of a system
> with writable RBAC files but without a writable '/usr' to install the
> necessary bits to make this feature work. If it's done as you're
> suggesting, as a single 'usr' type package with a postinstall, t
Darren J Moffat writes:
> James Carlson wrote:
> > I think it's a bit of teak polishing. Either will work fine, neither
> > appears to me to have architectural significance, and if the project
> > and/or consolidation team have a preference, go for that.
>
> I think this does have architectural s
Okay, so Jim says either is fine, and you say one is better. So, as
far as this case is concerned, the project team will do it your way,
and you and Jim can be in violent agreement.
Darren J Moffat wrote:
> James Carlson wrote:
>> Darren J Moffat writes:
So, do I take the lack of further co
Darren J Moffat writes:
> > So, do I take the lack of further comment as assent? Is the plan to
> > simply add a line to exec_attr and forgo the *r package?
>
> That is my strong preference but it seems no other ARC members are
> either listening or have an opinion on this that they wish to shar
Darren J Moffat wrote:
> I'd like to hear from other ARC members on this but I feel that
> introducing a root package just for updating exec_attr is wasteful, even
> though it does mean putbacks to two consolidations.
>
So, do I take the lack of further comment as assent? Is the plan to
sim
> As I said, violent agreement. I was just trying to make sure there
> weren't any unresolved conflicts, and there weren't.
Jumping in late and probably missing some important mail, but
Documented best practice (pre IPS -- which really doesn't exist
yet from an ARC pe
Martina Tomisova wrote:
> Hi Nicolas,
>
>> That can't be right, can it?
> It seems it can. I'm integrating the package into the Nevada so as I'm
> informed it has nothing to do with IPS team and Indiana. And Nevada SFW
> gatekeepers recommended me to use the class action script.
However the ARC
Hi Nicolas,
> That can't be right, can it?
It seems it can. I'm integrating the package into the Nevada so as I'm
informed it has nothing to do with IPS team and Indiana. And Nevada SFW
gatekeepers recommended me to use the class action script.
Have a nice day,
Martina
Hi Darren,
there was a quite long discussion (see attachment) with Norm Jacobs and
Mike Sullivan about this topic. The final recommendation for me was to
user class action script.
(The first recommendation was the same as you recommend to me from
sustaining gatekeepers. Then I've received the
Hi,
I'm sorry for the late correction. I have to create the root package for
the ngrep too (because of RBAC) so the exported interface has to change
from:
> Exported Interfaces:
>
> SUNWngrep Uncommitted Package name
> /usr/sbin/ngrepCommitted
Martina Tomisova wrote:
> Hi,
>
> I'm sorry for the late correction. I have to create the root package for
> the ngrep too (because of RBAC) so the exported interface has to change
> from:
I recommend you don't do this but instead just integrate the one line
change to the master exec_attr.txt
On Fri, Sep 05, 2008 at 02:11:36PM +0200, Martina Tomisova wrote:
> Hi Darren,
>
> there was a quite long discussion (see attachment) with Norm Jacobs and
> Mike Sullivan about this topic. The final recommendation for me was to
> user class action script.
That can't be right, can it?
Of course
Martina Tomisova writes:
> > For those who haven't used ngrep (and for the larger picture), what's
> > the difference between this utility and tshark or snoop? What does it
> > do that those things don't do, or when might you choose to use one
> > over the other?
> >
> > A quick read through the
SFW, it was a misunderstanding.
On 09/04/08 16:36, Don Cragun wrote:
>>From blu at sac.sfbay.sun.com Thu Sep 4 05:03:19 2008
>> I am sponsoring the following fast-track for Martina Tomisova. This case
>> proposes to integrate the ngrep open-source utility into the ON
>> consolidation.
>> A patc
> For those who haven't used ngrep (and for the larger picture), what's
> the difference between this utility and tshark or snoop? What does it
> do that those things don't do, or when might you choose to use one
> over the other?
>
> A quick read through the documentation makes it look mostly eq
I'm going to integrate it into the SFW.
On 09/04/08 15:20, James Carlson wrote:
> Brian Utterback writes:
>>
>> James Carlson wrote:
>>> Brian Utterback writes:
Imported Interfaces:
SUNWlibpcapLibraries (libpcap.so)
>>> "Libraries" isn't a stability level. Any idea
My mistake. I wrote down ON in the proposal. I'll update the proposal
in the case dir.
Martina Tomisova wrote:
> I'm going to integrate it into the SFW.
>
> On 09/04/08 15:20, James Carlson wrote:
>> Brian Utterback writes:
>>>
>>> James Carlson wrote:
Brian Utterback writes:
> Imported
Brian Utterback writes:
>
>
> James Carlson wrote:
> > Brian Utterback writes:
> >> Imported Interfaces:
> >>
> >> SUNWlibpcapLibraries (libpcap.so)
> >
> > "Libraries" isn't a stability level. Any idea where this is coming
> > from or what stability it has?
>
> This was delive
James Carlson wrote:
> Brian Utterback writes:
>> Imported Interfaces:
>>
>> SUNWlibpcapLibraries (libpcap.so)
>
> "Libraries" isn't a stability level. Any idea where this is coming
> from or what stability it has?
This was delivered into sfwnv_93 via PSARC 2008/288. Stability
Brian Utterback writes:
> Imported Interfaces:
>
> SUNWlibpcapLibraries (libpcap.so)
"Libraries" isn't a stability level. Any idea where this is coming
from or what stability it has?
For those who haven't used ngrep (and for the larger picture), what's
the difference between thi
>From blu at sac.sfbay.sun.com Thu Sep 4 05:03:19 2008
>
>I am sponsoring the following fast-track for Martina Tomisova. This case
>proposes to integrate the ngrep open-source utility into the ON consolidation.
>A patch binding is requested.
>
>From Martina.Tomisova at sun.com Thu Sep 4 07:24:3
I am sponsoring the following fast-track for Martina Tomisova. This case
proposes to integrate the ngrep open-source utility into the ON consolidation.
A patch binding is requested.
Template Version: @(#)sac_nextcase %I% %G% SMI
This information is Copyright 2008 Sun Microsystems
1. Introduction
38 matches
Mail list logo
