On Thu, Apr 24, 2008 at 03:59:26PM +0100, Daniel P. Berrange wrote:
> I'd just like to see if have an impl for Solaris - whether you happen to
> use it or not, is separate issue. Some people may be taking libvirt
Fair enough.
> > When there's genuine configuration values that users need for something
> > enabled on Solaris, it will be in SMF anyway, so will need re-working on
> > the config backend in libvirt.
>
> So you're not making use of any of the remote management features like
> TLS and SASL/Kerberos ? I'd think at least users need the config to switch
> between which auth scheme they'd like to use, because the choice of TLS
> vs Kerberos is really a deployment question for admins.
Today, we're not. When we do, as I said, we'll need libvirt changes to
understand SMF configuration instead of the config file, so we'll have
to fix up things there.
> > > > +int
> > > > +xenHavePrivilege()
> > > > +{
> > > > +#ifdef __sun
> > > > + return priv_ineffect (PRIV_XVM_CONTROL);
> > > > +#else
> > > > + return getuid () == 0;
> > > > +#endif
> > > > +}
> > >
> > > As mentioned earlier, we probably want to move this into the util.c file
> > > and have the privilege name passed in as a parameter.
> >
> > Could you explain further how you see this working?
>
> Something like
>
> int virHavePrivilege(const char *);
>
> Pass in PRIV_XEN_CONTROL, and on Solaris have that check with your
> prvilege code, and on Linux just have it ignore the param and check
> the UID. It is likely we'll do more fine grained checks based on
> named privileges on Linux too
I'm not sure I like this. It's pushing out a Solaris-specific detail
("PRIV_XVM_CONTROL") to every user. Furthermore, I'm not sure about it
being generic either: PRIV_XVM_CONTROL wouldn't apply to qemu on
Solaris, or zones, or whatever.
> > This just adds a whole bunch of extra code to no clear advantage?
>
> There's no extra code because virsh console already exists and isn't
> going away because it offers a superset of what xenconsole does, by
> virtue of being portable
Sure there is:
- code to spawn and run virt-console
- all the current virsh console code in virt-console
- the least-priv implementation in virt-console, duplicating xenconsole
Note the latter is going to be Xen-specific (indeed, Xen on Solaris
specific). There's no way I can avoid that.
Anyway, if you're set on this, I'm not entirely averse to it, I'm just
not sure I see the point.
regards,
john
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list