Re: [Spacewalk-devel] Spacewalk on RHEL8 - Step 1 (of many) completed
Dne 11. 03. 20 v 13:32 Neal Gompa napsal(a): > It'd be good to get this back into Fedora. Get in touch on the Fedora > development mailing list to help integrate this packages back in the > distribution. They could also be built into EPEL 7/8 for reusability > too. I maintained some of those packages in Fedora. I orphaned them some time ago. I guess some of them will be still owned by orphan. Then you just grab it. But some of the are already retired, and you must go through: https://fedoraproject.org/wiki/Package_Review_Process -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk 2.6 Released!
Dne 29.11.2016 v 10:59 Gennadii Altukhov napsal(a): > We are proudly announcing a release of Spacewalk 2.6, a systems management > solution. I build and pushed Spacecmd to Fedora 26, 25, 24, Epel 7 and 6. It should appear in updates-testing in few hours. I build all packages which are in main Fedora into rawhide and forward ported few issued into Spacewalk master. -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Adoption of python-hwdata
On 01/27/2015 02:22 PM, Tomas Lestach wrote: feel free to do it. Done https://github.com/xsuchy/python-hwdata -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Adoption of python-hwdata
Hi, I would like to take out python-hwdata from spacewalk.git and move it to my personal github. I created this library for Spacewalk. While I no longer work on Spacewalk code, I still continue maintaining this package and I would like to continue. Moving it to my personal namespace on github will make things little bit easier for me. Unless somebody object I will: * move the code to github * remove it from spacewalk.git (and probably leave there just MOVED.txt) * move the documentation of this module from Spacewalk wiki -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Fwd: Package: rhnpush-5.5.71-2.fc21 Tag: f21-rebuild Status: failed Built by: ausil
Hi, rhnpush is failing on Fedora 21 due pylint. Can somebody can fix before next release please? http://koji.fedoraproject.org/koji/getfile?taskID=7006959name=build.log Mirek Original Message Subject: Package: rhnpush-5.5.71-2.fc21 Tag: f21-rebuild Status: failed Built by: ausil Date: Sun, 8 Jun 2014 07:05:27 + (UTC) From: Fedora Koji Build System build...@fedoraproject.org To: au...@fedoraproject.org, msu...@fedoraproject.org Package: rhnpush-5.5.71-2.fc21 Tag: f21-rebuild Status: failed Built by: ausil ID: 534110 Started: Sun, 08 Jun 2014 06:54:08 UTC Finished: Sun, 08 Jun 2014 07:05:14 UTC rhnpush-5.5.71-2.fc21 (534110) failed on buildvm-23.phx2.fedoraproject.org (noarch), arm02-builder14.arm.fedoraproject.org (noarch): BuildError: error building package (arch noarch), mock exited with status 1; see build.log for more information SRPMS: rhnpush-5.5.71-2.fc21.src.rpm Failed tasks: - Task 6997041 on buildvm-23.phx2.fedoraproject.org Task Type: build (f21-rebuild, /rhnpush:6999d408075f1e975020121308af4b58608979c2) Task 7006959 on arm02-builder14.arm.fedoraproject.org Task Type: buildArch (rhnpush-5.5.71-2.fc21.src.rpm, noarch) logs: http://koji.fedoraproject.org/koji/getfile?taskID=7006959name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=7006959name=mock_output.log http://koji.fedoraproject.org/koji/getfile?taskID=7006959name=root.log http://koji.fedoraproject.org/koji/getfile?taskID=7006959name=state.log Closed tasks: - Task 7006815 on arm02-builder20.arm.fedoraproject.org Task Type: buildSRPMFromSCM (/rhnpush:6999d408075f1e975020121308af4b58608979c2) logs: http://koji.fedoraproject.org/koji/getfile?taskID=7006815name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=7006815name=checkout.log http://koji.fedoraproject.org/koji/getfile?taskID=7006815name=mock_output.log http://koji.fedoraproject.org/koji/getfile?taskID=7006815name=root.log http://koji.fedoraproject.org/koji/getfile?taskID=7006815name=state.log Task Info: http://koji.fedoraproject.org/koji/taskinfo?taskID=6997041 Build Info: http://koji.fedoraproject.org/koji/buildinfo?buildID=534110 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Fwd: Package: rhnpush-5.5.71-2.fc21 Tag: f21-rebuild Status: failed Built by: ausil
And the same for spacewalk-backend: http://koji.fedoraproject.org/koji/getfile?taskID=7018053name=build.log Mirek On 06/09/2014 10:45 AM, Miroslav Suchý wrote: Hi, rhnpush is failing on Fedora 21 due pylint. Can somebody can fix before next release please? http://koji.fedoraproject.org/koji/getfile?taskID=7006959name=build.log -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Orphaning spacewalk-branding
Hi, I just orphaned spacewalk-branding. New version have new dependency (bootstrap-less), which is not present in Fedora and I have no intention to package it there. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Some Spacewalk packages orphaned
Hi, I orphaned following packages in Fedora (and EPEL): nocpulse-common perl-NOCpulse-CLAC perl-NOCpulse-Debug perl-NOCpulse-Gritch perl-NOCpulse-Object perl-NOCpulse-SetID perl-NOCpulse-Utils spacewalk-admin They transitively need new package, which is not yet in Fedora. And since I do not use Spacewalk anymore I will not try to get that missing dependency into Fedora. If you want, take them. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Fwd: [ACTION REQUIRED] Packages depending on retired packages
Hi. Unless someone will take over spacewalk-web in Fedora soon I will be forced to orphan nocpulse-common, which force me to orphan all NOCpulse packages. Mirek Original Message Subject: [ACTION REQUIRED] Packages depending on retired packages Date: Wed, 28 Aug 2013 22:53:53 +0200 From: Till Maas opensou...@till.name To: Development discussions related to Fedora de...@lists.fedoraproject.org The following packages are currently retired but other packages depend on them. Since the packages are not yet blocked in koji, this is not very visible. Nevertheless, the packages need new maintainers or the depending packages need to drop dependencies on them. Remarks: - There are no recursive deps in this report, because there are too many especially for libgssglue. - libgssglue might be superseded by the krb5 package - It might happen that the packages will be blocked in the near future, making it impossible to install the affected packages on f20 and later Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Package(co)maintainers === directfb orphan, kwizart libgssglue orphan python-quantumclient orphan, jruzicka, vaneldik, pbrady, apevec, gkotton, markmc, rkukura spacewalk-web orphan tslib orphan The following packages require above mentioned packages: Depending on: directfb xine-lib (maintained by: kkofler, rdieter) xine-lib-extras-1.1.21-7.fc20.i686 requires libdirect-1.6.so.0, libdirectfb-1.6.so.0, libfusion-1.6.so.0 Depending on: libgssglue conserver (maintained by: jkastner) conserver-8.1.18-7.fc19.i686 requires libgssglue.so.1, libgssglue.so.1(libgssapi_CITI_2) conserver-8.1.18-7.fc19.src requires libgssapi-devel = 0.4-2.fc19, libgssglue-devel = 0.4-2.fc19 conserver-client-8.1.18-7.fc19.i686 requires libgssglue.so.1, libgssglue.so.1(libgssapi_CITI_2) libserf (maintained by: cicku, jorton) libserf-1.2.1-4.fc20.src requires libgssapi-devel = 0.4-2.fc19 rdesktop (maintained by: ssp, fab, alexl, caillon, caolanm, hadess, johnp, mbarnes, mclasen, rhughes, rstrode, ssp, xiphmont, rathann) rdesktop-1.8.0-1.fc20.i686 requires libgssglue.so.1, libgssglue.so.1(libgssapi_CITI_2) rdesktop-1.8.0-1.fc20.src requires libgssglue-devel = 0.4-2.fc19 Depending on: python-quantumclient openstack-quantum (maintained by: rkukura, itamarjp, otherwiseguy, mmagr, josecastroleon, vaneldik, pbrady, rackerjoe, apevec, chrisw, gkotton, markmc) python-quantum-2013.2-0.3.b1.fc20.noarch requires python-quantumclient = 2:2.2.1-4.fc20 Depending on: spacewalk-web nocpulse-common (maintained by: msuchy) nocpulse-common-2.2.7-2.fc20.noarch requires perl(RHN::DBI) spacewalk-admin (maintained by: msuchy) spacewalk-admin-2.0.1-2.fc20.noarch requires perl(RHN::SatelliteCert), spacewalk-base = 1.9.22-4.fc20 Depending on: tslib ecore (maintained by: spot, vicodan, terjeros) ecore-1.7.8-2.fc20.i686 requires libts-0.0.so.0 ecore-1.7.8-2.fc20.src requires tslib-devel = 1.0-7.fc20 Affected (co)maintainers alexl: libgssglue apevec: python-quantumclient caillon: libgssglue caolanm: libgssglue chrisw: python-quantumclient cicku: libgssglue fab: libgssglue gkotton: python-quantumclient hadess: libgssglue itamarjp: python-quantumclient jkastner: libgssglue johnp: libgssglue jorton: libgssglue josecastroleon: python-quantumclient jruzicka: python-quantumclient kkofler: directfb kwizart: directfb markmc: python-quantumclient mbarnes: libgssglue mclasen: libgssglue mmagr: python-quantumclient msuchy: spacewalk-web otherwiseguy: python-quantumclient pbrady: python-quantumclient rackerjoe: python-quantumclient rathann: libgssglue rdieter: directfb rhughes: libgssglue rkukura: python-quantumclient rstrode: libgssglue spot: tslib ssp: libgssglue terjeros: tslib vaneldik: python-quantumclient vicodan: tslib xiphmont: libgssglue ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Fwd: rpmconf and new feature to configure application
Hi guys,
I would appreciate your feedback as well.
Original Message
Subject: rpmconf and new feature to configure application
Date: Thu, 25 Jul 2013 14:42:25 +0200
From: Miroslav Suchý msu...@redhat.com
Reply-To: Development discussions related to Fedora
de...@lists.fedoraproject.org
Organization: Red Hat, Registered Address: Red Hat Czech s.r.o.,
Purkynova 99/71, 612 45 Brno, Czech Republic, Registered in Brno under
identification number CZ27690016
To: Development discussions related to Fedora
de...@lists.fedoraproject.org
Hi,
I just built into rawhide new rpmconf(8) which has new feature - to
configure application.
Background:
After each yum upgrade/install you should resolve .rpmnew/.rpmsave
files. Rpmconf(8) will help you with that. But it will not help you with
initial configuration. Especially with installation of layered
applications. In such cases installing rpm packages is not enough. You
must then configure whole application. And the command is different for
each application. It is:
spacewalk-setup for Spacewalk
katello-configure for Katello
sh setup-broker.sh for OpenShift Broker
and something else for projects I even do not know.
And sometimes you need to run upgrade script, sometimes you need to
re-run installation script.
Idea:
If you put all this upgrade/installation scripts on one pile (i.e.
Fedora distribution) it is mess. But if rpmconf can handle
rpmnew/rpmsave files, can it help even here?
If each project/package will provide idempotent installation/upgrade
script, then rpmconf can just run each time rpmconf is executed.
So I put in rpmconf this code (little bit simplified here):
if [ -x /usr/share/rpmconf/$PACKAGE ]; then
/usr/share/rpmconf/$PACKAGE
fi
File /usr/share/rpmconf/$PACKAGE can be interactive or not. Obviously it
should not ask question which has been answered in past. But do whatever
you want and need. Only real condition is that it must be idempotent.
While I have ideas for more complicated solutions, I decided to keep it
simple and stupid. At least for start.
If you want to use this feature, just put in your spec file:
Requires: rpmconf-base
...
%files
%{_datadir}/rpmconf/%{name}
where %{_datadir}/rpmconf/%{name} is that idempotent executable.
I am open to your feedback and suggestions. And if I stabilize it during
F20 and somebody find it useful, then I may propose it as F21 feature.
--
Miroslav Suchy
Red Hat, Software Engineer
--
devel mailing list
de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Fwd: Bug#703582: Possible fix for bug
Can someone please review this patch?
Mirek
Original Message
Subject:Bug#703582: Possible fix for bug
Resent-Date:Mon, 08 Jul 2013 06:36:02 +
Resent-From:carsten.men...@bechtle.com carsten.men...@bechtle.com
Resent-To: debian-bugs-d...@lists.debian.org
Resent-CC: Miroslav Suchý miros...@suchy.cz
Date: Mon, 8 Jul 2013 06:20:33 +
From: carsten.men...@bechtle.com carsten.men...@bechtle.com
Reply-To: carsten.men...@bechtle.com carsten.men...@bechtle.com,
703...@bugs.debian.org
To: 703...@bugs.debian.org 703...@bugs.debian.org
Dear maintainer,
we at Bechtle AG would like to use Spacewalk to manage the software on
our Debian servers.
When registering a Debian Wheezy machine I experienced the bug 703582.
According to the hint in the bug report I was able to identify the
reason for the problem.
In the function getInstalledPackageList(), the installTime() function is
called with the package name only.
Unfortunately this name does not contain the architecture, so that the
installTime() function is not able to check the correct file
(/var/lib/dpkg/info/packagename:arch.list).
So I created a small fix for this in the file
/usr/share/rhn/up2date_client/debUtils.py:
def installTime(pkg_name,*pkg_arch*): *# additional parameter for the
package architecture*
path = '/var/lib/dpkg/info/%s.list' % pkg_name
if os.path.isfile(path):
return os.path.getmtime(path)
else:
* # fix for packages with architecture in the name of the list file*
* path = '/var/lib/dpkg/info/%s:%s.list' %(pkg_name, pkg_arch)*
* if os.path.isfile(path):*
* return os.path.getmtime(path)*
else:
return None
snip
….
def getInstalledPackageList(msgCallback = None, progressCallback = None,
getArch=None, getInfo = None):
...
snip
package = {
'name': pkg.name,
'epoch': epoch,
'version': version,
'release': release,
'arch': pkg.installed.architecture + '-deb',
'installtime': installTime(pkg.name,
*pkg.installed.architecture*) *# additional parameter for the package
architecture*
}
snip
With these modifications, it was possible to register my Debian Wheezy
machine with the package list in Spacewalk.
Could you please implement a fix like this in the rhn-client-tools
package (currently version 1.8.9-3) for Debian Wheezy?
Can you also please tell me, when we can expect, that the fix will be
deployed as an update?
Yours sincerely
Carsten Menzel
Bechtle AG
Bechtle Platz 1
D-74172 Neckarsulm
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Retire some spacewalk packages in Epel and Fedora
On 07/02/2013 05:30 PM, Miroslav Suchý wrote: Hi, I plan to retire package spacewalk-admin in epel, because it requires spacewalk-base perl(RHN::SatelliteCert) which are not in epel. And I plan to retire spacewalk-web in both Fedora and Epel, because it require perl(Spacewalk::Setup). I do not have intention to package those missing deps and I do not use those packages any more. If you want to take over those package raise your voice. Both packages have been retired. -- Miroslav Suchy Red Hat, Software Engineer ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Retire some spacewalk packages in Epel and Fedora
Hi, I plan to retire package spacewalk-admin in epel, because it requires spacewalk-base perl(RHN::SatelliteCert) which are not in epel. And I plan to retire spacewalk-web in both Fedora and Epel, because it require perl(Spacewalk::Setup). I do not have intention to package those missing deps and I do not use those packages any more. If you want to take over those package raise your voice. -- Miroslav Suchy Red Hat, Software Engineer ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Fwd: Bug#708182: apt-transport-spacewalk always tries to install packages that are already installed
FYI: I have no time to investigate it. If someone else can reproduce/comment/fix, it would be appreciated. Mirek Original Message Subject: Bug#708182: apt-transport-spacewalk always tries to install packages that are already installed To: Debian Bug Tracking System sub...@bugs.debian.org Package: apt-transport-spacewalk Version: 1.0.6-2.1 Severity: important Dear Maintainer, * What led up to the situation? 1. install apt-transport-spacewalk 2. register to a spacewalk server 3. install a package from the spacewalk server 4. run apt-get upgrade * What exactly did you do (or not do) that was effective (or ineffective)? run apt-get upgrade * What was the outcome of this action? apt-get attempts to install packages that are alreay installed. root@ms:~# apt-get -V upgrade Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be upgraded: apt-transport-spacewalk (1.0.8-2 = 1.0.8-2) python-rhn (2.5.55-2 = 2.5.55-2) rhn-client-tools (1.9.10-2 = 1.9.10-2) rhnsd (4.9.15-2 = 4.9.15-2) 5 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/664 kB of archives. After this operation, 676 MB of additional disk space will be used. Do you want to continue [Y/n]? n * What outcome did you expect instead? apt-get should not try to install a package that is already installed. -- System Information: Debian Release: 7.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_ZA.UTF-8, LC_CTYPE=en_ZA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages apt-transport-spacewalk depends on: ii apt 0.9.7.8 ii python2.7.3-4 ii python-apt0.8.8.2 ii rhn-client-tools 1.9.10-2 Versions of packages apt-transport-spacewalk recommends: ii rhnsd 4.9.15-2 apt-transport-spacewalk suggests no packages. -- no debconf information -- Miroslav Suchy Red Hat Systems Management Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] L10N : translation of spacewalk java frontend blocked on Transifex
On 03/08/2013 01:55 PM, Jérôme Fenal wrote: Any specific reason why this resource is not accepting translations on Transifex (despite being updated on a regular basis?) : Spacewalk → Java part of java frontend https://fedora.transifex.com/projects/p/spacewalk/resource/java-part-of-java-frontend/ Because XLIFF support does not work. tl;dr version: Once upon a time, Transifex did not support XLIFF for translations. But we use XLIFF for java part and we use Transifex for other parts of Spacewalk (but there is used .po format). So I spent few days and wrote initial support for XLIFF, but was unable to test it. But Transifex guys accepted it and started working on that and at one point transifex.com got support for XLIFF. So at that point it was my first moment when I was actually able to test it and import our files. And I find that is mostly works. Mostly. The XLIFF standard is quite comprehensive and we use quite a lot of its features. So I reported those parts which does not work to Transifex. Some of them were addressed, but some of them are still pending (AFAIK). So once Transifex will support full XLIFF standard we may enable this resource in Transifex. In fact last problem I recall was: https://getsatisfaction.com/indifex/topics/xliff_parser_stop_on_tag which they claimed to fix, but was not fixed (or not completly). But that was one year ago. It may be worth if somebody will try it again. -- Miroslav Suchy Red Hat Systems Management Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Fwd: Permanent failure of automatic update of source file: Spacewalk: spacewalk-backend
On 01/25/2013 09:47 AM, Miroslav Suchy wrote: We have not been able to update the source file of the resource 'spacewalk-backend' of the project 'Spacewalk' from the URL https://fedorahosted.org/spacewalk/browser/backend/po/server.pot?format=txt for some time now. So, we are disabling this feature. The exact error we FYI: I fixed it. New urls are: http://git.fedorahosted.org/cgit/spacewalk.git/plain/client/rhel/rhn-client-tools/po/rhn-client-tools.pot http://git.fedorahosted.org/cgit/spacewalk.git/plain/backend/po/server.pot Transifex should now automatically fetch new translation sources. -- Miroslav Suchy Red Hat Systems Management Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] [PATCH] systemd services for rhnsd and osad
I done that some weeks ago, while traveling by train.
I did not have time to test it thoroughly, and I will probably have no
time for that in future. So I'm posting it here.
Decide yourself, if you want to merge it, or leave it for somebody else
who will work on systemd integration.
--
Miroslav Suchý
Red Hat Satellite Engineering
From 1e9dcfd8016d85888c02d44d50a611f0987f6090 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Miroslav=20Such=C3=BD?= msu...@redhat.com
Date: Fri, 15 Jun 2012 11:46:44 +0200
Subject: [PATCH 1/3] implement rhnsd.service for systemd
---
client/rhel/rhnsd/rhnsd.service | 11 +++
client/rhel/rhnsd/rhnsd.spec| 30 +++---
2 files changed, 38 insertions(+), 3 deletions(-)
create mode 100644 client/rhel/rhnsd/rhnsd.service
diff --git a/client/rhel/rhnsd/rhnsd.service b/client/rhel/rhnsd/rhnsd.service
new file mode 100644
index 000..14b3e3b
--- /dev/null
+++ b/client/rhel/rhnsd/rhnsd.service
@@ -0,0 +1,11 @@
+[Unit]
+Description=Red Hat Network Server daemon
+After=syslog.target network.target auditd.service
+
+[Service]
+PIDFile=/var/run/rhnsd.pid
+ExecStart=/usr/sbin/rhnsd
+ExecReload=/bin/kill -HUP $MAINPID
+
+[Install]
+WantedBy=multi-user.target
diff --git a/client/rhel/rhnsd/rhnsd.spec b/client/rhel/rhnsd/rhnsd.spec
index 5c9d4c0..711b188 100644
--- a/client/rhel/rhnsd/rhnsd.spec
+++ b/client/rhel/rhnsd/rhnsd.spec
@@ -4,7 +4,7 @@ Group: System Environment/Base
Source0: https://fedorahosted.org/releases/s/p/spacewalk/%{name}-%{version}.tar.gz
URL: https://fedorahosted.org/spacewalk
Name: rhnsd
-Version: 4.9.15
+Version: 5.0.0
Release: 1%{?dist}
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
@@ -15,6 +15,13 @@ Requires: rhn-check = 0.0.8
Requires(post): aaa_base
Requires(preun): aaa_base
BuildRequires: sysconfig
+%elsif 0%{?fedora} || 0%{?rhel} 5
+Requires(post): chkconfig
+Requires(preun): chkconfig
+Requires(post): systemd-sysv
+Requires(preun): systemd-sysv
+Requires(post): systemd-units
+Requires(preun): systemd-units
%else
Requires(post): chkconfig
Requires(preun): chkconfig
@@ -41,6 +48,11 @@ make -f Makefile.rhnsd install VERSION=%{version}-%{release} PREFIX=$RPM_BUILD_R
%if 0%{?suse_version}
install -m 0755 rhnsd.init.SUSE $RPM_BUILD_ROOT/%{_initrddir}/rhnsd
%endif
+%if 0%{?fedora} || 0%{?rhel} 5
+rm $RPM_BUILD_ROOT/%{_initrddir}/rhnsd
+mkdir -p $RPM_BUILD_ROOT/%{_unitdir}
+install -m 0644 rhnsd.service $RPM_BUILD_ROOT/%{_unitdir}/
+%endif
%find_lang %{name}
@@ -50,14 +62,22 @@ install -m 0755 rhnsd.init.SUSE $RPM_BUILD_ROOT/%{_initrddir}/rhnsd
%preun
if [ $1 = 0 ] ; then
-/etc/rc.d/init.d/rhnsd stop /dev/null 21
+%if 0%{?fedora} || 0%{?rhel} 5
+/bin/systemctl stop rhnsd /dev/null 21
+%else
+service rhnsd stop /dev/null 21
+%endif
/sbin/chkconfig --del rhnsd
fi
%postun
if [ $1 -ge 1 ]; then
-/etc/rc.d/init.d/rhnsd condrestart /dev/null 21 || :
+%if 0%{?fedora} || 0%{?rhel} 5
+/bin/systemctl condrestart rhnsd /dev/null 21 || :
+%else
+service rhnsd condrestart /dev/null 21 || :
+%endif
fi
%clean
@@ -68,7 +88,11 @@ rm -fr $RPM_BUILD_ROOT
%dir %{_sysconfdir}/sysconfig/rhn
%config(noreplace) %{_sysconfdir}/sysconfig/rhn/rhnsd
%{_sbindir}/rhnsd
+%if 0%{?fedora} || 0%{?rhel} 5
+%{_unitdir}/rhnsd.service
+%else
%{_initrddir}/rhnsd
+%endif
%{_mandir}/man8/rhnsd.8*
%doc LICENSE
--
1.7.10.4
From b7bef2628996765fc0e67412bfefe772dd5ae30f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Miroslav=20Such=C3=BD?= msu...@redhat.com
Date: Sun, 17 Jun 2012 17:16:57 +0200
Subject: [PATCH 2/3] implement osad.service for systemd
---
client/tools/osad/osad.service | 11 +++
client/tools/osad/osad.spec| 31 ---
2 files changed, 35 insertions(+), 7 deletions(-)
create mode 100644 client/tools/osad/osad.service
diff --git a/client/tools/osad/osad.service b/client/tools/osad/osad.service
new file mode 100644
index 000..5597571
--- /dev/null
+++ b/client/tools/osad/osad.service
@@ -0,0 +1,11 @@
+[Unit]
+Description=OSAD daemon
+After=syslog.target network.target
+
+[Service]
+EnvironmentFile=-/etc/sysconfig/osad
+PIDFile=/var/run/osad.pid
+ExecStart=/usr/sbin/osad --pid-file $PIDFile
+
+[Install]
+WantedBy=multi-user.target
diff --git a/client/tools/osad/osad.spec b/client/tools/osad/osad.spec
index cba0768..dd74885 100644
--- a/client/tools/osad/osad.spec
+++ b/client/tools/osad/osad.spec
@@ -16,7 +16,7 @@ Group: System Environment/Daemons
License: GPLv2
URL: https://fedorahosted.org/spacewalk
Source0: https://fedorahosted.org/releases/s/p/spacewalk/%{name}-%{version}.tar.gz
-Version: 5.10.44
+Version: 5.11.0
Release: 1%{?dist}
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
@@ -35,17 +35,24 @@ Requires: PyXML
%endif
Conflicts: osa-dispatcher %{version}-%{release}
Conflicts: osa-dispatcher %{version}-%{release}
-%if !0
Re: [Spacewalk-devel] [PATCH] systemd services for rhnsd and osad
On 07/19/2012 04:46 PM, Franky Van Liedekerke wrote: But in RHEL6, systemctl is not present as a command, service should still be used (systemd is not present in rhel6). Or am I misreading this? Yes, you are correct. Systemd is not present on RHEL6. I have it incorrect there. -- Miroslav Suchy Red Hat Systems Management Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] type error when trying to register an ubuntu 12.04 system
On 07/03/2012 09:20 PM, william wrote:
I have a few packages which don't have the file with that name in the
/var/lib/dpkg/info directory.
e.g.
e2fslibs is installed:
ii e2fslibs 1.42-1ubuntu2 ext2/ext3/ext4 file
system libraries
which has the corresponding list file
ls /var/lib/dpkg/info/e2fslibs\:amd64.*
e2fslibs:amd64.list e2fslibs:amd64.md5sums e2fslibs:amd64.postinst
e2fslibs:amd64.postrm e2fslibs:amd64.shlibse2fslibs:amd64.symbols
so should the function be updated to look for e2fslibs:amd64 or i386 or
is the package name just false and should this be updated (file bug
report to ubuntu about the name)?
thats about 422 packages on my current desktop. But this is about the
installtime so we could also return just 0 or epoch?
I do not have Ubuntu. Just good plain Debian. But anyway - let assume
there is no difference:
I tried this command on my machine:
# for i in $(dpkg -l |grep ii |awk '{print $2}' ); do ls
/var/lib/dpkg/info/${i}.list /dev/null; done
and I get empty output. So in my system I have
/var/lib/dpkg/info/${package_name}.list for every package.
This was run on Sid, but I should have even old lenny somewhere... Yes,
still the same. File for every package.
So I would say it is Ubuntu problem (or you have corrupted package db).
If you feel it is not your local problem, please file Ubunutu bug report.
--
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] ubuntu dependancy python-hwdata and support for 3.x kernels for memory information
On 07/03/2012 10:29 PM, william wrote: after investigation i saw it could not import hwdata so i manually installed python-hwdata and it started to work. python-hwdata should be a dependancy for rhn (maybe it should be packaged, not sure) Good point, will try to fix that in next release. Also my current kernel is version 3.2 (ubuntu 12.04) but the hardware.py file only checks for uname 2.4 and uname 2.6 so i added if kernel[:3] == 3: return read_memory_2_6() to hardware.py def read_memory(): un = os.uname() kernel = un[2] if kernel[:3] == 3: return read_memory_2_6() if kernel[:3] == 2.6: return read_memory_2_6() if kernel[:3] == 2.4: return read_memory_2_4() and now the memory information gets collected and pushed to spacewalk. Indeed. Commited as 4e48c16. Thanks for investigation. -- 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] spacewalk-backend-xp package is missing at nightly repo for RHEL6
On 07/04/2012 12:32 AM, Marcelo Moreira de Mello wrote:
Should we fix the SPEC in order to automatically remove the
spacewalk-backend-xp instead showing the RPM conflicting message?
Package spacewalk-backend-app do that:
Obsoletes: spacewalk-backend-xp 1.8.33
Provides: spacewalk-backend-xp = %{version}-%{release}
So you should investigate why yum does not decided to upgrade
spacewalk-backend-app. Did you run yum upgrade or some other command?
--
Miroslav Suchy
Red Hat Satellite Engineering
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Debian BSP post-mortem
As you may know I visited Debian Bug Squashing Party at Salzburg this week. And together with Bernd Zeimetz we tried to package Spacewalk packages to official Debian repository. And we succeeded in most important stuff. We reviewed, packaged and tested those packages: * python-ethtool * rhnlib (in debian python-rhn) * rhn-client-tools (as oposed to Fedora, all rhn-client-tools, rhn-setup, rhn-check and rhn-setup-gnome in Debian they are all in one package) * rhnsd * apt-spacewalk (transport protocol for apt-get) * and we tested Simon patch for apt. The code was recently refactored, so I had to rebased it and test it. The result is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677871 All packages are: Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. So they should land in Sid soon. And in one month is freeze so few weeks (or months, you know Debian) it can land in stable. We had not time for the rest of packages (rhncfg, osad, rhn-custom-info etc.). So we are still looking for Debian Developer who will package the rest or clients packages. And now some photos: http://www.salzburg-cityguide.at/de/partyzone/detail/debian-bug-squashing-party---conova_102492/debian-bug-squashing-party---conova_87847?page=1#title -- Miroslav Suchy Red Hat Satellite Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] GPL and OpenSSL licensing issue
I learned from Debian guys about this problem: http://people.gnome.org/~markmc/openssl-and-the-gpl.html So I take the liberty and put in every file where we have: import OpenSSL the clause that it can be linked against openssl: https://fedorahosted.org/spacewalk/changeset/9b930abf494222ccf4c086bb354db73950c15217 I expect that everybody agree, but Cliff you may want to ask legals, if the wording is fine with them. -- Miroslav Suchý Red Hat Satellite Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Fwd: Kickstart Create Distribution Error - Traceback Included (NIGHTLY)
On 06/16/2012 02:35 AM, Steven Crothers wrote: Hello everyone, I've been working on trying to fix a few bugs that I've recently been running into with Spacewalk. Sending it to one mailing list is usually sufficient. -- Miroslav Suchý Red Hat Satellite Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] option standard_conforming_strings in Pg breaks our code and data.
If you look at commit:
d8744d1693c1fc6e231278dd9a6537f269371192
and the code:
+if self.blob_map:
+for blob_var in self.blob_map.keys():
+ kw[blob_var] = kw[blob_var].replace('\\', '')
This worked fine in default Pg till version 9.0, but the behavior
depends on server side setting of option standard_conforming_strings
(boolean):
http://www.postgresql.org/docs/9.1/static/runtime-config-compatible.html
and this option changed its default value in 9.1. Which caused that this
statement corrupts data if \char appears in blob.
Why we could not use ordinary prepare here?
--
Miroslav Suchý
Red Hat Satellite Engineering
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] YUM RHN Lock Plugin
On 06/13/2012 10:45 PM, Musayev, Ilya wrote: Am I correct in my assumptions and would the proposed changes be acceptable? You are very correct and yes that would be acceptable. -- 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] YUM RHN Lock Plugin
On 06/08/2012 12:32 AM, Musayev, Ilya wrote:
The proof of concept code is below - if you could make any suggestions and
improvements - it would be appreciated.
Instead of getSystemID(xml) you can use:
from rhn import rpclib
system_id = re.sub('^ID-', '',
rpclib.xmlrpclib.loads(up2dateAuth.getSystemId())[0][0]['system_id'])
Instead of:
client = xmlrpclib.Server(SATELLITE_URL, verbose=0)
key = client.auth.login(SATELLITE_LOGIN, SATELLITE_PASSWORD)
you can do:
cfg = config.initUp2dateConfig()
satellite_url = config.getServerlURL()[0]
scheme, netloc, path, query, fragment = \
urlparse.urlsplit(satellite_url)
satellite_url = urlparse.urlunsplit((scheme, netloc, '/rpc/api',
query, fragment))
client = xmlrpclib.Server(satellite_url, verbose=0)
This seems to be longer and complicated, but you get spacewalk url from
config and you will get all url of possible parents. You may have more
then once for fail over.
It would be nice if you do instead of:
satellite_url = config.getServerlURL()[0]
loop over all items in config.getServerlURL() if some network error happen.
Additionaly I would change:
enabled=1
to 0. Because it will cause huge problem to people who install it, but
did not register to Spacewalk server.
Anyway - good idea. If you will polish it and test it, I will be happy
to merge it to yum-rhn-plugin.
--
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] Deployment of images built with SUSE Studio
On 05/21/2012 10:35 AM, Uwe Gansert wrote: the reason we only support kvm and xen images Ehm, how do you support KVM? I anticipate that for KVM is supposed DiskImage format. But it does not show up in Spacewalk WebUI, although it is created in SuseStudio. -- 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] Deployment of images built with SUSE Studio
On 05/21/2012 01:45 PM, Uwe Gansert wrote: On 21.05.2012 13:19, Miroslav Suchý wrote: the reason we only support kvm and xen images Ehm, how do you support KVM? I anticipate that for KVM is supposed DiskImage format. But it does not show up in Spacewalk WebUI, although it is created in SuseStudio. with the vmware/virtualbox/kvm (vmdk) image You should see the vmdk image in the webui we support vmdk and xen so far Aha I see: +// List of all valid image types +private static ListString validImageTypes = Arrays.asList(vmx, xen); Any problem with DiskImage? Can you add it to list of valid Images? -- 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] Deployment of images built with SUSE Studio
On 05/18/2012 05:11 PM, Miroslav Suchy wrote: I still have to test the client part. in spec: Requires: python-curl In Fedora/RHEL the package is called python-pycurl, please fix it using %if After image is scheduled, you land on: /rhn/systems/details/virtualization/VirtualGuestsList.do I would prefer to stay on: /rhn/systems/details/virtualization/Images.do Beside that I do not see another problem. So please fix that and I will be happy to commit those patches. -- 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] spacecmd wrapper staging scripts on github : RFC re inclusion in spacewalk?
On 04/24/2012 12:18 PM, Steven Hardy wrote: Also wondering if there's any interest in including these (and other similar scripts) in spacewalk, either as part of the spacecmd package, say under/usr/share/spacecmd/scripts/, or in some other package? We have /utils/ where goes scripts which can be useful for lots of people, and which are clean and commiter is willing to maintain it. This is packaged as spacewalk-utils, so you have to care about Requires in .spec. Then we have /scripts/ which is not packaged, so has lower barrier to entry. But still - please do not put there every script which has spacewalk somewhere in code. -- 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] [PATCH] Fix errata clone name generation in perl code
On 04/23/2012 03:11 PM, Johannes Renner wrote: In the long run I guess we should definitely rather rewrite those pages in Java, instead of maintaining both of the code stacks. Was there a specific reason for the errata cloning page, why it was not rewritten? Or is it just remaining by accident? Because: https://fedorahosted.org/spacewalk/wiki/RemainingPxtPages -- 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] [PATCH] Fix errata clone name generation in perl code
On 04/23/2012 03:11 PM, Johannes Renner wrote: Attached, please find the new algorithm for name generation of cloned errata, written in Perl! Commited as 41ee9a76ec59496c120a4dfae08a87e93f752633 Thanks! -- 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] Deployment of images built with SUSE Studio
On 04/13/2012 10:24 AM, Uwe Gansert wrote:
+def _md5(path):
Could not you flip to sha1 or sha256?:
I know that md5 is not state of the are anymore but we need to use that
because Studio provides the checksum in md5.
We should change that in Studio but for now it's like that.
OK. I expected something like, that. It seems fair.
+# this is not nice but tarfile.py does not support
+# sparse file writing :(
I did not test it but:
http://docs.python.org/library/tarfile.html
say:
The GNU tar format (GNU_FORMAT). It supports long filenames and
linknames, files bigger than 8 gigabytes and sparse files. It is the de
facto standard on GNU/Linux systems. tarfile fully supports the GNU tar
extensions for long names, sparse file support is read-only.
the last three words are the problem.
read-only for sparse files :/
Aha :)
+%dir %{rhn_conf_dir}
This is not needed. This directory is already owned by rhn-client-tools,
which are required by rhn-virtualization-common
it's needed for our build service or our BS will cry about directory
not owned by any package after building. Unless I add a package to the
BUILDREQUIRES that owns that directoy already - but it would be bad to
change the BUILDREQUIRES just for that.
I can remove that %dir for Red Hat in the spec file but not for SUSE
Yes, please use:
%if 0%{?suse_version} ...
for that.
--
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] Fwd: [Fedora Update] [comment] cobbler-2.2.1-1.el5
On 04/13/2012 04:12 PM, James Hogarth wrote: cobbler-2.2 appeared today on my EPEL6 sync ... broke my SW provisioning until I recalled about this Is there an open bugzilla ticket already for carrying out any work required to make SW happy with cobbler-2.2? RHEL6 should not be broken. Just EL5 and that fixed adelton in commit 7e7129fe35d0bd0e762a947eddb3e761797466bc -- 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] Status of Debian support in Spacewalk
I have been approached by Debian developer Alexander Wirt. And Bernd Zeimetz invited me to BSP in Salzburg: http://wiki.debian.org/BSP/2012/06/at/Salzburg I hope that Alexander, Bernd and I will be able to get there Spacewalk packages into Debian. If somebody is interested in Spacewalk and Debian I would be happy to see you in Salzburg in June. P.S. To Steven and Eduardo - this does not mean that you should stop trying packaging Debian packages. We still need maintainer(s). In Salzburg we just may get packages to 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] bz 811990 proxy auth cache patch
On 04/12/2012 03:26 PM, Shannon Hughes wrote: Attaching a patch for review against proxy. Proxy continues to cache the authentication token across requests that have different parsed hostnames from the rhn proxy borker logic(ip vs canonical) for the current proxy. This cache forces the spacewalk server to generate incorrect kickstart files since it uses the proxy auth header to know what hostname to replace in the generated kickstart file. full details are in the spacewalk bug https://bugzilla.redhat.com/show_bug.cgi?id=811990 Ah, I already answered in: https://bugzilla.redhat.com/show_bug.cgi?id=811990#c1 -- 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] Deployment of images built with SUSE Studio
On 03/30/2012 04:46 PM, Johannes Renner wrote:
On 03/27/2012 02:53 PM, Miroslav Suchý wrote:
I'm looking forward to see your patches.
Ok, here they are. They apply to spacewalk master and I tried to not forget
anything.
The last patch is about fixing checkstyle issues only, while the other ones are
about
patching the respective parts of Spacewalk, not very intrusive though.
Oh yes, there is two new required jar files, while RPM packages + spec files
can be
found here:
-
https://build.opensuse.org/package/show?package=susestudio-java-clientproject=Java%3Abase
- https://build.opensuse.org/package/show?package=simple-xmlproject=Java%3Abase
The reason why susestudio-java-client currently requires simple-xml is that it
is
supposed to run on Android as well, where javax.xml.* classes are not available.
+CREATE TABLE suseCredentials
...
+type VARCHAR2(32) NOT NULL,
+CREATE TABLE rhnActionImageDeploy
...
+image_typeVARCHAR2(32) NOT NULL,
Hmm, can we normalize those table. I suppose that type is something
enumarated. In such case I would put those values in separate table and
here put just reference.
+bridge_device VARCHAR2(32) DEFAULT('br0') NOT NULL,
Really not null? I'm sure I had some virtual machines without network.
+url = row['download_url']
+proxy_server = row['proxy_server']
+proxy_user= row['proxy_user']
+proxy_pass= row['proxy_pass']
+mem_kb= row['mem_kb']
+vcpus = row['vcpus']
+bridge_device = row['bridge_device']
+
+if row['image_type'] == 'vmx':
+image_type = 'vmdk'
+elif row['image_type'] == 'xen':
+image_type = 'xen'
+else:
+raise InvalidAction(image.deploy: invalid image_type)
+
+
+return (url, proxy_server, proxy_user, proxy_pass, mem_kb, vcpus,
image_type, bridge_device)
That assigment is overkill. Can you just:
return (row['download_url'] ...)
you will save 6 lines. But this is really no blocker. :)
+++ b/backend/server/action_extra_data/image.py
...
+def deploy(server_id, action_id, data={}):
+if not data:
+return
+log_error(action_error.image.deploy: Should do something
+useful with this data, server_id, action_id, data)
log_error? really?
That would couse traceback IIRC. if you do not know what to do with
returned data just call pass or log_debug.
+++ b/client/tools/rhn-virtualization/actions/image.py
...
+sys.path.append(/usr/share/rhn/)
+import virtualization.support as virt_support
+from virtualization.util import hyphenize_uuid
+
+sys.path.append(/usr/share/rhn/)
I'm sure one append is enough.
+IMAGE_BASE_PATH = /var/lib/libvirt/images/
+STUDIO_KVM_TEMPLATE = /etc/sysconfig/rhn/studio-kvm-template.xml
+STUDIO_XEN_TEMPLATE = /etc/sysconfig/rhn/studio-xen-template.xml
Can this be defined in config file? That would be awesome.
+if os.path.isfile(STUDIO_KVM_TEMPLATE):
+f = open(STUDIO_KVM_TEMPLATE, 'r')
+KVM_CREATE_TEMPLATE = f.read()
+f.close()
+
+if os.path.isfile(STUDIO_XEN_TEMPLATE):
+f = open(STUDIO_XEN_TEMPLATE, 'r')
+XEN_CREATE_TEMPLATE = f.read()
+f.close()
Duplicate code. I would prefer to create function which read content of
file.
+def deploy(downloadURL, proxyURL=, proxyUser=, proxyPass=,
memKB=524288, vCPUs=1, imageType=vmdk, virtBridge=xenbr0,
extraParams=,cache_only=None):
I would try to persuade you to not pass every single attribute as
specific attribute of this function.
We had several problems with that in past.
The problem is that if you would pass another attribute (e.g storage
location) next year, you could not do that easily.
Because if you pass this action with additional storage_location
attribute (even if it will be set to ) to client which could not
handle it, than it will traceback. So you will have to use and check
capabilities (which is PITA).
If you pass these values as dictionary, you will save yourself lots of
problems in future.
Additionally you do not use attribute cache_only at all. That is bad.
If cache_only is true you should not execute this action and you just
prepare this action. I.e. action packages.install will download packages
to /var/cache/yum so when the action is really executed, then those rpm
are already downloaded and the action is executed faster.
If you do not want to implement or it does not make sense for you, then
just put at the top of this function:
if cache_only:
return (0, no-ops for caching, {})
Although as I can see, in your case you can take advance from this
framework and put this if before:
+# image exists in /var/lib/libvirt/images/image-name now
which means after:
_getImage(fileName,downloadURL,proxySettings)
if it needs to be called.
+def _md5(path):
Could not you flip to sha1 or sha256?:
https://www.google.cz/search?q=md5%20not%20safehl=cslr=
I know we use md5 on several places, but new things should not start
with md5. But if this can not be done
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 03/30/2012 04:46 PM, Johannes Renner wrote: Oh yes, there is two new required jar files, while RPM packages + spec files can be found here: -https://build.opensuse.org/package/show?package=susestudio-java-clientproject=Java%3Abase -https://build.opensuse.org/package/show?package=simple-xmlproject=Java%3Abase The reason why susestudio-java-client currently requires simple-xml is that it is supposed to run on Android as well, where javax.xml.* classes are not available. I see no problem with these two. They cleanly build on my Fedora. Once you clean up issues with your patch I can import them to our koji. -- Miroslav Suchy Red Hat Satellite Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] [PATCH] enhancement for spacecmd
Can somebody (Steven or Aron) review this patch please?: https://bugzilla.redhat.com/show_bug.cgi?id=809905#c0 -- 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] [PATCH] Added systemd unit files
On 04/02/2012 11:42 PM, Pablo Hess wrote: Hello Folks, In an effort to port Spacewalk's sysV init script to the all-new-and-shiny systemd, Marcelo Mello and I have created quite a few unit files (systemd speak for init script). Due to service dependencies, we want to propose a new layout to make it compatible with the systemd approach. Mandatory and dependent services --- Since Spacewalk is not a daemon, but a collection of daemons, we created a target-type file (named spacewalk.target) which will just call all child services required by Spacewalk (jabberd, osa-dispatcher, tomcat, httpd, rhn-search, cobbler and taskomatic). On start, stop, restart and reload, spacewalk.target will perform the same action on all dependencies. The idea of having separate target is interesting, But I'm not sure if it is wise. We already have script spacewalk-service and since it just wrapper around service command, it works on RHELs and Fedoras. No matter if system-V or systemd is used. We also had to include dependency info in a few of those services, so we named them spacewalk-SERVICENAME, as in spacewalk-httpd, spacewalk-cobblerd and spacewalk-tomcat6. The original httpd, cobblerd and tomcat6 service files remain untouched. However, starting the original httpd service file will immediately stop spacewalk-httpd, and so on for cobblerd and tomcat6. Why? Why should I have two services for one binary command (e.g httpd or tomcat). I would not touch or care about tomcat* httpd, cobbled and jabberd. They provide their own systemd unit files. Independent services DB_service (postgresql) and Monitoring and MonitoringScout - since these services are not mandatory for running Spacewalk, they will require a second step from the sysadmin which is to enable it manually: Do not worry about DB. DB is and always have been managed separately. Monitoring and MonitoringScout are in sys-v started always. Just when they determine that they are not enabled, they will exit. # systemctl enableservice.service For example: # systemctl enable MonitoringScout.service What is wrong on chkconfig which works with both sys-v and systemd? Changes for sysadmins Systemd is different from sysV and Upstart and it requires a few changes in the way sysadmins enable the Spacewalk service. For instance, if the DB service is independent from Spacewalk, then a regular systemctl enable spacewalk.target should suffice. However, if the DB service is PostgreSQL and its only reason to live is to serve Spacewalk, it should be associated to the Spacewalk service file like this: # systemctl enable spacewalk-postgresql.service Again do not worry about DB. If you would like to not make regression. Then you have to parse (in fact execute) /etc/rhn/service-list, where admin can set variable SERVICES and override the default which is (in script spacewalk-service): if [ -x /etc/init.d/oracle ]; then DB_SERVICE=oracle fi if [ -x /etc/init.d/tomcat5 ]; then TOMCAT=tomcat5 fi if [ -x /etc/init.d/tomcat6 -o -x /lib/systemd/system/tomcat6.service ]; then TOMCAT=tomcat6 fi SERVICES=jabberd $DB_SERVICE $TOMCAT httpd osa-dispatcher Monitoring MonitoringScout rhn-search cobblerd taskomatic if [ -f /etc/rhn/service-list ] ; then . /etc/rhn/service-list fi +++ b/spacewalk/systemd-units/MonitoringScout.service @@ -0,0 +1,14 @@ +[Unit] +Description=NOCpulse Monitoring Scout +After=Monitoring.service +Before=rhn-search.service Why is there that Before? rhn-search can be started in paralel with Monitoring. +++ b/spacewalk/systemd-units/osa-dispatcher.service @@ -0,0 +1,15 @@ +[Unit] +Description=osa-dispatcher daemon used by Spacewalk +Before=spacewalk-tomcat6.service Tomcat needs osa-dispatcher? +After=spacewalk-db.target +++ b/spacewalk/systemd-units/spacewalk-db.target @@ -0,0 +1,5 @@ +[Unit] +Description=Spacewalk Database +After=jabberd.service + +[Install] This can be tricky. And I currently do not know how to say start after db is up. Especially when db is oracle or postgresql. +++ b/spacewalk/systemd-units/rhn-search.service @@ -0,0 +1,14 @@ +[Unit] +Description=Spacewalk search engine +After=spacewalk-httpd.service +After=Monitoring.service MonitoringScout.service +Before=spacewalk-cobblerd.service Again, why is there Before? And why is there this line: +After=Monitoring.service MonitoringScout.service at all? +ExecStart=/etc/init.d/osa-dispatcher start +ExecStop=/etc/init.d/osa-dispatcher stop +PIDFile=/var/run/osa-dispatcher.pid You define ExecStart and ExecStop in this manner for all service. Which does not have sense for me. Why not use directly?: EnvironmentFile=/etc/sysconfig/osa-dispatcher ExecStart=/usr/sbin/osa-dispatcher --pid-file /var/run/osa-dispatcher.pid PIDFile=/var/run/osa-dispatcher.pid -- Miroslav Suchy Red Hat Satellite Engineering
Re: [Spacewalk-devel] ivy
On 03/28/2012 10:38 AM, Tomas Lestach wrote: Where do you see, we use ivy? I believe we do not require ivy in run or build time. Well it was written here: https://fedorahosted.org/spacewalk/wiki/GettingPackagesIntoFedora and $ git grep ivy |wc -l 47 So you are saing that we do not use it at all for ordinary installation? Good. I will remove it from list GettingPackagesIntoFedora. -- 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] Provisioning
On 03/28/2012 09:08 AM, duncan.in...@virginmoney.com wrote: I wondered if it would add any useful functionality to be able to create a boot.kernel.org-style image on the Spacewalk/Satellite server. The resultant image would then boot a system and go direct to the Spacewalk server for instructions. I know it's a basic copy of PXE booting, but it allows this functionality to exist in a few key areas. What is boot.kernel.org? (asked Google) - Aha. If I understand it correctly it is the same thing as cobbler makeiso [1]. Yes, that would be useful. And since Spacewalk already use cobbler, integrate Spacewalk with cobbler makeiso can be relatively easy. [1] https://fedorahosted.org/cobbler/wiki/BuildIso -- 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] SysV to Systemd
On 12/13/2011 03:48 AM, Marcelo Moreira de Mello wrote: On 12/06/2011 01:52 PM, Miroslav Suchy wrote: FYI: http://fedoraproject.org/wiki/Features/SysVtoSystemd We will need to migrate from SysV init scripts to Systemd to support Fedora 17. This is still 5 months ahead, but if somebody is boring, then you can grab this task. :) Mirek ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel Hello Mirek, I'm working on this. I'll send a mail when it be ready. Hi Marcelo, what is status of your work? -- 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] Deployment of images built with SUSE Studio
On 03/27/2012 10:27 AM, Johannes Renner wrote: The feature involves a new action type to be put in table rhnActionType, which we chose to give the ID 500 for now (just to make sure there will be no clash in the near future). Would you maybe want to provide us with an ID for this action that we can safely use throughout the future or what is the preferred procedure here? We are not going to assign ID for action which is not in our master. If you ever decide to contribute your work to Spacewalk project, you can take advantage to have it in upstream and no one will override that id. If you decide - for whatever reason - to keep it private, you will have to live with the fear and uncertainty that one day we will use that id for something else. -- Miroslav Suchy Red Hat Satellite Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Status of Debian support in Spacewalk
I just upgraded some Debian client packages and put them on my site. But I would like to point that I have nearly no time for that packaging and those packages are ugly (lintian gives me two screen of warnings). So I would really like to see some volunteer, who will take over Debian packaging. If nobody will volunteer, there is high chance that Debian support will be dropped at all. And that would be shame. Raise your hand if you are familiar with Debian or you know some Debian developer who can find Spacewalk attractive. I can help with that Debian and give the pointers, but I could not do all that work it require. -- 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] All relevant errata as All Errata
On 03/02/2012 03:41 PM, Duncan Mac-Vicar P. wrote: I suggest to change it to All Types un both Errata-All and Errata-Relevant. +1 -- 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] API date inconsistency : channel.software.listErrata
On 02/14/2012 10:24 AM, Steven Hardy wrote: Planning to raise a Bz for this issue, but wanted to post it here for comments first. So the problem is the channel.software.listErrata calls handle dates inconsistently, with some using the errata issue date (which is what I expect unless explicitly mentioned otherwise in the docs), and others interpreting arguments (and returning dates) based on the last *modified* date, which obviously may change so is not a good key for selecting errata. Specifically: snip from the API docs Method: listErrata Description: List the errata applicable to a channel between startDate and endDate. Parameters: * string sessionKey * string channelLabel - channel to query * dateTime.iso8601 startDate * dateTime.iso8601 endDate Returns: * array: * struct - errata * int id - Errata ID. * string date - Date erratum was created. * string advisory_synopsis - Summary of the erratum. * string advisory_type - Type label such as Security, Bug Fix * string advisory_name - Name such as RHSA, etc /snip AFAICT this call is broken - it says that the returned date field is the date the erratum was created, but this is a lie - it's really the date the errata was*last modified*. I did not tried to reproduce it, but yes I see it in code. True. You find that we are lying, then feel free to fix it :) -- 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] [PATCHES] two patches for SUSE support
On 01/17/2012 11:40 AM, Michael Calmer wrote: Hi, Am Dienstag, 17. Januar 2012, 10:54:45 schrieb Jan Pazdziora: On Mon, Jan 16, 2012 at 04:48:17PM +0100, Michael Calmer wrote: [...] Renamed in Spacewalk master and rhn-client-tools-1.7.5-1. Thanks for pointing this issue out. Thanks. I have a new patch attached which define YumBaseError and RepoError also in SUSE. Commited as 1417f0700405f27f13309d12fc41603fd37b72a4. Thanks. -- Miroslav Suchy Red Hat Satellite Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Spacewalk's year 2011 in numbers
Let me allow to summarize year of 2011. I gathered some numbers for you: == Code == We commited 3810 changesets to Spacewalk http://miroslav.suchy.cz/spacewalk/gitstat/chart.php?chart_parameter1=2showcount=10submit=1page=0 Top contributor is Jan Pazdziora (again) with 953 commits. Top contributor outside of Red Hat is Michael Calmer with 52 commits. http://miroslav.suchy.cz/spacewalk/gitstat/chart.php?chart_parameter1=5chart_parameter_ver=spacewalk-backend-1.7.1-1submit=1chart_parameter2_year=2011chart_parameter2_month=0submit=1showcount=10 We resolved 1206 Bugs. https://bugzilla.redhat.com/buglist.cgi?chfieldto=Nowquery_format=advancedchfield=bug_statuschfieldfrom=2011-01-01bug_status=CLOSEDclassification=Red%20Hatproduct=Red%20Hat%20Network%20Proxyproduct=Red%20Hat%20Network%20Satellite https://bugzilla.redhat.com/buglist.cgi?chfieldto=Nowquery_format=advancedchfield=bug_statuschfieldfrom=2011-01-01bug_status=CLOSEDclassification=Communityproduct=Spacewalk Red Hat is behind of 95,4% of contributions. SUSE is behind of 2,65% of contributions http://miroslav.suchy.cz/spacewalk/gitstat/chart.php?chart_parameter1=3chart_parameter_ver=spacewalk-backend-1.7.1-1submit=1chart_parameter2_year=2011chart_parameter2_month=0submit=1showcount=10 == Project cost == This is wild estimation, but just guess: Codebase: 3,100,153 lines (including code and mark up) Effort (est.):903 Person Years Avg. Salary:$55000 year Estimated cost of project:$ 49,688,059 http://www.ohloh.net/p/spacewalk == Releases == We released 4 releases during year 2010: 1.3, 1.4, 1.5 and 1.6 http://freecode.com/projects/spacewalk/releases == IRC == We have nearly 1246 users on #spacewalk and 190 users on #spacewalk-devel. More numbers at: http://miroslav.suchy.cz/spacewalk/irc/spacewalk-devel/ http://miroslav.suchy.cz/spacewalk/irc/spacewalk/ I'm looking forward to see you in new year :) -- 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] [PATCH] - BZ#765816 - Add an option into rhncfg-manager to allow file/directory to be uploaded without setting a SELinux context
On 12/12/2011 07:15 PM, Marcelo Moreira de Mello wrote:
Hello team,
Follow attached 2 patches which introduces to rhncfg-manager a new
functionality to allow a file to be uploaded to Spacewalk server
overwriting the SELinux context at command line.
The second patch adds the option into the rhncfg-manager man page.
Best Regards,
Marcelo Moreira de Mello
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
This part:
+selinux_ctx = None
+if type(self.options.selinux_context) != None:
+selinux_ctx = self.options.selinux_context
+else:
+selinux_ctx = ''
and
+if type(selinux_ctx) == str:
+params.update({
+'selinux_ctx' : selinux_ctx,
+)}
means that you always override selinux context. Empty string is string
as well.
If you remove that else branch, it will work.
And that
+if type(selinux_ctx) == str
is not good too.
You generaly never know if that string is str or unicode. So checking
for type of string is better to be done like:
if isinstance(selinux_ctx, basestring):
but since isinstance is painfully slow, I would use in this case:
if selinux_ctx is not None:
The second patch seems ok.
Please fix the issue I mentioned and I would be happy to commit it.
--
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] Cobbler 2.2 support in 1.6
On 12/12/2011 12:58 AM, Parsons, Aron wrote: I committed some patches for Cobbler 2.2 support tonight. It'd be great if a few others could test to ensure I didn't break anything before 1.6 is released. Thanks for the work. But please next time try to check checkstyle (ant checkstyle). Otherwise it will not build: http://koji.spacewalkproject.org/koji/getfile?taskID=86515name=build.log I fixed those issues already. -- 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] implementation of the action system reboot
On 11/01/2011 11:17 PM, Christian Berendt wrote: 1. task: Schedule a package deployment at 22:00 and a system reboot at 22:01. problem: After starting the package deployment the system reboot starts, the action is probably not completed when the system goes down, the package deployment action failed. solution?: It should not be possible to schedule a system reboot if there are running actions on a system. Nope, this problem never happen. The actions are executed serialized and not parallel. Therefore if you schedule package deployment at 22:00 rhn_check wait till the package is installed and only after it finish, it will pick up next action. Which will be that system reboot. But the reboot will be initiated after packages will be deployment. Notice that when you schedule the actions it say not before XXX. Let assume that given schedule. If the package installation will last 20 minutes, then the real timing of the actions will be: 22:00 package deployment 22:20 system reboot 2. task: Schedule a system reboot at 22:00 and a package deployment at 22:01. problem: After starting the system reboot the systems picks up the next action, the package deployment action, and starts installing packages. Because there is a running system reboot the package deployment action will fail a few minutes later, the package deployment action failed. Yes, this is valid. solution?: It should not be possible to schedule new actions after scheduling a system reboot action (system is locked and gets unlocked after the succeeded system reboot?). If there are already scheduled actions they 1) should be cancelled or 2) they should be delayed. Well I may want to schedule some task to be executed in that 3 minutes time window. But I admit that most admins do not want to do that. 3. task: Schedule a system reboot at 22:00. problem: The system picks up the action and starts the system reboot, the action in the event schedule is now completed. But the system reboot will fail a few minutes later, because I will detach the power. True. An other example: At the moment it's possible to cancel the system reboot on the system (shutdown -c). The action in the event schedule is completed but the system reboot will never happen. What *I* would like is to have two reboots. 1) reboot and forget - which will behave exactly as it works right now 2) reboot and wait - which will force rhn_check to wait till machine is rebooted and only then send result of the action. And I can imagine 2) as default. The implementation in rhn_check can be as follows: after scheduling reboot of type rebootwait, do not pick up other actions and wait 3 minutes + some reserve. If we will live by that time (?and /etc/nologin does not exist?), then schedule was cancelled and we can mark this action failed. And then hook something(?) in boot sequence and after reboot send success to rhnParent. -- 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/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
[Spacewalk-devel] [Proposal] Schema change of rhnServerInterface due IPv6
I recently changed rhnServerNetwork due IPv6 and it was quite straight.
Now I focused on rhnServerInterface and I want to give you chance to
argue with me, before I do the change. :)
Today the table looks like:
http://spacewalk.redhat.com/documentation/schema-doc/table-RHNSERVERNETINTERFACE.html
It has columns:
* SERVER_ID NUMBER(38)
* NAME VARCHAR2(32)
IP_ADDR VARCHAR2(64)
NETMASK VARCHAR2(64)
BROADCAST VARCHAR2(64)
HW_ADDR VARCHAR2(18)
MODULE VARCHAR2(128)
CREATED DATE
MODIFIEDDATE
* marks primary key
Previusly clients send over XMLRPC this data:
intDict[interface] = {'hwaddr':hwaddr,
'ipaddr':ipaddr,
'netmask':netmask,
'broadcast':broadcast,
'module': module
}
for some time (since 2010-11-20) it send:
intDict[interface] = {'hwaddr':hwaddr,
'ipaddr':ipaddr,
'netmask':netmask,
'broadcast':broadcast,
'module': module,
'ipv6': ip6_list}
where ip6_list is:
ip6_list.append({
'scope': ip6.scope,
'addr':ip6.address,
'netmask': ip6.netmask
})
The ipv6 key/value pair is ignored by server for now.
The IPv6 stuff will not fit into current table so I come with following
solution:
Simplify table rhnServerInterface to columns:
* SERVER_ID NUMBER(38)
* NAME VARCHAR2(32)
HW_ADDR VARCHAR2(18)
MODULE VARCHAR2(128)
CREATED DATE
MODIFIEDDATE
Create new table rhnServerInterfaceIPv4 with columns:
* SERVER_ID NUMBER(38)
* NAME VARCHAR2(32)
IP_ADDR VARCHAR2(64)
NETMASK VARCHAR2(64)
BROADCAST VARCHAR2(64)
CREATED DATE
MODIFIEDDATE
Migration of existing data from rhnServerInterface to this new table is
easy and should not be problem.
Create new table rhnServerInterfaceIPv6 with columns:
* SERVER_ID NUMBER(38)
* NAME VARCHAR2(32)
SCOPE VARCHAR2(19)
ADDRVARCHAR2(45)
NETMASK VARCHAR2(49)
CREATED DATE
MODIFIEDDATE
SCOPE can be (according rfc2373):
scop is a 4-bit multicast scope value used to limit the scope of
the multicast group. The values are:
0 reserved
1 node-local scope
2 link-local scope
3 (unassigned)
4 (unassigned)
5 site-local scope
6 (unassigned)
7 (unassigned)
8 organization-local scope
9 (unassigned)
A (unassigned)
B (unassigned)
C (unassigned)
longest is organization-local with 19 chars, but I seen more different
strings already (local, universe etc.).
So I tend to think that more general VARCHAR(128) would be better here.
ADDR - longest IPv6 address can be 45 character wide. While we may
normalize the address and make it shorter. Question is whether we want
it normalize here or exactly as we get it over wire.
NETMASK - it is addr plus /128 as longest prefix.
Comments?
--
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 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
[Spacewalk-devel] Developers conference
There will be Developer Conference in Brno in February 2012: http://fedoraproject.org/wiki/DeveloperConference2012 Most (and probably all) Spacewalk developers based in Brno will be there. If you are Spacewalk developer or power user, it will be nice if we can meet there. -- Miroslav Suchy Red Hat Satellite Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Fwd: [ANNOUNCE] Cobbler 2.2.0 released
I nacked this in EPEL5: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2011-463 But that does not mean it will not get into EPEL5 so we should watch this closely. We may prepare ourself for testing this new release in EPEL6 and Fedora. Mirek Original Message Subject: [ANNOUNCE] Cobbler 2.2.0 released Date: Fri, 7 Oct 2011 06:56:45 -0500 From: James Cammarata j...@sngx.net Reply-To: cobbler development list cobbler-de...@lists.fedorahosted.org To: cobbler mailing list cobb...@lists.fedorahosted.org, cobbler development list cobbler-de...@lists.fedorahosted.org Cobbler 2.2 has been tagged and released, with RPMS built and available in EPEL-testing now. This release incorporates a ton of new features: * Import modules, which allowed easy integration of... * Ubuntu and Debian support again! * Better support for SuSE * Support for FreeBSD * Support for ESX 4+/ESXi * Integration with the python TFTP server pytftpd * fetchable files and boot files support for distros that need to get more files from the TFTP server * Faster sync using link cache * Support for EFI grub booting * Support for bridged interfaces * WSGI instead of mod_python for the web interface. * Lots of Web UI improvements * A lot more I'm sure I missed when going through the change log Bugfixes: * Seriously way too many to list individually. Read the change log, there were almost 1000 commits since the last release! This will also start the new development period, in which we will target a major release every 6 months. That means we should release 2.4 in April of 2012, with periodic updates to 2.2.x monthly for bug fixes. February 6th of 2012 will mark the end of the development period for 2.4, after which only bug fixes will be applied to the master branch until 2.4 is released. Thanks and enjoy! ___ cobbler-devel mailing list cobbler-de...@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Fwd: Re: About BZ707241
FYI Original Message Subject: Re: About BZ707241 Date: Tue, 13 Sep 2011 17:47:48 +0800 From: Leon leon.w.w...@oracle.com To: Miroslav Suchý msu...@redhat.com On 09/13/2011 04:52 PM, Miroslav Suchý wrote: On 09/13/2011 05:16 AM, Leon wrote: Hi Miroslav, 707241 - create progressbar even during groupinstall and do not delete rhnplugin... http://git.fedorahosted.org/git?p=spacewalk.git;a=commit;h=83fc936f50812b72e40c3cd64b866bd462a5d53f But now even we do the yum clean all, the rhnplugin.repos is not deleted. The consequence is after detele repo and yum clean all, old cache is still in rhnplugin.repos. Then yum repolist will be misleading. Please create new BZ that rhnplugin.repos file should be deleted during yum clean all. I just simply wrote an easy patch, and tests OK. leon@leon-desktop:~/work/yum-rhn-plugin-0.9.1$ diff -u rhnplugin.py rhnplugin.py.new --- rhnplugin.py2011-09-09 11:35:32.0 +0800 +++ rhnplugin.py.new2011-09-13 16:35:41.053454947 +0800 @@ -218,6 +218,11 @@ _(Package profile information could not be sent.) + \n + str(e)) +def clean_hook(conduit): + To delete the cache file generated by this plugin +cachedir = conduit._base.conf.cachedir +os.system(rm -rf +cachedir) + def rewordError(e): #This is compensating for hosted/satellite returning back an error #message instructing RHEL5 clients to run up2date --register Thank you for replying, have a nice day! - Leon ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] 1, y, true, yes, on etc
On 09/05/2011 04:08 PM, Bo Maryniuk wrote:
Guys,
should we support all of the list of valid true's for the config,
listed in /spacewalk/java/code/src/com/redhat/rhn/common/conf/Config.java,
or 1 is just enough for the next century?
/**
* List of values that are considered true, ignoring case.
*/
private static final String[] TRUE_VALUES = {1, y, true,
yes, on};
This is a bit not synchronized, since *only* Java stack allows such
odd choices, while the rest of the Spacewalk seems like understands
only 1 or 0 (Python part, at least).
I would suggest to put it to the common schema, because this is
very confusing.
So either:
1. Teach the rest of the Spacewalk to understand all of the above,
where seems like Esperanto and Swahili are still missing :-)
2. Reduce it to just 1 or 0.
What you think? I would go #2 personally...
Well it is always good to understand more languages. And I know from my
experience that people do not always know whether they should use
true/yes/1 as different projects use different constants.
So when I have time I try to write code which understood all possible
constants. When I'm lazy I just choose one.
Since our configuration files are well documented (hmm not documented,
but has all option and its default values) I will not object agains #2,
but I think #1 is better.
--
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] [PATCH] NPE when scheduling a package (install/remove/upgrade) action + remote command
On 09/08/2011 03:02 PM, Johannes Renner wrote: If it can be reproduced, I will open a bug on bugzilla.redhat.com. I could not reproduce it on my Spacewalk 1.5 -- 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] Audit Logging
On 08/30/2011 12:06 PM, Jan Pazdziora wrote: To achieve that, I'll gladly review a patch which will add logging triggers to all tables that we have in the schema, together with initial insert to a central log table with identity/timestamp/remote host/user agent/whatever information. How would you log read only access? -- 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] Audit Logging
On 08/25/2011 06:55 PM, Johannes Renner wrote:
Well, I can count three, while only one (!) of them is public. But we
can still rename the other ones, no problem.
I count:
private static Logger log = Logger.getLogger(AuditLog.LOGGER_NAME);
as well.
- How can you distinguish between interesting and uninteresting requests?
- There is some interesting requests that are not POST requests, e.g. logouts.
- There is some POST requests that are not interesting, e.g user selects all
entries of a list.
- Log events cannot be categorized for a later filtering. At a single entry
point it is very hard to see what really has happened.
I thought that there will be configuration file, where you state what
and how will be logged. All based on URI similary to struts config file.
E.g.
/rhn/LoginSubmit.do {
key = LOGIN
value = user=${POST.username};pass=${POST.password}
}
/rhn/admin/config/GeneralConfig.do {
key = CONF
value = email=${POST.email};.
}
etc. you probably got the idea now.
And those url not specified will not be logged.
- When using an external entry point (like mod_security), you can't actually
see from the logs which user was involved since it is not possible to map
between uid, sid, ... and real world 'objects'.
I said something liek mod_security. I can imagine build something upon
existing project, but even something new written from scratch just for
Spacewalk.
And translating sid to user is not so big problem. You can have config
file where you specify how you translate sid to user. Ie.
[translate]
user = select login from web_contact join pxtsession on
web_user_id=web_contact.id where pxt.id = :sid
and in logging config have:
/rhn/admin/config/GeneralConfig.do {
key = CONF
translate[user] = sid
value = logged=${user};email=${POST.email};.
}
This way it can be even Spacewalk independent and you can use it on
different project where they have different tables.
I agree with you completely on the fact that getting the big picture is hard,
but generic logging of request data does somehow not satisfy our needs :-/
So there is place to write one :)
Just think that after some years customer will ask you and which
events/action/url are logged? Can you give me the list.
And you will have hard time to provide such list.
--
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] Audit Logging
On 08/25/2011 07:10 PM, Bo Maryniuk wrote: I thought the patches reviews you, guys, doing are more than just works/not-works? Not exactly. This is true for small bugs. E.g there is some bug in Spacewalk. Somebody diagnose it, create patch and sent it here (unless he is proved Spacewalk contributor and has git access). We review it and if it works, we commit it. But even then we often fix some code style. Trim trailing whitespaces, wrap lines... etc. But if it is feature, then we try to public face it as much and as soon as possible. And we try to find solution which is as generic as possible and which will be maintainable even few years from now. I have to admit that we discuss some things internally in our cubicle as RH developers sits in one room, but when we are not lazy we post it to mailing list to get feedback from others as well. Debian support and PostgreSQL support comes to my mind as good example where we discussed our progress during our work. -- 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] Audit Logging
On 08/26/2011 03:10 PM, Johannes Renner wrote: I got the idea and I was even researching such an approach already. For the webapp I started with a ServletFilter (see my attached patch as an example) that simply logs all POST requests to the backend using my helper classes from the patches I already sent. The main thing that's missing would be the integration of a configuration file like the above. I will now continue to investigate in this approach since I agree with you that it will be much easier to maintain than having log statements all over the code. However there is also some drawbacks: - Performance might be worse, since _every_ request this filter is registered for (e.g. all *.do) will be checked if it needs to be logged or not *nod* - Sometimes the same URL is used for different actions, e.g. creating and updating an object, so classification of log events might be difficult or even not possible Can you provide example of such page. If we can solve such hard page and everything else will be easier, then we can continue persuade this idea. Otherwise we can scratch it and return to that mega-patch modifying all the code. - Sometimes you only want to log the request in case a certain parameter is there, so there would need to be a something like a list of parameters required for logging for each URL in the config *nod* - does it make sense to have a whitelist of interesting parameters for each URL or rather take everything and maintain a global blacklist? What about reusing idea from httpd. I.e have order deny, allow deny foo so everything having foo will be blacklisted and everything else for this url will be audited and similary order allow, deny allow foo will mean that we will not audit it unless it have foo parameter. Yes, but I actually think it would make sense to do this specifically within spacewalk-java, because there is already code to determine all the stuff from the database. To me it would make sense to reuse this code, so we don't need to rewrite all those queries? But how will you audit backend and those old perl pages we still have there? Yes, and such a configuration could even be modified by a customer itself. Indeed, I did not seen this advantage. -- 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] Audit Logging
On 08/24/2011 01:57 PM, Bo Maryniuk wrote: Well, if your admin can do more than 2000 changes-per-second, then just let me know... :) You want to audit just frontend? I.e. if I do some changes through backend it will not be logged? -- 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] Audit Logging
On 08/25/2011 02:30 PM, Johannes Renner wrote: So (1.) there are some helper classes that I put into a new separate package, see 01-new-classes.patch: AuditLog.java has 4 (!) functions log() and all of them has different semantics - if I ommit that they are utilized to logging. Please consider different names. Therefore there is (2.) calls to the logger from within the existing code, see 03-rhnaction-example.patch: Hmm, what I dislike is the need to change the code. Which will be prone to coder error and you may end up in situtation where somebody commit code, which are worth auditing, but the audit call will not be there. If I would be designing such functionality I would prefer something like mod_security. So you will have one entry point and you will not care if the action is actually handled by cobbler, backend, frontend or some aliens. This would even allow you to have configuration file where you will define what and how will be audited. In your design it will be hard to say which actions are audited. Especially in 2 years from now, when other will add/remove/change your initial audit calls. - While most of the struts actions are RhnAction or RhnLookupDispatchAction, there is still some that are not derived from these classes. Therefore it's not enough to put a shortcut method to the logger in the(se) superclass(es). Exactly, if you go from bottom (base classes) you can be never sure if log all childs and getting the big picture will be very hard. And you could not be really sure till you test it. -- 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] Audit Logging
On 08/25/2011 05:28 PM, Bo Maryniuk wrote: I.e. if I do some changes through backend it will not be logged? No, they will. Well we have users with tens thousands or registered machines. And they can easily create hundreds and even thousands request in the same time. So human admin is not capable of thousands request per seconds, but registred machines are capable of that. So if we accept that in Spacewalk eventually. I would definitelly like to see some benchmarks before this feature and after. And you to be willing to address potential speed issues. -- 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] spacewalk with oracle 11.2 has problems with the monitoring code
On 08/24/2011 01:05 PM, Michael Calmer wrote: Some monitoring code expect special columns with id 1 which fail if id 1 column does not exist. E.g: java/code/src/com/redhat/rhn/domain/monitoring/satcluster/SatClusterFactory.java private static final PhysicalLocation PHYSICAL_LOCATION = lookupPhysicalLocation(new Long(1)); A quick fix is, to disable this feature in oracle with: alter system set deferred_segment_creation=FALSE; but a real fix would be better. Requiring presence of row with id=1 is definitely bug. I do not like that Oracle workaround. That code which lookup id=1 should be replaced. Patches are welcome. :) -- 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] Audit Logging
On 08/23/2011 06:26 PM, Bo Maryniuk wrote: Entire Spacewalk components are going to be altered, where each audit-able action will perform a call. We already developed an log4j appender and now processing all Java part and XML-RPC backend and a frontend. This will help community to reconnect audit to something So you already have something. Can you send what you have, so we can review the implementation? It would be unfortunate if you send mega patch and we will do not like several items and reject it. It does not need to be polished or apply to current HEAD. And it does not need to be complete. Just to see the code behind your ideas. The feature will be turned off by a default and will be able to turn it on in a Spacewalk conf, like: audit = on. Definitelly. Most users will not need this one, so it should be disabled by default. Q: Why not just another log appender? A: We believe it should be generic, agnostic and reliable. Hence the embedded database and thread black magic are involved among other things. :) This is where I disagree. But I would like to see your code and maybe I will change my mind. Q: A daemon? A: Yes. A daemon. Because if this would be a servlet on a Tomcat, so once Tomcat feels sour during various reasons, like a star wars satellite accidentally blew up WAN or endothermal recalibration caused failure converting big to little endian, for example :-), then the rest of the stack won't properly functioning. That should not happen. *nod* Q: How fast the thing is? A: 1000 messages linearly per 0.42 sec per instance should be enough. That is quite slow IMO for logger. We are going to open it under Apache Licence 2.0 and contribute back to the community along with a mega-patch for Spacewalk 1.2 base. Please no mega-patch. And definitelly no unless you send few iteration of what-you-have patch, so we can review and discuss whether it is good approach or not. This is thing which can be done good and be great benefit, but with only few things screwed can slow down whole Spacewalk even in disabled state. -- 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] Fedora 15 rhnreg_ks error with nightly build
On 08/19/2011 06:56 PM, Shelby, James wrote:
I'm using a simple default kickstart that seems to fail when it gets to the
registration part. If I reboot the system and then run the rhnreg_ks it
works fine but just seems to error if run during the kickstart. Any ideas?
I have checked the time on both systems to be insync.
[Fri Aug 19 16:45:56 2011] up2date
Traceback (most recent call last):
File /usr/sbin/rhnreg_ks, line 205, in module
cli.run()
File /usr/share/rhn/up2date_client/rhncli.py, line 74, in run
sys.exit(self.main() or 0)
File /usr/sbin/rhnreg_ks, line 99, in main
hardwareList = hardware.Hardware()
File /usr/share/rhn/up2date_client/hardware.py, line 662, in Hardware
allhw = get_devices()
File /usr/share/rhn/up2date_client/hardware_gudev.py, line 45, in
get_devices
'desc': _get_device_desc(device),
File /usr/share/rhn/up2date_client/hardware_gudev.py, line 306, in
_get_device_desc
(vendor_id, model_id) = device.get_property('product').split('/')[:2]
type 'exceptions.AttributeError': 'NoneType' object has no attribute 'split'
This was fixed in commit ebd9948a92945026db88932eefd23c4c0c7738ea
And should be fixed since rhn-client-tools-1.5.2-1.
You are using rhn-client-tools-1.3.12-2.fc15 which is in Fedora and
which have this bug.
--
Miroslav Suchy
Red Hat Satellite Engineering
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] PXT::Config is in both spacewalk-web-minimal and spacewalk-pxt
In: https://bugzilla.redhat.com/show_bug.cgi?id=705363 Files layout and permissions are Ok, except the issue with /usr/share/perl5/vendor_perl/PXT/Config.pm: Notice: perl(PXT::Config) (and /usr/share/perl5/vendor_perl/PXT/Config.pm) is provided by two packages: spacewalk-base-minimal and spacewalk-pxt. Is it intentional? Yes, it is intentional. PXT is quite standalone (but still part of Spacewalk and primary developed for spacewalk) so it is included directly in that sub-package and we do not want to force potential user to install spacewalk-base. On the other hand we need PXT/Config.pm on Spacewalk proxy and to read monitoring configuration files, but we do not need there whole PXT. Therefore it is packaged in -minimal sub-package together with additional essential files. Fedora packaging guidelines forbids sharing files between packages https://fedoraproject.org/wiki/Packaging/Guidelines#Duplicate_Files. FIX: I recommend to split the /usr/share/perl5/vendor_perl/PXT/Config.pm file into new sub-package and make this sub-package required by spacewalk-base-minimal and spacewalk-pxt. Otherwise make the two packages mutually exclusive, or ask Fedora Packaging Committee for exception. I plan to leave PXT::Config only in spacewalk-base-minimal. And spacewalk-pxt will require spacewalk-base-minimal. Does anyone have objection? If there will be no objection till tomorrow, I will do the split, so I can continue with the review. -- 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] [PATCH] Bug with trusted SSL cert on PostgreSQL
On 08/12/2011 04:22 PM, George Nikandrov wrote: Hello, I've got Spacewalk 1.5 on PostgreSQL, and during the replacemento of CA certificate (https://fedorahosted.org/spacewalk/wiki/ChangeCaCert) command rhn-ssl-dbstore -vvv --ca-cert /root/ssl-build/RHN-ORG-TRUSTED-SSL-CERT fails with quite obvious python traceback. Here's the patch which should solve the problem for PostgreSQL setups. Sorry, it's not against the git tree, but just the standard install, but I hope it still can be useful. Commited to git as 7692fe587856bb528081bd3def202647eb6b20b5 Thanks for contributing. -- Miroslav Suchy Red Hat Satellite Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Looking for Fedora reviewer
I'm getting a lot of broken dependecies in Fedora rawhide due missing spacewalk-web in Fedora. If some Fedora developer can do the review of: https://bugzilla.redhat.com/show_bug.cgi?id=spacewalk-web I would be very glad. -- 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] dojo - javascript framework
On 06/21/2011 03:33 PM, Bo Maryniuk wrote: There are many various discussions about how good/bad GWT is, but we weighted all the tradeoffs, pros and cons, we were looking at other stuff, like Wicket or ZK and even OpenLaszlo, as well as ExtGWT or SmartGWT but we are convinced that GWT with Vaadin is the very way we will go with. Can you share with us the pro and cons? It all sounds interesting to me. Hence we are going to package GWT with Vaadin and ship it with our SUSE Manager. Any chance to see that back in Spacewalk? -- 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] dojo - javascript framework
On 06/20/2011 05:40 PM, Shannon Hughes wrote: did you get a chance to look at jquery 1.5.x? the ones being tested in that 2nd link are old. No. But from quick glance it has two cons: - less features (e.g. I really miss ComboBox and Charting) - it is not in Fedora :) But I'm open minded. Do you use jquery? Does it have some advances over Dojo? -- 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] Remove python-hwdata from comps
On 05/25/2011 12:45 PM, Jan Blažek wrote: On 05/23/2011 08:50 AM, Jan Blažek wrote: On 05/22/2011 11:29 PM, Miroslav Suchy wrote: Jan, can you please remove python-hwdata from Spacewalk Client comps? This package is in Fedora and Epel and despite the fact that we are the upstream, it is merely support package and it is very stable and it does not change since its origin. Mirek Hi Mirek, I've removed python-hwdata from comps: http://git.fedorahosted.org/git/?p=spacewalk.git;a=commitdiff;h=a791409e92570468eaf753cb1b680906f7223257 Jan Mirek, I've also blocked it in the *-sw-1.5 tags. Can you stop building it? The tasks fail because it's blocked. It is blocked since today morning. -- 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 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/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: 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
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
[Spacewalk-devel] open or close *.pdf files in /help/
I stubmled upon web/html/help/.htaccess Where is: Files RHN-satellite-en.pdf AuthType Basic PerlModule PXT::ApacheHandler PerlModule PXT::ApacheAuth PerlAuthenHandler PXT::ApacheAuth /Files and few others... The purpose is obviously to allow download documentation only after successful login. Trouble is that pdf of such name does not exist since RHN Satellite 5.0. So I face two possibilities. Remove these lines and leave documentation open. Or update it to current names and protect the documentation by username/password. I think I'm going to remove it. What is your opinion? -- 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] Func vs osad vs AMQP
On 05/11/2011 10:05 AM, duncan.in...@virginmoney.com wrote: Finally, is there going to be an open source project for System Engine? Somewhere to discuss direction, development etc? Or will it be Red Hat internal only? https://fedorahosted.org/katello/ -- 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] [PATCH] - BZ#699966 - Add an option on rhncfg-manager to ignore missing local files
On 04/27/2011 02:39 PM, Marcelo Moreira de Mello wrote: Hello Miroslav and Jan, Follow a better patch for BZ#699966 with --ignore-missing and a better logical flow. [root@dhcp96 ~]# rhncfg-manager update --channel=test2-channel --ignore-missing /etc/hosts /etc/shadow /etc/autofss /etc/group /etc/bunda Local file /etc/autofss does not exist. Ignoring file... Local file /etc/bunda does not exist. Ignoring file... Pushing to channel nega: Local file /etc/hosts - remote file /etc/hosts Local file /etc/shadow - remote file /etc/shadow Local file /etc/group - remote file /etc/group Thank you for guidelines guys! Commited as 812793c6c24678e6e362d628ddef225c298f7ead Thx for contributing. -- 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] [PATCH] - BZ#648868 - No such file `/etc/httpd/conf.d/rhn_proxy.conf'
On 04/27/2011 03:04 PM, Marcelo Moreira de Mello wrote: Hello, This is a complementary patch for commit 8994dccc7d499e6acb4a14ab5f04d0bd468f191d which removes the files $HTTPDCONFD_DIR/proxy_redirect.conf and $HTTPDCONFD_DIR/proxy_broker.conf that also does not exists. [root@server ~]# echo $HTTPDCONFD_DIR /etc/httpd/conf.d [root@server ~]# ls -la $HTTPDCONFD_DIR/proxy_broker.conf ls: /etc/httpd/conf.d/proxy_broker.conf: No such file or directory [root@server ~]# $HTTPDCONFD_DIR/proxy_redirect.conf -bash: /etc/httpd/conf.d/proxy_redirect.conf: No such file or directory Thank you! Commited as be411a6ed081207f8fa4009dc949f9158455816e Thank you too. -- 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] [PATCH] - BZ#699966 - Add an option on rhncfg-manager to ignore missing local files
On 04/27/2011 07:46 AM, Marcelo Moreira de Mello wrote: Hello, This patch adds a new option in rhncfg-manager which allows to continue if local files were missing. Per example: [root@server ~]# rhncfg-manager update --help usage: rhncfg-manager update [options] file [ file ... ] options: -c CHANNEL, --channel=CHANNEL Upload files in this config channel -d DEST_FILE, --dest-file=DEST_FILE Upload the file as this path -t TOPDIR, --topdir=TOPDIR Make all files relative to this string --delim-start=DELIM_START Start delimiter for variable interpolation --delim-end=DELIM_END End delimiter for variable interpolation -f, --force Ignore errors if some local files does not exist -h, --helpshow this help message and exit [root@server ~]# rhncfg-manager update --channel=test-channel --force /etc/shadow /etc/autofss /etc/group /etc/no_exists Local file /etc/autofss does not exist. Ignoring file... Local file /etc/no_exists does not exist. Ignoring file... Pushing to channel test-channel: Local file /etc/shadow - remote file /etc/shadow Local file /etc/group - remote file /etc/group Cheers, Marcelo ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel I do not like this: -if not os.path.exists(local_file): -die(9, No such file `%s' % local_file) +if self.options.force: +if not os.path.exists(local_file): +files_to_push.remove((local_file,remote_file)) +print Local file %s does not exist. Ignoring file... %(local_file) +else: +if not os.path.exists(local_file): +die(9, No such file `%s' % local_file) I would rather use: if not os.path.exists(local_file): if self.options.force: files_to_push.remove((local_file,remote_file)) print Local file %s does not exist. Ignoring else: die(9, No such file `%s' % local_file) This is very similar, but you do not duplicate that line with: os.path.exists(local_file) also IMHO it better reflect the logical flow. -- 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] draft of release notes
On 04/25/2011 05:40 PM, Speagle, Andy wrote: 5) Has Solaris support been addressed in 1.4? We're still missing an updated Solaris client. Nope. Solaris support is in the same state as was in 1.3. We did not touch it during this release. -- Miroslav Suchy Red Hat Satellite Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Spacewalk 1.4 released
Hello world, Spacewalk 1.4 is now available for download from http://spacewalk.redhat.com/yum/1.4/RHEL/5/$basearch/ http://spacewalk.redhat.com/yum/1.4/RHEL/6/$basearch/ http://spacewalk.redhat.com/yum/1.4/Fedora/13/$basearch/ http://spacewalk.redhat.com/yum/1.4/Fedora/14/$basearch/ Note: Fedora packages for server are released only for x86_64 architecture. depending on your operating system, with client repositories under: http://spacewalk.redhat.com/yum/1.4-client/Fedora/13 http://spacewalk.redhat.com/yum/1.4-client/Fedora/14 http://spacewalk.redhat.com/yum/1.4-client/RHEL/5 http://spacewalk.redhat.com/yum/1.4-client/RHEL/6 http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/1.4/openSUSE_11.4/ http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/1.4/openSUSE_Factory/ http://miroslav.suchy.cz/spacewalk/debian Check the installation steps at https://fedorahosted.org/spacewalk/wiki/HowToInstall or if you will upgrade from older release, consult http://fedorahosted.org/spacewalk/wiki/HowToUpgrade Features Enhancements in Spacewalk 1.4: * client packages for Debian * client packages for OpenSuse * support for IDN [1] (but RHN Tools part) - you can now have Spacewalk server and clients, whose hostnames contains non latin domain name. * issues in PostgreSQL backend, reported by users, were fixed. For PostgreSQL status see [2] * system history reports were added in spacewalk-reports * spacewalk-repo-sync now automatically create errata from updateinfo [1] http://en.wikipedia.org/wiki/Internationalized_domain_name [2] https://fedorahosted.org/spacewalk/wiki/PostgreSQL Spacewalk 1.4 contains support for apt-get plug-in. An apt-get plug-in client package is available at http://miroslav.suchy.cz/spacewalk/debian/ Feel free to try it and report any issues. This repo contains apt with spacewalk patches. For more information check: https://fedorahosted.org/spacewalk/wiki/RegisteringClients#Debian Community contributors: We thank the community members who contributed to this release: * Aron Parsons * Dale Bewley * Jerome Fenal * Johannes Renner * John van Zantvoort * Luc de Louw * Marcelo Moreira de Mello * mareklaane * Michael Calmer * Paresh Mutha * Šimon Lukašík * Trent Johnson * Uwe Gansert * ypoyarko https://fedorahosted.org/spacewalk/wiki/ContributorList Bug fixes and commits: In Spacewalk 1.4 there were: * 68 bugs solved * 634 changesets committed * 899 commits done Enjoy using Spacewalk! -- Miroslav Suchy Red Hat Satellite Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Spacewalk 1.4 delayed
The news from battle field: I need to respin one package, but unfortunately koji builder has and still is offline for whole day. This is due major problems Amazon EC2 is experiencing today. See http://status.aws.amazon.com/ I hope I will be able to release it tomorrow. -- Miroslav Suchy Red Hat Satellite Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] draft of release notes
This is my draft of release notes. Did I miss something? Is there something wrong? I have two test to run, but I hope I will do the release tomorrow. Mirek Hello world, Spacewalk 1.4 is now available for download from http://spacewalk.redhat.com/yum/1.4/RHEL/5/$basearch/ http://spacewalk.redhat.com/yum/1.4/RHEL/6/$basearch/ http://spacewalk.redhat.com/yum/1.4/Fedora/13/$basearch/ http://spacewalk.redhat.com/yum/1.4/Fedora/14/$basearch/ depending on your operating system, with client repositories under http://spacewalk.redhat.com/yum/1.4-client/Fedora/13 http://spacewalk.redhat.com/yum/1.4-client/Fedora/14 http://spacewalk.redhat.com/yum/1.4-client/RHEL/5 http://spacewalk.redhat.com/yum/1.4-client/RHEL/6 http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/1.4/openSUSE_11.4/ http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/1.4/openSUSE_Factory/ http://miroslav.suchy.cz/spacewalk/debian Check the installation steps at https://fedorahosted.org/spacewalk/wiki/HowToInstall or if you will upgrade from older release, consult http://fedorahosted.org/spacewalk/wiki/HowToUpgrade Features Enhancements in Spacewalk 1.4: * client packages for Debian * client packages for OpenSuse * support for IDN [1] (but RHN Tools part) - you can now have Spacewalk server and clients, whose hostnames contains non latin domain name. [1] See: http://en.wikipedia.org/wiki/Internationalized_domain_name Spacewalk 1.4 contains server support for apt-get plug-in. An experimental apt-get plug-in client package is available at http://miroslav.suchy.cz/spacewalk/debian/ Feel free to try it and report any issues. This repo contains apt with spacewalk patches. For more information check: https://fedorahosted.org/spacewalk/wiki/RegisteringClients#Debian Some notes about the PostgreSQL support: PostgreSQL support is still limited similar to Spacewalk 1.2 and 1.3. https://fedorahosted.org/spacewalk/wiki/PostgreSQL From previous release these additional areas are known to work with PostgreSQL: * spacewalk-reports * configuration management Community contributors: We thank the community members who contributed to this release: * Aron Parsons * Dale Bewley * Jerome Fenal * Johannes Renner * John van Zantvoort * Luc de Louw * Marcelo Moreira de Mello * mareklaane * Michael Calmer * Paresh Mutha * Šimon Lukašík * Trent Johnson * Uwe Gansert * ypoyarko https://fedorahosted.org/spacewalk/wiki/ContributorList Bug fixes and commits: In Spacewalk 1.4 there were: * 68 bugs solved * 633 change sets committed (commits without tags) * 897 commits done Enjoy using Spacewalk! -- 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] [PATCH] build rhncfg on openSUSE
On 04/08/2011 02:57 PM, Michael Calmer wrote:
Hi,
here is the patch for rhncfg.
0007-build-rhncfg-on-SUSE.patch:
- only some specfile modifications
If I put aside the fact that I would prefer more commits about this
splitting things which allow build rhncfg on SUSE like:
+%if 0%{?rhel}
Requires: libselinux-python
%endif
+%endif
from general fixes, like:
+%dir %{_sharedstatedir}/rhncfg
Then I have problem with:
+%dir %{_sharedstatedir}
This is owned by filesystem package on Fedora. If this is not owned by
any base package on SUSE wrap it with if/endif
+%dir %{rhnconf}
This should not be there. This directory is owned by rhn-client-tools
and we Require it.
+%dir %{client_caps_dir}
This is the same. This directory is owned by rhn-client-tools and we
Require it.
--
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] [PATCH] build rhn-custom-info on openSUSE
On 04/08/2011 02:59 PM, Michael Calmer wrote:
Hi,
here is the patch to build rhn-custom-info on openSUSE.
0008-build-rhn-custom-info-on-SUSE.patch:
- only some specfile modifications
%else
+%if 0%{?suse_version}
+Requires: zypp-plugin-spacewalk
+%else
I would much rather prefer usage of %elif here.
+%dir %{_datadir}/rhn
Again. rhn-custom-info requires yum-rhn-plugin, which requires
rhn-client-tools, which own this directory. So this should not be there.
--
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] [PATCH] build rhn-client-tools on openSUSE
On 04/08/2011 05:10 PM, Michael Calmer wrote: Hi, Am Freitag, 8. April 2011, 14:49:30 schrieb Michael Calmer: Hi, 0002-enhance-getOSVersionAndRelease-to-find-SUSE-distribu.patch: Add code to make _getOSVerionAndRelease work on SUSE This patch has a little typo. I have attached a fixed version. Sorry :-) Committed. Thanks for contributing. -- 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] [PATCH] rhn-custom-info
On 04/07/2011 04:02 PM, Michael Calmer wrote: Hi, during some tests of the master branch I realized some issues with rhn-custom- info. It seems that some reorganization of the code introduced some bugs in this package. I have created a patch which is attached. Thanks for noticing that. Patch committed. I added one more enhancement: -if isinstance(ca, str) or isinstance(ca, unicode): +if isinstance(ca, basestring): -- 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] [PATCH] - BZ#688461 - Error when using the web UI to compare the differences between a file revision when SELinux is disabled in RHEL6
On 04/05/2011 11:16 AM, Jan Pazdziora wrote: what was the resolution to this issue? Ahh, sorry, we continued on IRC with Marcelo, I forgot to post the resolution here... Commit: ab80c2974e4fa2261478bed2c6d8a99703671b4c -- 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] The struggle with rhn-client-tools on Debian
On 04/02/2011 01:46 PM, Simon Lukasik wrote: I have finished a minimal work needed for rhn-client-tools on Debian. Changes are in rhn-client-tools-debian branch. Would You mind to take a review? I just read the code and have no problem. My comment: - in debUtils I would use python-dpkg. I know that it is long time dead, but dpkg does not change either. So you may not depend on it directly, but copy'n'paste it from that library. -- 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] The struggle with rhn-client-tools on Debian
On 03/29/2011 08:19 AM, Simon Lukasik wrote: (A) A big part of the code depends directly on python-rpm. We don't want 'import rpm' on Debian nor 'import apt' on Fedora. (B) /etc/sysconfig does not exist on Debian I would suggest to use /etc/default/rhn. /etc/default is Debian equivalent for /etc/sysconfig. More or less. (C) redhat-release does not exist on Debian /etc/debian_version or lsb_release -r or lsb_release -c (D) Architecture names are slightly different Yeah, but we already have Debian architecture in DB and rhnpush count with it, right? Potential solutions: My priorities: (1) Create a Debian patch, and apply it only when building the .deb package. It is easier for start, but the patch needs to be maintained. +1 (2) Modify upstream rhn-client-tools, to include bits for both: Debian Fedora and choose one during a build-time. +3 (3) Same as (2) but in run-time. (polymorphism). +2 (4) interleave with if-else: if getPlatform() == 'deb': import apt else: import rpm +2 (5) Still there is an option to write rhn-client-tools from scratch. (Design new interface). I doubt anybody likes that. -10 -- 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] Dropping i386 for Spacewalk Server?
On 03/25/2011 08:16 PM, Luc de Louw wrote: The other question that arises is: How would this affect RHN-Satellite? I got this idea for Spacewalk. It is still my personal idea. When and if we do this for Spacewalk, then we may start thinking about RHN Satellite. But that is far future. -- 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] [PATCH] - BZ#688461 - Error when using the web UI to compare the differences between a file revision when SELinux is disabled in RHEL6
On 03/18/2011 08:54 AM, Michael Mraka wrote:
Marcelo Moreira de Mello wrote:
% Hello,
Hi Marcelo,
% Following as attached a patch which fixes the python exception when
% comparing files using the web UI in RHEL6 when SELinux is disabled.
%
% The BZ# is flagged to RHN Satellite, but the same issue occurs in
% Spacewalk.
%
% Thank you.
%
% Kind Regards,
% Marcelo Moreira de Mello
I applied your patch to spacewalk master, thanks for it.
Well,
I have little problem with this patch.
I have no problem with client/tools/rhncfg/config_common/repository.py
part. But I have with client/tools/rhncfg/config_common/file_utils.py part.
Lets do some exercise:
[root@XXX190 ~]# ls -ldZ /root
drwxr-x--- root root root:object_r:user_home_dir_t:s0 /root
[root@XXX190 ~]# python
Python 2.4.3 (#1, Dec 10 2010, 17:24:32)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-50)] on linux2
Type help, copyright, credits or license for more information.
from selinux import lgetfilecon, is_selinux_enabled
is_selinux_enabled()
0
lgetfilecon('/root')
[33, 'root:object_r:user_home_dir_t:s0']
[root@XXX190 ~]# getenforce
Disabled
So with this patch the selinux content will not be used even if it has
some content.
Accoring my investigation lgetfilecon(path)[1] returns None (RHEL6,
python 2.4) or 'unlabeled' (Fedora14, python 2.7).
I would like first see which problem in web UI we are solving.
Isn't correct fix?:
if cur_sectx == None or cur_sectx == 'unlabeled':
cur_sectx = ''
--
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] rhn_register vs. up2date --register @ RHEL(3, 4)
On 03/21/2011 11:36 PM, Cliff Perry wrote: No objection removing any mentions of up2date from Spacewalk client code. +1 to what Jan P said Removed. -- Miroslav Suchy Red Hat Satellite Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
