Re: [Spacewalk-devel] erratas and the client plugin package action

2011-10-19 Thread Simon Lukasik
On 10/18/2011 08:43 PM, Miroslav Suchy wrote:
 Dne 18.10.2011 17:56, Ionuț Arțăriși napsal(a):
 Cool. So can you apply the patch that I attached to my previous email?
 
 Ahh, I did not notice it first time - sorry. Applied. Thanks.
 
 Mirek
 

This is going to break Debian client.

When something is moved from the rhn-client-tools to yum-rhn-plugin, it
should be moved to apt-spacewalk as well.

-- 
Simon LukasikSystems Management QA
sluka...@redhat.com  #satellite-qa

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

Re: [Spacewalk-devel] erratas and the client plugin package action

2011-10-19 Thread Miroslav Suchý
On 10/19/2011 09:45 AM, Simon Lukasik wrote:
 This is going to break Debian client.
 
 When something is moved from the rhn-client-tools to yum-rhn-plugin, it
 should be moved to apt-spacewalk as well.

We use errata actions in Debian?

-- 
Miroslav Suchy
Red Hat Satellite Engineering

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


Re: [Spacewalk-devel] erratas and the client plugin package action

2011-10-18 Thread Ionuț Arțăriși

On 05/13/2011 02:27 PM, Miroslav Suchý wrote:

On 05/13/2011 02:22 PM, Duncan Mac-Vicar P. wrote:

Would it make more sense for errata.py to be in the yum-rhn-plugin?

It fine with me. yum-rhn-plugin and rhn-client-tools require each other
(on rhel/fedora) anyway. So yes, it can be moved to yum-rhn-plugin.


For *SUSE I think we will have to override errata.py as zypper should
install the patch directly and not let the plugin resolve the package list.

Would it be acceptable upstream that we don't install errata.py from the
.spec file %if 0%{?suse_version} and supply it with
zypp-plugin-spacewalk (which contains package.py)?

That possible as well.

I slightly prefer the first option (move it to yum-rhn-plugin). But
choose yourself.

Can we still move errata.py to yum-rhn-plugin? We've gone with the 
second option until now, but this would make packaging cleaner.


-Ionuț
From 8bfecb11e2f14b1f922bb2986693840e8dc77107 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ionu=C8=9B=20Ar=C8=9B=C4=83ri=C8=99i?= iartar...@suse.cz
Date: Tue, 18 Oct 2011 16:49:24 +0200
Subject: [PATCH] move errata.py action to the yum-rhn-plugin package

---
 client/rhel/rhn-client-tools/rhn-client-tools.spec |1 -
 client/rhel/rhn-client-tools/src/actions/Makefile  |2 +-
 client/rhel/rhn-client-tools/src/actions/errata.py |   87 
 client/rhel/yum-rhn-plugin/actions/errata.py   |   87 
 4 files changed, 88 insertions(+), 89 deletions(-)
 delete mode 100644 client/rhel/rhn-client-tools/src/actions/errata.py
 create mode 100644 client/rhel/yum-rhn-plugin/actions/errata.py

diff --git a/client/rhel/rhn-client-tools/rhn-client-tools.spec b/client/rhel/rhn-client-tools/rhn-client-tools.spec
index 8d9f58b..51292fb 100644
--- a/client/rhel/rhn-client-tools/rhn-client-tools.spec
+++ b/client/rhel/rhn-client-tools/rhn-client-tools.spec
@@ -249,7 +249,6 @@ make -f Makefile.rhn-client-tools test
 # actions for rhn_check to run
 %{_datadir}/rhn/actions/__init__.*
 %{_datadir}/rhn/actions/hardware.*
-%{_datadir}/rhn/actions/errata.*
 %{_datadir}/rhn/actions/systemid.*
 %{_datadir}/rhn/actions/reboot.*
 %{_datadir}/rhn/actions/rhnsd.*
