As to the 'user vs root' apps. If you want this behavior, then compile the graphical yum so it will only take a url as the conf location. Or just compile the url into it. That url naturally being under the control of wiser, more experienced admins. Some nice ideas here. ------------------------------------------------------------------------ Jim Wildman, CISSP, RHCE jim@xxxxxxxxxxxxx http://www.rossberry.com On Wed, 5 Mar 2003, Robert G. Brown wrote: > On Wed, 5 Mar 2003, Troy Dawson wrote: > > > Howdy, > > First off, I've put the latest daily release into our contrib repository > > so that our users can test it more. We'll let you know if anyone finds > > a bug. > > > > Just out of curiousity, has anyone done any work on some type of > > graphical interface for yum? > > I'm not saying it really needs one, it works great by text alone, but > > being a person who does alot of graphics, I was just wondering. > > This is actually a lovely thing to have, once yum really stabilizes in > its features and API. With glade and perl-gtk is is pretty simple to > whomp up a GUI that fronts almost any command line tool. As of ten > seconds ago, our local version of glade doesn't have a python-gtk > interface (if any such thing even exists) so I don't know that it can be > easily done native in python. > > Why would it be lovely to have? Because there is an enormous class of > users that would like to be able to add and delete packages from their > personal desktop workstations, and who are relatively ignorant of how to > do things at the command line. Ex-windows users, for example, get very > poofy if they don't have a mouseful interface to something they want to > do, because doing it from the command line means they have to RTFM and > actuall learn something. > > This isn't worth critiquing as a desirable or evil behavior, it just is. > And truly, for various classes of relatively simple task, a GUI can > encapsulate and hide much of the manual, so a user DOESN'T have to read > it. This is how e.g. xmms and related tools work -- one doesn't read a > manual to figure out how to select songs to play, one just clicks on a > selection tool that works about the way you'd expect a selection tool to > work. > > There are definitely going to be users for whom a selection tool is the > preferred interface. A gui which called yum list as it initialized, > splitting installed and available into two windows, and let one install > or uninstall by highlighting entries in one list or the other and > clicking a button wouldn't be a horrible thing, ESPECIALLY IF there was > an auxiliary window in which the package description automagically > appeared as the selection was clicked or the mouse hovered over it for a > while. > > Such a gui needn't be full featured -- yum's "power features" are mostly > for sysadmins and scripting, and of little use to a user. The basic > list, install, uninstall, though, would be lovely, as would an "update" > button, and perhaps buttons for a few other common user operations, if > anyone can think of any. > > Problems that I can think of: > > a) root access, of course. I say user, but naturally the user has to > have root privileges to install. Thus there are suid (Evil!), su, and > sudo paths to root to consider. For true user workstations (student > systems in the dorms) you'd likely want the gui to just prompt them for > the root password when they crank it up and then run as root thereafter. > > b) It makes it easy for a user to break the hell out of their system. > Not FUNDAMENTALLY any easier than yum itself, but the possibility of > accidentally removing (e.g.) procps because of mouse error. > > c) It would have to resolve dependency conflicts in a sane way. The > GUI would have to be able to point out to silly beanie users that > removing glibc is likely to be an unbelievably destructive thing to do > even if they "plan to put back a new one" in a moment. > > d) This in turn creates a really interesting question: is it possible > to tag packages as "root" controlled vs "user" controlled, and permit > the gui only to mess with "user" controlled (basically userspace) > applications? Is it further possible to permit access to the user > portion (only) with e.g. sudo? This question really applies to yum as > well as the GUI. > > For example, even in a managed LAN environment it is pretty reasonable > to permit users to add and remove certain components to their > workstation. It is just insanely dangerous to let them add or remove > ARBITRARY components. Maybe they just don't use kword and would like to > remove it. Maybe they want xine, but their sysadmin didn't install it > on standard desktops (although it is available to yum in the > installation archives). Or perhaps they want octave, or mathematica, or > any of a hundred packages that just do one thing with little dependency > and are completely optional according to the whim of a user. > > IF one could identify all the packages in the archive that are in that > general category, AND identify a way for the workstation owner to be > able to install those packages (only), but never any of the base/root > packages that might break the system, that might be a useful thing. > > I'd say that this is a generally low priority, though. It would > definitely increase the amount of metadata associated with each package, > and would require an additional stage of LAN level setup. One > presumably would make back the time this took by being able to tell > users once how to install and remove optional packages on their own > instead of having to process their administrative requests one at a time > for them. > > The list of restricted/permitted packages would need to be LAN local and > not global, as different LANs might require different tools to be > present (no you can NOT remove KDE in our environment, but you CAN > remove KDE in their environment, you CAN add pvm here, but you can NOT > add it there). > > Then there is the root thing and security -- how to permit a general > user to run e.g. yum install pvm (which definitely installs in > root-controlled /usr) without the root password, while NOT allowing them > to hack it so that yum gets pvm from their own private RPM (where "pvm" > is an suid root shell) and NOT allowing them to remove the kernel, libc, > or any other "critical" or protected component. Obviously a bit of a > chore, here. > > rgb > > > > > Troy > > > > _______________________________________________ > > Yum mailing list > > Yum@xxxxxxxxxxxxxxxxxxxx > > https://lists.dulug.duke.edu/mailman/listinfo/yum > > > > Robert G. Brown http://www.phy.duke.edu/~rgb/ > Duke University Dept. of Physics, Box 90305 > Durham, N.C. 27708-0305 > Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@xxxxxxxxxxxx > > > > _______________________________________________ > Yum mailing list > Yum@xxxxxxxxxxxxxxxxxxxx > https://lists.dulug.duke.edu/mailman/listinfo/yum >
