Re: [Spacewalk-devel] erratas and the client plugin package action
On 10/19/2011 11:59 AM, Miroslav Suchý wrote: > 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? > Well, we don't have a test for it. However, Until 561ee725dd0f6 we have distributed it. And no problem was reported so far. -- 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
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
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
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 ___ 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
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
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
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?=
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 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: u[a], u.keys())
-
-if packagelist == []:
- data = {}
- data['version'] = "0"
- data['name'] = "errata.update.no_packages"
- data['erratas'] = errataidlist
-
- return (39,
- "No packages from that errata are available",
- data)
-
-return packages.update(packagelist, cache_only)
-
-
-def main():
- print update([23423423])
-
-
-if __name__ == "__main__":
- main()
-
diff --git a/client/rhel/yum-rhn-plugin/actions/errata.py b/client/rhel/yum-rhn-plugin/actions/errata.py
new file mode 100644
index 000..49f1c65
--- /dev/null
+++ b/client/rhel/yum-rhn-plugin/actions/errata.py
@@ -0,0 +1,87 @@
+#!/usr/bin/python
+
+# Client code for Update Agent
+# Copyright (c) 1999-2002 Red Hat, Inc. Distributed under GPL.
+#
+# Author: Adrian Likins 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:
Re: [Spacewalk-devel] erratas and the client plugin package action
On Mon, Oct 17, 2011 at 04:45:55PM +0200, Ionuț Arțăriși wrote: > On 10/17/2011 04:19 PM, Jan Pazdziora wrote: > >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. Thanks, pushed to master as 9da7323af775c288af8dc9c436c3e3da007a509b. -- 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
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 Calmer
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?=
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
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
> 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
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
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
On Tue, May 24, 2011 at 03:00:13PM +0200, Ionuț Arțăriși wrote: > On 05/23/2011 04:45 PM, Jan Pazdziora wrote: > > > >Now all that is left is make sure the call cannot be used to access > >information which should not be accessible to the server. If you check > >the getErrataInfo and take it as an example, you will see how to > >authenticate / authorize, and we will need the query extended to join > >with (probably) rhnServerChannel and rhnChannelErrata. > > Thanks, I think this should be fixed now. [...] > 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! -- 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
On 05/23/2011 04:45 PM, Jan Pazdziora wrote:
On Thu, May 19, 2011 at 11:46:37AM +0200, Ionuț Arțăriși wrote:
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 :).
Good.
Now all that is left is make sure the call cannot be used to access
information which should not be accessible to the server. If you check
the getErrataInfo and take it as an example, you will see how to
authenticate / authorize, and we will need the query extended to join
with (probably) rhnServerChannel and rhnChannelErrata.
Thanks, I think this should be fixed now.
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.
It is certainly possible.
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.
-Ionuț
>From 3688631b956423aa3a0b31d370f98b177462272a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ionu=C8=9B=20Ar=C8=9B=C4=83ri=C8=99i?=
Date: Tue, 24 May 2011 14:53:40 +0200
Subject: [PATCH] added errata.getErrataNamesById function to the API
---
backend/server/handlers/xmlrpc/errata.py | 56 ++
1 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/backend/server/handlers/xmlrpc/errata.py b/backend/server/handlers/xmlrpc/errata.py
index 5b11637..ef161cd 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,62 @@ class Errata(rhnHandler):
pkg_arch])
return ret
+def getErrataNamesById(self, system_id, errata_ids):
+"""Return a list of RhnErrata tuples of (id, advisory_name)
+IN: system_id - id of the system requesting this info (must be
+subscribed to the channel that contains the erratas)
+errata_ids - a list of RhnErrata ids
+
+Only the erratas that belong to channels that the client system
+is subscribed to are returned. If no erratas match this
+criterion, then an empty list is returned.
+
+"""
+log_debug(5, system_id, errata_ids)
+self.auth_system(system_id)
+
+log_debug(1, self.server_id, errata_ids)
+
+sql_list, bound_vars = _bind_list(errata_ids)
+bound_vars.update({'server_id': self.server_id})
+
+sql = """SELECT DISTINCT e.id, e.advisory_name
+ FROM rhnErrata e,
+ rhnPackage p,
+ rhnChannelPackage cp,
+ rhnServerChannel sc,
+ rhnErrataPackage ep
+ WHERE e.id in (%s) AND
+ ep.errata_id = e.id AND
+ ep.package_id = p.id AND
+ sc.server_id = :server_id AND
+ sc.channel_id = cp.channel_id AND
+ cp.package_id = p.id"""
+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.4.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
On Thu, May 19, 2011 at 11:46:37AM +0200, Ionuț Arțăriși wrote: > 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 :). Good. Now all that is left is make sure the call cannot be used to access information which should not be accessible to the server. If you check the getErrataInfo and take it as an example, you will see how to authenticate / authorize, and we will need the query extended to join with (probably) rhnServerChannel and rhnChannelErrata. > 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. It is certainly possible. -- 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
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?=
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
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
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
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
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?=
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
On Wed, May 18, 2011 at 12:44:46PM +0200, Ionuț Arțăriși wrote: > > I have attached a patch to add a new method to the API which returns > the names of erratas when given a list of errata ids. We need this > so we can call it from actions/errata.py in the > zypp-plugin-spacewalk. [...] > +# 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 advisory_name FROM rhnerrata > + WHERE id IN (%s)""" % sql_list > +h = rhnSQL.prepare(sql) > +h.execute() Nack. This is SQL-injection-prone. You have to use bind parameters or sanitize the input properly. 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? -- 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
Thanks a lot for your comprehensive answer.
On 05/17/2011 04:06 PM, Miroslav Suchý wrote:
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?
Right now it's done the same way that yum does it - it receives the list
of packages and installs them as normal packages. This approach doesn't
work so well for zypper though.
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.
I have attached a patch to add a new method to the API which returns the
names of erratas when given a list of errata ids. We need this so we can
call it from actions/errata.py in the zypp-plugin-spacewalk.
-Ionuț
>From 4c72b6bf32872377e427bcc53cfefe8e59e69895 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ionu=C8=9B=20Ar=C8=9B=C4=83ri=C8=99i?=
Date: Wed, 18 May 2011 12:31:59 +0200
Subject: [PATCH] added errata.getErrataNamesById function to the API
---
backend/server/handlers/xmlrpc/errata.py | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/backend/server/handlers/xmlrpc/errata.py b/backend/server/handlers/xmlrpc/errata.py
index 5b11637..b5fbada 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,26 @@ class Errata(rhnHandler):
return ret
+def getErrataNamesById(self, errata_ids):
+"""Return a list of RhnErrata names
+
+: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 advisory_name FROM rhnerrata
+ WHERE id IN (%s)""" % sql_list
+h = rhnSQL.prepare(sql)
+h.execute()
+erratas = [tup[0] for tup in h.fetchall()]
+
+return erratas
+
#-
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
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
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
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
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
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
Re: [Spacewalk-devel] erratas and the client plugin package action
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
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
[Spacewalk-devel] erratas and the client plugin package action
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. cheers -- 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
