Alan,
> Gary Winiger wrote:
> > > > > > * 20 Questions states that ndmpd can be started manually
> > > > > > from a shell. Why should this be? Isn't it an SMF service?
> > > > > > What's wrong with svcadm enable svc:/system/ndmpd ?
> > > > >
> > > > > When the NDMP service is managed via SMF, it will support both
> > > > > backup and restore operations but the team believes that there
> > > > > is a benefit in providing profiles to allow sites to assign
> > > > > backup or restore roles separately to users, with provision
> > > > > to allow those users to manage (start, stop etc) the service.
> > > > > The attached document provides definitions and an example.
> > > >
> > > > Hummm, I agree that "operators" should be able to backup,
> > > > but not necessarially restore, while "system admins" should
> > > > be able to do both. Rather than the existing proposal which
> > > > mixes together SMF and pfexec, consider a purely SMF proposal.
> > > > Have different service instances.
> > >
> > > This was the approach originally being pursued but we ran into
> > > some limitations of the SMF implementation and changed tack.
> > > IIRC, the challenge was how to enforce that SMF would only
> > > allow one instance (of the three defined) to run at any time.
> > > We assumed that this was the purpose of the single instance
> > > flag but it didn't appear to work the way we anticipated.
> >
> > Talking with a member of the SMF team, indeed they
> > say that is what the single instance statement means.
> > Unfortunately there seem to be no implementation behind
> > the statement. However, it was suggested that there could
> > be a way to do this. Please consult smf-discuss at opensolaris.org.
> >
> > Let's not give up yet. IMO, this is the way in which the
> > SMF/RBAC subsystem is intended to be use.
>
> One suggestion has been to use a property to define the ndmpd
> role (backup, restore, backup and restore), with the appropriate
> authorization requireed to change the property, but I can't
> put any more onto this project.
Perhaps I'm being obtuse. I don't understand what you're saying
here. My point is to get the architecture correct, not to add
stuff to the project. What is the architecture? Is there
a spec update in the plan? It's always good to have the final
spec recorded so we're all on the same page.
> > > > One for backup and restore
> > > > and one for backup only. Or maybe one for backup, one for
> > > > restore and one that does both. Their enabling/disabling
> > > > could be completely authorization driven.
> > > > solaris.smf.manage.ndmp (for both), solaris.smf.manage.ndmp.backup
> > > > (for only backup), and if a separate restore makes sense,
> > > > solaris.smf.manage.ndmp.restore.
> > > > Note that authorizations are hierarical so manage.ndmp includes
> > > > backup and restore (above ;-).
> > >
> > > As there is no explicit requirement for separate backup/restore
> > > roles at this time, I am going to defer this feature. We will
> > > deliver a single service that supports backup and restore using
> > > the pure SMF implementation suggested.
> >
> > I beg to differ. The RBAC evaluation requirements are for
> > separation of services. And the default shipping system
> > has separate Media Backup and Media Restore Rights Profiles.
>
> Sorry, I should clarify, the implementation will still have
> three profiles: NDMP Backup, NDMP Restore and NDMP Management:
>
> NDMP Management will be the profile for managing the SMF
> service (start/stop/refresh) and property values.
>
> NDMP Backup will be added to Media Backup
> NDMP Restore will be added to Media Restore
Perhaps I'm missing something. It would seem that just adding
the ndmp backup authorization to Media Backup (and restore to
Media Restore) would be sufficient. Perhaps the project team
envisions that granting NDMP Backup independently of Media Backup.
So, I guess it's OK to have the profiles with just the one
authorization in each.
Gary..
