On Wed, June 6, 2012 16:17, Brian Collins wrote: >> Thanks Mirek, >> >> Any other options? >> >> Unfortunately it is root. > [] > > What are you trying to accomplish? Anyone who logs in as root already has > enough power to do plenty of damage. If you are managing clients through > spacewalk, you can deny them access to packages you don't want them to > have. And while root can circumvent that through creative means, it would > be troublesome for them to do so. >
Don't know about OP's situation, but ours is that we have clone channels with only security errata in them as far as errata go, but have to have up to date packages so the errata package dependencies can be satisfied. That also permits updating selected packages (or all) for a system without changing base channel for the system. We have SLAs that require application of security errata, but in general we do not otherwise update systems because of the risk of breaking something in the customer application layers (yes, a security erratum could also do that, but we're exempt from the SLA in that circumstance). It's not practical to blacklist lists of packages, but it's desirable not to have exposure of someone doing a full yum update without understanding the consequences. We have policy against it, and said "someone" could get fired, but we'd still be on the hook for a severity 1 or 2 incident. _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