diff --git a/client/rhel/rhn-client-tools/src/actions/Makefile b/client/rhel/rhn-client-tools/src/actions/Makefile
index 2d72848..fec4eff 100644
--- a/client/rhel/rhn-client-tools/src/actions/Makefile
+++ b/client/rhel/rhn-client-tools/src/actions/Makefile
@@ -3,7 +3,7 @@
 # $Id$
 
 ACTIONS		= up2date_config hardware reboot \
-		  rhnsd systemid errata __init__
+		  rhnsd systemid __init__
 PYFILES		= $(addsuffix .py, $(ACTIONS))
 OBJECTS		= $(PYFILES) $(addsuffix .pyc, $(ACTIONS))
 
diff --git a/client/rhel/rhn-client-tools/src/actions/errata.py b/client/rhel/rhn-client-tools/src/actions/errata.py
deleted file mode 100644
index 49f1c65..000
--- a/client/rhel/rhn-client-tools/src/actions/errata.py
+++ /dev/null
@@ -1,87 +0,0 @@
-#!/usr/bin/python
-
-# Client code for Update Agent
-# Copyright (c) 1999-2002 Red Hat, Inc.  Distributed under GPL.
-#
-# Author: Adrian Likins alik...@redhat.com
-#
-
-import sys
-sys.path.append(/usr/share/rhn/)
-from up2date_client import rhnserver
-from up2date_client import up2dateAuth
-from up2date_client import pkgUtils
-from actions import packages
-
-__rhnexport__ = [
-'update']
-
-# action version we understand
-ACTION_VERSION = 2 
-
-def __getErrataInfo(errata_id):
-s = rhnserver.RhnServer()
-return s.errata.getErrataInfo(up2dateAuth.getSystemId(), errata_id)
-
-def update(errataidlist, cache_only=None):
-packagelist = []
-
-if type(errataidlist) not in [type([]), type(())]:
-errataidlist = [ errataidlist ]
-
-for errataid in errataidlist:
-tmpList = __getErrataInfo(errataid)
-packagelist = packagelist + tmpList
-
-current_packages_with_arch = {}
-current_packages ={}
-for p in pkgUtils.getInstalledPackageList(getArch=1):
-current_packages_with_arch[p['name']+p['arch']] = p
-current_packages[p['name']] = p
-
-u = {}   
-# only update packages that are currently installed
-# since an applicable errata may only contain some packages
-# that actually apply. aka kernel. Fun fun fun. 
-
-if len(packagelist[0])  4:
-# Newer sats send down arch, filter using name+arch
-for p in packagelist:
-	if current_packages_with_arch.has_key(p[0]+p[4]):
-	u[p[0]+p[4]] = p
-	elif current_packages_with_arch.has_key(p[0]+noarch):
-	u[p[0]+p[4]] = p
-	elif p[4] == noarch and current_packages.has_key(p[0]):
-	u[p[0]] = p
-else:
-# 5.2 and older sats + hosted dont send arch
-for p in packagelist:
-if current_packages.has_key(p[0]):
-u[p[0]] = p
-
-
-# XXX: Fix me - once we keep all errata packages around,
-# this is the WRONG thing to do - we want to keep the specific versions
-# that the user has asked for.
-packagelist = map(lambda a: 

Re: [Spacewalk-devel] erratas and the client plugin package action

2011-10-18 Thread Miroslav Suchý
On 10/18/2011 04:53 PM, Ionuț Arțăriși wrote:
 Can we still move errata.py to yum-rhn-plugin? We've gone with the
 second option until now, but this would make packaging cleaner.

Still no objections.

-- 
Miroslav Suchy
Red Hat Satellite Engineering

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

Re: [Spacewalk-devel] erratas and the client plugin package action

2011-10-18 Thread Ionuț Arțăriși

On 10/18/2011 05:17 PM, Miroslav Suchý wrote:

On 10/18/2011 04:53 PM, Ionuț Arțăriși wrote:

Can we still move errata.py to yum-rhn-plugin? We've gone with the
second option until now, but this would make packaging cleaner.

Still no objections.

Cool. So can you apply the patch that I attached to my previous email?

Thanks,
-Ionuț

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

Re: [Spacewalk-devel] erratas and the client plugin package action

2011-10-17 Thread Ionuț Arțăriși

On 06/01/2011 10:31 AM, Jan Pazdziora wrote:

I looked a bit more into rhnSQL and I found two more helpers in
rhnSQL.sql_lib. It looks like a good place for adding the bind_list
function.

You patch is now in Spacewalk master,
49df1fa935453bbb3fa027d31859b44dfec6c32d. I just polished a couple of
trailing whitespaces.

Thank you!

The whole point of this patch for us was so that we could install suse 
patches with the special zypper way. In order for that to happen we need 
to first check if the server supports this new API command, so we need a 
new capability.


So can you please apply this patch? (zypp-plugin-spacewalk currently 
depends on this capability being provided to install patches correctly).


Thank you,
Ionuț
From 35e7d4257942ac91c21d7120ed5d874032629b72 Mon Sep 17 00:00:00 2001
From: Michael Calmer m...@suse.de
Date: Wed, 6 Jul 2011 17:51:04 +0200
Subject: [PATCH] add server capability xmlrpc.errata.patch_names'

---
 backend/server/rhnCapability.py |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/backend/server/rhnCapability.py b/backend/server/rhnCapability.py
index 1259747..ad6c306 100644
--- a/backend/server/rhnCapability.py
+++ b/backend/server/rhnCapability.py
@@ -186,6 +186,7 @@ def _set_server_capabilities():
 'rhncfg.filetype.directory' : {'version' : 1, 'value' : 1},
 'xmlrpc.packages.extended_profile'  : {'version' : '1-2', 'value' : 1},
 'xmlrpc.packages.suse_products' : {'version' : 1, 'value' : 1},
+'xmlrpc.errata.patch_names' : {'version' : 1, 'value' : 1},
 'staging_content'   : {'version' : 1, 'value' : 1},
 }
 l = []
