Re: [Spacewalk-devel] Audit Logging
On Thu, Aug 25, 2011 at 02:30:51PM +0200, Johannes Renner wrote: Well, the general 'problem' is that Spacewalk consists of a lot of different components and this audit log should gather log events coming from these sources (web ui, frontend api, backend api, taskomatic), while sending them as one 'trail' to a destination that might be whatever (syslog, database, etc.). Therefore we decided to use yet again xmlrpc for the interface, because there is at least an easy-to-use client implementation available for every scripting language that is used within Spacewalk. I'd much rather see a patch which would make the set of used technologies / stacks smaller, for example a patch which would finish the Perl-to-Java migration of the outstanding .pxt Web pages. Also, the completness and accuracy of the trail depends on thousands of new calls to be added throughout the code base. Do we really need that when we already have a place where all actions/changes end (the database) and we could do the auditing/logging from there? While the implementation of the daemon is a totally different story, I want to show you how the code might look like for the Java/Web UI part. I attached some initial patches I have written and would really like to get review and feedback on this. So (1.) there are some helper classes that I put into a new separate package, see 01-new-classes.patch: - AuditLog is a Singleton that serves as the entry point for calls to I don't like the fact that the essential information of true/false is massaged into a string -- shouldn't that be a first-class citizen fields there? The same for the user name -- what if I got and create user named 'none'? Do you really want the message to be localized? That would mean that they can change in time easily. Shouldn't the audit messages be as solid/stable as possible for automatic processing, and only be localized upon presentation? the log. The interface of the log daemon conists of only one method that is called log(). - This method is called via xmlrpc from within the AuditLogAppender. So this AuditLog is server (the daemon) side, or the client (the tomcat or taskomatic) side? - AuditLogMessage is just a wrapper object representing a log event. Don't you need to have toString there? What constructor of AuditLogMessage does the AuditLogAppender use? - LogUtil is just a class containing helper methods. The most interesting part is probably the createExtMap() method that takes an HTTPServletRequest and extracts its parameters into a HashMap while ignoring some of them using a blacklist. This map is also passed on to the logger. The LogUtil.get*String stringifies the parameters without quoting them, making it virtually impossible to process in an automatic manner later. Shouldn't the values stay as map as long as possible, so that for example the database backend can then easily and safely detect values of those parameter and store them in table columns specific for the given type, ideally with foreign keys? For the actual logging of web UI actions, I investigated into generic approaches first (using a ServletFilter, do it in RhnRequestProcessor), but I found out the result of all these approaches is not really what we want. Interesting events are not really correlating to general HTTP POST requests, unfortunately :-/ Can you be more specific about this? I further added (3.) generic audit logging of API calls, please see my attached 04-xmlrpc-api.patch: - This patch also fixes missing IP adresses in already existent logs (I can also provide this as a single patch, if I find the time..). That would be the right thing to do, obviously. - 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). By all means, refactor code which needs to be refactored and submit as patch against master, instead of supporting actions coded not in the latest-greatest technology style. - Also, because sometimes an action contains the implementation of actually different things, one log message per action class will not be enough. In addition to that sometimes singular as well as pluralized messages would be needed. As mentioned above, I believe localization has no business in this side of the code. You have languages that distinguish more than just singular and plural. - Sometimes when a form is submitted it is actually hard to find out if _really_ something has changed, Why is that possible? Isn't this confirming my idea that this all should be done on the database level where you'd know for sure if something has been modified or not (because if not, the trigger would not fire)? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing
Re: [Spacewalk-devel] Audit Logging
On Fri, Aug 26, 2011 at 04:10:03PM -0400, Cliff Perry wrote: Do you do it within the schema (and loose the who from where did what - unless all app code passes it down to DB). No. You do it once, at the start of the HTTP request handling, store that to the database and use identifier throughout your HTTP request processing. You have the identifier in (say) package variables in Oracle and in temporary table or environment variable in PostgreSQL, and you don't have to change a bit of application code. And if new application Y which does the same thing like X, except it does some filtering here and there and also touches objects Z gets created, you don't have to aprinkle new auditing calls into it -- you just log on the data level. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Audit Logging
On Tue, Aug 30, 2011 at 05:29:48PM +0200, Miroslav Suchý wrote: 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? I would not. Is that part of the requirement? So far in the proposal/patches I've only seen actions that modify something being logged. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Monitoring related fixes
On Thu, Aug 04, 2011 at 05:18:54PM +0100, David Nutter wrote: Hi, Here are a few monitoring-related patches, developed while I was chasing the real monitoring problem. These won't fix monitoring in 1.5 by themselves, see spacewalk-list postings for why. Anyway: 0001-Add-additional-member-name-mappings-in-ProbeRecord-t.patch This fixes the errors seen when using rhn-runprobe to run a probe manually (Can't locate object method hostname via package NOCpulse::Probe::Config::ProbeRecord) It also ensures than rhn-catalog outputs the hostname and host address when listing probes. 0003-Properly-dereference-the-array-references-for-old-an.patch This fixes junk output (Rescanned directory: ARRAY(0x10be1600) current, ARRAY(0x10bbe090) old) in /var/log/nocpulse/TSDBLocalQueue/TSDBLocalQueue.log 0002-Since-autocommit-is-off-in-RHN-DB-add-explicit-commi.patch The NOCPulse-ini script shipped with spacewalk 1.5 does not actually change the config due to a lack of a dbh-commit call. This patch adds such calls. Thank you, applied to Spacewalk master. New packages will land in Spacewalk nightly repos in an hour or so. diff --git a/monitoring/PerlModules/NP/Probe/Config/ProbeRecord.pm b/monitoring/PerlModules/NP/Probe/Config/ProbeRecord.pm index 35a322e..ee764f4 100644 --- a/monitoring/PerlModules/NP/Probe/Config/ProbeRecord.pm +++ b/monitoring/PerlModules/NP/Probe/Config/ProbeRecord.pm @@ -54,6 +54,8 @@ my %FIELD_MAP = contactGroupCustomers = 'contact_group_customers', contactGroupNames = 'contact_group_names', hostAddress = 'host_ip', + HOSTADDRESS = 'host_ip', + HOSTNAME = 'host_name', hostName = 'host_name', Here, I just previously removed the hostAddress and hostName altogether, as the FetchHashKeyName makes them into uppercase anyway. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Patch for re-activation error Spacewalk
On Mon, Aug 08, 2011 at 01:13:48PM -0700, Robert Hernandez wrote:
Michael I apologize its actually the following, I mixed around the files:
--- a/usr/lib/perl5/vendor_perl/5.8.8/RHN/DB/Token.pm 2011-08-05
11:58:59.0 -0700
+++ b/usr/lib/perl5/vendor_perl/5.8.8/RHN/DB/Token.pm2011-08-05
12:18:52.0 -0700
@@ -426,7 +426,7 @@
my $dbh = $trans || RHN::DB-connect;
if ($self-id == -1) {
-my $sth = $dbh-prepare(SELECT rhn_reg_token_seq.nextval FROM DUAL);
+my $sth = $dbh-prepare(SELECT sequence_nextval('rhn_reg_token_seq'));
$sth-execute;
my ($id) = $sth-fetchrow;
die No new token id from seq rhn_reg_token_seq (possible error:
. $sth-errstr . ) unless $id;
Michael has already applied it:
http://git.fedorahosted.org/git/?p=spacewalk.git;a=commitdiff;h=2cec4e439e2f64a75b5564656c3761d0a85357ce
Please make sure you keep the from dual clause there, otherwise
you'd be breaking Oracle.
--
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] - RHBZ#508936 - Run remote command works even when run is disabled on the client
On Thu, Jul 21, 2011 at 05:35:14PM -0300, Marcelo Moreira de Mello wrote: On Thu, 2011-07-21 at 13:21 +0200, Jan Pazdziora wrote: On Tue, Jul 19, 2011 at 02:38:24PM -0300, Marcelo Moreira de Mello wrote: Not sure what would be verifying the Satellite/Spacewalk version. If rhncfg*, then, well, it should just gracefuly rename all to run, in runtime (as opposed to the postinstall time I originally proposed). Hello, Following advice from Jan, here is a new patch which honor the script/run file for remote commands. If a script/all file were found, the options --report, --disable-all, --disable-run, --enable-run will take care and rename the file script/all to script/run which is expected and consistent with the documentation. Also, if the file script/all were found when executing a remote command, the patch will check the file and rename the script/all to script/run at runtime, then customers can use old Satellite/Spacewalk versions and newer rhncfg* package. Applied to Spacewalk master, d8740eee2c2a60ac385ea2e1d2c26a3c063d14b6. Thank you, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Kickstart Session Status
On Wed, Jun 22, 2011 at 02:57:56PM +0200, Uwe Gansert wrote: I started a kickstart installation of a fedora system and I can see the RPM installation progress on the provisioning status page. So every 15 seconds that page refreshes, I can see the latest installed RPM and the complete number of yet installed RPMs. But when all packages are installed, no further progress is shown. I never see the System rebooted or any other status go green. Only Initiate Kickstart. is green Next Action is set to None Description: The initial files required for anaconda have been downloaded. I saw that the RPM installation is tracked via ks/dist/session/ URLs but can someone please explain me in a few words how the Spacewalk Server notices states like rebooted (RESTARTED it's called in the code if I see it right) It's reboot.reboot in backend/server/action_extra_data/reboot.py. or how does the Spacewalk Server knows that the provisioning is COMPLETE? The schedule_config_deploy in backend/server/rhnServer/server_kickstart.py. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] quartz and slf4j
On Tue, Jul 26, 2011 at 06:34:28PM +0200, Tomas Lestach wrote: I noticed quartz depends on spacewalk-slf4j. Why is there a custom version of slf4j (spacewalk-slf4j)? It's because slf4j isn't distributed in RHEL. And I believe we did not want to rebuild the whole slf4j because it requires maven or something and dependencies got ugly. So spacewalk-slf4j is just a minimal subset needed. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] - fixed typo at Query bindParameters() on java/code/src/com/redhat/rhn/common/hibernate/HibernateFactory.java
On Mon, Jul 25, 2011 at 05:14:23PM -0300, Marcelo Moreira de Mello wrote:
Hello,
Follow attached a patch which fixes a typo (s/exectued/executed/g) at
HibernateFactory.java.
[...]
On Mon, Jul 25, 2011 at 05:33:07PM -0300, Marcelo Moreira de Mello wrote:
Please,
Note that probably there is more one typo:
if (c.size() 100) {
- LOG.error(Query exectued with Collection larger than 1000);
+ LOG.error(Query executed with Collection larger than 1000);
}
Applied, thank you!
--
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] VARCHAR2 BYTEs and CHARs
On Wed, Jul 20, 2011 at 04:39:14PM +0200, Ionuț Arțăriși wrote: Hello, We've recently come upon a bug when trying to insert a string of 1024 unicode characters into a database column of VARCHAR2(1024 BYTE). Rather than dealing with string encoding transformations everywhere this issue pops up in the code, I thought that modifying the database schema would be the better solution. BYTE seems to be the default for the Oracle database, but unicode strings would map better to VARCHAR2(1024 CHAR). The problem is that I couldn't find any way to set this in the table schema files and get it past chameleon. chameleon just doesn't have the right grammar defined to parse VARCHAR2(1024 CHAR) or alter session set nls_length_semantics=char. So I was wondering if you guys know more about this problem or a better solution than patching chameleon. Replacing chameleon with a custom script (sed? perl?) which would do the equivalent transformation but be easier to be extended would be my preferred option. I'll be happy to review a patch which would do that. Adding a char to varchar2 definitions would then be step to, and piece of cake. Is there a specific reason for not using VARCHAR2( CHAR)? Not really, just historical thing. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] - RHBZ#508936 - Run remote command works even when run is disabled on the client
On Tue, Jul 19, 2011 at 02:38:24PM -0300, Marcelo Moreira de Mello wrote: Yes. Makes sense! What do you think if we verify the Satellite/Spacewalk version and then apply /script/run or /script/all. What do you think? Not sure what would be verifying the Satellite/Spacewalk version. If rhncfg*, then, well, it should just gracefuly rename all to run, in runtime (as opposed to the postinstall time I originally proposed). -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Has signed Metadata
On Tue, May 24, 2011 at 12:24:53PM +0200, Michael Calmer wrote: I re-worked the patches now. spacewalk-repo-sync uses now a fix directory with a GPG keyring to store trusted keys. Michael, I'm not quite happy about two things: - The interactiveness of the approach. Neither satellite-sync nor spacewalk-repo-sync were interactive in the past and I'm worried that making it interactive now could break expectations for people who run these from quartz or from cron jobs, when the scripts start to do some interactive manipulations. Also, this approach kinda assumes that you are a root on the Spacewalk server to hit that y to allow the key to be imported. But with spacewalk-repo-sync and the sync (and scheduled syncs), we finally were able to separate the root on the Spacewalk server from the content admin -- you can now define channel and repository *and schedule sync of the content* from the WebUI, without even knowing the root password. I wouldn't like us to lose this. - I don't quite understand why you use filesystem to store the pubring, why not put the keys to the database. That would make it much easier to manage them, for example to ack import of the key from the WebUI. When the distribution is being created, we could fetch the repomd.xml and the key right on the spot and let the user approve it right there, before the first sync. The biggest problem with your approach is the fact that repositories and channels are per-organization but the gpgdir in your patch is global. So again, it gets us back to the you have to be root to manage things approach. We already have a GPG and SSL Keys application which stores the keys in the rhnCryptoKey table, that even has the org_id column. Can't you just use this table to store the keys, instead of the gpgdir? Also, is it correct that there is a boolean in the rhnContentSource, instead of have a relation table which would list allowed and expected keys (in rhnCryptoKey) for each rhnContentSource? Essentially have per-rhnContentSource keyring. With the current boolean approach, I might have a key for some external repository that I don't trust much, mixed with key for my primary, most important content. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] - RHBZ#508936 - Run remote command works even when run is disabled on the client
On Fri, Jul 15, 2011 at 03:43:34PM -0300, Marcelo Moreira de Mello wrote: But for those systems already installed and when updating the rhncfg* packages, the %post scriptlet will works and make it compatible with script/run. That's why we test if the script/all exits and then move the file. Right. But, if the Remote commands were enabled at KS, the file /script/run will be created at KS normally. Not if you kickstart using say Satellite 5.4 or Spacewalk 1.4 that create /script/all. The compatibility of the new (fixed) rhncfg* code (being installed) with the old server (that generates the kickstart file) is the issue. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Bring out your patches
Hello, I plan to branch Spacewalk 1.5 later this week. Please send in any patches that you wish to see in Spacewalk 1.5 so that we can review and commit them before the branching event. Thank you, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] - RHBZ#508936 - Run remote command works even when run is disabled on the client
On Fri, Jul 15, 2011 at 11:16:11AM -0300, Marcelo Moreira de Mello wrote: * Will the new code work with kickstarts from current spacewalk which contain 'touch .../script/all'? I mean if new rhncfg-* is installed so it looks for .../script/run but no %postinst which renames .../script/all to .../script/run has fired. Yes. If customer upgrade the rhncfg* packages, at the %post section, the file will be automatically renamed to 'run' if ../script/'all' exists. rhncfg.spec 107 %post 108 test -f /etc/sysconfig/rhn/allowed-actions/script/all \ 109 mv /etc/sysconfig/rhn/allowed-actions/script/all /etc/sysconfig/rhn/allowed-actions/script/run To new kickstarts, this the file will be deployed as expected. KickstartFormatter.java 123 touch /etc/sysconfig/rhn/allowed-actions/script/run; Please, let me know if you have further questions. It's the combination of Spacewalk 1.4 (or Satellite 5.3, 5.4) and new rhncfg* being kickstarted. The file is touched in the kickstart file only after the rhncfg* packages were installed. So the %post scriptlet trick does not apply (there is no file there when the package is being installed) and then the script/all gets created and the package never sees it because it was modified to only assume and use script/run. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] - RHBZ#508936 - Run remote command works even when run is disabled on the client
On Wed, Jul 06, 2011 at 02:05:12PM -0300, Marcelo Moreira de Mello wrote: Howdy, Any news regarding this patch? Marcelo, could you explain in deeper detail what in the current (Spacewalk) code makes both 'all' and 'run' to be taken as True for the script.run action? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] - RHBZ#508936 - Run remote command works even when run is disabled on the client
On Thu, Jul 14, 2011 at 02:54:41PM +0200, Jan Pazdziora wrote: On Wed, Jul 06, 2011 at 02:05:12PM -0300, Marcelo Moreira de Mello wrote: Howdy, Any news regarding this patch? Marcelo, could you explain in deeper detail what in the current (Spacewalk) code makes both 'all' and 'run' to be taken as True for the script.run action? The reason I ask is: If both the current and old versions of rhncfg* observe the /etc/sysconfig/rhn/allowed-actions/script/run file correctly, then there would be no problem changing the touch in KickstartFormatter.java to create the run file instead of all. So no new installation would have the all file there. Since the rhn-actions-control only seems to create and remove the run file, we could then use %post script of some of the rhncfg package to move any existing all to run, to make it consistent with the documentation and with new kickstart. Then we would also need to disable any actions based on the /etc/sysconfig/rhn/allowed-actions/script/all file in the rhncfg* packages, and make it only use the run file as its flag. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PATCH BZ#633400 - rhncfg-client lists lower-ranked config channel for file
On Tue, Jul 12, 2011 at 09:09:56PM -0300, Marcelo Moreira de Mello wrote: --- .../handlers/config/rhn_config_management.py |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/backend/server/handlers/config/rhn_config_management.py b/backend/server/handlers/config/rhn_config_management.py index f35b3e4..273cefd 100644 --- a/backend/server/handlers/config/rhn_config_management.py +++ b/backend/server/handlers/config/rhn_config_management.py @@ -144,7 +144,12 @@ class ConfigManagement(configFilesHandler.ConfigFilesHandler): break path = row['path'] -result_hash[path] = (config_channel, path, row['config_file_type_id']) + +if not path in result_hash: +result_hash[path] = (config_channel, path, row['config_file_type_id']) + +if config_channel == str(self.server.getid()): +result_hash[path] = (config_channel, path, row['config_file_type_id']) result = result_hash.values() # Sort by path first since that's what the web site does Committed to Spacewalk master, 46830082e095a9273ef2e5fe6fcd3a91eb14a952. Tagged as spacewalk-backend-1.5.40-1. Thank you, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Remote commands temporary file location
On Mon, Jun 13, 2011 at 09:59:53AM +0200, Matteo Sessa wrote: Is there a chance of having this committed for the upcoming release? I've internally backported the patch to the stable rhncfg-5.9.52. I'm actively using that in production and it's doing quite well. I have committed your patch to Spacewalk master be9c7586090e42f56f06fea67512c625883434b3 and tagged as rhncfg-5.10.7-1 -- thank you! You should see the new packages in Spacewalk nightly repo later today. I'm sorry we missed the patch -- thanks for pinging us about it. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] - RHBZ#508936 - Run remote command works even when run is disabled on the client
On Thu, Jun 02, 2011 at 07:30:23PM -0300, Marcelo Moreira de Mello wrote: Follow attached the patch which fixes the BZ#508936. At RHN Satellite/Spacewalk documentation, to be able to execute remote commands, it must exists a file named run into /etc/sysconfig/rhn/allowed-actions/scripts directory. This patch fixes remote commands only be executed if the file run exists into allowed-actions/scripts directory. All the other files will be ignored. While this patch might make the behaviour consistent with the documentation, it will likely break existing clients. If the client has a file 'all' and remote commands are working fine (and are expected to work), suddenly they will stop working. We really have to think about the upgrade implications. If I understand it correctly, your concern is that even if rhn-actions-control --disable-all is run and passes, it does not disable the option because it removes the other file. Well, for that, one possibility is to always remove both files when disabling. To make it consistent, we also fixed KickstartFormatter.java, which now appends into kickstart the 'run' instead 'all' into /etc/sysconfig/rhn/allowed-actions directory when rendering the kickstart file. Did you verify that even old RHN Tools packages (RHEL 5, RHEL 4) use both run and all file to enable the option? In other words, won't this Spacewalk change break behaviour of existing distributions that people might be kickstarting? After patched, --report option works as expected (ignoring all the other files created manually) and remote commands will be only executed when a file run exists at allowed-action/scripts directory. Nack. I don't see an upgrade path for systems that already have the 'all' file and are happy that things work. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH 1/2] 705935 - add rhnSQL.commit() after process() to flush dangling transaction
On Fri, Jun 03, 2011 at 06:07:01AM +0200, Andreas Rogge wrote: Change to apacheHandler.py to make sure a transaction that might be open at the end of the request handling will be committed (or rolled back) --- backend/server/apacheHandler.py |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/backend/server/apacheHandler.py b/backend/server/apacheHandler.py index 2d3530f..a1b4e04 100644 --- a/backend/server/apacheHandler.py +++ b/backend/server/apacheHandler.py @@ -193,6 +193,8 @@ class apacheHandler(apacheSession): # Avoid leaving Oracle deadlocks try: ret = self._req_processor.process() +if not CFG.SEND_MESSAGE_TO_ALL: +rhnSQL.commit() except: if not CFG.SEND_MESSAGE_TO_ALL: rhnSQL.rollback() Andreas, thanks for the patch. While I agree that we should not leave active transactions behind when we are finished processing the request, I am not sure the commit is the best way to go. Ideally it should be the individual application which would make an informed decision about committing its work. And if it decided not to commit (or it did not commit due to a bug in the code), we should probably just rollback. Would rhnSQL.rollback() instead of rhnSQL.commit() sound reasonable? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH 1/2] 705935 - add rhnSQL.commit() after process() to flush dangling transaction
On Tue, Jun 07, 2011 at 01:29:33PM +0200, Andreas Rogge wrote: I don't think so. I guess the best way to go is: call the handler if all went well, commit Yes but do that within the handler, not in apacheHandler.py, which is the framework around the handlers. If the handler ended and did not commit, we (apacheHandler.py) really have no business committing for that handler. if something failed, rollback That's what the code above does. If anything goes really wrong the handler should throw an exception and the transaction will be rolled back. The right way to fix this would be to trace *all* handlers and see which one leaves dangling transactions behind. Right, that's my goal. By doing rollback, I hope to find the faulty applications (handlers) that don't commit properly, by rolling-back their work and thus turning them into noop. There is probably a reason that transactions are only rolled back when an exception inside the handler occurs. Well, they have to be rolled back because if exception is thrown in the Python stack, something went really wrong in Python, yet the database connection does not know about it. I think addition of a commit right here is the least intrusive way to work around the issue (especially as there already is an oracle-workaround one line below). I'd call it a quick fix which can potentially hurt us in the long run. I have no idea wether there's a way to ask the PostgreSQL/Oracle session wether there is uncommitted work and/or a transaction open. If there is a way to check this, we could just log detailed warning-messages when a handler returns and rhnSQL has an open transaction. I'll try to check this, good point. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] NOW WITH ATTACHMENTS - patch for accidentally grabbing '--help' in shell arguments
On Fri, Jun 03, 2011 at 03:26:37PM -0400, Adam Price wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=710554
I have attached for review a patch to fix this issue.
[...]
diff --git a/spacecmd/src/lib/shell.py b/spacecmd/src/lib/shell.py
index c95655b..df437e8 100644
--- a/spacecmd/src/lib/shell.py
+++ b/spacecmd/src/lib/shell.py
@@ -126,8 +126,10 @@ class SpacewalkShell(Cmd):
args = ''
# print the help message if the user passes '--help'
-if re.search('--help', line):
-return 'help %s' % command
+line_parts = line.split(\)
+for i in range(0, len(line_parts), 2):
+if re.search('--help', line):
+return 'help %s' % command
I don't believe the patch is a proper fix.
The bugzilla does not include the exact reproducer, so let's start
with
$ spacecmd -s 'localhost' -- softwarechannel_create -n 'test123--help'
-l 'test123--help' -a 'x86_64'
The split line.split(\) seems to be bogus -- we already have the
line split to parts via
parts = line.split()
and there are no doublequotes in the data to split on anyway.
Of course, there seems to be a more general problem of parsing the
commands:
$ spacecmd -s 'localhost' -- softwarechannel_create -n 'test123 --help'
-l 'test123--help' -a 'x86_64'
(not the space in the -n option) gets split by the
['softwarechannel_create', '-n', 'test123', '--help', '-l',
'test123--help', '-a', 'x86_64']
-- so even if they were passed in as proper command line arguments
from the shell to spacecmd, they were probably merged into one line
without proper quoting.
Aron, how are things supposed to work there?
--
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Missing python import in HEAD
On Tue, May 31, 2011 at 01:27:06PM +0200, Matteo Sessa wrote:
Hi,
commit 1a95582f4079fb92566daf491bd2c542f00865b6 introduced a regression in
client/tools/rhncfg/actions/configfiles.py
adding sys.path.append('/usr/share/rhn') without prior importing sys package.
Patch attached.
Applied to master, d1ed312c702500d09dca07b1dedfe2d2522c6320.
Thanks!
--
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Replacement for tanukiwrapper
On Tue, May 24, 2011 at 09:39:16AM +0200, Miroslav Suchy wrote: Premature notice: I discovered free fork of tanukiwrapper: https://bitbucket.org/ivertex/java-service-wrapper And I have intention to replace tanukiwrapper with java-service-wrapper as soon as it pass package review: https://bugzilla.redhat.com/show_bug.cgi?id=707132 Do we need it at all? Wouldn't two startup scripts (taskomatic and the search server) plus log4j achieve the same, without a dependency on the external piece of software? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Oracle (+) syntax
On Tue, May 24, 2011 at 12:14:16PM +, Julian Einwag - rockenstein AG wrote: I just came across the query visible_to_system in SystemGroup_queries.xml: SELECT MAX(DECODE(VSGM.server_id, :sid, 1, 0)) is_system_member, VSGM.GROUP_ID id, VSGM.GROUP_NAME, VSGM.GROUP_TYPE, VSGM.CURRENT_MEMBERS, VSGM.MAX_MEMBERS, DECODE(USGP.server_group_id,VSGM.group_id,1,0) AS USER_PERMITTED_ACCESS FROM rhnVisServerGroupMembership VSGM, rhnUserServerGroupPerms USGP WHERE VSGM.ORG_ID = :org_id AND :user_id = USGP.user_id (+) AND VSGM.group_id = USGP.server_group_id (+) GROUP BY VSGM.group_id, VSGM.group_name, VSGM.group_type, VSGM.current_members, VSGM.max_members, USGP.server_group_id ORDER BY UPPER(VSGM.group_name), VSGM.group_id While I do understand that (+) is the old fashioned Oracle syntax for outer joins, I'm having trouble understanding what the (+) does in the condition ':user_id = USGP.user_id (+)', since it's not join-related. I did some quick tests on an Oracle installation but I couldn't make sense of it. Any help would be appreciated. Think of it as if you had ( select :user_id from dual ) and an outer join of this subselect with that USGP. The AND :user_id = USGP.user_id (+) matches where the USGP.user_id is the same as :user_id, or where the USGP's columns have NULL value due to the records not being present at all. You can try select web_customer.id, web_contact.id from web_customer, web_contact where web_customer.id = web_contact.id (+) and 1 = web_contact.id (+) to see something similar -- on my system it returns ID ID -- -- 1 1 2 3 4 5 25 26 46 66 -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] erratas and the client plugin package action
On Wed, May 18, 2011 at 02:38:54PM +0200, Ionuț Arțăriși wrote: On 05/18/2011 01:14 PM, Jan Pazdziora wrote: ... Nack. This is SQL-injection-prone. You have to use bind parameters or sanitize the input properly. Thanks, I have fixed the SQL issue. It's still somewhat missing in your patch. +# transform the list of ints to an sql list that we can forcibly +# insert into the sql statement +sql_list = ', '.join([str(i) for i in errata_ids]) + +sql = SELECT id, advisory_name FROM RhnErrata + WHERE id IN (%s) +h = rhnSQL.prepare(sql % sql_list) -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] erratas and the client plugin package action
On Fri, May 13, 2011 at 02:27:42PM +0200, Miroslav Suchý wrote: On 05/13/2011 02:22 PM, Duncan Mac-Vicar P. wrote: Would it make more sense for errata.py to be in the yum-rhn-plugin? It fine with me. yum-rhn-plugin and rhn-client-tools require each other (on rhel/fedora) anyway. Is that really true? # rpm -q rhn-client-tools rhn-client-tools-1.0.0-60.el6.noarch # rpm -q --requires rhn-client-tools | grep yum-rhn-plugin | wc -l 0 -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [Spacewalk-list] file NEVRAO mismatches
On Tue, Apr 26, 2011 at 04:40:48PM +0700, bearwere wrote: File path mismatch: /var/satellite/redhat/1/0ef/xalan-j2-javadoc/2.7.0-6jpp.1/i386/0ef89afa8c0dda990655983243a8eaf6/xalan-j2-javadoc-2.7.0-6jpp.1.i386.rpm (evr: 0:2.7.0-6jpp.1 vs. 2.7.0-6jpp.1) File path mismatch: /var/satellite/redhat/1/549/axis/1.2.1-2jpp.6/i386/5498cf48b2b87ef10b23359dd17a1959/axis-1.2.1-2jpp.6.i386.rpm (evr: 0:1.2.1-2jpp.6 vs. 1.2.1-2jpp.6) File path mismatch: /var/satellite/redhat/1/2a7/jakarta-commons-lang-javadoc/2.1-5jpp.1/i386/2a7a1e09296290a143be8dc1e1a48e51/jakarta-commons-lang-javadoc-2.1-5jpp.1.i386.rpm (evr: 0:2.1-5jpp.1 vs. 2.1-5jpp.1) File path mismatch: /var/satellite/redhat/1/e28/wpa_supplicant/0.5.10-9.el5/i386/e2839ad90ea8c4a7fc0db6bae8b79a03/wpa_supplicant-0.5.10-9.el5.i386.rpm (evr: 1:0.5.10-9.el5 vs. 0.5.10-9.el5) File path mismatch: /var/satellite/redhat/1/a4a/bsf/2.3.0-11jpp.1/i386/a4ad7f3438ad450c0b77744b9ef7fe21/bsf-2.3.0-11jpp.1.i386.rpm (evr: 0:2.3.0-11jpp.1 vs. 2.3.0-11jpp.1) File path mismatch: /var/satellite/redhat/1/160/arpwatch/2.1a13-22.el5/i386/1608454c01e8be14924c26efd5d8a860/arpwatch-2.1a13-22.el5.i386.rpm (evr: 14:2.1a13-22.el5 vs. 2.1a13-22.el5) File path mismatch: /var/satellite/redhat/1/9e1/kdelibs-apidocs/3.5.4-25.el5.centos.1/i386/9e10d4c1ba5770f61a9a415d302663f7/kdelibs-apidocs-3.5.4-25.el5.centos.1.i386.rpm (evr: 6:3.5.4-25.el5.centos.1 vs. 3.5.4-25.el5.centos.1) Michael, the issue reported by spacewalk-data-fsck is about missing epoch in that path segment. I did some checks and found out that when you rhnpush or spacewalk-repo-sync packages, the epoch is not in the path. When you satellite-sync (a channel dump), the epoch is there. Since spacewalk-data-fsck expects the epoch to be there, it seems like rhnpush and spacewalk-repo-sync are wrong here and would need to be fixed to include the epoch. It seems like diff --git a/backend/server/rhnPackageUpload.py b/backend/server/rhnPackageUpload.py index c099b1d..fb93e89 100644 --- a/backend/server/rhnPackageUpload.py +++ b/backend/server/rhnPackageUpload.py @@ -115,7 +115,7 @@ def relative_path_from_nevra(nevra, org_id, package_type=None, checksum_type=Non is_source = 0 log_debug(4, nevra, is_source) return get_package_path(nevra, org_id=org_id, source=is_source, -prepend=CFG.PREPENDED_DIR, omit_epoch=1, package_type=package_type, +prepend=CFG.PREPENDED_DIR, omit_epoch=None, package_type=package_type, checksum_type=checksum_type, checksum=checksum) # bug #161989 - get the relative path from the nevra, but omit the package name could be used to address the problem but I'd like to get your opinion about potential side-effects of such a change. Thanks, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Fix remote command schedule date on postgresql
On Tue, May 10, 2011 at 10:38:06AM +0300, Ville Salmela wrote: Hi, with this patch the scheduled command has an accurate date 5/10/11 10:28:00 AM EEST instead of 5/10/11 12:00:00 AM EEST Applied to Spacewalk master, 266e5277fdb7de141d374b7dad906711a4f93720. Thank you, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Password Strength Verification
On Tue, May 10, 2011 at 12:22:47PM +0200, Johannes Renner wrote: Hello, I was recently investigating in hardening security in the spacewalk web-app by introducing password strength verification for new passwords, which means forcing the users to choose passwords with a certain strength. It currently seems to me as if there are two options that I listed below with my personal pros(+) and cons(-). So, which implementation would you prefer and why? 1. Write a custom password strength verificator in Java (like in e.g. ESAPI [1]): + not hard to implement (at least when omitting dictionary lookups) + requirements can be made configurable, e.g. password min/max length - no dictionary lookups 2. Write a wrapper around the 'cracklib-check' binary: + backend is a well known and tested library (cracklib) + comes with an integrated dictionary lookup - introduces a dependency on a 3rd party binary - strength requirements seem to be not configurable Couldn't we use the password feature of PAM and thus use the standard PAM modules for the strength requirements? It could then make it possible to use any PAM module there exists -- pam_cracklib, pam_passwdqc, length limits ... -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Misleading parameter usage help for rhncfg-manager diff
On Tue, May 10, 2011 at 03:27:27PM +0200, Ionuț Arțăriși wrote: It seems that this thread was buried. I'll try to resurrect it with some patches. 0001 - fix usage documentation messages for topdir and dest-file 0002 - remove unused import, fix indentation and a minor typo Pushed to Spacewalk master, will be in the nighly repo later today. Thank you! -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] At v1.5+ org.apache.juli.logging.LogFactory missing in the classpath
On Sun, May 08, 2011 at 03:27:47PM +0200, Bo Maryniuk wrote: On 05/06/2011 09:06 PM, Jan Pazdziora wrote: OKay but what do you propose we do? Add this thing to the common classpath, perhaps? Well, when you look at that commit 608448e0d0ab75bd1fdc3ffe9c9ff52dbcb37c2d, we create the missing symlink (missing in the tomcat6 package). You might want to do that as well. Aren't you using some sort of developer's setup instead of properly building via rpm? Yes, developer setup, of course. It is built from the latest sources. Noone really uses the developers setup here so it might be a bit rusty. Anyway, this thing is a bug in Fedora's tomcat6 (and RHEL 6, IIRC) packaging, and we have the workaround in the .spec for that. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] rhn-satellite-exporter with start-date and end-date
On Mon, May 09, 2011 at 04:41:50PM +0200, Jan Brázdil wrote: This patch fix problem in rhn-satellite-exporter on Postgre: When we are trying to export dump with options --start-date and/or --end-date with Postgre backend these dates have only day precision, but with Oracle backend they have second precision. On Postgre DATE is represented as day only and the time information is striped. We want to represent these dates as TIMESTAMP so we can preserve time and have second precision. Committed as e1a225a62b3034709d20ea87b9f7e767ad6ee105. Thank you, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] - BZ#702524 - rhncfg-client does not deploy an file when permission is set to 000 by webUI
On Fri, May 06, 2011 at 12:48:15AM -0300, Marcelo Moreira de Mello wrote:
Hello,
This patch fixes the rhncfg-client error when trying to deploy a file
with permission 000.
The BZ# mentioned in $subject were cloned to BZ#702535 and flipped
Product to Satellite.
Cheers,
mmello
--
Marcelo Moreira de Mello mme...@redhat.com
Red Hat Inc.
From: Marcelo Moreira de Mello mme...@redhat.com
Date: Fri, 6 May 2011 00:39:56 -0300
Subject: [PATCH] 702524 - fixed the python error when trying to deploy an
file with permission 000 using rhncfg-client
---
client/tools/rhncfg/config_common/transactions.py |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/client/tools/rhncfg/config_common/transactions.py
b/client/tools/rhncfg/config_common/transactions.py
index de7a459..e55b337 100644
--- a/client/tools/rhncfg/config_common/transactions.py
+++ b/client/tools/rhncfg/config_common/transactions.py
@@ -142,9 +142,12 @@ class DeployTransaction:
if file_info['filetype'] != 'symlink':
os.chown(temp_file_path, uid, gid)
-mode = '600'
if file_info.has_key('filemode'):
-mode = file_info['filemode']
+try:
+if string.atoi(str(file_info['filemode'])) 0:
+mode = file_info['filemode']
+except:
+mode='600'
mode = string.atoi(str(mode), 8)
os.chmod(temp_file_path, mode)
So, why is the default here set to '600' by default, not to that '000'?
I don't like the exception logic as well -- why not something like
(untested)
mode = 0
if file_info.has_key('filemode'):
try:
mode = string.atoi(str(file_info['filemode']))
except ValueError:
None
?
--
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Fix remote commands on Spacewalk 1.4 and PostgreSQL
On Fri, May 06, 2011 at 02:15:21PM +0300, Ville Salmela wrote: There were some leftovers from testing in my tree. I cleaned and reinstalled some packages and applied those two patches you committed. And it works now. The other patches can be forgotten I think. Great, thanks for reporting back. Yours, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] - BZ#702524 - rhncfg-client does not deploy an file when permission is set to 000 by webUI
On Fri, May 06, 2011 at 11:30:36AM -0300, Marcelo Moreira de Mello wrote: Hello Jan, Following your guidelines, here is a better patch which fixes that issue. Applied, bbc13b8e49e78dbe463b4aaa495a5b9ecef9bc81. Thanks, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] What to do with an Oracle-only set-difference operator MINUS?
On Fri, May 06, 2011 at 04:38:10PM +0200, Bo Maryniuk wrote: There is an Oracle-only operator for a set differences, called MINUS and seems like it is already known problem when it comes to PostgreSQL. It is seen in a several places, like hard-coded directly in Java code com.redhat.rhn.manager.system.SystemManager as well as in web/modules/rhn/RHN/DB/DataSource/xml/Package_queries.xml as snapshot_unservable_package_list query. Seems like there is no way to use PostgreSQL's EXCEPT along with current query, so should we rewrite query in different way, like NOT IN or and outer join? Yes, that's what we recommend in the porting guide: https://fedorahosted.org/spacewalk/wiki/PostgreSQLPortingGuide#MINUSkeyword Yours, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] - BZ#699966 - Add an option on rhncfg-manager to ignore missing local files
On Wed, Apr 27, 2011 at 02:46:02AM -0300, Marcelo Moreira de Mello wrote: 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 I don't like the --force. Could we have it names --ignore-missing or --skip-missing or something similar? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] draft of release notes
On Wed, Apr 20, 2011 at 11:32:40PM +0200, Miroslav Suchy wrote: Dne 20.4.2011 20:06, Cliff Perry napsal(a): 1) Did 'disable fuzzy search' make the release? Nope. 1.5 material. 2) Isn't Spacewalk-reports event history new to 1.4? Jan? Can you confirm? ./rel-eng/fixed-in-version 55e159a48d23054904329608f8fbed4c2d47 spacewalk-reports-1.4.3-1 Yes, it's new in 1.4. 4) Was there any of the Novell patches which introduced general features useful to others? We commited it after branching. So it will be 1.5 material. Actually, the updateinfo feature went in the Friday before you branched. So that one is in. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] build rhnpush on openSUSE
On Fri, Apr 15, 2011 at 01:45:32PM +0200, Michael Calmer wrote: Hi, Am Montag, 11. April 2011, 17:18:13 schrieb Miroslav Suchý: On 04/08/2011 03:01 PM, Michael Calmer wrote: Hi, here is the patch to build rhnpush on openSUSE. 0009-build-rhnpush-on-SUSE.patch: - only some specfile modifications Applied only first part. And next time I would to see instead of - modify the specfile some better explanation why this is done. Well I from first line I know that it is because Suse build, but why? Do you receive some error in OBS. Do you get some Traceback. Or is it some kind of policy (link)?... The rest is as in previous commits. Directories are already owned by rhn-client-tools. Here is the patch for the missing filelist issue with a short explanation why we BuildRequire rhn-client-tools Pushed to master as 68a62d0c98976d3224ac3fb4edf53260259f6e9b and tagged as rhnpush-5.5.26-1. Thanks, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] build rhn-custom-info on openSUSE
On Fri, Apr 15, 2011 at 01:42:10PM +0200, Michael Calmer wrote:
Hi,
Am Montag, 11. April 2011, 16:58:21 schrieb Miroslav Suchý:
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.
Hmm, rpm do not support %elif. It does not in OBS and we looked in the
upstream code and also there is elif not implemented.
+%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.
Ok, here is a modified version of the patch.
Pushed to master as fcb043e5c59703a7803be5af2920b95041571db4
and tagged as rhn-custom-info-5.4.12-1.
Thanks,
--
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] build rhncfg on openSUSE
On Fri, Apr 15, 2011 at 01:38:21PM +0200, Michael Calmer wrote: Hi, Am Freitag, 8. April 2011, 14:57:56 schrieb Michael Calmer: Hi, here is the patch for rhncfg. 0007-build-rhncfg-on-SUSE.patch: - only some specfile modifications I splitted this into seperate patches. One SUSE specific and one general one like you suggested. Pushed to master as dae10073c35f9cbba7d1160014788316c56c37aa and baf0e0467eb5d6c924532399537a02b3ad26cf4a and tagged as rhncfg-5.10.2-1 Thanks, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] build rhn-client-tools on openSUSE
On Fri, Apr 15, 2011 at 01:31:41PM +0200, Michael Calmer wrote: Hi, Am Freitag, 8. April 2011, 14:49:30 schrieb Michael Calmer: Hi, rhn-client-tools: [...] 0003-modify-spec-file-to-build-on-SUSE.patch: Specfile work. Use SUSE rpm names and add some directories to the filelist which does not exist on SUSE or does not exist during build. attached you can find a new version for this. Pushed to master as 4f8ebf782cae9687c1cb7b779df159182b988a9d and tagged as rhn-client-tools-1.5.3-1. Thanks, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] build rhnmd on openSUSE
On Fri, Apr 15, 2011 at 01:55:45PM +0200, Michael Calmer wrote: Hi, Am Freitag, 8. April 2011, 15:23:52 schrieb Michael Calmer: Hi, here is a patch to build rhnmd on openSUSE. 0014-build-rhnmd-on-SUSE.patch - modify the specfile - add init script for openSUSE For SUSE I have removed the ssh key generation from the %post section. I added the generation into the SUSE init script. The reason for this is, that if you do it in %post and use this RPM in an appliance, you have the same ssh key on all copies of your appliance. Maybe you are interrested to do this also for RedHat / Fedora. I changed this patch and splited one more general thing out. build rhnmd on SUSE - add init script for SUSE - BuildRequire sysconfig to make chkconfig work during build in OBS - openssh-server does not exist on SUSE (part of openssh) - no keygen in %post to use it in appliances - create nocpulse user in a different way to make hime work on SUSE with openssh add nocpulse config dir to filelist I think rhnmd requires nothing which already provides this directory. Pushed to master as d4dfbbc37eb42e07b8d2afc6d3a19195731bcb7b and 1e2120ddfc84f6804dda2decc6b2809c5dd154a9 and tagged as rhnmd-5.3.9-1. Thanks, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] build spacewalk-koan on openSUSE
On Fri, Apr 15, 2011 at 01:50:37PM +0200, Michael Calmer wrote: Hi, Am Freitag, 8. April 2011, 15:12:19 schrieb Michael Calmer: Hi, here is the patch to build spacewalk-koan on openSUSE. 0011-build-spacewalk-koan-on-SUSE.patch: - modify the specfile - require virtualization packages It seems, that code of spacewalk-koan import modules from rhn-virtualization. So I added these requires to the specfile. Is there a special reason why it is not there, or simply forgot to add this requirement? Attached is a new versoin of this patch, but without the Requires: rhn- virtualization. Pushed to master as c2950ccba2cc98bb87ea6fba6d4fcd1aceae758e and tagged as spacewalk-koan-0.2.18-1. Thanks, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] build rhn-virtualization on openSUSE
On Fri, Apr 15, 2011 at 01:48:32PM +0200, Michael Calmer wrote: Hi, Am Freitag, 8. April 2011, 15:07:12 schrieb Michael Calmer: Hi, here is the patch to build rhn-virtualization on openSUSE. 0010-build-rhn-virtualization-on-SUSE.patch: - modify the specfile - add SUSE init script Attached is a new version of this patch. build rhn-virtualization on SUSE - add packages to make it build in OBS - change scripts to call cron init script on SUSE - add SUSE init script Pushed to master as c9ce75adb303f812dcc26aa1f40e2ce8b1bbe86b and tagged as rhn-virtualization-5.4.22-1. Thanks, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] build osad on openSUSE
On Fri, Apr 15, 2011 at 01:35:52PM +0200, Michael Calmer wrote: Hi, Am Freitag, 8. April 2011, 14:55:50 schrieb Michael Calmer: Hi, here is the patch to build and run osad on openSUSE. 0006-build-osad-on-SUSE.patch: - specfile work - add init script for SUSE - osad.py missed and import of the config module I have splitted this one into 3 seperate patches. Pushed to master as 39f768dc06eb56c115bc02d660929ab55bab4148, 6ddb9dcf9969d8feceff37b3cbc8f5d87df3dd48, and a16cf5b6ced8302322e47e6b750a65a09a67a3cf and tagged as osad-5.10.12-1. Thanks, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] adding support zypper in bootstrap script and allow multiple GPG keys
On Fri, Apr 08, 2011 at 03:18:49PM +0200, Michael Calmer wrote: Hi, here is a patch for the server side. This patch add support for zypper as installer to the bootstrap script. Additionally it enhances the ORG_GPG_KEY variable to be a comma seperated list like the activation keys. 0013-support-zypper-in-bootstrap-script-and-allow-multipl.patch - add zypper as valid installer in the bootstrap script - allow to install multiple GPG keys. Use comma seperated list in ORG_GPG_KEY - force installing ORG_CA_CERT if rpm is used Pushed to master as e78222713ed55aba5a6bfc35fcd3fda7340d2c19 and tagged as spacewalk-certs-tools-1.5.1-1. Ideally we'd like to see patch like this split into multiple commits, which you nicely list in those items. The reason is -- if we hit a problem in the future (say, the --force truns out to break something), it will be easier to see it and revert it. Please don't be shy splitting things into multiple commits. Thanks, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] support for weak dependencies
On Fri, Mar 11, 2011 at 05:21:50PM +0100, Michael Calmer wrote: Hi, Am Mittwoch, 9. März 2011, 12:21:41 schrieb Jan Pazdziora: On Wed, Mar 09, 2011 at 11:11:08AM +0100, Jan Pazdziora wrote: On Mon, Mar 07, 2011 at 01:24:54PM +0100, Michael Calmer wrote: Hello, [...] Could you please investigate? Do you need list of rpms I have installed or something? I reworked the patchset: - removed the trailing whitespaces - fix the missing RPMTAG names bug (patch 0006) I've committed the patches to master now and tagged the respective packages. I'm sorry it got burried for so long. I've shifted the schema upgrade scripts to *-1.5 directory as Spacewalk 1.4 was already branched. I had to fix the SHA1 values in PostgreSQL sources -- you might want to do ( cd schema/spacewalk perl schema-source-sanity-check.pl ) to check that the schema sources look sane. It's actually necessary to do that because the rpm build would fail otherwise. Thank you, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Misleading parameter usage help for rhncfg-manager diff
On Thu, Apr 14, 2011 at 05:25:45PM +0200, Miroslav Suchý wrote: --topdir help=Make all files relative to this string. Here the help text is misleading because there are no new files being made, they are just being compared. Yes, make in the meaning of create/add is false. Treat may be better word, but I'm not native speaker so ideas are welcome. Make all filenames relative to this string. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk 1.4-RC post-upgrade report
On Tue, Apr 12, 2011 at 04:10:09PM +0200, Michael Calmer wrote: On which OS was this? This was SLES11 with python 2.6. I don't know exactly how python import works. So I do not exactly now what should work and what not :-) On Wed, Apr 13, 2011 at 03:12:15PM +0200, Martin Zehetmayer wrote: Hi, for I am new on this list let me introduce myself: My name is Martin Zehetmayer, I work for as consultant for a small linux solution provider in germany, mostly dealing with RHEL systems. I am currently testing spacewalk 1.4-RC6 on a RHEL6.0 x86_64 system. Installing works very fine but when adding packages to a custom channel I get the following error: [...] After searching I found a post in this list from Michael Calmer which reports the same error under SLES. As mentioned above I tested it under RHEL6 and the same problem appear. It can be solved using three tests as suggested from Michael. I've only tested this on RHEL 6.1 (to be) and sadly, yum has changed since vanilla RHEL 6.0. I've now added the import from xml.etree and the 1.4-RC repo has the new spacewalk-backend* packages (1.4.38-1). Thanks for bringing this to our attention. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [Fwd: Oracle Database 11g Express Edition Beta!]
On Sun, Apr 10, 2011 at 10:35:53AM +0200, Luc de Louw wrote: I already made tests with 1.4 nightly and XE11 on EL6. I tested some very basic stuff like installing, ISS, registering a client. It basically works. There are some issues: 1. Installation of oracle XE 11 failed: Transaction Test Succeeded Running Transaction Error in PREIN scriptlet in rpm package oracle-xe-11.2.0-0.5.x86_64 error: net.bridge.bridge-nf-call-ip6tables is an unknown key error: net.bridge.bridge-nf-call-iptables is an unknown key error: net.bridge.bridge-nf-call-arptables is an unknown key error: %pre(oracle-xe-11.2.0-0.5.x86_64) scriptlet failed, exit status 255 error: install: %pre scriptlet failed (2), skipping oracle-xe-11.2.0-0.5 Failed: oracle-xe.x86_64 0:11.2.0-0.5 However, with rpm -ihv --noscript I was able to install it. The better approach is not to --noscript but to run the rpm -Uvh twice, to get sysctl settled: https://fedorahosted.org/spacewalk/wiki/OracleXeSetup#OracleXEitself If you noscript it, you might lose potentially useful changes that the %pre / %post scriptlets make to the installation. 2. Installation of oracle-xe-selinux failes due to dependency problems (oracle-xe-univ vs. oracle-xe): --- Package oracle-xe-selinux.noarch 0:10.2.0.20-1.el6 set to be updated -- Processing Dependency: oracle-xe-univ for package: oracle-xe-selinux-10.2.0.20-1.el6.noarch --- Package setools-libs.x86_64 0:3.3.7-4.el6 set to be updated -- Finished Dependency Resolution Error: Package: oracle-xe-selinux-10.2.0.20-1.el6.noarch (spacewalk) Requires: oracle-xe-univ No problem so far with rpm -ihv --nodeps oracle-xe-selinux-10.2.0.20-1.el6.noarch.rpm Have not seen any oracle releated AVCs afterwards. Please check (ps axuZ) what SELinux domain the Oracle processes are in -- I assume it will not be properly confined as the location of the binaries changed since oracle-xe-univ, so the file context don't apply for the version 11. If you or someone want to spend the time updating the path to match the new version, I'm willing to apply a patch, but we don't know what Oracle plans to use as the final (non-beta) location, so it might be just a waste of time if they go back to the 10-ish setup later. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] updateinfo to Errata import in spacewalk-repo-sync
On Wed, Mar 23, 2011 at 03:25:43PM +0100, Michael Calmer wrote: Here is a new patchset. I had to do some more changes. To not loose the overview I have combined them into 4 patches. 0001: The database changes 0002: changes in the python code; mainly reposync and yum repo_plugin 0003: changes in java web pages 0004: changes in perl web pages I hope I included everything what was mentioned in this thread. I also did a short test with the nightly build (2 days ago) with a fedora 14 repository and a openSUSE 11.4 repository. Michael, I've now applied your patches to Spacewalk master. Packages for the nightly repo are being built while I'm writing this so people will have chance to see the feature in Spacewalk nightly later today, and we will have chance to flesh out any issues before Spacewalk 1.4 is out. Thank you for your contribution and I'm sorry that it took me so long to get to your post. Yours, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] spacewalk-service start hangs at waiting for tomcat
On Fri, Mar 25, 2011 at 09:49:24AM -0700, Dale Bewley wrote: I have a brand new install on F14 x86_64 of spacewalk-admin-1.3.9-1.fc14. If I run /usr/sbin/spacewalk-service start it hangs at Waiting for tomcat to be ready ... until I telnet localhost 8009. Changing the lsof command to below seems to fix that. --- spacewalk-service.dist 2011-01-20 09:56:49.0 -0800 +++ spacewalk-service 2011-03-25 09:33:59.017356000 -0700 @@ -52,7 +52,7 @@ if lsof /proc /dev/null ; then echo Waiting for tomcat to be ready ... while [ -f /var/run/$TOMCAT.pid ] ; do -lsof -t -i @localhost:8009 -p $(cat /var/run/$TOMCAT.pid) /dev/null break +lsof -t -i TCP:8009 -p $(cat /var/run/$TOMCAT.pid) /dev/null break sleep 1 done else Thank you, committed to Spacewalk git master as c63c29542cbe22247ab6e4bdcabd78de3a13933e. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] rhn_register vs. up2date --register @ RHEL(3, 4)
On Mon, Mar 21, 2011 at 10:19:48PM +0100, Miroslav Suchy wrote: We have in several strings this text: Please run rhn_register (or up2date --register on Red Hat Enterprise Linux 3 or later) and I wonder what is difference between: rhn_register and up2date --register on Red Hat Enterprise Linux 4 (as 3 is EOL). Both works there. Looking at the source code rhn_register is just symlink to up2date. And it has been this way even in RHEL3. Any objection to wipe out that text in parenthesis: (or up2date --register on Red Hat Enterprise Linux 3 or later) ? The rhn_register was RHEL 2.1 thing. Then the functionality was moved to up2date --register for RHEL 3 and 4. Then up2date was removed in RHEL 5 and rhn_register was reintroduced. No objection removing any mentions of up2date from Spacewalk client code. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] updateinfo to Errata import in?spacewalk-repo-sync
On Tue, Mar 08, 2011 at 05:57:05PM +0100, Michael Calmer wrote: Hi, Am Montag, 7. März 2011, 15:49:59 schrieb Miroslav Suchý: On 03/07/2011 02:28 PM, Michael Calmer wrote: Hello, [...] Regarding patch 0001-implement-updateinfo-Errata-import-5.patch... It seems to me that it is merge of 4 smaller commits and therefore the commit description is quite misleading... I would expectd something like: Decide if package is errata based on updateinfo Well, this was the initial patch for this feature. So I think implement updateinfo to Errata import is a good headline. The 2 additional patches merged into this first commit were smaller bugfixes for the initial patch. and something more how the detection works and which all information you extract from updateinfo. * fix errata override bug. Create a unique advisory_name This was about the id element in the updateinfo which is not unique. To get it unique we append notice['version'] to it. The next hit was, By the way, when I've removed some safechecks to actually see some erratas being created from http://archives.fedoraproject.org/pub/archive/fedora/linux/updates/7/i386/repodata/updateinfo.xml.gz I get traceback No cheksum found for hydrogen-0.9.3-9.fc7.1.src. Skipping Patch FEDORA-2007-3554-1.4-channel-ia32 Traceback (most recent call last): File /usr/bin/spacewalk-repo-sync, line 69, in module sys.exit(abs(main() or 0)) File /usr/bin/spacewalk-repo-sync, line 63, in main sync.main() File /usr/lib/python2.6/site-packages/spacewalk/satellite_tools/reposync.py, line 111, in main self.import_updates(plugin, url) File /usr/lib/python2.6/site-packages/spacewalk/satellite_tools/reposync.py, line 146, in import_updates self.upload_updates(notices) File /usr/lib/python2.6/site-packages/spacewalk/satellite_tools/reposync.py, line 297, in upload_updates importer.run() File /usr/lib/python2.6/site-packages/spacewalk/server/importlib/importLib.py, line 622, in run self.submit() File /usr/lib/python2.6/site-packages/spacewalk/server/importlib/errataImport.py, line 196, in submit dml = self.backend.processErrata(self.batch) File /usr/lib/python2.6/site-packages/spacewalk/server/importlib/backend.py, line 682, in processErrata transactional=1) File /usr/lib/python2.6/site-packages/spacewalk/server/importlib/backend.py, line 1364, in __processObjectCollection return self.__processObjectCollection__(objColl, parentTable, childDict, **kwargs) File /usr/lib/python2.6/site-packages/spacewalk/server/importlib/backend.py, line 1450, in __processObjectCollection__ _buildExternalValue(extObject, object, parentTableObj) File /usr/lib/python2.6/site-packages/spacewalk/server/importlib/backend.py, line 1982, in _buildExternalValue dict[f] = sanitizeValue(entry[attr], datatype) File /usr/lib/python2.6/site-packages/spacewalk/server/importlib/backendLib.py, line 494, in sanitizeValue return int(value) ValueError: invalid literal for int() with base 10: '1.4' I assume the 1.4 value is the version you've put to the errata name as the updateinfo.xml.gz has 1.4 in version -- it starts like ?xml version=1.0? updates update from=bodhiadmin-memb...@fedoraproject.org status=stable type=bugfix version=1.4 idFEDORA-2007-2609/id titlefilezilla-3.0.2.1-1.fc7/title releaseFedora 7/release issued date=2007-11-20 17:45:27/ references/ I further assume that that value somehow gets massaged into epoch column somewhere, or some other integer field. It looks like another reason why we really should try to find alternative approaches to the uniqueness problem, if there indeed is one. Perhaps some command line option? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] updateinfo to Errata import in?spacewalk-repo-sync
On Fri, Mar 11, 2011 at 09:40:25AM +0100, Jan Pazdziora wrote: By the way, when I've removed some safechecks to actually see some erratas being created from http://archives.fedoraproject.org/pub/archive/fedora/linux/updates/7/i386/repodata/updateinfo.xml.gz I get traceback No cheksum found for hydrogen-0.9.3-9.fc7.1.src. Skipping Patch FEDORA-2007-3554-1.4-channel-ia32 Traceback (most recent call last): File /usr/bin/spacewalk-repo-sync, line 69, in module sys.exit(abs(main() or 0)) File /usr/bin/spacewalk-repo-sync, line 63, in main sync.main() File /usr/lib/python2.6/site-packages/spacewalk/satellite_tools/reposync.py, line 111, in main self.import_updates(plugin, url) File /usr/lib/python2.6/site-packages/spacewalk/satellite_tools/reposync.py, line 146, in import_updates self.upload_updates(notices) File /usr/lib/python2.6/site-packages/spacewalk/satellite_tools/reposync.py, line 297, in upload_updates importer.run() File /usr/lib/python2.6/site-packages/spacewalk/server/importlib/importLib.py, line 622, in run self.submit() File /usr/lib/python2.6/site-packages/spacewalk/server/importlib/errataImport.py, line 196, in submit dml = self.backend.processErrata(self.batch) File /usr/lib/python2.6/site-packages/spacewalk/server/importlib/backend.py, line 682, in processErrata transactional=1) File /usr/lib/python2.6/site-packages/spacewalk/server/importlib/backend.py, line 1364, in __processObjectCollection return self.__processObjectCollection__(objColl, parentTable, childDict, **kwargs) File /usr/lib/python2.6/site-packages/spacewalk/server/importlib/backend.py, line 1450, in __processObjectCollection__ _buildExternalValue(extObject, object, parentTableObj) File /usr/lib/python2.6/site-packages/spacewalk/server/importlib/backend.py, line 1982, in _buildExternalValue dict[f] = sanitizeValue(entry[attr], datatype) File /usr/lib/python2.6/site-packages/spacewalk/server/importlib/backendLib.py, line 494, in sanitizeValue return int(value) ValueError: invalid literal for int() with base 10: '1.4' I assume the 1.4 value is the version you've put to the errata name as the updateinfo.xml.gz has 1.4 in version -- it starts like ?xml version=1.0? updates update from=bodhiadmin-memb...@fedoraproject.org status=stable type=bugfix version=1.4 idFEDORA-2007-2609/id titlefilezilla-3.0.2.1-1.fc7/title releaseFedora 7/release issued date=2007-11-20 17:45:27/ references/ I further assume that that value somehow gets massaged into epoch column somewhere, or some other integer field. It turns out, the e['advisory_rel'] = notice['version'] is at fault -- at least in that Fedora 7 updateinfo, the version is not integer. When I've changed the line to e['advisory_rel'] = 1 things went much better. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] updateinfo to Errata import in?spacewalk-repo-sync
On Fri, Mar 11, 2011 at 10:31:45AM +0100, Michael Calmer wrote: is at fault -- at least in that Fedora 7 updateinfo, the version is not integer. When I've changed the line to e['advisory_rel'] = 1 things went much better. Yes, this is the version appended to advisory_name. Here is an example from openSUSE which shows the unique problem updates !--PATCHINFO id=898568de8313f62fc290e303946cfe11!-- update status=stable from=maint-co...@suse.de type=recommended version=1596 idflash-player/id issued date=1256155647/ [...] update status=stable from=maint-co...@suse.de type=security version=1707 idflash-player/id issued date=1260492724/ Same id used but with a different version. I think we need to find a way to deal with all these differences in how updateinfo is used. Right. I've checked http://download.englab.brq.redhat.com/pub/fedora/linux/updates/14/i386/repodata/updateinfo.xml.gz and it still has version=1.4 there, so it looks like Fedora uses that attribute to mean the version of the data structure (it's 1.4 both on Fedora 7 and Fedora 14), not version of the errata. Can you come up with some proposal? From top of my head, we could add a type of updatesinfo to the repository definition in the database and use that, or use some heuristics, either checking that the id does not end with /-\d+-\d+$/ or checking something else specific to Fedora / *SuSE. About the channel label added to the advisory_name. I think the correct way would be to search in DB if the errata already exist. If so, create the errata object from the DB and add the new packages and channels to it. Than update the errata in the database. Exactly. Doing this, we do not need to append the channel label to advisory_name. Is there already a method to create an Erratum object from the database? There has to be, as satellite-sync does exactly that. Unfortunately, I won't be able to dig into it for the next week as I will be away -- if you could investigate, that would be great. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] updateinfo to Errata import in spacewalk-repo-sync
'] == 'bugzilla', notice['references']) +bzs = () +if notice['references']: + bzs = filter(lambda r: r['type'] == 'bugzilla', notice['references']) if len(bzs): but you might have some better approach in the queue. As for the patches: Subject: [PATCH 1/9] implement updateinfo = Errata import [...] import yum import shutil import sys +from yum import config What is the config here needed for? diff --git a/schema/spacewalk/upgrade/spacewalk-schema-1.3-to-spacewalk-schema-1.4/016-rhnErrata.sql b/schema/spacewalk/upgrade/spacewalk-schema-1.3-to-spacewalk-schema-1.4/016-rhnErrata.sql index 6c81260..bbfda5f 100644 --- a/schema/spacewalk/upgrade/spacewalk-schema-1.3-to-spacewalk-schema-1.4/016-rhnErrata.sql +++ b/schema/spacewalk/upgrade/spacewalk-schema-1.3-to-spacewalk-schema-1.4/016-rhnErrata.sql @@ -12,5 +12,6 @@ ALTER TABLE rhnErrata MODIFY advisory_name varchar2(100); ALTER TABLE rhnErrata MODIFY advisory varchar2(100); +ALTER TABLE rhnErrata ADDerrata_from varchar2(127); \ show errors These will fail on PostgreSQL. Could you please provide .oracle and .postgresql variants of the schema upgrade scripts? Please see https://www.redhat.com/archives/spacewalk-devel/2011-January/msg00061.html for suggestions about how to do that. FYI, the packages that I've used are at https://koji.spacewalkproject.org/koji/taskinfo?taskID=62852 https://koji.spacewalkproject.org/koji/taskinfo?taskID=62851 https://koji.spacewalkproject.org/koji/taskinfo?taskID=62849 https://koji.spacewalkproject.org/koji/taskinfo?taskID=62846 should you review the result of my git am. Thank you, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] updateinfo to Errata import in?spacewalk-repo-sync
On Tue, Mar 08, 2011 at 05:57:05PM +0100, Michael Calmer wrote: * fix errata override bug. Create a unique advisory_name This was about the id element in the updateinfo which is not unique. Not unique where, across what domain? When I take http://archives.fedoraproject.org/pub/archive/fedora/linux/updates/7/i386/repodata/updateinfo.xml.gz and see errata FEDORA-2007-2609 there I expect that errata to land in Spacewalk as FEDORA-2007-2609, and not as FEDORA-2007-2609-1.4 or FEDORA-2007-2609-1.4-channel-ia32. When does this get non-unique? To get it unique we append notice['version'] to it. The next hit was, that patches may be created for mulitarch repositories, but in spacewalk we have single arch channels. This can lead into duplicate updates where only the package list differ because of the architectures. So we also append self.channel['arch'] to advisory and advisory_name This is not how erratas work in Spacewalk/Satellite. Take this scenario: You have Satellite with i386, x86_64, and s390x channels synced. You make a dump with rhn-satellite-exporter with all the channels. Erratas in that dump will reference packages from all arches. Then on another Satellite/Spacewalk you satellite-sync that dump, but only channel i386. This will create the erratas and link them to 32bit packages (because you have no x86_64 and s390x channels / packages synced). And then you sync the s390x channel. And the s390x packages have to end up added to the same erratas that have been created when syncing the i386 channels. You can see it even if you have one dump with one arch, and second dump with another arch, for example if you use channel dumps from RHN. * we need to search for the package in the correct channel. It may happen, that the same nevra exists multiple times in rhnPackage. The only difference is the checksum. They are assigned to different channels. So we need to take care during errata import to get the right package added to the errata. How do you do that? What if I run the spacewalk-repo-sync with multiple -c options? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] updateinfo to Errata import in spacewalk-repo-sync
On Mon, Mar 07, 2011 at 02:28:48PM +0100, Michael Calmer wrote:
Hello,
the attached patch set implements updateinfo to errata import in spacewalk-
repo-sync.
[...]
diff --git a/backend/satellite_tools/reposync.py
b/backend/satellite_tools/reposync.py
index 2fc46a0..ee3be6e 100644
--- a/backend/satellite_tools/reposync.py
+++ b/backend/satellite_tools/reposync.py
[...]
-from spacewalk.server.importlib.importLib import IncompletePackage
+from spacewalk.common.rhn_mpm import InvalidPackageError
+from spacewalk.server.importlib.importLib import IncompletePackage, Erratum,
Checksum, Bug, Keyword
+from spacewalk.server.importlib.backendOracle import OracleBackend
[...]
+
+ backend = OracleBackend()
+ backend.init()
+ importer = ErrataImport(batch, backend)
+ importer.run()
Michael,
this fails on PostgreSQL database backend with traceback
Traceback (most recent call last):
File /usr/bin/spacewalk-repo-sync, line 69, in module
sys.exit(abs(main() or 0))
File /usr/bin/spacewalk-repo-sync, line 63, in main
sync.main()
File
/usr/lib/python2.6/site-packages/spacewalk/satellite_tools/reposync.py, line
111, in main
self.import_updates(plugin, url)
File
/usr/lib/python2.6/site-packages/spacewalk/satellite_tools/reposync.py, line
146, in import_updates
self.upload_updates(notices)
File
/usr/lib/python2.6/site-packages/spacewalk/satellite_tools/reposync.py, line
296, in upload_updates
backend.init()
File
/usr/lib/python2.6/site-packages/spacewalk/server/importlib/backendOracle.py,
line 573, in init
self.setDateFormat(-MM-DD HH24:MI:SS)
File
/usr/lib/python2.6/site-packages/spacewalk/server/importlib/backend.py, line
80, in setDateFormat
sth.execute()
File /usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/sql_base.py,
line 163, in execute
return apply(self._execute_wrapper, (self._execute, ) + p, kw)
File
/usr/lib/python2.6/site-packages/spacewalk/server/rhnSQL/driver_postgresql.py,
line 268, in _execute_wrapper
raise rhnSQL.SQLStatementPrepareError(0, str(e), self.sql)
spacewalk.server.rhnSQL.sql_base.SQLStatementPrepareError: ('syntax error at or
near session\nLINE 1: alter session set nls_date_format =\'-MM-DD
HH24:MI:SS\'\n ^\n', 0, alter session set nls_date_format
='-MM-DD HH24:MI:SS')
You shouldn't need to explicitly use OracleBackend. Instead, we
now have the SQLBackend, see commit
7d5ed504e7e809fdcc7c82f8b5e82c37279200dd
where it was introduced. So I assume something like (untested)
--- satellite_tools/reposync.py.orig2011-03-09 05:36:51.0 -0500
+++ satellite_tools/reposync.py 2011-03-10 06:05:32.213461147 -0500
@@ -288,8 +288,7 @@
if not error:
batch.append(e)
- backend = OracleBackend()
- backend.init()
+ backend = SQLBackend()
importer = ErrataImport(batch, backend)
importer.run()
self.regen = True
could do the trick.
--
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] support for weak dependencies
On Mon, Mar 07, 2011 at 01:24:54PM +0100, Michael Calmer wrote: Hello, attached is a patch set which implement weak rpm dependencies (Recommends, Suggests, Supplements) into spacewalk. This patch set implements: parsing weak dependencies during spacewalk-repo- sync, store them into the database, show them in the WebUI and generate them into new created channel metadata. Michael, when I apply the patches to Spacewalk nightly and try rhnpush (of openSUSE rpm or Spacewalk rpm), I get the following traceback: File /usr/lib/python2.6/site-packages/spacewalk/server/apacheUploadServer.py, line 97, in _wrapper ret = function(req) File /usr/share/rhn/upload_server/handlers/package_push/package_push.py, line 134, in handler relative_path=self.rel_package_path, org_id=self.org_id) File /usr/lib/python2.6/site-packages/spacewalk/server/rhnPackageUpload.py, line 150, in push_package header_end=header_end, channels=channels) File /usr/lib/python2.6/site-packages/spacewalk/server/importlib/mpmSource.py, line 224, in create_package header_end=header_end, channels=channels) File /usr/lib/python2.6/site-packages/spacewalk/server/importlib/headerSource.py, line 406, in createPackage channels) File /usr/lib/python2.6/site-packages/spacewalk/server/importlib/headerSource.py, line 141, in populate self._populateDependencyInformation(header) File /usr/lib/python2.6/site-packages/spacewalk/server/importlib/headerSource.py, line 161, in _populateDependencyInformation self._populateTag(header, k, v) File /usr/lib/python2.6/site-packages/spacewalk/server/importlib/headerSource.py, line 186, in _populateTag v = sanitizeList(header[rf]) File /usr/lib/python2.6/site-packages/spacewalk/common/rhn_rpm.py, line 68, in __getitem__ return self.hdr[name] ValueError: unknown header tag Could you please investigate? Do you need list of rpms I have installed or something? Thanks, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] support for weak dependencies
On Wed, Mar 09, 2011 at 11:11:08AM +0100, Jan Pazdziora wrote: On Mon, Mar 07, 2011 at 01:24:54PM +0100, Michael Calmer wrote: Hello, attached is a patch set which implement weak rpm dependencies (Recommends, Suggests, Supplements) into spacewalk. This patch set implements: parsing weak dependencies during spacewalk-repo- sync, store them into the database, show them in the WebUI and generate them into new created channel metadata. Michael, when I apply the patches to Spacewalk nightly and try rhnpush (of openSUSE rpm or Spacewalk rpm), I get the following traceback: [...] File /usr/lib/python2.6/site-packages/spacewalk/server/importlib/headerSource.py, line 186, in _populateTag v = sanitizeList(header[rf]) File /usr/lib/python2.6/site-packages/spacewalk/common/rhn_rpm.py, line 68, in __getitem__ return self.hdr[name] ValueError: unknown header tag Could you please investigate? Do you need list of rpms I have installed or something? One thing which might be good to have when you submit patch sets with new features / functionality would be examples of commands or steps (CLI, API, WebUI) which would make it easy to see the feature in action, or reference to some specs page which would have the steps. In this case I just tried rhnpush as that was the easiest for me and I got stuck right at the beginning, which became kinda blocker for the whole patch set. But maybe you did not verify the change with rhnpush at all because it does not fit your workflows and you have some other preferred way to get the feature running and observe it, which would unblock me in reviewing it. If you and your peers could add reproducer steps to your submissions in the future, it would be cool. Ideally they should be fairly specific about what exact rpm file / repository / whatever was tested and is supposed to work. Thanks, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Storing passwords into LDAP
On Tue, Mar 08, 2011 at 11:34:10PM +0200, derleader mail wrote: Is it possible to store usernames and passwords into exteranl LDAP server? If you mean authenticating against LDAP server, yes, that is possible via PAM. The only thing to keep in mind is that the account has to be (pre)created with proper Use PAM flag in Spacewalk as well. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] support for weak dependencies
On Mon, Mar 07, 2011 at 01:24:54PM +0100, Michael Calmer wrote: attached is a patch set which implement weak rpm dependencies (Recommends, Suggests, Supplements) into spacewalk. This patch set implements: parsing weak dependencies during spacewalk-repo- sync, store them into the database, show them in the WebUI and generate them into new created channel metadata. I'm taking this patch set for review. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [Fwd: [Spacewalk-announce-list] Patch missing return in rhn_ks_session_history_trigger_fun (spacewalk-postgresql 1.3.3)]
On Thu, Mar 03, 2011 at 01:15:41PM -0500, Cliff Perry wrote: Was this looked into? Yes, I have fixed rhn_ks_session_history_trigger_fun: http://git.fedorahosted.org/git/?p=spacewalk.git;a=commitdiff;h=a14b2f07e579a3d47aac1f76006f8f7f9f767ca9 I've tried to reach to Pascal to suggest to use spacewalk-devel mailing list in the future but his email address bounces. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Hide the 'delete note' link on creation of system notes
On Tue, Mar 01, 2011 at 11:26:57AM +0100, Johannes Renner wrote: Attached is a small patch for the jsp page that is used for editing system notes. It hides the delete note link when a system note is currently being created. This is done by including the toolbar within the c:choose element. Clicking this link during the creation of a new note will otherwise lead to internal server error (NPE), because (of course) the nid is still null. Pushed to Spacewalk master, thanks. By the way: will you be submitting the patch for the Has Signed Metadata feature as well? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Hide the 'delete note' link on creation of system notes
On Tue, Mar 01, 2011 at 11:26:57AM +0100, Johannes Renner wrote: From ea324e8b7b6907f24d010b7b4439bc1e00e8f8bf Mon Sep 17 00:00:00 2001 From: Johannes Renner jren...@suse.de Date: Thu, 17 Feb 2011 11:20:52 +0100 Subject: [PATCH] do not show delete link on creation of notes (bnc#672090) One note here -- we really like the bugzillas to be public when they are referenced in the git commits. Is the bnc#672090 going to be flipped to public eventually? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Added NULL checks in setMaxFlex() and setMaxMembers()
On Thu, Jan 27, 2011 at 10:07:57AM +0530, Paresh Mutha wrote: Hello, I am proposing a patch which includes NULL checks for setMaxFlex() and setMaxMembers() in ChannelOverview.java. Without that, in few cases where maxFlex or maxMembers were null, it led to NullPointerException and page https://server.example.com/rhn/admin/multiorg/OrgSoftwareSubscriptions.do?oid=orgid failed with an ISE. We already have a bugzilla created for RHN Satellite v5.4 - https://bugzilla.redhat.com/show_bug.cgi?id=671450 Paresh, did you investigate why (in which situation) does the setMaxFlex and/or setMaxMembers get called with null? Shouldn't/couldn't we handle this on the caller's side, rather than in the setter? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Spacewalk 1.3 delayed
Folks, we have hit an issue with recent change to Fedora 14 selinux-policy which became a blocker for the Spacewalk 1.3 release. We are working with the SELinux guys to resolve the issue but currently Spacewalk release is blocked. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] - fix typo in spacewalk-koan/spacewalkkoan/spacewalkkoan.py
On Thu, Jan 27, 2011 at 11:34:53PM -0200, Marcelo Moreira de Mello wrote: This proposed patch fixed a typo when importing subprocess module in spacewalkkoan.py Applied, thanks! -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Schema upgrades on PostgreSQL
One-line summary for developers: From now on, please have PostgreSQL in mind even for schema upgrades. Full story: With spacewalk-schema-1.3.17-1, the upgrade from 1.2 to nightly ends up with the same schema content (definition) as fresh Spacewalk nightly installation, even on PostgreSQL, after the spacewalk-schema-upgrade was executed. I've added the necessary schema upgrade scripts for to achieve that, and we need to keep PostgreSQL upgradable from now on. The schema/spacewalk/upgrade/spacewalk-schema-* directories can have not only .sql files now, but also .sql.oracle and .sql.postgresql content. If the schema upgrade script runs fine both on sqlplus and on psql, just leave it as .sql, like we did for all the previous releases. If however there needs to be different syntax on Oracle than on PostgreSQL, create *both* .sql.oracle and .sql.postgresql scripts, and mark the PostgreSQL one as equivalent to the Oracle one using the SQL comment on the first line of the .sql.postgresql file, with the has being sha1sum of the Oracle schema upgrade script, for example -- oracle equivalent source sha1 b14267384bc104605623a41b755e68e0103b5aa8 Maybe the change is only needed on one of those database backends. Even in this case you have to create both files, and put a comment like -- This file is intentionally left empty. into the unneeded one, to make it clear that you really did not mean to put any SQL there. The schema-source-sanity-check.pl script was amended to check that indeed both variants exist if one of them exists, and you are welcome to check your schema changes with this script before pushing your schema or schema upgrade changes. The script is run upon rpm build time and the build fails if the check does not pass, so you really want to make sure you add all the necessary files. Thank you, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] New records get born in RHNDAEMONSTATE
On Tue, Jun 15, 2010 at 11:44:55AM -0400, Tomas Lestach wrote: Right, this approach is really not the best one. As this is a part of the taskomatic, I'll investigate it more in detail. I'd touch the code anyway. Not sure if somebody makes use out of the rhnDaemonState table content, but if not (what I suppose), I'd remove the table and the appropriate code. Tomáš, I've noticed that you've dropped the table for 1.3. However, doing git grep -i rhnDaemonState still shows it mentioned in the comments in multiple java/code/src/com/redhat/rhn/taskomatic/task/*.java files. Frankly, I'm a bit unsure that the comment refers to -- the whole class, the DISPLAY_NAME string, the getLogger ... Could you please look at it and clean it up or something? Thank you, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] spacewalk-setup does not work with local?
On Tue, Jan 18, 2011 at 08:22:17PM +0100, Luc de Louw wrote: On https://fedorahosted.org/spacewalk/wiki/PostgreSQL one reads: Hostname (leave empty for local)? With Spacewalk 1.2 leaving it empty was working, with Spacewalk 1.3 nightly it does not work anymore? Please define does not work. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Registering New Client on SW1.2 postgres
On Tue, Jan 11, 2011 at 01:04:23PM +0100, Jonathan Hoser wrote: Hi all, I've managed to get the kickstart-creation going on the SW1.2 postgres version, (and if told how, will gladly supply you the information of the changes) Just send the patches to this mailing list. Thanks! -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Package: spacewalk-schema-1.3.9-1.el6 Tag: dist-6E-sw-1.3-candidate Status: failed Built by: msuchy (fwd)
- Forwarded message from Spacewalk Koji Build System build...@koji.spacewalkproject.org - Date: Fri, 7 Jan 2011 20:48:32 + (UTC) Subject: Package: spacewalk-schema-1.3.9-1.el6 Tag: dist-6E-sw-1.3-candidate Status: failed Built by: msuchy Package: spacewalk-schema-1.3.9-1.el6 Tag: dist-6E-sw-1.3-candidate Status: failed Built by: msuchy ID: 20654 Started: Fri, 07 Jan 2011 20:46:24 UTC Finished: Fri, 07 Jan 2011 20:48:06 UTC spacewalk-schema-1.3.9-1.el6 (20654) failed on build3.spacewalkproject.org (noarch), build3.spacewalkproject.org (noarch): BuildError: error building package (arch noarch), mock exited with status 30; see root.log for more information I've now blocked spacewalk-schema from being built on RHEL 6. Please resolve the python-ply issue and the revert 9915a80abf22bc7566981ac34f7b757625453e04. By the way spacewalk-schema-1.3.8-1.el6 got built just fine in December and http://koji.spacewalkproject.org/packages/spacewalk-schema/1.3.8/1.el6/data/logs/noarch/root.log shows that python-ply got installed there alright. So something has changed recently. I might blame the changes done for spacewalk-java a bit. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Fwd: [Fedora Update] [comment] rhnlib-2.5.24-1.fc13
On Wed, Dec 22, 2010 at 09:52:01AM +0100, Miroslav Suchý wrote: FYI Original Message Subject: [Fedora Update] [comment] rhnlib-2.5.24-1.fc13 Date: Wed, 22 Dec 2010 00:07:00 + From: upda...@fedoraproject.org To: msu...@redhat.com The following comment has been added to the rhnlib-2.5.24-1.fc13 update: I've untagged rhnlib-2.5.24-1.fc13 from dist-f13-sw-1.3-candidate because having that as the latest build was confusing our build scripts -- it did not see the newest rhnlib-2.5.31-1.fc13 there and insisted on building it again and again. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] removal of /etc/rc.d/init.d/rhn-satellite
On Mon, Dec 13, 2010 at 03:57:50PM +0100, Miroslav Suchy wrote: We have in file: /etc/rc.d/init.d/rhn-satellite present only this warning: #!/bin/sh echo Warning: /etc/init.d/rhn-satellite is obsolete. echo Each service has its own init script now. echo The whole suite can be manipulated using command /usr/sbin/rhn-satellite instead. It is there since Spacewalk 0.5 (definitely from RHN Satellite 5.3). Is it time to completely remove it? Does somebody have objection? No objection here. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Two checkstyle issues in Spacewalk java code
On Tue, Dec 14, 2010 at 08:50:53AM +0100, Jan Pazdziora wrote: On Mon, Dec 13, 2010 at 02:53:08PM -0500, a...@redhat.com wrote: The first one is a pretty lengthy else if list building the Lucene query. Not much I can do without rewriting the whole method. My additions were only 4 lines at the end. The second fix has been committed. Thank you. I've bumped up the limit from 150 to 180 to address the other problem before the other guys decide what to do about the long method. Folks, where does the 150 line limit come from? I mean, why 150 and not 149 or 151? -- Jan Pazdziora | adelton at #satellite*, #brno Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Where have all the patches done?
Hello community members. When we've released Spacewalk 1.2 with basic yet functional PostgreSQL support two weeks ago, installable on all current Fedora versions and with detailed instructions how to address individual types of issues at https://fedorahosted.org/spacewalk/wiki/PostgreSQLPortingGuide and with documented process to migrate Oracle installation to PostgreSQL at https://fedorahosted.org/spacewalk/wiki/PostgreSQLFromOracle it was my hope that stream of patches will start flowing to spacewalk-de...@redhat.com. So far, it has not happened. Come on guys. If you keep the changes and fixes you do to your Spacewalk with PostgreSQL installations to yourself, they will not make it to the next Spacewalk release. And you will see the PostgreSQL effort go stale again. So please, post the patches. Thank you, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] spacewalk-nightly repo with broken dependency on RHEL5/CentOS5
On Sat, Nov 27, 2010 at 03:34:08PM +0100, Luc de Louw wrote: I just wanted to install the nightly build from koji, it failed... [r...@spacewalk-nightly ~]# yum install spacewalk-postgresql Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * addons: centos.de-mirror-server.de * base: centos.de-mirror-server.de * epel: mirrors.se.eu.kernel.org * extras: centos.de-mirror-server.de * updates: centos.de-mirror-server.de Setting up Install Process Resolving Dependencies -- Running transaction check [lot of stuff removed] rhn-client-tools-1.3.1-1.el5.noarch from spacewalk-client has depsolving problems -- Missing Dependency: python-ethtool = 0.4 is needed by package Mirek, you seem to have added this versioned Requires in commit c295d2f4387f76b3d7186a39a1cc04d9c7eccd09 Author: Miroslav Suchý msu...@redhat.com Date: Sat Nov 20 14:14:45 2010 +0100 655310 - send IPv6 addresses to server The package is in Fedoras ... but what was your plan for EL 5? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk 1.2 release candidate available
On Tue, Nov 16, 2010 at 10:56:35AM +0100, Sandro red Mathys wrote: On 11/15/2010 08:39 PM, Jan Pazdziora wrote: Hello, Spacewalk 1.2 release candidate yum repo is available at http://koji.spacewalkproject.org/spacewalk/split/spacewalk-5E/server/spacewalk-5E-1.2/$basearch/os http://koji.spacewalkproject.org/spacewalk/split/spacewalk-f12/server/spacewalk-f12-1.2/$basearch/os http://koji.spacewalkproject.org/spacewalk/split/spacewalk-f13/server/spacewalk-f13-1.2/$basearch/os http://koji.spacewalkproject.org/spacewalk/split/spacewalk-f14/server/spacewalk-f14-1.2/$basearch/os Use one of these baseurl's depending on your OS. Please help us verify bugzillas which are currently ON_QA and point out bugs which are not fixed and should be a blocker for Spacewalk 1.2 -- ideally with a patch. Would you call this a bug or normal? Updating : jabberd-selinux 39/122 /usr/sbin/semanage: Port tcp/5347 already defined Cosmetic issue, it does not affect the functionality. I have filed https://bugzilla.redhat.com/show_bug.cgi?id=530353 for this, and yes, we could do grep before running semanage port -a. I just did not bother to do it. Patches welcome. ;-) -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] git via ssh
On Thu, Nov 11, 2010 at 12:13:18PM -0700, Shelby, James wrote: Our firewall doesn't allow the git port going out and I've tried to clone the repository via http which doesn't seem to work all the time. I have the Fedora account and everything setup but do I need to be in the gitspacewalk group in order to clone the repository via ssh? Unfortunately, I don't think we are able to setup the access via ssh as read only. What problems exactly are you facing with the http access? Please open a ticket for fedora-infrastructure because I was under the impression that this should work for our git repo just as it works for other projects hosted at fedorahosted.org. Yours, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk 1.2 release candidate available
On Tue, Nov 16, 2010 at 11:04:08AM +, Jonathan Downward wrote: Hi All, Thanks for getting back to me with some answers. The issue shows itself as a crash of the spacewalk service when a user attempts to authenticate using LDAP. The website shows a 404 error and the entire service needs to be rebooted before we can continues. Application of oracle-lib-compat-10.2.0.25-1.el5.x86_64.rpm resolved the issue for me. Yep, we LD_PRELOAD the standard libldap in tomcat-setenv.sh and the fix will be in Spacewalk 1.2. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk 1.2 branched
On Tue, Nov 16, 2010 at 09:16:52PM +0800, Colin Coe wrote: Is there any chance http://git.fedorahosted.org/git/?p=spacewalk.git;a=commit;h=b856791ce8efe5225a7b6d47c4cc3c4a3543037b could make it into v1.2? This is inspired by https://www.redhat.com/archives/spacewalk-list/2010-November/msg00095.html which seems a great idea to me but the script directly accesses the backend which, I believe, runs contrary to the RHN Satellite license (when used with embedded Oracle). This patch will enable a small modification to the script attached to https://www.redhat.com/archives/spacewalk-list/2010-November/msg00095.html and avoid the above mentioned problem. No last minute additions / features please. We can always backport it from nightly if it turns out to be wanted / needed /etc. We are only in the release candidate stabilization phase. I've asked Tomáš to review the b856791ce8efe5 change because giving out any file on the filer seems like a security issue on first glance. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk 1.2 release candidate available
On Mon, Nov 15, 2010 at 08:56:15PM +0100, Sandro red Mathys wrote: On Mon, Nov 15, 2010 at 20:39, Jan Pazdziora jpazdzi...@redhat.com wrote: http://koji.spacewalkproject.org/spacewalk/split/spacewalk-5E/server/spacewalk-5E-1.2/$basearch/os http://koji.spacewalkproject.org/spacewalk/split/spacewalk-f12/server/spacewalk-f12-1.2/$basearch/os http://koji.spacewalkproject.org/spacewalk/split/spacewalk-f13/server/spacewalk-f13-1.2/$basearch/os http://koji.spacewalkproject.org/spacewalk/split/spacewalk-f14/server/spacewalk-f14-1.2/$basearch/os I would suggest dropping support for F12 as it's going EOL on 2010-12-02, i.e. in two and a half weeks. We will do 1.2 as the last release on F12. Instead, support for EL6 (at least clients) would be nice :) We won't be able to have everything set up and building for 1.2, especially with the Java stack dependencies, and we really want to get the release out sooner than later. The clients that are in RHEL 6 and its RHN Tools channels are fairly new and can be used with latest Spacewalks, so rebuilding just them wouldn't buy us much anyway. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] tanukiwrapper no longer in Fedora 14
On Fri, Nov 12, 2010 at 01:20:12PM +0100, Miroslav Suchý wrote: On 11/12/2010 11:41 AM, Jan Pazdziora wrote: Hello, so it looks like based on http://lists.fedoraproject.org/pipermail/devel/2010-August/142064.html the tanukiwrapper is no longer in Fedora 14. What is the most reasonable course of action for Spacewalk on Fedora 14? Do we want to just take tanukiwrapper-3.2.3-5.fc12 from Fedora 13 and import it to koji and throw it to Spacewalk yum repos? Do we have anybody who would be willing and able to take over the maintenance of tanukiwrapper in Fedora? Are there any alternatives (ideally in Fedora) we should be looking at? I will apply for the ownership. Unless somebody will come with alternative. Thanks. Since the package will have to go through review, we shall use the tanukiwrapper-3.2.3-5.fc12 for now. Jan, can you please import it to dist-f14-sw-1.2-candidate? -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Slipping the release some more
Folks, we seem to be having serious issues with our builder so I'm slipping the next release until at least the next week. Sorry about that, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Registration entitles ... but fails with str issue
Commit 335f140534de31335727ceb9ed18ad8b405bf638 fixes the error 31 -- the rhn_entitlements.can_entitle_server returned 1 in psql but via rhnSQL it was returning None. Currently rhnreg_ks fails with Error code: 1While running 'queue.get': caught exceptions.TypeError : unsupported operand type(s) for -: 'float' and 'str' which can also be triggered by rhn_check after registration. It comes from Traceback (most recent call last): File /usr/lib/python2.4/site-packages/spacewalk/server/apacheRequest.py, line 119, in call_function response = apply(func, params) File /usr/share/rhn/server/handlers/xmlrpc/queue.py, line 270, in get self.__update_status(status) File /usr/share/rhn/server/handlers/xmlrpc/queue.py, line 136, in __update_status if abs(last_boot-self.server.server[last_boot]) 60*5: TypeError: unsupported operand type(s) for -: 'float' and 'str' and from the fact that that self.server.server[last_boot] is a string '0'. The object self.server.server gets populated via backend/server/rhnHandler.py's server = rhnServer.get(system_id, load_user = self.load_user) which then seems to populate the data from rhnServer, and it puts string '0' into the object instead of 0, even if the type of the last_boot column is number. I wonder if something in that row populating code needs to be fixed to better understand PostgreSQL types ... -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Spacewalk on PostgreSQL: migrating existing Oracle installation
Hello, on page https://fedorahosted.org/spacewalk/wiki/PostgreSQLFromOracle you will find steps needed to turn your Spacewalk on Oracle installation to the one using the PostgreSQL database. The most important is obviously the dump of the data from Oracle and its import to the PostgreSQL database and there's nothing you couldn't figure out, but you still might want to walk through the whole document to see all the steps. Happy hacking, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Spacewalk on PostgreSQL port status
Folks, during the last three weeks, Lukáš and myself have been working on the Spacewalk on PostgreSQL port again a bit. It is still developers-only. Do not expect it to work without being ready to patch issues that you encounter. Even if it works for your use-case, do not expect to be able to upgrade the schema to newer versions. On the other hand, more things work than they used to, so if you are ready to hack, why not give it a try? You should be able to use the nightly repos to install Spacewalk on PostgreSQL on RHEL/CentOS 5 and Fedora 12 and 13, without needing any Oracle bits. You should be able to run spacewalk-setup, create the first user, log in, create channels and repositories and sync them, register systems with and without activation keys, view them on the WebUI. Yum and rhn_check operations will most probably not work yet, we are working on the repodata generation right now. Even for the things listed above as working, they are only working in the sense that we've managed to do through the process. If you put in different data, it might fail. If you use different parameters, it might fail. On the other hand, there are people who have used it and it did not fail for them. We now have a page https://fedorahosted.org/spacewalk/wiki/PostgreSQLPortingGuide which lists issues that we've met and how we've fixed the, so if you hit the same issue with WebUI or with anything, maybe it will be easy for you to fix it and send in patch? Patches really welcome. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Spacewalk on PostgreSQL: empty string
When fixing issues on PostgreSQL installation, one problem that you might hit quite often is the different semantics that an empty string has in Oracle vs. in PostgreSQL. In Oracle, when you insert empty string, it gets converted to NULL automatically. So the sequence insert into tab (id, name) values (:id, ''); select from tab where name is null; works in Oracle while in PostgreSQL the empty string is stored, so select from tab where name = '' is needed. To catch this situation right where it originates (the first insert of the empty string), all varchar column in the PostgreSQL schema have constraints (created by schema/spacewalk/postgres/end.sql) that prevent setting the value to empty string. Which would force us to fix any code to insert NULLs, not empty string. Please see more at: https://fedorahosted.org/spacewalk/wiki/PostgreSQLPortingGuide#empty_string_null -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] java/code: Fix checkstyle errors
On Thu, Oct 21, 2010 at 07:09:50PM +, Colin Coe wrote: java/code/src/com/redhat/rhn/common/conf/ConfigDefaults.java | 24 +++ 1 file changed, 24 insertions(+) New commits: commit dfbcc4fb8f65b6f2ac6c0a0358e50c6084d46738 Author: Colin Coe colin@gmail.com Date: Fri Oct 22 03:07:52 2010 +0800 Fix checkstyle errors Colin, thanks for the fix. The spacewalk-java now built alright: http://koji.spacewalkproject.org/koji/buildinfo?buildID=19358 -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Changes to 'debian'
On Mon, Oct 18, 2010 at 08:14:16PM +, Miroslav Suchý wrote: New branch 'debian' available with the following commits: Why separate branch and why not master? commit e32d9f14749fa3b406bb9d7ef89e77c70c763402 Author: Miroslav Suchý msu...@redhat.com Date: Mon Oct 18 22:12:52 2010 +0200 add python-ethtool-0.5 package commit f1afa2871a326edb8ac62f8a9cb0ff7a04e10f55 Author: Miroslav Suchý msu...@redhat.com Date: Mon Oct 18 22:09:40 2010 +0200 add manual how to build debian packages commit 39502f523d4d8240566b17b9a4893d3696e369d9 Author: Miroslav Suchý msu...@redhat.com Date: Mon Oct 18 21:58:08 2010 +0200 add debian control files for python-rhnlib -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] quartz-oracle removed, no PostgreSQL equivalent
Hello, it looks like the quartz-oracle package requires ojdbc14 which is provided by oracle-lib-compat, which in turn requires oracle-instantclient-basic. So having quartz-oracle is a blocker in our goal to be able to install Spacewalk on PostgreSQL. I've now moved the Requires from spacewalk-taskomatic to spacewalk-oracle, so that it only gets installed on Oracle installations. Alas, I don't see quartz-postgresql or similar package to add to spacewalk-postgresql. Whoever is the most fluent with quartz: could you please build new quartz package with PostgreSQL subpackage and add it to spacewalk-postgresql? Thank you, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] The nutch package
Hello, the nutch-1.0-0.6.20081201040121nightly.el5 package that we have in our Spacewalk repo seems to have *a lot* of stuff in it that I believe is not strictly necessary for it to operate correctly -- documentation, .jars of various other projects, sources. Could someone please look at the package and remove any cruft that is not needed (.jars, sources), and/or split them out to some subpackages (docs), so that we minimize the size of the package? Thank you, -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PATCH: make NVL work in PostgreSQL
On Mon, Oct 04, 2010 at 11:12:37AM -0400, Tom Lane wrote: I'm affraid we cannot just use = here: I think $1 is not distinct from $2 would be more appropriate, if you Right. Except, that will not work in Oracle, so we couldn't use one syntax for both. expect the null, null, x, y case to work like that. Also, a possibly bigger issue is that this formulation of decode() requires all four inputs to be of the same data type. Logically it would be sufficient for the first two to be of one type and the second two of some other type --- but I don't know whether Oracle works that way, or whether there are any places in Spacewalk that care. I prefer not to do the decode compatibility function in PostgreSQL for now and see if we can manage to just rewrite the decode to case when ... then ... end blocks -- that should give us code which runs both on Oracle and PostgreSQL. If that proves too hard, we can always add the decode later. +create or replace +function nvl(input integer, replace_with integer) returns integer +as $$ +SELECT COALESCE(NULLIF($1,0), $2); +$$ +LANGUAGE SQL; I'm affraid the nullif is not correct here: I think that nvl is just equivalent to coalesce($1,$2), no? Also Yes, that's what I've tried to say. Of course, for varchars we needed that check for empty string to be compatible with the use of nvl in our code, but for other types it should be just plain coalesce. I'd be inclined to declare the arguments and results as anyelement rather than hard-wiring them to integer. Nod. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PATCH: make NVL work in PostgreSQL
On Tue, Aug 10, 2010 at 08:31:19PM +0800, Colin Coe wrote: Hi all Attached is a patch that makes the NVL errors GoAway(tm). Pushed, thanks. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] PATCH: make NVL work in PostgreSQL
On Tue, Aug 10, 2010 at 09:12:07PM +0800, Colin Coe wrote: + +create or replace +function decode(value anyelement, s1 anyelement, r1 anyelement, def anyelement) returns anyelement +as +$$ +select case + when +$1=$2 + then +$3 + else +$4 +end; +$$ +LANGUAGE SQL; I'm affraid we cannot just use = here: SQL select decode(null, null, 3, 4) from dual ; DECODE(NULL,NULL,3,4) - 3 spaceschema=# select decode(null, null, 3, 4) from dual ; decode 4 (1 row) +create or replace +function nvl(input integer, replace_with integer) returns integer +as $$ +SELECT COALESCE(NULLIF($1,0), $2); +$$ +LANGUAGE SQL; I'm affraid the nullif is not correct here: SQL select nvl(0, 123) from dual ; NVL(0,123) -- 0 spaceschema=# select nvl(0, 123) from dual ; nvl - 123 (1 row) So I'm not committing these two changes yet. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
