Re: [Spacewalk-devel] fix an ISE relating to config management w/selinux
On 08/20/2009 04:13 AM, Miroslav Suchý wrote: Joshua Roys wrote: Hello all, Attached is a patch to kill another bug in the configuration management w/selinux. Specifically, backend/server/configFilesHandler.py ended up calling the old version of lookup_config_info, which caused all file uploads to fail in an ISE. In fixing this, I also added functionality to upload the selinux context of files to spacewalk in client/tools/rhncfg/config_common/repository.py . The other changes are for completeness, as they look like they could cause problems in the future. Hopefully this is the last bug - sorry I didn't squash them earlier! Thx. But: a) can you send nex time patch created using: git format-patch? This way you will get credit in git history. b) from selinux import getfilecon will fail on RHEL/Centos 4. I wrapped it into try/except block and in case of failure define new function getfilecon which returns [0, '']. I aplied it to master. Commit: e38cfbaa329ea8814ea12014ffacb3b61d6bcbb9 Mirek: You should be able to just set the GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL env variables in your current bash session to Joshua's and do your commits and git commits it with his name. You dont have to have a patch with it. -- -- Pradeep Kilambi Senior Software Engineer RHN Satellite Engineering Phone: +1 919 754 4285 RHCE # 805008680430554 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Re: Add spacewalk-backend Requires on python-pgsql.
On 08/14/2009 09:00 AM, Michael Mraka wrote: Fedora Hosted Git Repositories - spacewalk.git/rss log: % Add spacewalk-backend Requires on python-pgsql. % % Add spacewalk-backend Requires on python-pgsql. % % • [DH] backend/spacewalk-backend.spec % % URL: http://git.fedoraproject.org/git/?p=spacewalk.git;a=commitdiff;h= % e56e4e9dc2959c28553350533a6b2dcea92a73f7 % --- a/backend/spacewalk-backend.spec % +++ b/backend/spacewalk-backend.spec % @@ -17,6 +17,7 @@ Requires: python, rpm-python % # /etc/rhn is provided by spacewalk-proxy-common or by spacewalk-config % Requires: /etc/rhn % Requires: rhnlib= 1.8 % +Requires: python-pgsql % BuildRequires: /usr/bin/msgfmt % BuildRequires: /usr/bin/docbook2man % BuildRequires: docbook-utils This is wrong for 2 reasons: a) Such dependency should not be in spacewalk-backend but spacewalk-backend-sql package which is Core functions providing SQL connectivity for the RHN backend modules. b) It means you have to install both oracle and postgresql for spacewak now which is weird. We should rather have meta dependency e.g. spacewalk-backend-db and spacewalk-backend-oracle and spacewalk-backend-postgresql packages which both provide spacewalk-backend-db and requires appropriate oracle/postgresql stuff. So you can install one or another. \ I agree with Michael here. Postgres deps should be a choice not a requirement. If I chose to use oracle why should I even care about installing python-pgsql ? I think meta dependency as Michael suggested seems like a better way than what we have here. ~ Prad -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel -- -- Pradeep Kilambi Senior Software Engineer RHN Satellite Engineering Phone: +1 919 754 4285 RHCE # 805008680430554 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Cloned Channel Problems - SW 0.6
On 08/13/2009 10:20 AM, Andy Speagle wrote:
On Wed, 2009-08-12 at 18:01 -0500, Justin Sherrill wrote:
I think re-running this sql script will fix all the currently broken
channels, but you'll have to rerun it to fix newly created channels
every time (until a permanent fix gets created):
SQL UPDATE rhnChannel SET
checksum_type_id = (select id
from rhnChecksumType
where LABEL = 'sha1')
WHERE checksum_type_id is null;
-Justin
Hi Team,
I hate to kick a dying horse... but I tried this. Updating the database
directly did indeed update the record for the channel I just cloned,
however, I think because I've added the check that Prad suggested to the
webform, it's keeping me from being able to edit anything about this
channel. After making the SQL change, when I try to edit the cloned
channel it shows SHA-256.. because of the minor check that I added:
-form.set(checksum, c.getChecksum().getLabel());
+if (!c.isCloned()) {
+form.set(checksum, c.getChecksum().getLabel());
+}
I think that field isn't getting set in the form. So, while displaying
the webform works (and that field defaults to SHA-256) trying to edit it
without having anything in that field causes it to bork?
I'm really not sure here...
Thoughts?
Right whats happening here is. Your channel creation has pass3ed with
above patch. But since the checksum is not set in perl code, you're
checksum value is still null in the db and hence the traceback while
editing. Now you need to rerun the update table to fix the empty rows.
I'll be working on a patch to fix this issue sometime today and build
new packages. I'll let you know when the new packages are ready. Should
be no later than tomorrow.
~ Prad
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
--
--
Pradeep Kilambi
Senior Software Engineer
RHN Satellite Engineering
Phone: +1 919 754 4285
RHCE # 805008680430554
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Cloned Channel Problems - SW 0.6
On 08/13/2009 12:32 PM, Andy Speagle wrote: On Thu, 2009-08-13 at 10:58 -0500, Pradeep Kilambi wrote: Right whats happening here is. Your channel creation has pass3ed with above patch. But since the checksum is not set in perl code, you're checksum value is still null in the db and hence the traceback while editing. Now you need to rerun the update table to fix the empty rows. I'll be working on a patch to fix this issue sometime today and build new packages. I'll let you know when the new packages are ready. Should be no later than tomorrow. ~ Prad Thanks Prad. One thing to note is that after cloning the channel... I DID run the table update again: - SQL UPDATE rhnChannel SET checksum_type_id = (select id from rhnChecksumType where LABEL = 'sha1') WHERE checksum_type_id is null; 1 row updated. - And it updated the row... but the webform still shows SHA-256 .. and any attempts to edit the channel still throw a server error. Thanks, Hello Andy: I checked in a fix for this into the git repo. Should be in both master(1949d15abbc1dae321a1b54431602b89892c7f32) and spacewalk-0.6( 11e1848cb0274990d7b9eea378f95e2f635fd78a) if you git pull. I'll place a request to get the new respins for rhn-java pushed to the repo asap. Thanks for your patience. ~ Prad ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel -- -- Pradeep Kilambi Senior Software Engineer RHN Satellite Engineering Phone: +1 919 754 4285 RHCE # 805008680430554 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Cloned Channel Problems - SW 0.6
Devan Goodwin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 11 Aug 2009 14:47:30 -0500 Andy Speagle andy.spea...@wichita.edu wrote: On Tue, 2009-08-11 at 14:03 -0500, Andy Speagle wrote: Ok... in addition, I'm having general problems cloning channels that existed before my 0.5 - 0.6 upgrade. When I do try to clone them, I get an internal server error. However, the clone succeeds, I see the new channels in my channel list. But displaying them is a no-go. I don't have any problems creating and working with NEW channels in v0.6, but cloning old channels is problematic. Ok... even more information. I can display the channel fine when looking at it under Software Channels. However, when I try to Manage Software Channels any cloned channels return a server error. Andy The line throwing NPE from original stack trace was: form.set(checksum, c.getChecksum().getLabel()); Checksum appears to not be getting populated for existing custom channels during upgrade. Devan If you ran the upgrade scripts, there should a update table to default to sha1 for existing channels. spacewalk-schema-0.5-to-spacewalk-schema-0.6/191-rhnChannel.sql is the one I believe. ~ Prad - -- Devan Goodwin dgood...@redhat.com Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkqBzEcACgkQAyHWaPV9my49GgCdEZnCvF42C54nl4kSe77YmQpb ajQAoJopckvPQvXzJiLhap9vNl1FzEZO =h9x0 -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Cloned Channel Problems - SW 0.6
Andy Speagle wrote:
On Tue, 2009-08-11 at 14:59 -0500, Pradeep Kilambi wrote:
If you ran the upgrade scripts, there should a update table to
default
to sha1 for existing channels.
spacewalk-schema-0.5-to-spacewalk-schema-0.6/191-rhnChannel.sql is
the
one I believe.
~ Prad
I ran all of the upgrade scripts per the upgrade documentation. This
was the output in the logs.
SQL select
'spacewalk-schema-0.5-to-spacewalk-schema-0.6/191-rhnChannel.sql' from
dual;
'SPACEWALK-SCHEMA-0.5-TO-SPACEWALK-SCHEMA-0.6/191-RHNCHANNEL.SQ
---
spacewalk-schema-0.5-to-spacewalk-schema-0.6/191-rhnChannel.sql
SQL -- Add a checksum_type_id column, and fk to rhnChecksumType
SQL ALTER TABLE rhnChannel
2ADD checksum_type_id number
3 CONSTRAINT rhn_channel_checksum_fk
4 REFERENCES rhnChecksumType(id);
Table altered.
SQL
SQL -- Update any existing channels that are not set
SQL UPDATE rhnChannel SET
2checksum_type_id = (select id
3 from rhnChecksumType
4 where LABEL = 'sha1')
5 WHERE checksum_type_id is null;
23 rows updated.
SQL
SQL show errors
No errors.
SQL commit;
Commit complete.
Thoughts?
Andy
So lookong through the code, I think I know what I problem is. The perl
code when settup up the channel cloning process does'nt not account for
checksum value. So what ends up happening is, after the perl pxt setup
page it navigates to edit.do which makes assumptions based on channel
creation and edits and ends up trying to set the value thats not in the
form to being with. A workaround fix to get the cloning working for now
is to do something like,
---
a/java/code/src/com/redhat/rhn/frontend/action/channel/manage/EditChannelAct
+++
b/java/code/src/com/redhat/rhn/frontend/action/channel/manage/EditChannelAct
@@ -568,7 +568,9 @@ public class EditChannelAction extends RhnAction
implements
form.set(maintainer_phone, c.getMaintainerPhone());
form.set(maintainer_email, c.getMaintainerEmail());
form.set(support_policy, c.getSupportPolicy());
-form.set(checksum, c.getChecksum().getLabel());
+if (!c.isCloned()) {
+form.set(checksum, c.getChecksum().getLabel());
+}
if (c.isGloballySubscribable(ctx.getLoggedInUser().getOrg())) {
form.set(per_user_subscriptions, all);
}
eventually once the cloning logic in perl supports the checksum stuff,
we can remove this additional check.
I'll looking into adding this ability for the cloned channels. Please
open a bug on this and I'll knock it out asap.
Thanks,
~ Prad
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] rhnpush error from latest 0.6 packages
On 08/06/2009 10:07 PM, John Matthews wrote: In addition to the rhnpush issue, the install displayed 2 warnings from Cheetah about md5 being deprecated. Let's file a bug on the md5 issue. It will still work in F11, but display those warnings. Turns out this has already been filed as a bz, and there is a plan mentioned for this getting into Fedora-11 https://bugzilla.redhat.com/show_bug.cgi?id=480945#c8 Bug 480945 - [PATCH] Use hashlib instead of deprecated module 'md5' If you actually looked through our bug list for 0.6, you should have seen 494436 ~ Prad ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel -- -- Pradeep Kilambi Senior Software Engineer RHN Satellite Engineering Phone: +1 919 754 4285 RHCE # 805008680430554 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH/RFC/WIP] manage symlinks in config management
On 08/04/2009 03:53 PM, Joshua Roys wrote: Hello all, Attached is a patch that lets you play around with symlinks through the config management interface (rhbz#428190). It's a bit of a hack in the sense that it asks you to put the target of the symlink in the file contents. Also, a few things are unfinished or don't do what is expected with this patch. Things to do/fix: - asking for a diff dereferences the symlink. move the code from transaction.py to file_utils.py/process? - integrate with deploy/rollback. pretend symlinks are files in transaction.py? necessary with symlinks? - hide the owner:group/mode fields? always root:root/0777? - when you click on Symbolic link in the web interface, hide the File Contents box and have a Destination input field appear? - on the Channel overview page, the incorrect count of files appears. where is this number calculated from? (how does it get into ConfigChannelDto.java?) Anyone have some advice on the last one? Or any suggestions on the other ones, too. Thanks, Joshua Roys I'll go ahead and take this for review as well. But I vote to include this for 0.7 as its already too late for inclusion into spacewalk-0.6 at this point. Thanks, ~ Prad ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel -- -- Pradeep Kilambi Senior Software Engineer RHN Satellite Engineering Phone: +1 919 754 4285 RHCE # 805008680430554 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [RFC/PATCH] selinux context for config files
On 07/31/2009 02:28 PM, Joshua Roys wrote: On 07/30/2009 05:24 PM, Pradeep Kilambi wrote: Also few suggestions looking through the behaviour after fixing that one line: * If we set an invalid content for a file, setfilecon will return a -1 and leave the default context. I would check if the return code of setfilecon is -1 and log that info so user knows that the context dint apply in failure case. * Secondly in the fileDetails.do page, below the selinux Content entry area, I would add a tip to help users know the format of the input that field takes. Thanks, ~ Prad Hello, Thanks for taking a look at this! Suggestions applied. Attached are two patches - the full one from master, and an 'update' diff from the previously sent patch. Thanks again, Joshua Roys Hello Joshua: This final version looks good. config files deployed with correct selinux content for me. Thanks for including all the suggestion. Patches tested and applied. New commits: commit 40785d998874d7e9b022a79a8322bce09af8ac3f Author: Joshua Roysjoshua.r...@gtri.gatech.edu Date: Mon Aug 3 13:21:21 2009 -0400 Patch: Selinux Context support for config files commit 074cca0508e8d6b4817453f45b2bfada62ed8623 Author: Joshua Roysjoshua.r...@gtri.gatech.edu Date: Mon Aug 3 13:25:08 2009 -0400 upgrade script for the previous commit. Patch from Joshua Roys Thanks a lot for your contribution. ~ Prad -- -- Pradeep Kilambi RHN Satellite Engineering pkila...@redhat.com Phone: +1 919 754 4285 RHCE # 805008680430554 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [RFC/PATCH] selinux context for config files
On 07/28/2009 03:53 PM, Joshua Roys wrote:
Hello,
Attached is a version rebased on latest master and taking into account
the recent postgresql changes.
Thanks,
Joshua Roys
I reviewed the code and Overall it looks good. Seeing minor issues
such as test build failures and checkstyle.
If you run
$ ant clean all (in java dir) you should see,
do-compile-main:
[javac] Compiling 2469 source files to
code/git/spacewalk/java/build/classes
[javac]
code/git/spacewalk/java/code/src/com/redhat/rhn/domain/config/test/ConfigurationFactoryTest.java:153:
lookupOrInsertConfigInfo(java.lang.String,java.lang.String,java.lang.Long,java.lang.String)
in com.redhat.rhn.domain.config.ConfigurationFactory cannot be applied
to (java.lang.String,java.lang.String,java.lang.Long)
[javac] ConfigInfo info1 =
ConfigurationFactory.lookupOrInsertConfigInfo(testman,
[javac]^
[javac]
code/git/spacewalk/java/code/src/com/redhat/rhn/domain/config/test/ConfigurationFactoryTest.java:155:
lookupOrInsertConfigInfo(java.lang.String,java.lang.String,java.lang.Long,java.lang.String)
in com.redhat.rhn.domain.config.ConfigurationFactory cannot be applied
to (java.lang.String,java.lang.String,java.lang.Long)
[javac] ConfigInfo info2 =
ConfigurationFactory.lookupOrInsertConfigInfo(testman,
[javac]^
[javac]
code/git/spacewalk/java/code/src/com/redhat/rhn/testing/ConfigTestUtils.java:310:
lookupOrInsertConfigInfo(java.lang.String,java.lang.String,java.lang.Long,java.lang.String)
in com.redhat.rhn.domain.config.ConfigurationFactory cannot be applied
to (java.lang.String,java.lang.String,java.lang.Long)
[javac] return
ConfigurationFactory.lookupOrInsertConfigInfo(user, group, fileMode);
[javac]^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 3 errors
BUILD FAILED
For checkstyle Errors:
run $ ant checkstyle (in your java dir) and you'll see,
[checkstyle]
code/git/spacewalk/java/code/src/com/redhat/rhn/domain/config/ConfigInfo.java:107:19:
Name 'getSelinux_ctx' must match pattern '^[a-z][a-zA-Z0-9]*$'.
[checkstyle]
code/git/spacewalk/java/code/src/com/redhat/rhn/domain/config/ConfigInfo.java:115:17:
Name 'setSelinux_ctx' must match pattern '^[a-z][a-zA-Z0-9]*$'.
[checkstyle]
code/git/spacewalk/java/code/src/com/redhat/rhn/domain/config/ConfigurationFactory.java:483:53:
Name 'selinux_ctx' must match pattern '^[a-z][a-zA-Z0-9]*$'.
[checkstyle]
code/git/spacewalk/java/code/src/com/redhat/rhn/domain/config/ConfigurationFactory.java:498:35:
Name 'selinux_ctx' must match pattern '^[a-z][a-zA-Z0-9]*$'.
[checkstyle]
code/git/spacewalk/java/code/src/com/redhat/rhn/manager/configuration/file/ConfigFileData.java:140:19:
Name 'getSelinux_ctx' must match pattern '^[a-z][a-zA-Z0-9]*$'.
[checkstyle]
code/git/spacewalk/java/code/src/com/redhat/rhn/manager/configuration/file/ConfigFileData.java:147:17:
Name 'setSelinux_ctx' must match pattern '^[a-z][a-zA-Z0-9]*$'.
[checkstyle]
code/git/spacewalk/java/code/src/com/redhat/rhn/manager/configuration/file/ConfigFileData.java:254:39:
'(' is followed by whitespace.
BUILD FAILED
Mind fixing those and including it in your patch? In the mean time I'm
trying to deploy your patch to a test server and testing it.
Thanks again,
~ Prad
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
--
--
Pradeep Kilambi
RHN Satellite Engineering
pkila...@redhat.com
Phone: +1 919 754 4285
RHCE # 805008680430554
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [RFC/PATCH] selinux context for config files
On 07/28/2009 03:53 PM, Joshua Roys wrote:
Hello,
Attached is a version rebased on latest master and taking into account
the recent postgresql changes.
Thanks,
Joshua Roys
Joshua:
Seeing more issues,
- If you try to deploy a file with a content it hits the below block.
D: do_call configfiles.deploy ({'files': [{'config_channel': 'pradtest',
'username': 'root', 'md5sum': '71b517126a29976c78b478065104bc04',
'encoding': 'base64', 'filetype': 'file', 'delim_start': '{|',
'file_contents': 'aGkgc2VsaW51eA==\n', 'groupname': 'root', 'delim_end':
'|}', 'selinux_ctx': 'user_home_t', 'filemode': 644, 'path':
'/tmp/foo.txt', 'revision': 2}]},)
global name 'setfilecon' is not defined
D: Sending back response (49, Failed deployment, rolled back: global
name 'setfilecon' is not defined, {})
D: do_call packages.checkNeedUpdate ('rhnsd=1',)
D: local action status: (0, 'rpm database not modified since last
update (or package list recently updated)', {})
D: closed db index /var/lib/rpm/Providename
D: closed db index /var/lib/rpm/Packages
D: closed db environment /var/lib/rpm/Packages
D: May free Score board((nil))
diff --git a/client/tools/rhncfg/config_common/transactions.py
b/client/tools/rhncfg/config_common/transactions.py
index 9f87700..2458f9a 100644
--- a/client/tools/rhncfg/config_common/transactions.py
+++ b/client/tools/rhncfg/config_common/transactions.py
...
+if file_info.has_key('selinux_ctx'):
+sectx = file_info.get('selinux_ctx')
+if sectx is not None:
+log_debug(1, selinux context: + sectx);
+setfilecon(temp_file_path, sectx);
+
...
In the above block setfilecon here is not defined, so it will fail with
a global setfilecon not set. Looks like you left out parts in your patch
that is suppose to set the content of the file once the client gets the
request.
~ Prad
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
--
--
Pradeep Kilambi
RHN Satellite Engineering
pkila...@redhat.com
Phone: +1 919 754 4285
RHCE # 805008680430554
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [RFC/PATCH] selinux context for config files
On 07/30/2009 04:42 PM, Joshua Roys wrote:
On 07/30/2009 04:19 PM, Pradeep Kilambi wrote:
Joshua:
Seeing more issues,
- If you try to deploy a file with a content it hits the below block.
D: do_call configfiles.deploy ({'files': [{'config_channel': 'pradtest',
'username': 'root', 'md5sum': '71b517126a29976c78b478065104bc04',
'encoding': 'base64', 'filetype': 'file', 'delim_start': '{|',
'file_contents': 'aGkgc2VsaW51eA==\n', 'groupname': 'root', 'delim_end':
'|}', 'selinux_ctx': 'user_home_t', 'filemode': 644, 'path':
'/tmp/foo.txt', 'revision': 2}]},)
global name 'setfilecon' is not defined
D: Sending back response (49, Failed deployment, rolled back: global
name 'setfilecon' is not defined, {})
D: do_call packages.checkNeedUpdate ('rhnsd=1',)
D: local action status: (0, 'rpm database not modified since last update
(or package list recently updated)', {})
D: closed db index /var/lib/rpm/Providename
D: closed db index /var/lib/rpm/Packages
D: closed db environment /var/lib/rpm/Packages
D: May free Score board((nil))
diff --git a/client/tools/rhncfg/config_common/transactions.py
b/client/tools/rhncfg/config_common/transactions.py
index 9f87700..2458f9a 100644
--- a/client/tools/rhncfg/config_common/transactions.py
+++ b/client/tools/rhncfg/config_common/transactions.py
...
+ if file_info.has_key('selinux_ctx'):
+ sectx = file_info.get('selinux_ctx')
+ if sectx is not None:
+ log_debug(1, selinux context: + sectx);
+ setfilecon(temp_file_path, sectx);
+
...
In the above block setfilecon here is not defined, so it will fail with
a global setfilecon not set. Looks like you left out parts in your patch
that is suppose to set the content of the file once the client gets the
request.
~ Prad
Hello,
How strange, I did somehow completely delete that from all copies of
my code... luckily it's actually one line.
from selinux import setfilecon
And now the package that file is in will depend on libselinux-python,
if it doesn't already.
Sorry about that.
I'll try to address the issues you've found and produce a more
official patch tomorrow.
Joshua Roys
No Problem. I'll wait for your final patch and retest it. I have all
your code deployed and setup so its gonna be a quick test this time.
Thanks again for your contribution.
~ Prad
--
--
Pradeep Kilambi
RHN Satellite Engineering
pkila...@redhat.com
Phone: +1 919 754 4285
RHCE # 805008680430554
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [RFC/PATCH] selinux context for config files
On 07/30/2009 05:11 PM, Pradeep Kilambi wrote: On 07/30/2009 04:42 PM, Joshua Roys wrote: Hello, How strange, I did somehow completely delete that from all copies of my code... luckily it's actually one line. from selinux import setfilecon And now the package that file is in will depend on libselinux-python, if it doesn't already. Sorry about that. I'll try to address the issues you've found and produce a more official patch tomorrow. Joshua Roys No Problem. I'll wait for your final patch and retest it. I have all your code deployed and setup so its gonna be a quick test this time. Thanks again for your contribution. ~ Prad Also few suggestions looking through the behaviour after fixing that one line: * If we set an invalid content for a file, setfilecon will return a -1 and leave the default context. I would check if the return code of setfilecon is -1 and log that info so user knows that the context dint apply in failure case. * Secondly in the fileDetails.do page, below the selinux Content entry area, I would add a tip to help users know the format of the input that field takes. Thanks, ~ Prad -- -- Pradeep Kilambi RHN Satellite Engineering pkila...@redhat.com Phone: +1 919 754 4285 RHCE # 805008680430554 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [RFC/PATCH] selinux context for config files
On 07/09/2009 10:19 AM, Joshua Roys wrote: Hello all, Attached is a patch to add the ability to specify a SELinux context in the Configuration management part of Spacewalk. It works for me, but I would appreciate your expert review. Also attached is a sql schema upgrade. Thanks, Joshua Roys Thanks for the patches Joshua. I'll review the changes , test and apply to master if all goes well. ~ Prad ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel -- -- Pradeep Kilambi RHN Satellite Engineering pkila...@redhat.com Phone: +1 919 754 4285 RHCE # 805008680430554 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Re: Branch 'sha256-support' - 135 commits - ... schema/spacewalk ...
On 07/27/2009 01:54 PM, Milan Zazrivec wrote: On Monday 27 July 2009 15:54:13 Pradeep Kilambi wrote: diff --git a/schema/spacewalk/rhnsat/tables/rhnChannel.sql b/schema/spacewalk/rhnsat/tables/rhnChannel.sql index 95a54dc..b4e1fab 100644 --- a/schema/spacewalk/rhnsat/tables/rhnChannel.sql +++ b/schema/spacewalk/rhnsat/tables/rhnChannel.sql @@ -49,6 +49,8 @@ rhnChannel gpg_key_id varchar2(14), gpg_key_fp varchar2(50), end_of_life date, +checksum_type_id number constraint rhn_channel_checksum_fk + references rhnChecksumType(id), receiving_updates char(1) default 'Y' constraint rhn_channel_ru_nn not null Now that rhnChannel table depends on rhnChecksumType, this relation needs to be put into the Makefile.deps (and the pgsql branch equivalent) so that the resulting schema deploys cleanly. Thanks milan. Yea I was waiting for jortel to finish his merge. Before I make any further db changes. ~ Prad -MZ ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel -- -- Pradeep Kilambi RHN Satellite Engineering pkila...@redhat.com Phone: +1 919 754 4285 RHCE # 805008680430554 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] XMLRPC APIs
Jason Dobies wrote: In registration.py, why is the new_system_activation_key API commented out? I might be missing it but I don't see an explanation in the code. To being with that was just a place holder. That call was never implemented afaik. It was added as part of the initial RHEL-5 changes. We already handle the activation keys in create_systems call which is in turn called by new_system and new_system_user_pass so use that instead. Lemme know if you need help with usage on that. I dont see any need for the call based on current use cases we have. I'll go ahead and clean it up. ~ Prad ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [SHA256] - problems and options
Miroslav Suchý wrote: I do not see any other options. And you? My personal preferences are (from best to worse): 2, 3, 1, 4. Please share your opinions about this. Dint we already come to a conclusion on this :). I spoke to James antill on the options and how yum handles. Older yum clients will not be able to handle sha256 and newer clients will be able to handle both. Having python-haslib into el5 from epel is not our decision. Yes that will make our life easy ofcourse. python-hashlib dependency if any has to be on yum not yum-rhn-plugin. We don't deal with checksums in our plugin. Its all yum code that depends on it. So adding python-hashlib to plugin is wrong thing to do. It should be yum and we from satellite/spacewalk dont maintain it. So yea we can file a request for yum to include it. But I doubt it as its gonna be supported from 5.5 anyway. Also older u releases will have to be patched which is not possible. So if someone is using 5u3 or older they cannot use python-hashlib. So we have to account for that. We cannot blindly generate everything with sha256. Now since the new clients handle both types * if its newer version of client we will default to sha256. * else if its older version default to sha1/md5 * else if its custom default to sha1/md5. So currently thats the approach I was gonna take unless we can convince people to include python-hashlib into el5.4 or older. ~ Prad ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Support inifinite available entitlements in TUI registration
James Bowes wrote: getRemainingSubscriptions can return -1 if your account has an unlimited amount of entitlements for the channel you're trying to subscribe to. The rhn_register GTK+ gui knew about this, but the TUI did not. (attached) Patch Applied! Thanks :} ~ Prad -James ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel -- -- Pradeep Kilambi RHN Satellite Engineering pkila...@redhat.com Phone: +1 919 754 4285 RHCE # 805008680430554 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Send smbios data to remaining_subscriptions during registration
James Bowes wrote: Hey gang: Attached is a patch to get rhn_register to send up smbios data during a remaining_subscriptions call, so that during rhn_register you won't get prompted for an IN if your account has no available channel entitlements, but you should get free guest channel entitlements due to the host having a virtualization system level entitlement. -James We cant do this yet as remaining_subscriptions call on satellite does'nt support virt uuid. I'm guessing you forgot to add the hosted changes here. I see that you guys are tracking this in bug#499830. We'll need to create a clone for this bug for spacewalk/satellite and port the server changes to satellite and then add this to the client. I'll create a clone and port the hosted patch to satellite first, looks like its in commit #1b70e30e038c00d0dcaef9c34be9c153265cd92d in hosted if I'm not mistaken. ~ Prad ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Send smbios data to remaining_subscriptions during registration
Pradeep Kilambi wrote: James Bowes wrote: Hey gang: Attached is a patch to get rhn_register to send up smbios data during a remaining_subscriptions call, so that during rhn_register you won't get prompted for an IN if your account has no available channel entitlements, but you should get free guest channel entitlements due to the host having a virtualization system level entitlement. -James We cant do this yet as remaining_subscriptions call on satellite does'nt support virt uuid. I'm guessing you forgot to add the hosted changes here. I see that you guys are tracking this in bug#499830. We'll need to create a clone for this bug for spacewalk/satellite and port the server changes to satellite and then add this to the client. I'll create a clone and port the hosted patch to satellite first, looks like its in commit #1b70e30e038c00d0dcaef9c34be9c153265cd92d in hosted if I'm not mistaken. ~ Prad ok per James thats hosted specific. But we still have this call in satellite so I guess I'll jus clean this stuff up. patch applied to support hosted remaining_subs api change to the client. I'm still working on getting the eus stuff tested..hitting road blocks. Will keep you posted. Thanks, ~ Prad ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Show all available eus channels during registration
James Bowes wrote: Hi gang: Attached is a patch to fix some of the slightly broken logic presenting available z-stream/eus channels during registration. Please see the commit message on the attached patch for a detailed explaination. AFAIK this removes the only read of the is_default column in rhnreleasechannelmap, so you can probably drop that column after removing the code that populates it in satellite-sync. disclaimer: I haven't actually tested this on a real spacewalk instance, but hey, what could possiblie go rong? -James Thanks for the patch. I'll review it and apply. ~ Prad ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Show all available eus channels during registration
James Bowes wrote: Hi gang: Attached is a patch to fix some of the slightly broken logic presenting available z-stream/eus channels during registration. Please see the commit message on the attached patch for a detailed explaination. AFAIK this removes the only read of the is_default column in rhnreleasechannelmap, so you can probably drop that column after removing the code that populates it in satellite-sync. disclaimer: I haven't actually tested this on a real spacewalk instance, but hey, what could possiblie go rong? -James Just fyi, tracking this as the clone for sat/spacewalk(bug#502915) ~ Prad ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Why rhn-client-tools requires yum-rhn-plugin?
Miroslav Suchy wrote: We have cyclic dependency between rhn-client-tools and yum-rhn-plugin, which seems to be bad for Fedora review. I tried to look on code in rhn-client-tools code, but I did not find direct dependency on yum-rhn-plugin. Did I miss something? Yes, they are interdependent wrt versioning, multiarch resolutions and cdn support. If you use yum-rhn-plugin 0.5.3-30 with latest version of rhn-client tools it will break the multiarch support. If you use latest yum-rhn-plugin with older rhn-client-tools it will break cdn and versioning thats being sent across. I prefer not to make any changes now as RHEL-5.4 is devel frozen. ~ Prad That specific Requires: was put there in commit e80c11ae050937f7db0893b241724c6177873c57, which merged code from our old svn. But, when I check our old svn, it does not seem to be present in latest trunk/eng/client/rhel/rhn-client-tools/rhn-client-tools.spec file? Do we really need this Requires then? Can I remove? Miroslav Suchy ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Why rhn-client-tools requires yum-rhn-plugin?
Miroslav Suchy wrote: - Pradeep Kilambi pkila...@redhat.com wrote: cdn support. If you use yum-rhn-plugin 0.5.3-30 with latest version of rhn-client tools it will break the multiarch support. If you use latest yum-rhn-plugin with older rhn-client-tools it will break cdn and versioning thats being sent across. Aha, so it is not requires, but rather conflicts with older versions. So should be more correct to put inside rhn-client-tools.spec instead of: Requires: yum-rhn-plugin = 0.5.3-30 this line: Conflicts: yum-rhn-plugin 0.5.3-30 ??? I'm not sure about yum-rhn-plugin.spec since I did not check its code and dunno if there should be conflict as well or if the code is really required. Its not a conflict. We should force users using latest yum-rhnplugin to get newer rhn-client-tools and vice-versa. So requires as we have should do it. ~ Prad I prefer not to make any changes now as RHEL-5.4 is devel frozen. NP. Fedora waited long time for Spacewalk. Can wait few weeks :) Miroslav Suchy ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Why rhn-client-tools requires yum-rhn-plugin?
Jan Pazdziora wrote: On Thu, May 14, 2009 at 10:50:11AM -0400, Pradeep Kilambi wrote: cdn support. If you use yum-rhn-plugin 0.5.3-30 with latest version of rhn-client tools it will break the multiarch support. If you use latest yum-rhn-plugin with older rhn-client-tools it will break cdn and versioning thats being sent across. Aha, so it is not requires, but rather conflicts with older versions. So should be more correct to put inside rhn-client-tools.spec instead of: Requires: yum-rhn-plugin = 0.5.3-30 this line: Conflicts: yum-rhn-plugin 0.5.3-30 ??? I'm not sure about yum-rhn-plugin.spec since I did not check its code and dunno if there should be conflict as well or if the code is really required. Its not a conflict. We should force users using latest yum-rhnplugin to get newer rhn-client-tools and vice-versa. So requires as we have should do it. Prad, if the user does have yum-rhnplugin but not rhn-client-tools, will yum-rhnplugin work? If it won't then it's Requires case. If it will work without rhn-client-tools or with new rhn-client-tools but not with old rhn-client-tools, it's Conflicts. And vice versa -- for does rhn-client-tools need yum-rhnplugin to work? yes, without yum-rhn-plugin, rhn_check(part of rhn-client-tools) will not be able to process actions picked up and pass it to yum. Similarly without rhn-client-tools, yum-rhn-plugin will not be able to authenticate to rhn, as rhn-client-tools is what provides the authentication layer. There are also other cases where, the versioning is enforced in the http headers through clientCaps in rhn-client-tools to get the access to various capabilities such as arch info from the supported server. But this arch info can only be processed by the latest yum-rhn-plugin which has the arch capability fixes and which depends on the new rebased yum in 5.3. And hence a Requires case in my opinion. ~ Prad ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Recognize KVM/QEMU guests as virtual systems
James Bowes wrote: Hi all: Attached are two patches. The first changes how smbios data is handled during registration, to send it when the server is created (so that, similar to xen, it can get free entitlements if appropriate). The second are the matching server side changes to parse the sent smbios data for indications that the registering system is a KVM/QEMU guest. Right now this just sets the guest type as fully virt. It might be nice to add a third type for KVM/QEMU. -James patches applied, thx! ~ Prad ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Channel Name Length
Jason Dobies wrote: I'm taking a look at https://bugzilla.redhat.com/show_bug.cgi?id=498467 In short, when we clone a channel we default the name to Clone of *. For certain Red Hat channels, this results in a channel name that's longer than the limit (64 characters). Of course, one approach is to make sure the name we generate is less than 64 characters. But I'm wondering if we're hitting this because 64 is too short of a length for the name. Since the label is capped at 128, I was thinking of changing the DB to allow a channel name of up to 128 characters as well. I don't think it's a big problem, but for DB changes like this I like to throw it out there first in case someone sees a problem that I'm not seeing. Yep I hit the same for package names and iirc we bumped it to 256. So yep I agree with db change. ~ Prad ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] handle orphaned GID's the same way as orphaned UID's
Maxim Burgerhout wrote: Hi, Below is a patch to rhncfgcli_verify.py to make it handle orphaned GID's the same way as orphaned UID's are handled. I recently found out the current implementation raises a KeyError exception if an orphaned GID is encountered. This happens when rhncfg_client verify is run on a system on which one of the deployed configuration files is owned by a group that doesn't exist (anymore). Patch is basically an adaptation of the code that handles UID's in the same file, about ten lines up. I usually spend my time being an sysadmin, so I hope I'm doing this 'sending patch' stuff the right way ;-) Hope this helps. Maxim Burgerhout ma...@wzzrd.com GPG Fingerprint 1CC2 A9B2 FE2E 799D 01DB 8A89 0AE8 B60A ACA3 4452 diff --git a/client/tools/rhncfg/config_client/rhncfgcli_verify.py b/client/tools/rhncfg/config_client/rhncfgcli_verify.py index 8240d2b..03d2716 100644 --- a/client/tools/rhncfg/config_client/rhncfgcli_verify.py +++ b/client/tools/rhncfg/config_client/rhncfgcli_verify.py @@ -152,7 +152,11 @@ class Handler(handler_base.HandlerBase): if not stat_err: #check for group differences dst_gid = dst_stat[stat.ST_GID] -dst_group = grp.getgrgid(dst_gid)[0] +try: +dst_group = grp.getgrgid(dst_gid)[0] +except KeyError: +# Orphan GID with no name,return unknown +dst_group = unknown(GID %d) % (dst_gid,) else: dst_group = missing Patch tested and applied! commit b9d85020ef88ee507e51f0f182074c96f63ccc95 Author: Maxim Burgerhout ma...@wzzrd.com Date: Tue Apr 7 14:10:07 2009 +0200 Thanks for your contribution. ~ Prad ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Can someone review/add script
Pradeep Kilambi wrote: Cliff wrote: https://bugzilla.redhat.com/show_bug.cgi?id=146192 The above public satellite bug has a script attached to it that is GPL'd and does signing and push of rpms into a Satellite/Spacewalk server. Can someone review it and add into spacewalk git if we feel it will be benefit to other users/admins to have available. Cliff ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel I'll review and add my comments to the bug. Thanks, ~ Prad Done. I've reviewed and tested the above script. Although the script is needlessly complex for what its doing, since we dont have a script that has similar functionality, I decided to add it to our repo. I've put it under spacewalk/scripts. Thanks, ~ Prad. -- -- Pradeep Kilambi RHN Satellite Engineering pkila...@redhat.com Phone: +1 919 754 4285 RHCE # 805008680430554 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Can someone review/add script
Cliff wrote: https://bugzilla.redhat.com/show_bug.cgi?id=146192 The above public satellite bug has a script attached to it that is GPL'd and does signing and push of rpms into a Satellite/Spacewalk server. Can someone review it and add into spacewalk git if we feel it will be benefit to other users/admins to have available. Cliff ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel I'll review and add my comments to the bug. Thanks, ~ Prad -- -- Pradeep Kilambi RHN Satellite Engineering pkila...@redhat.com Phone: +1 919 754 4285 RHCE # 805008680430554 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] yet another gitk
Stumbled across this tool called giggle. Its a graphical frontend for the git. Apparently gitk for GTK+ http://live.gnome.org/giggle Its a bit slow compared to gitk. But looks much cleaner and nicer. The colors and graphs that we care about look even prettier. Another tool for us to please ;) jus yum install giggle if you're on fedora. -- -- Pradeep Kilambi RHN Satellite Engineering pkila...@redhat.com Phone: +1 919 754 4285 RHCE # 805008680430554 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [Fwd: [Bug 490438] Review Request: rhn-client-tools - Support programs and libraries for Red Hat Network or Spacewalk]
Miroslav Suchý wrote:
Do we have reason why we have python code in /usr/share/rhn and not in
%{python_sitelib}?
Well as the guidelines say, we have our python *modules* (eg: rhnlib) in
python_sitelib. I don't really consider our server/client code to be a
utility module that belongs to sitelib and as far as I see its placed
right in /usr/share/. Of course its before my time this decision was
made, but I think its the right one. We should not have code in sitelib
unless its a module that could be used generically. Anyway, thats my
take. All they have to do is add that path to their PYTHONPATH. I don't
think python guidelines enforce all the code to be in python-sitelibs
anywhere.
- Prad
Original Message
Subject: [Bug 490438] Review Request: rhn-client-tools - Support
programs and libraries for Red Hat Network or Spacewalk
Date: Tue, 24 Mar 2009 08:02:28 -0400
From: bugzi...@redhat.com
To: msu...@redhat.com
References: bug-490438-206...@bugzilla.redhat.com
--- Comment #3 from Nigel Jones nigjo...@redhat.com 2009-03-24
2. Python module locations
I'm not sure how set in stone this is, but w/ our Python Guidelines,
python
modules are prefered to be in %{python_sitelib}/modulename/foo.*
(https://fedoraproject.org/wiki/Packaging/Python#System_Architecture)
would
moving these libraries cause any issues with rhn_register etc?
--
--
Pradeep Kilambi
RHN Satellite Engineering
pkila...@redhat.com
Phone: +1 919 754 4285
RHCE # 805008680430554
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] package-push: Avoid opening the system rpmdb
Ah nice timing. We hit this recently and were investigating the same as
stated boiled down to rpm and httpd's db4. See this bug#491119. Panu was
going to spend sometime and see if he could get rpm to upgrade to db4.7,
which apparently has number of advantages and he wanted to do it anyway
irrespective of this issue. Of course if we have a patch then even
better, we dont have to wait for his efforts to get spacewalk on f10
out. I'll test the attached patch and apply if all is well.
Thanks for the patch.
~ Prad
James Bowes wrote:
httpd and rpm both use the db4 library. When running code in httpd that
uses rpmlib, the db4 so loaded by httpd will trump whatever may be
loaded by rpm. If the versions linked against by the two code bases are
different, any api/abi changes can cause breakage in the rpm code.
Spacewalk imports rpms into its database via an rpm read-only
transaction and hdrFromFdno, which initializes the system rpmdb, even
though it's not strictly required for reading the rpm's header
information.
Instead, use rpm.readHeaderFromFD (after seeking to the header's start
in the rpm file), which does not try to open the rpmdb.
---
This patch should fix up the segfaults rhnpush has been causing
server-side on F10. There may be other places where such changes
could be made, but I've yet to look for them.
Tested with a few x86_64 and noarch packages, both signed and unsigned.
-James
backend/common/rhn_rpm.py | 61 --
backend/satellite_tools/satComputePkgHeaders.py |4 +-
backend/server/rhnPackageUpload.py | 54 +
3 files changed, 58 insertions(+), 61 deletions(-)
diff --git a/backend/common/rhn_rpm.py b/backend/common/rhn_rpm.py
index a7a9baf..93b87d5 100644
--- a/backend/common/rhn_rpm.py
+++ b/backend/common/rhn_rpm.py
@@ -189,6 +189,57 @@ class RPM_Header:
'signature' : ret,
})
+def get_header_byte_range(package_file):
+
+Return the start and end bytes of the rpm header object.
+
+For details of the rpm file format, see:
+http://www.rpm.org/max-rpm/s1-rpm-file-format-rpm-file-format.html
+
+
+lead_size = 96
+
+# Move past the rpm lead
+package_file.seek(lead_size)
+
+sig_size = get_header_struct_size(package_file)
+
+# Now we can find the start of the actual header.
+header_start = lead_size + sig_size
+
+package_file.seek(header_start)
+
+header_size = get_header_struct_size(package_file)
+
+header_end = header_start + header_size
+
+return (header_start, header_end)
+
+def get_header_struct_size(package_file):
+
+Compute the size in bytes of the rpm header struct starting at the current
+position in package_file.
+
+# Move past the header preamble
+package_file.seek(8, 1)
+
+# Read the number of index entries
+header_index = package_file.read(4)
+(header_index_value, ) = struct.unpack('I', header_index)
+
+# Read the the size of the header data store
+header_store = package_file.read(4)
+(header_store_value, ) = struct.unpack('I', header_store)
+
+# The total size of the header. Each index entry is 16 bytes long.
+header_size = 8 + 4 + 4 + header_index_value * 16 + header_store_value
+
+# Headers end on an 8-byte boundary. Round out the extra data.
+round_out = header_size % 8
+if round_out != 0:
+header_size = header_size + (8 - round_out)
+
+return header_size
# Loads the package header from a file / stream / file descriptor
# Raises rpm.error if an error is found, or InvalidPacageError if package is
@@ -217,12 +268,10 @@ def get_package_header(filename=None, file=None, fd=None):
if hdr is None:
raise InvalidPackageError
else:
-ts = RPMReadOnlyTransaction()
-nomd5 = getattr(rpm, 'RPMVSF_NOMD5')
-needpayload = getattr(rpm, 'RPMVSF_NEEDPAYLOAD')
-ts.pushVSFlags(~(nomd5 | needpayload))
-hdr = RPMReadOnlyTransaction().hdrFromFdno(file_desc)
-ts.popVSFlags()
+header_start, header_end = \
+get_header_byte_range(os.fdopen(os.dup(file_desc)))
+os.lseek(file_desc, header_start, 0)
+hdr, offset = rpm.readHeaderFromFD(file_desc)
if hdr is None:
raise InvalidPackageError
is_source = hdr[getattr(rpm, 'RPMTAG_SOURCEPACKAGE')]
diff --git a/backend/satellite_tools/satComputePkgHeaders.py
b/backend/satellite_tools/satComputePkgHeaders.py
index 7aca36d..015a658 100644
--- a/backend/satellite_tools/satComputePkgHeaders.py
+++ b/backend/satellite_tools/satComputePkgHeaders.py
@@ -55,7 +55,7 @@ sys.modules[_apache] = sys.modules[__main__]
from server import rhnSQL
-from server import rhnPackageUpload
+from common import rhn_rpm
options_table = [
Option(-v, --verbose, action=count,
@@ -205,7 +205,7 @@ class Runner:
continue
try:
-
[Spacewalk-devel] Re: 484879 - warn if you are connection using ISS to parent which do not know ISS
Miroslav Suchý wrote: Pradeep Kilambi wrote: Miroslav Suchý wrote: Pradeep Kilambi wrote: Looking at your commit: http://git.fedoraproject.org/git/?p=spacewalk.git;a=commitdiff;h=c587ddb52000ea2ec2635bccf6729cdf7f6dc0a2 You're missing the fact that even with CFG.ISS_PARENT set, we can still talk to RHN with my commandline url options. Which means you'll be raising an iss error even when you're communicating with hosted. Which is incorrect. Please fix this appropriately so we check the right condition. Just checking the iss_parent flag wont suffice. According to backend/satellite_tools/satsync.py line 2127: CFG.set(ISS_PARENT, OPTIONS.iss_parent or CFG.ISS_PARENT) I thought that CFG.ISS_PARENT is set to value in configuration file and overridden with command line option. Am I missing something? iss_parent flag is overridden only when you want to override iss_parent option while talking to another satllite/sw. When you're connecting to RHN, you'll be using server option. In which case, your iss_parent is intact. So, you're now in a situation where your iss_parent is set in the config but you're connecting to hosted through options.server and that takes precedence. Which is a valid scenario, so you'll need to take that into account before throwing specific exceptions. ~ Prad Around line 412: if CFG.ISS_PARENT: url = self.xmlWireServer.schemeAndUrl(CFG.ISS_PARENT) else: url = self.xmlWireServer.schemeAndUrl(CFG.RHN_PARENT) log(1, ['Red Hat Network Satellite - live synchronization', ' url: %s' % url, ' debug/output level: %s' % CFG.DEBUG]) if CFG.ISS_PARENT: self.xmlWireServer.setServerHandler(isIss=1) else: self.xmlWireServer.setServerHandler() So if CFG.ISS_PARENT is set, we are not connecting to CFG.RHN_PARENT (which is populated by OPTIONS.server)... So if we want to make your scenario working, we should replace: CFG.set(ISS_PARENT, OPTIONS.iss_parent or CFG.ISS_PARENT) with: if OPTIONS.server: CFG.set(ISS_PARENT, None) else: CFG.set(ISS_PARENT, OPTIONS.iss_parent or CFG.ISS_PARENT) Question is: do we want this behavior? Hrm, I think we're claiming that we support this scenario, so I think we might as well do it. -- -- Pradeep Kilambi RHN Satellite Engineering pkila...@redhat.com Phone: +1 919 754 4285 RHCE # 805008680430554 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] 484879 - warn if you are connection using ISS to parent which do not know ISS
Looking at your commit: http://git.fedoraproject.org/git/?p=spacewalk.git;a=commitdiff;h=c587ddb52000ea2ec2635bccf6729cdf7f6dc0a2 You're missing the fact that even with CFG.ISS_PARENT set, we can still talk to RHN with my commandline url options. Which means you'll be raising an iss error even when you're communicating with hosted. Which is incorrect. Please fix this appropriately so we check the right condition. Just checking the iss_parent flag wont suffice. ~ Prad ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] What is spacewalk-backend-upload-server?
Miroslav Suchý wrote: $SUBJ Why I ask? None package require spacewalk-backend-upload-server in Spacewalk. So it is not installed on spacewalk. Should the dependency be added to spacewalk.spec or we should delete this subpackage? As we spoke on irc, its was used by rhn-pkg-upload. But there is some useful code I would like to move and then we can clean it up. Thanks, ~ Prad -- -- Pradeep Kilambi RHN Satellite Engineering pkila...@redhat.com Phone: +1 919 754 4285 RHCE # 805008680430554 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PATCH: Allow for rhncfg-client get to --exclude files
Pradeep Kilambi wrote: Coe, Colin C. (Unix Engineer) wrote: Ahem... From: spacewalk-devel-boun...@redhat.com [spacewalk-devel-boun...@redhat.com] On Behalf Of Miroslav Suchý [msu...@redhat.com] Sent: Thursday, 12 February 2009 7:31 PM To: spacewalk-devel@redhat.com; Coe, Colin C. (Unix Engineer) Subject: Re: [Spacewalk-devel] PATCH: Allow for rhncfg-client get to --exclude files Coe, Colin C. (Unix Engineer) wrote: This patch (which I'm submitting on behalf of a college, Ian Chapman) adds an --exclude parameter to 'rhncfg-client get'. This allows you to get all files for this system except that one. Example: rhncfg-client get --exclude /etc/ldap.conf --exclude /etc/openldap/ldap.conf Please credit this to Ian. As always, Thanks Colin/Ian :) I'll add this the list of patches I'm suppose to review and apply this week. Thanks Again. ~ Prad Patch applied. One suggestion, your patch does'nt include the new exclude option in the man page. If you wish to include that feel free to send me a patch. If not I can update that as well. Thanks for your contribution. ~ Prad Hmm, did you intend to actually attach the patch to your email? :)) -- Miroslav Suchy RHN Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel NOTICE: This email and any attachments are confidential. They may contain legally privileged information or copyright material. You must not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages and all attachments. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel -- -- Pradeep Kilambi RHN Satellite Engineering pkila...@redhat.com Phone: +1 919 754 4285 RHCE # 805008680430554 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] rhnpush.spec small changes for submission to Fedora
Michael Stahnke wrote: A few minor changes since first patch. See Bug # 485007. I will submit final patch once this is accepted in Fedora. A question on rhnpush. There is a test directory, but I can't get any of the tests to run. It appears that some type of harness is missing or is not setup. Is there any documentation on getting those tests to work? Ideally in the spec file the %check section would call them. The test directory for the tools is pretty out of date. So yea I'm not surprised its not working. Any unit test contributions are welcome. But for now can you may be exclude this from your patch ? Thanks, ~ Prad Thanks, Michael Stahnke (stahnma) ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PATCH: Allow for rhncfg-client get to --exclude files
Coe, Colin C. (Unix Engineer) wrote: Ahem... From: spacewalk-devel-boun...@redhat.com [spacewalk-devel-boun...@redhat.com] On Behalf Of Miroslav Suchý [msu...@redhat.com] Sent: Thursday, 12 February 2009 7:31 PM To: spacewalk-devel@redhat.com; Coe, Colin C. (Unix Engineer) Subject: Re: [Spacewalk-devel] PATCH: Allow for rhncfg-client get to --exclude files Coe, Colin C. (Unix Engineer) wrote: This patch (which I'm submitting on behalf of a college, Ian Chapman) adds an --exclude parameter to 'rhncfg-client get'. This allows you to get all files for this system except that one. Example: rhncfg-client get --exclude /etc/ldap.conf --exclude /etc/openldap/ldap.conf Please credit this to Ian. As always, Thanks Colin/Ian :) I'll add this the list of patches I'm suppose to review and apply this week. Thanks Again. ~ Prad Hmm, did you intend to actually attach the patch to your email? :)) -- Miroslav Suchy RHN Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel NOTICE: This email and any attachments are confidential. They may contain legally privileged information or copyright material. You must not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages and all attachments. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel -- -- Pradeep Kilambi RHN Satellite Engineering pkila...@redhat.com Phone: +1 919 754 4285 RHCE # 805008680430554 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] rhnpush.spec small changes for submission to Fedora
Michael Stahnke wrote: I made a few changes to the rhnpush spec to submit it to Fedora. Mostly it was whitespace and ordering of parameters changing to be more 'fedora-like' for the RPMs. Other changes were a few words here and there to have make a little more sense to the reader. I also am submitting the bug for review in Fedora. Bug # 485007 stahnma I'll review your patch and apply asap if all is well. Thanks, ~ Prad ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] rhn-client-tools with python2.5
Lukas Durfina wrote: Hi, I am trying run rhnreg_ks with python2.5. I have this problem: [Fri Feb 6 10:08:57 2009] up2date Traceback (most recent call last): File /usr/sbin/rhnreg_ks, line 266, in module File /usr/sbin/rhnreg_ks, line 90, in main rhnreg.getCaps() File rhnreg.py, line 329, in getCaps File rhnserver.py, line 50, in __call__ File rpcServer.py, line 194, in doCall File /usr/lib/python2.5/xmlrpclib.py, line 1147, in __call__ return self.__send(self.__name, args) File rpcServer.py, line 38, in _request1 File /var/lib/python-support/python2.5/rhn/rpclib.py, line 319, in _request request, verbose=self._verbose) File /var/lib/python-support/python2.5/rhn/transports.py, line 187, in reque st return self._process_response(fd, connection) File /var/lib/python-support/python2.5/rhn/transports.py, line 215, in _proc ess_response return self.parse_response(fd) File /var/lib/python-support/python2.5/rhn/transports.py, line 225, in parse _response p, u = self.getparser() File /usr/lib/python2.5/xmlrpclib.py, line 1210, in getparser return getparser(use_datetime=self._use_datetime) type 'exceptions.AttributeError': Transport instance has no attribute '_use_da tetime' Should I stay with python2.4 and dont spend time useless or is there any chance to fix it with adequate effort? I should note, that if I changed xmlrpclib.py and used version from 2.4 it worked ok. Please use the latest rhnlib version. It should already ahve a fix for this. ~ Prad Thanks, Lukas ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel -- -- Pradeep Kilambi RHN Satellite Engineering pkila...@redhat.com Phone: +1 919 754 4285 RHCE # 805008680430554 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Anyone Have PostgreSQL + python-pgsql experience?
Devan Goodwin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Looking for anyone who has experience with these particularly in the realm of calling procedures, would love to bounce a few questions off you. It's looking like the Python DBAPI (http://www.python.org/dev/peps/pep-0249/) method of calling stored procedures (Cursor.callproc()) is not implemented for PostgreSQL. It looks like this is because PostgreSQL does procedures quite differently. All the examples I've seen so far of using stored procedures has them embedded within regular queries like: spacewalk=# select return_int(5) as qty; qty - - 5 (1 row) If I'm on the right track it might be possible to hack something up in our rhnSQL code where if you tried to call a procedure, the same way as we do for Oracle, it would translate it into a SELECT blah(arg1, arg2) as blah statement behind the scenes but will see how it goes. Otherwise we've got a problem with the backend code where we'll need to fork calls to procedures, though fortunately there aren't a huge number. Have to make sure I'm on the right track first. Yep, this probably would be the appropriate solution without breaking the oracle compatibility. We should be able to add some overriding methods that could translate the sql statements to be be pgsql centric. I agree that Its gonna be a pain if we fork each call. I vote for a more generic approach as you outlined above. - Prad Thanks, Devan - -- Devan Goodwin dgood...@redhat.com Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmAgf0ACgkQAyHWaPV9my7HNgCfeMz0Cm672BodMLc3S9+b5r5A gLsAoOpv8xDf0PWbV8XPzZrfEch5iJjn =4ZG7 -END PGP SIGNATURE- ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel -- -- Pradeep Kilambi RHN Satellite Engineering pkila...@redhat.com Phone: +1 919 754 4285 RHCE # 805008680430554 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Satellite sync error in 0.4
John hit a similar issue recently. But it was happening only on x86_64 version and i386 iso was working fine. We suspected his setup. But now since we have another reproducer, can you open a bug on this and assign it to me. I'll take a peek at it sometime this week. Thanks, ~ Prad Mike McCune wrote: Got this below when attempting a: satellite-sync -c rhel-i386-server-5 -m /export/ thoughts? Original Message Subject: RHN Management Satellite sync. report from test02-vmx Date: Tue, 13 Jan 2009 23:16:17 -0500 From: rhn-satell...@redhat.com To: mmcc...@redhat.com 23:16:16 SYNC ERROR: unhandled exception occurred: Exception reported from test02-vmx Time: Tue Jan 13 23:16:16 2009 Exception type exceptions.IOError Exception Handler Information Traceback (most recent call last): File /usr/bin/satellite-sync, line 142, in main return satsync.Runner().main() File /usr/share/rhn/satellite_tools/satsync.py, line 206, in main ret = method() File /usr/share/rhn/satellite_tools/satsync.py, line 293, in _step_short return self.syncer.processShortPackages() File /usr/share/rhn/satellite_tools/satsync.py, line 825, in processShortPackages self._diff_packages() File /usr/share/rhn/satellite_tools/satsync.py, line 861, in _diff_packages package = package_collection.get_package(pid, p_timestamp) File /usr/share/rhn/satellite_tools/sync_handlers.py, line 245, in get_package return self._cache.cache_get(package_id, timestamp=timestamp) File /usr/share/rhn/satellite_tools/syncCache.py, line 41, in cache_get compressed=self._compressed) File /usr/share/rhn/common/rhnCache.py, line 71, in get return cache.get(name, modified) File /usr/share/rhn/common/rhnCache.py, line 363, in get return self.cache.get(name, modified) File /usr/share/rhn/common/rhnCache.py, line 334, in get pickled = self.cache.get(name, modified) File /usr/share/rhn/common/rhnCache.py, line 232, in get fd.close() File /usr/share/rhn/common/rhnCache.py, line 175, in close _unlock(self.fd.fileno()) File /usr/share/rhn/common/rhnCache.py, line 59, in _unlock fcntl.fcntl(fd, rhn_fcntl.F_SETLKW, UNLOCK) IOError: [Errno 22] Invalid argument ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] #!/usr/bin/env python to #!/usr/bin/python
Devan Goodwin wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 14 Jan 2009 12:13:20 +0100
Jan Pazdziora jpazdzi...@redhat.com wrote:
On Wed, Jan 14, 2009 at 10:36:37AM +0100, Jan Pazdziora wrote:
I propose to phase out
#!/usr/bin/env python
in favour of
#!/usr/bin/python
in our python scripts.
Speak now or forever hold your peace.
Note that we already use the second form 182 times in non-test
scripts, while we use env 63 times.
The current problem that I'm solving is that osa-dispatcher, when
started via /usr/bin/env, will search directories for python, which
generates SELinux AVC denials like
type=AVC msg=audit(1231924839.798:5971): avc: denied { search }
for pid=15336 comm=python name=root dev=dm-0 ino=784129
scontext=root:system_r:osa_dispatcher_t:s0
tcontext=root:object_r:user_home_dir_t:s0 tclass=dir
Actually, this AVC denial is about different problem. So it was not
a good example.
But nevertheless: shouldn't we decide for env or direct path in the
shebang line and be consistent about it?
+1. I'd go the other direction though and stick with /usr/bin/env
python, iirc that's considered best practice to accommodate people
with Python installed in a weird location or using multiple versions.
Devan
Agree with Devan on this. /usr/bin/env python is more farsighted for
users who have weird install locations. Else they i'll have to link
/usr/bin/python each time they have new version. /usr/bin/env is more
adaptable. I suggest changing the rest to this.
~ Prad
- --
Devan Goodwin dgood...@redhat.com
Software Engineer Spacewalk / RHN
Satellite Halifax, Canada
650.567.9039x79267 Coming back to Java after a few months off is like
a slap in the face.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAklt4UYACgkQAyHWaPV9my4/qACbBZ1YE/c9Vl0Xt4lxTR293Oth
cJgAnR3duyp7zEM02m64byk9vEfB6Uiq
=8N1T
-END PGP SIGNATURE-
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Patches: rhncfg-*
Thanks for the patches Colin!! I'll review these asap and do the needful. ~ Prad Coe, Colin C. (Unix Engineer) wrote: Hi all Attached are two patches. The first fixes an issue where the sticky, suid and/or guid bits are ignored when uploading files using rhncfg-manager. The second provides an 'ls' like output of managed files. Called by 'rhncfg-client elist'. (I'm submitting this on behalf of a colleague, Ian Chapman.) Thanks CC NOTICE: This email and any attachments are confidential. They may contain legally privileged information or copyright material. You must not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages and all attachments. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk 0.4 update
Mike McCune wrote: Jesus M. Rodriguez wrote: Hey Spacewalk hackers, I'd like to wrap up feature and bug fixing by 12/5 so that we can start the package building process on Monday 12/8 for a release on 12/15. Let me know if this will be a problem. Feature freeze: 12/5 Packages: 12/9 QA freeze: 12/12 Release: 12/15 I'm thinking since the scope of features in 0.4 is much much larger than the previous releases we are going to need to spend more time in testing (multiorg and cobbler-koan come to mind) I'd advocate we instead release a QA build to the public on 12/15 and do the final release on say ... 12/22? Or after the break? I realize I'm calling for us to be late but it seems rational to me. Anyone else agree/disagree? Also don't forget that we have a feature called multiarch enhancements for 0.4 which needs extensive testing as its a revamp of existing functionality to use arch info in a bunch of areas. This IMHO is highly regression prone and needs rigorous testing as well. Also we have stored profile devel work still in progress for 0.4 so I think 12/15 would be pretty tight to get this feature wrapped up and tested enough within the next two weeks into 0.4. Thanks, ~ Prad ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] rhnSQL errors in master
Devan Goodwin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 14 Nov 2008 19:21:29 -0500 Pradeep Kilambi [EMAIL PROTECTED] wrote: Mike McCune wrote: Mike McCune wrote: Mike McCune wrote: When trying to register: Exception Handler Information Traceback (most recent call last): File /usr/share/rhn/server/apacheServer.py, line 58, in __call__ ret = f(req) File /usr/share/rhn/server/apacheHandler.py, line 72, in headerParserHandler rhnSQL.initDB() File /usr/share/rhn/server/rhnSQL/__init__.py, line 97, in initDB __init__DB(backend, host, port, username, password, database) File /usr/share/rhn/server/rhnSQL/__init__.py, line 57, in __init__DB if db == __DB.dsn: # this connection has been already made NameError: global name 'db' is not defined I changed the code to use the new incoming param database: --- a/backend/server/rhnSQL/__init__.py +++ b/backend/server/rhnSQL/__init__.py @@ -54,7 +54,7 @@ def __init__DB(backend, host, port, username, password, database): else: del my_db -if db == __DB.dsn: # this connection has been already made +if database == __DB.dsn: # this connection has been already made __DB.check_connection() return __DB.commit() Oops, sorry! Just looking over my tests to figure out why this error never surfaced for me, looks like i had no tests that called rhnSQL.initDB() *multiple* times and thus the except NameError name error above always triggered and never made it to this problem. Going to add one with multiple initializations. This exposes another problem, the if database == __DB.dsn line is bad I think, database will be something like xe, dsn will be something like spacewalk/[EMAIL PROTECTED]. I'll get this addressed. but then get more errors later on: Exception Handler Information Traceback (most recent call last): File /usr/share/rhn/server/apacheRequest.py, line 120, in call_function response = apply(func, params) File /usr/share/rhn/server/handlers/xmlrpc/registration.py, line 526, in new_system architecture, data) File /usr/share/rhn/server/handlers/xmlrpc/registration.py, line 373, in create_system newserv.save(0, channel) File /usr/share/rhn/server/rhnServer/server_class.py, line 576, in save rhnSQL.transaction(save_server) File /usr/share/rhn/server/rhnSQL/__init__.py, line 181, in transaction return db.transaction(name) File /usr/share/rhn/server/rhnSQL/driver_cx_Oracle.py, line 434, in transaction return self.execute(savepoint %s % name) AttributeError: Database instance has no attribute 'execute' Looks like it was because you removed: diff --git a/backend/server/rhnSQL/driver_cx_Oracle.py b/backend/server/rhnSQL/driver_cx_Oracle.py index 2a38113..fd59cb9 100644 --- a/backend/server/rhnSQL/driver_cx_Oracle.py +++ b/backend/server/rhnSQL/driver_cx_Oracle.py @@ -490,12 +490,6 @@ class Database(sql_base.Database): # Pass the cursor in so we can close it after execute() return self._procedure_class(name, c) -# why would anybody need this?! -def execute(self, sql, *args, **kwargs): -cursor = self.prepare(sql) -apply(cursor.execute, args, kwargs) -return cursor - I added it back in and it worked. Mike FYI, I haven't committed/pushed this. Just say the word and I will! Ugh, sorry about this one as well. I thought that was unused. It's just a shortcut around getting a cursor and calling execute on that, I must have grepped bad. (or possibly recklessly) Push away! (although if you get a conflict I've fixed it and pushed as well in attempting to resolve that earlier issue) :) yea I think we need that for stuff for sql queries to work. Anyhu I think these were changes from postgres pre clean up work dgoodwin was working on. So I'll let him say the word. But jus wanna say, we should not be committing this into master yet. Probably working in a branch until its stable would be easier so we can avoid these regressions. This work was done in a branch originally and brought back when I *thought* it was stable and as soon as 0.3 was released. My apologies if it's causing major problems. I was nervous to leave it in a long term branch due to massive refactors that were going to cause big conflict troubles if the code got touched in master. Considering all the postgresql stuff just sits by the wayside I figured it would be best to merge sooner rather than later and expose anything I missed. (as that bullet has to be bitten at some point regardless, post-0.3 seemed like as good a time as any) This make sense? Let me know if others disagree and I can prevent this in the future. I think the real mistake here is I should have rebuilt my own test rpms and plugged them into a live spacewalk server before merging in. I've just been testing with scripts that talk straight to rhnSQL, which in hindsight
Re: [Spacewalk-devel] rhnSQL errors in master
Mike McCune wrote: Mike McCune wrote: Mike McCune wrote: When trying to register: Exception Handler Information Traceback (most recent call last): File /usr/share/rhn/server/apacheServer.py, line 58, in __call__ ret = f(req) File /usr/share/rhn/server/apacheHandler.py, line 72, in headerParserHandler rhnSQL.initDB() File /usr/share/rhn/server/rhnSQL/__init__.py, line 97, in initDB __init__DB(backend, host, port, username, password, database) File /usr/share/rhn/server/rhnSQL/__init__.py, line 57, in __init__DB if db == __DB.dsn: # this connection has been already made NameError: global name 'db' is not defined I changed the code to use the new incoming param database: --- a/backend/server/rhnSQL/__init__.py +++ b/backend/server/rhnSQL/__init__.py @@ -54,7 +54,7 @@ def __init__DB(backend, host, port, username, password, database): else: del my_db -if db == __DB.dsn: # this connection has been already made +if database == __DB.dsn: # this connection has been already made __DB.check_connection() return __DB.commit() but then get more errors later on: Exception Handler Information Traceback (most recent call last): File /usr/share/rhn/server/apacheRequest.py, line 120, in call_function response = apply(func, params) File /usr/share/rhn/server/handlers/xmlrpc/registration.py, line 526, in new_system architecture, data) File /usr/share/rhn/server/handlers/xmlrpc/registration.py, line 373, in create_system newserv.save(0, channel) File /usr/share/rhn/server/rhnServer/server_class.py, line 576, in save rhnSQL.transaction(save_server) File /usr/share/rhn/server/rhnSQL/__init__.py, line 181, in transaction return db.transaction(name) File /usr/share/rhn/server/rhnSQL/driver_cx_Oracle.py, line 434, in transaction return self.execute(savepoint %s % name) AttributeError: Database instance has no attribute 'execute' Looks like it was because you removed: diff --git a/backend/server/rhnSQL/driver_cx_Oracle.py b/backend/server/rhnSQL/driver_cx_Oracle.py index 2a38113..fd59cb9 100644 --- a/backend/server/rhnSQL/driver_cx_Oracle.py +++ b/backend/server/rhnSQL/driver_cx_Oracle.py @@ -490,12 +490,6 @@ class Database(sql_base.Database): # Pass the cursor in so we can close it after execute() return self._procedure_class(name, c) -# why would anybody need this?! -def execute(self, sql, *args, **kwargs): -cursor = self.prepare(sql) -apply(cursor.execute, args, kwargs) -return cursor - I added it back in and it worked. Mike FYI, I haven't committed/pushed this. Just say the word and I will! yea I think we need that for stuff for sql queries to work. Anyhu I think these were changes from postgres pre clean up work dgoodwin was working on. So I'll let him say the word. But jus wanna say, we should not be committing this into master yet. Probably working in a branch until its stable would be easier so we can avoid these regressions. Thanks, ~ Prad ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel -- -- Pradeep Kilambi RHN Satellite Engineering [EMAIL PROTECTED] Phone: +1 919 754 4285 RHCE # 805008680430554 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Patch: jabberpy spec cleanup for Fedora packaging guidelines
Looks good. jabberpy build and install working as expected. Patch applied! I'll make sure this gets into our spacewalk fedora repo. Thanks Again, ~ Prad Pradeep Kilambi wrote: I'm reviewing this now. Will apply your patch if everything looks ok. Thanks for your contribution. ~ Prad Michael Stahnke wrote: I don't know exactly how all the client-side tools will be handled for inclusion in Fedora, but I decided to take a stab at one. I cleaned up jabberpy.spec and it now complies with Fedora guidelines. I think it will still fine within the git tree as well. I tested briefly on EL3, 4 and 5 (Centos/RHEL), and everything appears to work fine. The spec is quite a bit different, but now should look more Fedora-y. Let me know if there are questions/concerns about the patch. Also, if you want community members to start submitting these RPMs for review in Fedora, I am happy to help. stahnma ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel -- -- Pradeep Kilambi RHN Satellite Engineering [EMAIL PROTECTED] Phone: +1 919 754 4285 RHCE # 805008680430554 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
