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

2012-06-06 Thread 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


On Jun 6, 2012, at 6:39 PM, "rhn-satell...@epperson.homelinux.net" 
 wrote:

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


___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel


Re: [Spacewalk-devel] Deployment of images built with SUSE Studio

2012-06-06 Thread Johannes Renner
On 06/04/2012 08:47 PM, Miroslav Suchy wrote:
>> So here is the latest version of the patches.
> 
> Committed (with some white space and check style fixes). Thanks for 
> contribution.

Thank you very much, here is already a first follow up patch:

Replace "default" string with the new constant RhnHelper.DEFAULT_FORWARD,
just for being consistent with recent changes here.

Regards,
Johannes

-- 
SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg)
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
>From d3fe367991d13c85b83e5a821688d4c32db5f248 Mon Sep 17 00:00:00 2001
From: Johannes Renner 
Date: Wed, 6 Jun 2012 15:27:35 +0200
Subject: [PATCH] Refactor "default" to RhnHelper.DEFAULT_FORWARD

---
 .../images/ScheduleImageDeploymentAction.java  |3 ++-
 .../action/user/UserCredentialsDeleteAction.java   |3 ++-
 .../action/user/UserCredentialsEditAction.java |3 ++-
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/java/code/src/com/redhat/rhn/frontend/action/systems/images/ScheduleImageDeploymentAction.java b/java/code/src/com/redhat/rhn/frontend/action/systems/images/ScheduleImageDeploymentAction.java
index 117f949..a3a9491 100644
--- a/java/code/src/com/redhat/rhn/frontend/action/systems/images/ScheduleImageDeploymentAction.java
+++ b/java/code/src/com/redhat/rhn/frontend/action/systems/images/ScheduleImageDeploymentAction.java
@@ -34,6 +34,7 @@ import com.redhat.rhn.domain.user.User;
 import com.redhat.rhn.frontend.action.renderers.ImagesRenderer;
 import com.redhat.rhn.frontend.struts.RequestContext;
 import com.redhat.rhn.frontend.struts.RhnAction;
+import com.redhat.rhn.frontend.struts.RhnHelper;
 import com.redhat.rhn.frontend.taglibs.list.ListTagHelper;
 import com.redhat.rhn.manager.action.ActionManager;
 import com.redhat.rhn.manager.system.SystemManager;
@@ -115,7 +116,7 @@ public class ScheduleImageDeploymentAction extends RhnAction {
 request.getRequestURI());
 }
 // Find the default destination
-forward = actionMapping.findForward("default");
+forward = actionMapping.findForward(RhnHelper.DEFAULT_FORWARD);
 }
 return forward;
 }
diff --git a/java/code/src/com/redhat/rhn/frontend/action/user/UserCredentialsDeleteAction.java b/java/code/src/com/redhat/rhn/frontend/action/user/UserCredentialsDeleteAction.java
index 7dcacef..431a2f1 100644
--- a/java/code/src/com/redhat/rhn/frontend/action/user/UserCredentialsDeleteAction.java
+++ b/java/code/src/com/redhat/rhn/frontend/action/user/UserCredentialsDeleteAction.java
@@ -28,6 +28,7 @@ import com.redhat.rhn.domain.credentials.CredentialsFactory;
 import com.redhat.rhn.domain.user.User;
 import com.redhat.rhn.frontend.struts.RequestContext;
 import com.redhat.rhn.frontend.struts.RhnAction;
+import com.redhat.rhn.frontend.struts.RhnHelper;
 
 /**
  * Delete credentials for external systems or APIs.
@@ -61,6 +62,6 @@ public class UserCredentialsDeleteAction extends RhnAction {
 getStrutsDelegate().saveMessages(request, messages);
 return mapping.findForward("success");
 }
-return mapping.findForward("default");
+return mapping.findForward(RhnHelper.DEFAULT_FORWARD);
 }
 }
diff --git a/java/code/src/com/redhat/rhn/frontend/action/user/UserCredentialsEditAction.java b/java/code/src/com/redhat/rhn/frontend/action/user/UserCredentialsEditAction.java
index 6473985..8048eb1 100644
--- a/java/code/src/com/redhat/rhn/frontend/action/user/UserCredentialsEditAction.java
+++ b/java/code/src/com/redhat/rhn/frontend/action/user/UserCredentialsEditAction.java
@@ -29,6 +29,7 @@ import com.redhat.rhn.domain.credentials.CredentialsFactory;
 import com.redhat.rhn.domain.user.User;
 import com.redhat.rhn.frontend.struts.RequestContext;
 import com.redhat.rhn.frontend.struts.RhnAction;
+import com.redhat.rhn.frontend.struts.RhnHelper;
 
 /**
  * Create and edit credentials for external systems or APIs.
@@ -93,6 +94,6 @@ public class UserCredentialsEditAction extends RhnAction {
 request.setAttribute(ATTRIB_CREDS, newCreds);
 }
 }
-return mapping.findForward("default");
+return mapping.findForward(RhnHelper.DEFAULT_FORWARD);
 }
 }
-- 
1.7.7

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel

[Spacewalk-devel] The Spacewalk nightly now builds for Fedora 17 instead of 15

2012-06-06 Thread Jan Pazdziora

The Spacewalk nightly now builds for Fedora 17. New yum repos will
be available in a couple of days.

At the same time, I've stopped Fedora 15 builds and the Fedora 15
nightly yum repos will be removed in a couple of days.

-- 
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel