"Garrett D'Amore" wrote:
> I am not sure you've answered the question here. Mostly I'm concerned
> about the possibility of leaving persistent "turds" in the filesystem,
> where they may be harder to find.
>
> I'd be a lot happier if these incremental files were located in /var/run
> or some
Margot Miller wrote:
> All,
>
> Let's try to get the focus back to the open issues.
>
> It looks like the outstanding issues are now:
>
> - How does Solaris auditable policy interact with star/rmt?
I cannot answer that.
> - What happens if the system crashes during an incremental
> star? Ar
Darren J Moffat wrote:
> > I am not sure what you understand by auditing in this context. rmt allows
> > you
> > to define which user from which host may access which files. There is no
> > similar other feature on OpenSolaris.
>
> http://opensolaris.org/os/community/arc/policies/audit-policy/
Garrett D'Amore wrote:
>>> - What happens if the system crashes during an incremental
>>> star? Are these files automatically cleaned up on reboot?
>>>
>>
>> ufsrestore exists since 27 years. I am not aware that somebody
>> asked for a similar feature for the case that the kernel crashes
>
Joerg Schilling wrote:
> Margot Miller wrote:
>
>
>> All,
>>
>> Let's try to get the focus back to the open issues.
>>
>> It looks like the outstanding issues are now:
>>
>> - How does Solaris auditable policy interact with star/rmt?
>>
>
> I cannot answer that.
>
If this rmt is to re
"Garrett D'Amore" wrote:
> > Similarly the existing ON rmt program does not do any audit so
> > replacing it with the rmt from star should not be required to do any
> > auditing either.
>
> I *strongly* disagree with this one. Joerg's /etc/rmt makes
> authorization/access control decisions ba
Joerg Schilling wrote:
> "Garrett D'Amore" wrote:
>
>>> Similarly the existing ON rmt program does not do any audit so
>>> replacing it with the rmt from star should not be required to do any
>>> auditing either.
>> I *strongly* disagree with this one. Joerg's /etc/rmt makes
>> authorization/
Garrett D'Amore wrote:
>> Similarly the existing ON rmt program does not do any audit so
>> replacing it with the rmt from star should not be required to do any
>> auditing either.
>
> I *strongly* disagree with this one. Joerg's /etc/rmt makes
> authorization/access control decisions based on
All,
Let's try to get the focus back to the open issues.
It looks like the outstanding issues are now:
- How does Solaris auditable policy interact with star/rmt?
- What happens if the system crashes during an incremental
star? Are these files automatically cleaned up on reboot?
Margot
M
Margot Miller wrote:
> - If no objections, will not move configuration files into SMF
I have no objection to this either in this case or in a future case
where star is replacing the existing tar.
> - Project delivered via SFW consolidation
C-Team note: This creates a cross consolidation fla
Darren J Moffat wrote:
> Margot Miller wrote:
>
>> - If no objections, will not move configuration files into SMF
>
> I have no objection to this either in this case or in a future case
> where star is replacing the existing tar.
>
>> - Project delivered via SFW consolidation
>
> C-Team note: T
Below is the revised spec for star and rmt integration. The timer has been
reset to MARCH 20th. Seeking minor binding.
Have tried to summarize the issues. If I have left your issue off the list,
please respond to this email with it.
Closed issues:
- Will not provide /usr/include/schilly header
12 matches
Mail list logo