-- 
1.7.3.4

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

Re: [Spacewalk-devel] erratas and the client plugin package action

2011-10-17 Thread Jan Pazdziora
On Mon, Oct 17, 2011 at 04:05:46PM +0200, Ionuț Arțăriși wrote:

 The whole point of this patch for us was so that we could install
 suse patches with the special zypper way. In order for that to
 happen we need to first check if the server supports this new API
 command, so we need a new capability.
 
 So can you please apply this patch? (zypp-plugin-spacewalk currently
 depends on this capability being provided to install patches
 correctly).
 
 Thank you,
 Ionuț

 From 35e7d4257942ac91c21d7120ed5d874032629b72 Mon Sep 17 00:00:00 2001
 From: Michael Calmer m...@suse.de
 Date: Wed, 6 Jul 2011 17:51:04 +0200
 Subject: [PATCH] add server capability xmlrpc.errata.patch_names'
 
 ---
  backend/server/rhnCapability.py |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
 
 diff --git a/backend/server/rhnCapability.py b/backend/server/rhnCapability.py
 index 1259747..ad6c306 100644
 --- a/backend/server/rhnCapability.py
 +++ b/backend/server/rhnCapability.py
 @@ -186,6 +186,7 @@ def _set_server_capabilities():
  'rhncfg.filetype.directory' : {'version' : 1, 'value' : 
 1},
  'xmlrpc.packages.extended_profile'  : {'version' : '1-2', 
 'value' : 1},
  'xmlrpc.packages.suse_products' : {'version' : 1, 'value' : 
 1},
 +'xmlrpc.errata.patch_names' : {'version' : 1, 'value' : 
 1},

Nack -- it does not apply cleanly in Spacewalk master. We don't have
that xmlrpc.packages.suse_products at all so I'm affraid something is
getting lost in the translation.

Also, you might want to put the comment you have in the mail to the
commit message so that we have the documentation of this capability
preserved at least in the commit message.

-- 
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

Re: [Spacewalk-devel] erratas and the client plugin package action

