On Mon, 2012-05-21 at 11:01 -0400, Perry Myers wrote: > On 05/21/2012 10:43 AM, Mike Burns wrote: > > On Mon, 2012-05-21 at 10:29 -0400, Perry Myers wrote: > >> On 05/21/2012 09:30 AM, Andrew Cathrow wrote: > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "Mike Burns" <[email protected]> > >>>> To: "Andrew Cathrow" <[email protected]> > >>>> Cc: [email protected] > >>>> Sent: Monday, May 21, 2012 9:26:38 AM > >>>> Subject: Re: [node-devel] Using yum in Node > >>>> > >>>> On Mon, 2012-05-21 at 09:06 -0400, Andrew Cathrow wrote: > >>>>> > >>>>> ----- Original Message ----- > >>>>>> From: "Mike Burns" <[email protected]> > >>>>>> To: "Fabian Deutsch" <[email protected]> > >>>>>> Cc: [email protected] > >>>>>> Sent: Monday, May 21, 2012 8:56:27 AM > >>>>>> Subject: Re: [node-devel] Using yum in Node > >>>>>> > >>>>>> On Mon, 2012-05-21 at 09:50 +0200, Fabian Deutsch wrote: > >>>>>>> Hey, > >>>>>>> > >>>>>>> yum landed in node quite recently - not in the official build, > >>>>>>> but > >>>>>>> in > >>>>>>> gerrit [0]. > >>>>>>> It's somewhat tricky to get it working, I added a small section > >>>>>>> to > >>>>>>> the > >>>>>>> Node troubleshooting wiki page [1] to give other a better > >>>>>>> start. > >>>>>> > >>>>>> Just for clarity, this is being done to support plugins. It will > >>>>>> only > >>>>>> be supported offline when using the edit-node functionality. > >>>>>> > >>>>> > >>>>> Obviously the reason for this is not for users to have yum > >>>>> available for use on the node when it's deployed but it's going to > >>>>> cause confusion with users that they have utilities like yum and > >>>>> rpm and can't use them, or if they try to things fail in strange > >>>>> ways. > >>>>> > >>>>> If we don't want or support runtime use of rpm and yum then having > >>>>> them in the node and available to be called is asking for trouble. > >>>>> Having docs that explain why it failed and why they shouldn't be > >>>>> doing it isn't enough. > >>>> > >>>> The plan to mitigate this issue is that the yum binary will be > >>>> relocated > >>>> to either a non-standard place that isn't in the path (/usr/libexec) > >>>> or > >>>> renamed to something else non-standard (ovirt-yum or something). > >>>> The /usr/bin/yum executable will instead print a message/warning to > >>>> the > >>>> user that says the running yum in unsupported on a running host. The > >>>> offline edit-node process will call the renamed or relocated yum > >>>> script > >>>> correctly. > >>> > >>> Great. > >> > >> We could also solve this (and many other issues around folks trying to > >> do things in oVirt Node that should not be done) by making it harder to > >> get a shell. > >> > >> Doing things like disabling root ssh access completely (which is > >> presently only blocked by vdsm needing to use root ssh for registration) > >> and making the admin shell harder to enter would further enforce the > >> firmware like nature of oVirt Node > > > > Balancing this with the ability to debug issues when they come up is a > > tricky thing though. Perhaps a debug flag to enable/disable the ability > > to drop to a shell > > I was thinking more along the lines of drop to shell from Admin TUI user > account drops to 'admin' user vs. 'root' user. And then we could have > very selected subset of commands that will work via tightly controlled > sudoers configuration vs. giving root access.
We'd probably want to get the TUI itself to run as admin then. It runs as root currently. I guess we could keep the TUI running as root, but spawn a shell as admin. Not something that will be done in the short term regardless, though. renaming/moving will have to suffice for now. Mike _______________________________________________ node-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/node-devel
