[Spacewalk-list] how to block yum usage on client systems

[Musayev, Ilya]

My issues is identical to yours.

I'm afraid to give users YUM access as they will begin Installing stuff left and right, bypassing the other system we use for package deployment - HP SA (aka Opsware).

Here is how I'm thinking of addressing it. If devel folks can chime in, i would appreciate it. I would need to download yum source and do either one of three:


Create a plugin for yum that will check if host is locked in spacewalk, if it is, don't do any yum operations.

OR 

Modify the RHN plugin for YUM

OR

Easiest but not the cleanest, get yum source code, add a function to check if host is locked in spacewalk via API (pre-main), if it is, exit, if not, proceed.

OR 

Totally ghetto approach which will take few hours atmost, create a bash wrapper script for YUM that will check if host is locked via spacewalk API(tiny bit of python involved), if yes, exit. If not, pass all arguments and execute real yum executable.

My python skills are still in it's early ages, if someone can lend a hand, I would appreciate it. If not, I will write what I can - albeit it will stand out from the rest of the code.
 

Any input is appreciated,

Thanks
Ilya
-----Original Message-----
From: spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-bounces at redhat.com] On Behalf Of rhn-satellite at epperson.homelinux.net
Sent: Wednesday, June 06, 2012 6:35 PM
To: spacewalk-list at redhat.com
Subject: Re: [Spacewalk-list] how to block yum usage on client systems

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
Spacewalk-list at redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-list