2011-10-17 Thread Ionuț Arțăriși

On 10/17/2011 04:19 PM, Jan Pazdziora wrote:

On Mon, Oct 17, 2011 at 04:05:46PM +0200, Ionuț Arțăriși wrote:


The whole point of this patch for us was so that we could install
suse patches with the special zypper way. In order for that to
happen we need to first check if the server supports this new API
command, so we need a new capability.

So can you please apply this patch? (zypp-plugin-spacewalk currently
depends on this capability being provided to install patches
correctly).

Thank you,
Ionuț
 From 35e7d4257942ac91c21d7120ed5d874032629b72 Mon Sep 17 00:00:00 2001
From: Michael Calmerm...@suse.de
Date: Wed, 6 Jul 2011 17:51:04 +0200
Subject: [PATCH] add server capability xmlrpc.errata.patch_names'

---
  backend/server/rhnCapability.py |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/backend/server/rhnCapability.py b/backend/server/rhnCapability.py
index 1259747..ad6c306 100644
--- a/backend/server/rhnCapability.py
+++ b/backend/server/rhnCapability.py
@@ -186,6 +186,7 @@ def _set_server_capabilities():
  'rhncfg.filetype.directory' : {'version' : 1, 'value' : 
1},
  'xmlrpc.packages.extended_profile'  : {'version' : '1-2', 'value' 
: 1},
  'xmlrpc.packages.suse_products' : {'version' : 1, 'value' : 
1},
+'xmlrpc.errata.patch_names' : {'version' : 1, 'value' : 1},

Nack -- it does not apply cleanly in Spacewalk master. We don't have
that xmlrpc.packages.suse_products at all so I'm affraid something is
getting lost in the translation.

Also, you might want to put the comment you have in the mail to the
commit message so that we have the documentation of this capability
preserved at least in the commit message.


Thanks, this should fix it.
From cbda448d1f5834a8ebe39d1695ca6bce6cd6b1cc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ionu=C8=9B=20Ar=C8=9B=C4=83ri=C8=99i?= iartar...@suse.cz
Date: Mon, 17 Oct 2011 16:43:55 +0200
Subject: [PATCH] add an 'xmlrpc.errata.patch_names' capability

This capability corresponds to the getErrataNamesById action in
xmlrpc.errata. zypp-plugin-spacewalk depends on it for installing SUSE
patches as patches instead of individual packages (i.e. zypper install
patch:PatchName1 patch:PatchName2)
---
 backend/server/rhnCapability.py |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/backend/server/rhnCapability.py b/backend/server/rhnCapability.py
index fef1f32..5ac0fc6 100644
--- a/backend/server/rhnCapability.py
+++ b/backend/server/rhnCapability.py
@@ -186,6 +186,7 @@ def _set_server_capabilities():
 'rhncfg.content.base64_decode'  : {'version' : 1, 'value' : 1},
 'rhncfg.filetype.directory' : {'version' : 1, 'value' : 1},
 'xmlrpc.packages.extended_profile'  : {'version' : '1-2', 'value' : 1},
+'xmlrpc.errata.patch_names' : {'version' : 1, 'value' : 1},
 'staging_content'   : {'version' : 1, 'value' : 1},
 'ipv6'  : {'version' : 1, 'value' : 1},
 }
-- 
1.7.3.4

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

Re: [Spacewalk-devel] erratas and the client plugin package action

2011-05-19 Thread Ionuț Arțăriși

On 05/18/2011 05:05 PM, Jan Pazdziora wrote:

On Wed, May 18, 2011 at 02:38:54PM +0200, Ionuț Arțăriși wrote:

On 05/18/2011 01:14 PM, Jan Pazdziora wrote:

...

Nack. This is SQL-injection-prone. You have to use bind parameters
or sanitize the input properly.

Thanks, I have fixed the SQL issue.

It's still somewhat missing in your patch.


Ok, I think I now understood what you mean. Here's the re-patched patch :).

Those SQL IN operations seem to be quite tedious. Is there anywhere that 
we could move this _bind_list function? Perhaps to something like 
rhnSQL.bind_list? I haven't found any other helpers like this already in 
rhnSQL, but I've seen it used in other places.


-Ionuț
From a519ba5cef71bdec3bf6fa2e42438b00c34af14c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ionu=C8=9B=20Ar=C8=9B=C4=83ri=C8=99i?= iartar...@suse.cz
Date: Wed, 18 May 2011 12:31:59 +0200
Subject: [PATCH] added errata.getErrataNamesById function to the API

---
 backend/server/handlers/xmlrpc/errata.py |   36 ++
 1 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/backend/server/handlers/xmlrpc/errata.py b/backend/server/handlers/xmlrpc/errata.py
index 5b11637..cbaab6e 100644
--- a/backend/server/handlers/xmlrpc/errata.py
+++ b/backend/server/handlers/xmlrpc/errata.py
@@ -35,6 +35,7 @@ class Errata(rhnHandler):
 self.functions.append('GetByPackage')  # Clients v1-
 self.functions.append('getPackageErratum') # Clients v2+
 self.functions.append('getErrataInfo') # clients v2+
+self.functions.append('getErrataNamesById')
 
 def GetByPackage(self, pkg, osRel):
  Clients v1- Get errata for a package given n-v-r format
@@ -242,7 +243,42 @@ class Errata(rhnHandler):
 pkg_arch])
 return ret
 
+def getErrataNamesById(self, errata_ids):
+Return a list of RhnErrata tuples of (id, advisory_name)
 
+IN: errata_ids - a list of RhnErrata ids
+
+Returns an empty list if no erratas were found for the provided ids.
+
+
+sql_list, bound_vars = _bind_list(errata_ids)
+
+sql = SELECT id, advisory_name FROM RhnErrata
+ WHERE id IN (%s)
+h = rhnSQL.prepare(sql % sql_list)
+h.execute(**bound_vars)
+
+return h.fetchall()
+
+
+def _bind_list(elems):
+Transform a list into an sql list with bound parameters
+
+IN: elems - a list of elements
+
+Returns a tuple of:
+ sql_list - a comma separated list of parameter numbers: 'p_0, p_1, p_2'
+ bound_vars - a dict of parameter names and values {'p_0': 42, 'p_1': 34}
+
+
+bound_names = []
+bound_vars = {}
+for i, elem in enumerate(elems):
+bound_vars['p_%s' % i] = elem
+bound_names.append(':p_%s' % i)
+sql_list = ', '.join(bound_names)
+return sql_list, bound_vars
+
 #-
 if __name__ == __main__:
 print You can not run this module by itself
-- 
1.7.3.4

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

Re: [Spacewalk-devel] erratas and the client plugin package action

2011-05-18 Thread Ionuț Arțăriși

On 05/18/2011 01:14 PM, Jan Pazdziora wrote:

...

Nack. This is SQL-injection-prone. You have to use bind parameters
or sanitize the input properly.

Thanks, I have fixed the SQL issue.


Besides, if you allow the list of errata id's to be passed in, which
would lead to multiple erratas to be returned, shouldn't you return
the id as well to make it clear which advisory name belongs to which
id?


We don't exactly need the errata ids, but I can see how this might be 
useful, so I have changed the method to return a list of (id, 
advisory_name) tuples.


-Ionuț
From 2294cbcf78713d600f716aa202a812df7d6480be Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ionu=C8=9B=20Ar=C8=9B=C4=83ri=C8=99i?= iartar...@suse.cz
Date: Wed, 18 May 2011 12:31:59 +0200
Subject: [PATCH] added errata.getErrataNamesById function to the API

---
 backend/server/handlers/xmlrpc/errata.py |   20 
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/backend/server/handlers/xmlrpc/errata.py b/backend/server/handlers/xmlrpc/errata.py
index 5b11637..4f1abcd 100644
--- a/backend/server/handlers/xmlrpc/errata.py
+++ b/backend/server/handlers/xmlrpc/errata.py
@@ -35,6 +35,7 @@ class Errata(rhnHandler):
 self.functions.append('GetByPackage')  # Clients v1-
 self.functions.append('getPackageErratum') # Clients v2+
 self.functions.append('getErrataInfo') # clients v2+
+self.functions.append('getErrataNamesById')
 
 def GetByPackage(self, pkg, osRel):
  Clients v1- Get errata for a package given n-v-r format
@@ -243,6 +244,25 @@ class Errata(rhnHandler):
 return ret
 
 
+def getErrataNamesById(self, errata_ids):
+Return a list of RhnErrata tuples of (id, advisory_name)
+
+:arg errata_ids: a list of RhnErrata ids
+
+Returns an empty list if no erratas were found for the provided ids.
+
+
+# transform the list of ints to an sql list that we can forcibly
+# insert into the sql statement
+sql_list = ', '.join([str(i) for i in errata_ids])
+
+sql = SELECT id, advisory_name FROM RhnErrata
+ WHERE id IN (%s)
+h = rhnSQL.prepare(sql % sql_list)
+h.execute()
+
+return h.fetchall()
+
 #-
 if __name__ == __main__:
 print You can not run this module by itself
-- 
1.7.3.4

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

Re: [Spacewalk-devel] erratas and the client plugin package action

2011-05-18 Thread Duncan Mac-Vicar P.

On 05/18/2011 02:38 PM, Ionuț Arțăriși wrote:

On 05/18/2011 01:14 PM, Jan Pazdziora wrote:

...

Nack. This is SQL-injection-prone. You have to use bind parameters
or sanitize the input properly.

Thanks, I have fixed the SQL issue.


Besides, if you allow the list of errata id's to be passed in, which
would lead to multiple erratas to be returned, shouldn't you return
the id as well to make it clear which advisory name belongs to which
id?


We don't exactly need the errata ids, but I can see how this might be
useful, so I have changed the method to return a list of (id,
advisory_name) tuples.


This is tricky. What happens if the clients update their package, but 
the server is not updated yet (and therefore the API is not there)?


We could catch the error and fallback to the packages-way, but it looks 
like a common scenario: the client requiring something from the server.


Or we could look with getApiNamespaceCallList if the API is there. The 
question is what to do if it is not.


--
Duncan Mac-Vicar P. - Novell® Making IT Work As One™

SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix 
Imendörffer, HRB 16746 (AG Nürnberg)

Maxfeldstraße 5, 90409 Nürnberg, Germany

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

Re: [Spacewalk-devel] erratas and the client plugin package action

2011-05-18 Thread Miroslav Suchý
On 05/18/2011 03:22 PM, Duncan Mac-Vicar P. wrote:
 On 05/18/2011 02:38 PM, Ionuț Arțăriși wrote:
 On 05/18/2011 01:14 PM, Jan Pazdziora wrote:

 ...
 Nack. This is SQL-injection-prone. You have to use bind parameters
 or sanitize the input properly.
 Thanks, I have fixed the SQL issue.

 Besides, if you allow the list of errata id's to be passed in, which
 would lead to multiple erratas to be returned, shouldn't you return
 the id as well to make it clear which advisory name belongs to which
 id?

 We don't exactly need the errata ids, but I can see how this might be
 useful, so I have changed the method to return a list of (id,
 advisory_name) tuples.
 
 This is tricky. What happens if the clients update their package, but
 the server is not updated yet (and therefore the API is not there)?
 
 We could catch the error and fallback to the packages-way, but it looks
 like a common scenario: the client requiring something from the server.
 
 Or we could look with getApiNamespaceCallList if the API is there.

Or you can use capability. See commit:
6006097b890aa925e06bf65a81d11d73f78b9103
for example.


-- 
Miroslav Suchy
Red Hat Satellite Engineering

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

Re: [Spacewalk-devel] erratas and the client plugin package action

2011-05-18 Thread Jan Pazdziora
On Wed, May 18, 2011 at 02:38:54PM +0200, Ionuț Arțăriși wrote:
 On 05/18/2011 01:14 PM, Jan Pazdziora wrote:
 
 ...
 Nack. This is SQL-injection-prone. You have to use bind parameters
 or sanitize the input properly.
 Thanks, I have fixed the SQL issue.

It's still somewhat missing in your patch.

 +# transform the list of ints to an sql list that we can forcibly
 +# insert into the sql statement
 +sql_list = ', '.join([str(i) for i in errata_ids])
 +
 +sql = SELECT id, advisory_name FROM RhnErrata
 + WHERE id IN (%s)
 +h = rhnSQL.prepare(sql % sql_list)

-- 
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

Re: [Spacewalk-devel] erratas and the client plugin package action

2011-05-17 Thread Ionuț Arțăriși

On 05/12/2011 03:26 PM, Duncan Mac-Vicar P. wrote:
I would like to have the name of the errata so that the client solver 
can figure the right packages to install (we have the errata in the 
repo metadata as well). But right now it looks like the package list 
is sent down.


Is there any way to get the errata names at all right now? Since 
errata.update only receives a list of errata ids, how could we get the 
names from the server in order to send them to zypper? I looked around 
the XMLRPC API a bit and besides being deceived by the name of the 
getErrataInfo method(which only returns a list of packages - can we 
rename it to getPackageList?), I couldn't find a way to do this.


Could we add a getErrataNamesById method the xmlrpc API under errata?

-Ionuț

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

Re: [Spacewalk-devel] erratas and the client plugin package action

2011-05-17 Thread Miroslav Suchý
On 05/17/2011 02:17 PM, Ionuț Arțăriși wrote:
 Is there any way to get the errata names at all right now?

No, there is not. You are correct.

 Since
 errata.update only receives a list of errata ids, how could we get the
 names from the server in order to send them to zypper? I looked around

Hmm, I thought that zypper code could handle it already. How did you
done it till now?

 the XMLRPC API a bit and besides being deceived by the name of the
 getErrataInfo method(which only returns a list of packages - can we
 rename it to getPackageList?), I couldn't find a way to do this.

No, you could not rename it. It will break API!
If it really bothers you, you can create getPackageList as alias to
getErrataInfo. Mark getErrataInfo as obsolete. And after several year
rename it.
But IMO it is not worth.

 Could we add a getErrataNamesById method the xmlrpc API under errata?

Yes, you can.

Generally - if you need some API (backend or frontend) and you did not
change semantics of old ones. And as far as the new API call does not
create security risk (e.g. providing info, which system should not see).
Then you can add it without problem.

-- 
Miroslav Suchy
Red Hat Satellite Engineering

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

Re: [Spacewalk-devel] erratas and the client plugin package action

2011-05-16 Thread Jan Pazdziora
On Fri, May 13, 2011 at 02:27:42PM +0200, Miroslav Suchý wrote:
 On 05/13/2011 02:22 PM, Duncan Mac-Vicar P. wrote:
  Would it make more sense for errata.py to be in the yum-rhn-plugin?
 
 It fine with me. yum-rhn-plugin and rhn-client-tools require each other
 (on rhel/fedora) anyway.

Is that really true?

# rpm -q rhn-client-tools
rhn-client-tools-1.0.0-60.el6.noarch
# rpm -q --requires rhn-client-tools | grep yum-rhn-plugin | wc -l
0

-- 
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


Re: [Spacewalk-devel] erratas and the client plugin package action

2011-05-16 Thread Miroslav Suchy

Dne 16.5.2011 14:13, Jan Pazdziora napsal(a):

On Fri, May 13, 2011 at 02:27:42PM +0200, Miroslav Suchý wrote:

On 05/13/2011 02:22 PM, Duncan Mac-Vicar P. wrote:

Would it make more sense for errata.py to be in the yum-rhn-plugin?


It fine with me. yum-rhn-plugin and rhn-client-tools require each other
(on rhel/fedora) anyway.


Is that really true?

# rpm -q rhn-client-tools
rhn-client-tools-1.0.0-60.el6.noarch
# rpm -q --requires rhn-client-tools | grep yum-rhn-plugin | wc -l
0



Yes and no.

The dependency is not there written. But if you have not installed 
yum-rhn-plugin and you will receive action to install either package or 
errata and you will not have yum-rhn-plugin installed, then the action 
will fail.


So to be precise, the dependency should be there (as all soft 
dependencies should be listed in Requires), but somebody in past decided 
that it can be really useful to have rhn-client-tools without 
yum-rhn-plugin. And I must admit, that I agree with that.


Mirek

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


Re: [Spacewalk-devel] erratas and the client plugin package action

2011-05-13 Thread Miroslav Suchý
On 05/12/2011 03:26 PM, Duncan Mac-Vicar P. wrote:
 
 Hi,
 
 When I install an errata and the client fetch a job, which results in
 rhn/actions/package.py update(pkglist) action being called.
 
 Is the name of the errata lost? at which point does this happen? (job
 API, rhnsd, package.py action)?
 
 I would like to have the name of the errata so that the client solver
 can figure the right packages to install (we have the errata in the repo
 metadata as well). But right now it looks like the package list is sent
 down.

If you go through SDC - software - errata - and you choose one.
It should result in:
 errata.update
actions.

Which is picked up by:
client/rhel/rhn-client-tools/src/actions/errata.py

The transformation from errata to package list is there:
for errataid in errataidlist:
tmpList = __getErrataInfo(errataid)
packagelist = packagelist + tmpList

-- 
Miroslav Suchy
Red Hat Satellite Engineering

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


Re: [Spacewalk-devel] erratas and the client plugin package action

2011-05-13 Thread Duncan Mac-Vicar P.

On 05/13/2011 10:02 AM, Miroslav Suchý wrote:
  If you go through SDC -  software -  errata -  and you choose one.

It should result in:
  errata.update
actions.

Which is picked up by:
client/rhel/rhn-client-tools/src/actions/errata.py

The transformation from errata to package list is there:
 for errataid in errataidlist:
 tmpList = __getErrataInfo(errataid)
 packagelist = packagelist + tmpList



Thanks, I completely oversaw this errata action as I saw all installs 
ending in packages.py (which we reimplemented), but now I see errata.py 
actually uses packages.py.


Would it make more sense for errata.py to be in the yum-rhn-plugin?

For *SUSE I think we will have to override errata.py as zypper should 
install the patch directly and not let the plugin resolve the package list.


Would it be acceptable upstream that we don't install errata.py from the 
.spec file %if 0%{?suse_version} and supply it with 
zypp-plugin-spacewalk (which contains package.py)?


Thanks for the hint.

--
Duncan Mac-Vicar P. - Novell® Making IT Work As One™

SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix 
Imendörffer, HRB 16746 (AG Nürnberg)

Maxfeldstraße 5, 90409 Nürnberg, Germany

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


Re: [Spacewalk-devel] erratas and the client plugin package action

2011-05-13 Thread Miroslav Suchý
On 05/13/2011 02:22 PM, Duncan Mac-Vicar P. wrote:
 Would it make more sense for errata.py to be in the yum-rhn-plugin?

It fine with me. yum-rhn-plugin and rhn-client-tools require each other
(on rhel/fedora) anyway. So yes, it can be moved to yum-rhn-plugin.

 For *SUSE I think we will have to override errata.py as zypper should
 install the patch directly and not let the plugin resolve the package list.
 
 Would it be acceptable upstream that we don't install errata.py from the
 .spec file %if 0%{?suse_version} and supply it with
 zypp-plugin-spacewalk (which contains package.py)?

That possible as well.

I slightly prefer the first option (move it to yum-rhn-plugin). But
choose yourself.

-- 
Miroslav Suchy
Red Hat Satellite Engineering

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