Re: [Spacewalk-devel] [PATCH] New global configuration table, to store default organization for externally authenticated users.
On Thu, Jan 16, 2014 at 10:29:12AM -0500, Tomas Lestach wrote: we decided to store the global configuration in a different way. See the rhnConfiguration table. OK. Wouldn't it be better thou if its definition was under schema/spacewalk/common/tables? I applied your 2nd patch as: 6406c9ce65b8d68ba86cca50955b1cca01219597 Thank you, -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] [PATCH] New global configuration table, to store default organization for externally authenticated users.
Hello, please consider the attached patch which creates new global rhnConfiguration table (to avoid adding more confiugration options to /etc/rhn/rhn.conf) to be able to define which organization externally-authenticated users should be created in. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From cd652fd1045aa2c4f3e5a4219a7bff4421ff7083 Mon Sep 17 00:00:00 2001 From: Jan Pazdziora jpazdzi...@redhat.com Date: Mon, 13 Jan 2014 17:29:45 +0800 Subject: [PATCH] New global configuration table, to store default organization for externally authenticated users. --- schema/spacewalk/common/rhnConfiguration.sql | 35 ++ .../spacewalk/oracle/triggers/rhnConfiguration.sql | 24 +++ .../postgres/triggers/rhnConfiguration.sql | 29 ++ .../040-rhnConfiguration.sql | 35 ++ .../041-rhnConfiguration-trigger.sql.oracle| 24 +++ .../041-rhnConfiguration-trigger.sql.postgresql| 29 ++ 6 files changed, 176 insertions(+) create mode 100644 schema/spacewalk/common/rhnConfiguration.sql create mode 100644 schema/spacewalk/oracle/triggers/rhnConfiguration.sql create mode 100644 schema/spacewalk/postgres/triggers/rhnConfiguration.sql create mode 100644 schema/spacewalk/upgrade/spacewalk-schema-2.0-to-spacewalk-schema-2.1/040-rhnConfiguration.sql create mode 100644 schema/spacewalk/upgrade/spacewalk-schema-2.0-to-spacewalk-schema-2.1/041-rhnConfiguration-trigger.sql.oracle create mode 100644 schema/spacewalk/upgrade/spacewalk-schema-2.0-to-spacewalk-schema-2.1/041-rhnConfiguration-trigger.sql.postgresql diff --git a/schema/spacewalk/common/rhnConfiguration.sql b/schema/spacewalk/common/rhnConfiguration.sql new file mode 100644 index 000..0b1731f --- /dev/null +++ b/schema/spacewalk/common/rhnConfiguration.sql @@ -0,0 +1,35 @@ +-- +-- Copyright (c) 2014 Red Hat, Inc. +-- +-- This software is licensed to you under the GNU General Public License, +-- version 2 (GPLv2). There is NO WARRANTY for this software, express or +-- implied, including the implied warranties of MERCHANTABILITY or FITNESS +-- FOR A PARTICULAR PURPOSE. You should have received a copy of GPLv2 +-- along with this software; if not, see +-- http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt. +-- +-- Red Hat trademarks are not licensed under GPLv2. No permission is +-- granted to use or replicate Red Hat trademarks that are incorporated +-- in this software or its documentation. +-- + +create table rhnOrgConfiguration +( +id number not null + default (42) not null + check(id = 42), +default_ext_customer_id number + constraint rhn_conf_default_org_id_fk + references web_customer(id) + on delete cascade, +createdtimestamp with local time zone + default (current_timestamp) not null, +modified timestamp with local time zone + default (current_timestamp) not null +) +enable row movement +; + +create unique index rhn_conf_id +on rhnConfiguration (id) +tablespace [[8m_tbs]]; diff --git a/schema/spacewalk/oracle/triggers/rhnConfiguration.sql b/schema/spacewalk/oracle/triggers/rhnConfiguration.sql new file mode 100644 index 000..538c6d1 --- /dev/null +++ b/schema/spacewalk/oracle/triggers/rhnConfiguration.sql @@ -0,0 +1,24 @@ +-- +-- Copyright (c) 2014 Red Hat, Inc. +-- +-- This software is licensed to you under the GNU General Public License, +-- version 2 (GPLv2). There is NO WARRANTY for this software, express or +-- implied, including the implied warranties of MERCHANTABILITY or FITNESS +-- FOR A PARTICULAR PURPOSE. You should have received a copy of GPLv2 +-- along with this software; if not, see +-- http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt. +-- +-- Red Hat trademarks are not licensed under GPLv2. No permission is +-- granted to use or replicate Red Hat trademarks that are incorporated +-- in this software or its documentation. +-- + +create or replace trigger +rhn_conf_mod_trig +before insert or update on rhnConfiguration +for each row +begin +:new.modified := current_timestamp; +end; +/ +show errors diff --git a/schema/spacewalk/postgres/triggers/rhnConfiguration.sql b/schema/spacewalk/postgres/triggers/rhnConfiguration.sql new file mode 100644 index 000..b7c6b91 --- /dev/null +++ b/schema/spacewalk/postgres/triggers/rhnConfiguration.sql @@ -0,0 +1,29 @@ +-- oracle equivalent source sha1 ebf4903b278ce8c8315da67743451186fb9b8b7a +-- +-- Copyright (c) 2014 Red Hat, Inc. +-- +-- This software is licensed to you under the GNU General Public License, +-- version 2 (GPLv2). There is NO WARRANTY for this software, express
Re: [Spacewalk-devel] [PATCH] New global configuration table, to store default organization for externally authenticated users.
On Mon, Jan 13, 2014 at 05:36:16PM +0800, Jan Pazdziora wrote: please consider the attached patch which creates new global rhnConfiguration table (to avoid adding more confiugration options to /etc/rhn/rhn.conf) to be able to define which organization externally-authenticated users should be created in. I'll do another attempt of making a patch which actually makes sense. Also included are two new tables for mapping external groups to Spacewalk's local permissions/roles. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From aff19c2fd86a95a4804b8e5e5fa71d531b4ba9c6 Mon Sep 17 00:00:00 2001 From: Jan Pazdziora jpazdzi...@redhat.com Date: Mon, 13 Jan 2014 17:29:45 +0800 Subject: [PATCH 1/2] New global configuration table, to store default organization for externally authenticated users. --- .../spacewalk/common/tables/rhnConfiguration.sql | 34 ++ schema/spacewalk/common/tables/tables.deps | 1 + .../spacewalk/oracle/triggers/rhnConfiguration.sql | 24 +++ .../postgres/triggers/rhnConfiguration.sql | 29 ++ .../040-rhnConfiguration.sql | 34 ++ .../041-rhnConfiguration-trigger.sql.oracle| 24 +++ .../041-rhnConfiguration-trigger.sql.postgresql| 29 ++ 7 files changed, 175 insertions(+) create mode 100644 schema/spacewalk/common/tables/rhnConfiguration.sql create mode 100644 schema/spacewalk/oracle/triggers/rhnConfiguration.sql create mode 100644 schema/spacewalk/postgres/triggers/rhnConfiguration.sql create mode 100644 schema/spacewalk/upgrade/spacewalk-schema-2.0-to-spacewalk-schema-2.1/040-rhnConfiguration.sql create mode 100644 schema/spacewalk/upgrade/spacewalk-schema-2.0-to-spacewalk-schema-2.1/041-rhnConfiguration-trigger.sql.oracle create mode 100644 schema/spacewalk/upgrade/spacewalk-schema-2.0-to-spacewalk-schema-2.1/041-rhnConfiguration-trigger.sql.postgresql diff --git a/schema/spacewalk/common/tables/rhnConfiguration.sql b/schema/spacewalk/common/tables/rhnConfiguration.sql new file mode 100644 index 000..aba0c21 --- /dev/null +++ b/schema/spacewalk/common/tables/rhnConfiguration.sql @@ -0,0 +1,34 @@ +-- +-- Copyright (c) 2014 Red Hat, Inc. +-- +-- This software is licensed to you under the GNU General Public License, +-- version 2 (GPLv2). There is NO WARRANTY for this software, express or +-- implied, including the implied warranties of MERCHANTABILITY or FITNESS +-- FOR A PARTICULAR PURPOSE. You should have received a copy of GPLv2 +-- along with this software; if not, see +-- http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt. +-- +-- Red Hat trademarks are not licensed under GPLv2. No permission is +-- granted to use or replicate Red Hat trademarks that are incorporated +-- in this software or its documentation. +-- + +create table rhnConfiguration +( +id number default (42) not null + constraint rhn_conf_single_rec_ck check(id = 42), +default_ext_customer_id number + constraint rhn_conf_default_org_id_fk + references web_customer(id) + on delete cascade, +createdtimestamp with local time zone + default (current_timestamp) not null, +modified timestamp with local time zone + default (current_timestamp) not null +) +enable row movement +; + +create unique index rhn_conf_id +on rhnConfiguration (id) +tablespace [[8m_tbs]]; diff --git a/schema/spacewalk/common/tables/tables.deps b/schema/spacewalk/common/tables/tables.deps index 4125c6e..8baf543 100644 --- a/schema/spacewalk/common/tables/tables.deps +++ b/schema/spacewalk/common/tables/tables.deps @@ -63,6 +63,7 @@ rhnConfigFile :: rhnConfigChannel rhnConfigFileState rhnConfigF rhnConfigFile_foreignkeys :: rhnConfigRevision rhnConfigChannel :: web_customer rhnConfigChannelType rhnConfigRevision :: rhnConfigFile rhnConfigInfo rhnConfigContent rhnConfigFileType +rhnConfiguration :: web_customer rhnCpu :: rhnServer rhnCpuArch rhnCryptoKey :: rhnCryptoKeyType rhnCryptoKeyKickstart :: rhnCryptoKey rhnKSData diff --git a/schema/spacewalk/oracle/triggers/rhnConfiguration.sql b/schema/spacewalk/oracle/triggers/rhnConfiguration.sql new file mode 100644 index 000..538c6d1 --- /dev/null +++ b/schema/spacewalk/oracle/triggers/rhnConfiguration.sql @@ -0,0 +1,24 @@ +-- +-- Copyright (c) 2014 Red Hat, Inc. +-- +-- This software is licensed to you under the GNU General Public License, +-- version 2 (GPLv2). There is NO WARRANTY for this software, express or +-- implied, including the implied warranties of MERCHANTABILITY or FITNESS
Re: [Spacewalk-devel] [RFC] showing timestamps in Spacewalk
On Tue, Dec 17, 2013 at 03:46:22AM -0500, Tomas Lestach wrote: What I think to be great to have are options: * timestamp according to locales * 2013-12-31 as this is a format, that everybody understands * simple parsing of d(d) m(m) yy(yy), their order and separator Don't forget am/pm vs. 24 hr thing. I agree. Support the default locale thing plus a bunch of reasonable formats to choose from. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [RFC] showing timestamps in Spacewalk
On Fri, Dec 06, 2013 at 11:14:13AM +0100, Duncan Mac-Vicar P. wrote: While fixing glitches after the big merge, I have been looking for other details that could make the user interface easier to the eyes. One thing that immediately caught my attention was the amount of timestamps we show in the user interface. Stuff like 15/10/13 08:13:33 EDT. In most cases you don't care for that level of detail, and IMHO such level of detail makes you ignore parsing it with your eyes and ignoring it completely. Most modern websites use a human relative time that attracts the eyes. Is my server out of date since today, last week or a month?... after you processed that you may need the details. So I implemented this. Details, screen-shots are here. https://fedorahosted.org/spacewalk/wiki/User/Dmacvicar/HumanDates (and code attached) Nice idea. There is a problem with the general inconsistency of the date/time displays, and part of it stems from the fact that Java does it differently than Perl. What is the proposal for the Perl side of the code base? If there is going to be some mass deployment of the new tags, it would be good to make it a full audit of the time formatting usage and do it everywhere. And of course -- there may be people who prefer the exact dates/times to be shown so this really should be configurable. For new deployment/users, I assume the new behaviour would be fine but for existing users, we might want to preserve the existing behaviour, and let the users change it manually. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] pltcl question
important. ;-) - patching pltcl stored procedures so that they never assume a global has been initialized. The fact that the global variables are not initialized means that the user of the database (the applications) broke the contract which states that they should provide the auth logging information before doing anything with the database session because *any* database table can have logging enabled and need that information. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] pltcl question
On Wed, Sep 11, 2013 at 11:20:15AM -0400, Stephen Herr wrote: Normally the case yes, but there are at least a couple of instances where we commit a single request as multiple transactions to avoid overrunning Oracle's rollback buffer. One example that jumps to mind is generating yum repodata for channels. I'm not sure if that's relevant to this discussion or not, I just saw that comment and thought I'd chime in. These situations really should be checked. We probably don't see problems now because the tables manipulated by the yum repodata generation do not have logging enabled, but eventually there could be a problem. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Avoid a possible concurrency issue on RhnSet update
On Wed, Sep 04, 2013 at 08:35:27AM +0200, Silvio Moioli wrote: On 09/03/2013 02:33 PM, Tomas Lestach wrote: to be honest, I personally do not like seeing DB index names in the application code. I agree that it is not really an elegant solution, but I could not find another way of ignoring such specific exceptions. Ideas welcome :-) You can do a select after that exception to see if the record in the database is what you intended it to be. If it is (and you got an exception in your session), you can assume it was the other session which set it up. You don't really care if the operation in your session suceeded -- you care about the result. Of course, whether and how this will work with some application sessions (hibernate?), I can't really say. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Avoid a possible concurrency issue on RhnSet update
On Wed, Sep 04, 2013 at 08:35:27AM +0200, Silvio Moioli wrote: That would mean saving snapshot IDs between HTTP requests. Again, doable, but sounds quite difficult at least to me! Yet another possibility would be to INSERT only tuples not already present by set difference, something like this query: INSERT INTO rhnset (user_id, label, element, element_two, element_three) SELECT :user_id, :label, :element, :element_two, :element_three FROM dual WHERE (:user_id, :label, :element, :element_two, :element_three) NOT IN ( SELECT * FROM rhnset ) Is that better in your opinion? Please note that this will not work -- the fact that you check content of some table in your session and your transaction and based on that run the insert operation does not mean that the other session cannot do exactly the same, both will find the record not there, and you will get the ORA-1 anyway. The only viable approach is to accept that the same operations will happen, and either losen the unique constraint requirement, or handle the exceptions which will from time to time happen. Or just live with the fact that in some scenarios, the failures will occur. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] upstreaming some of our .spec file changes
On Tue, Aug 06, 2013 at 05:28:09PM -0600, Lamont Peterson wrote: [snip] Well, discussions about renaming all tools and packages to spacewalk- something pop up from time to time for many years ;). Althought we mostly agree with renaming comandline tools (assuming that old names will remain at least as symlinks for compatibility reasons) we've decided not to rename rpm packages because it will make upgrades much complicated. How so? You simply Obsoletes: the old package name with the new one. You can even drop the Obsoletes: from the SPEC file after a time. Except you won't see that package as a suggested errata in RHN or Spacewalk because, well, it's a different package. So it will work by replacing the original package correctly but you will have harder time making the new package be included in the transaction. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] SSH Push Feature Proposal
On Tue, Apr 30, 2013 at 04:08:54PM +0200, Duncan Mac-Vicar P. wrote: On 24/04/13 14:38, Johannes Renner wrote: Can the logic you propose to be put to taskomatic be put to osa-dispatcher, to throttle the number of clients which get invited to rhn_check? Doesn't osad work by having the clients connect via XMPP _to_ the server? Sure. But they just connect and then wait for osa-dispatcher to tell them to run rhn_check. -- 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] SSH Push Feature Proposal
and if there is a way to compromise that server that way, it will happen. I would still need to check the patches in details to see how you solve the problem of the client IP addresses as seen by the Spacewalk server being 127.0.0.1 for all those requests which is hardly something you'd like to see in production. You propose new scheduling service in taskomatic to initiate the SSH Push for client ... but we already have such a functionality, it's osa-dispatcher. So either we should get rid of osa-dispatcher and do even the jabber/osad based notifications from taskomatic, or we should stick with osa-dispatcher and not create very similar solution in Java. The second scenario is however much more important and interesting -- yes, the server will get overloaded if you use many osad-enabled clients, and we had Spacewalk users complaining about this on the mailing list in the past. However, is the cure really to allow ssh access from server to the clients? How about clients that are behind NAT, roaming, or in general unavailable? I would assume that the majority of the Spacewalk (and downstream products') installations has server accessible from clients because otherwise things would currently not work. If you completely reverse the style of operation, it will cause the disruption in our users' setups. And still, clients for which you won't be able or willing to enable the SSH Push functionality will not get the improvement in timely actions that don't put the server to its knees. I would very much love to see improvements to the second problem which could be used by all *existing* clients of Spacewalk, even those that are behind NAT, independed from the SSH Push feature. Can the logic you propose to be put to taskomatic be put to osa-dispatcher, to throttle the number of clients which get invited to rhn_check? Can we move the osad functionality (which we use purely for notification) to rhnsd and maybe have rhnsd keep connection open (WebSockets, maybe?) so that the server can wake the clients up in timely (yet well managed) fashion? I'd be interested to hear your thoughts, -- 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] L10N : translation of spacewalk java frontend blocked on Transifex
On Thu, Mar 28, 2013 at 10:01:33AM +0100, Jérôme Fenal wrote: Updates to the xliff file seem to be pushed to Transifex, can we give it a try, without pulling the translated strings for now? I've not pushed out resources https://fedora.transifex.com/projects/p/spacewalk/resource/java_java/ https://fedora.transifex.com/projects/p/spacewalk/resource/java_jsp/ 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] Kickstartable channels should contain the anaconda package
On Thu, Apr 04, 2013 at 05:44:09PM +0200, Johannes Renner wrote: Can you elaborate on the purpose of this change in general? The current code uses the Channel.kickstartableChannels query everywhere (via getKickstartableChannels). The patch seems to change the semantics for all getKickstartableChannels(org) invocations. What is the purpose? Why should all the other invocations start to care about anaconda? Sure, the problem is with the create a new kickstart profile wizard that can be found if you navigate to Systems - Kickstart. The first step of this wizard lets you decide on a base channel for the profile, where the above query is used to determine the candidates. SUSE channels should *not* be listed here, since it is not possible to have a kickstart profile with a SUSE base channel. This leads to the conclusion that only those channels should be listed, that actually support kickstarts (- kickstartable). As far as we know, Anaconda is the package that should make a channel kickstartable, since the whole kickstarting seems to be implemented in there, right? It's different though with the kickstart distributions. If you go there and click create new distribution, you want to have those SUSE channels listed a well. Distributions can be used with kickstart *as well as* with autoyast profiles! That's why we would need to return the unfiltered list here. We named this superset autoinstallable channels. All other invocations should be expecting kickstartable channels only. Hmm, I wonder if the current logic is actually correct. It feel that a kickstartable channel (for the purpose of creating kickstart profile, for example) would be channel that has at least one kickstartable tree, or channel cloned from one that has the tree. Which is not a logic I can see in Channel.kickstartableChannels. If we changed the logic this way, that would work for SUSE as well, right? I'd much prefer to do it this way than hardcoding yet another name of package to the code base. Of course, creating new distribution should basically be allowed for any parent channel, it would seem. I don't think there is actually logic implemented that would produce any kind of overhead. It's all in the database as you can see if you look at the used query (in Channel_queries.xml) latest_package_equal. Also I saw in another place that looking up a package was done like this, so this method appeared to be easier than anything else. It can be changed of course, if you want. I agree that we don't need the latest version of a package, but it looks like as soon as there is a record in the table rhnChannelNewestPackage, we can assume this package is contained in the channel. Fair enough. -- 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] Kickstartable channels should contain the anaconda package
On Thu, Apr 04, 2013 at 03:37:07PM +0200, Johannes Renner wrote: On 03/22/2013 02:55 PM, Michael Calmer wrote: Hi, please do not apply these patches. I found out, that it is not correct. It removes the channels at more places than needed. I guess the initial patch would be fine, as long as we add some additional small fixes on top. Here is another single patch containing everything. Basically what we are doing is to distinguish between kickstartable and autoinstallable channels. It would be really helpful though to get some feedback from you about using the anaconda package as a filter criteria. Can you elaborate on the purpose of this change in general? The current code uses the Channel.kickstartableChannels query everywhere (via getKickstartableChannels). The patch seems to change the semantics for all getKickstartableChannels(org) invocations. What is the purpose? Why should all the other invocations start to care about anaconda? Also, I'm not sure about the use of ChannelManager.listLatestPackagesEqual here -- we don't care about the latest at all, do we? The thing is happy about any package it finds so the best way is to just check for existence, without any newest computation 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] application-wide caching facility?
On Fri, Mar 22, 2013 at 10:12:46AM +0100, Duncan Mac-Vicar P. wrote: I gave it a second round to my patch that improves the channel status. Right now part of the status is calculated with queries to the job history, but the metadata generation leaves no traces on the queue. I could enhance the schema to insert a flag when an exception is thrown, but this is overkill, as I don't need this data to survive reboots. If the latest status is lost is harmless. Not sure what the data would be about. You have the channel repodata generation status, right? I believe we compare the modified timestamp of the channel (or channel package mapping?) to the mtime of the file on disk. Why isn't that enough? In other stacks I would use something like redis for this. A key/value store that can be configured in-memory or with very basic persistence, and accessible from all the components (webapp, taskomatic, python, etc). Do we have something like this already? Any other way of achieving the same? Would adding something like redis to the infrastructure would be desired? I don't see benefit for that. We have simple key/value caching store in /var/cache/rhn/ -- the key is the filename, the value is its content. For persistent data we have the database. -- 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] We now run spacewalk-oracle2postgresql for upgrade scripts as well
Hello, I've pushed a change to Spacewalk master which calls the spacewalk-oracle2postgresql script to generate PostgreSQL specific variants from the original .sql schema upgrade scripts. It means that for stuff like CREATE TABLE files in common/tables that are processed using spacewalk-oracle2postgresql for the main schema definition, you can just copy them to the respective upgrade subdirectory and you no longer need to create .oracle and .postgresql variants -- they will be created upon build time. On the other hand, anything more complex still needs separate .oracle and .postgresql files. Most notable are ALTER COLUMN upgrades -- this syntax is not supported by the conversion script at this point ... but you are welcome to amend the script and then just plain .sql should work 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 native kvm images in SUSE Studio integration
On Wed, Feb 06, 2013 at 04:43:15PM +0100, Johannes Renner wrote: Attached please find two patches enhancing the integration with SUSE Studio. They introduced a new image format last year that we are supporting now (native KVM, i.e. qcow2). See here: Pushed to Spacewalk master, 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] Future of Spacewalk/Satellite
On Wed, Feb 06, 2013 at 12:30:19PM -0500, Edson Manners wrote: All, I've been working on setting up our High Performance Computing (HPC) shop for full Satellite/puppet baremetal provisioning. Since we only have one satellite license I did all of my intial testing on spacewalk using centos and quickly got my kickstarted machines registered in the spacewalk server and handed off to puppet. With the proof of concept in place I've started to do the same in RH Satellite 5.5. however it seems like the version of cobbler that Satellite 5.5 needs does not play well with puppet. Specifically cobbler 2.1 does not support the puppet stanza remove_old_puppet_certs_automatically. This made me start looking around online for a newer version of satellite or anyone who got the actual RH Satellite to work with puppet. This is where I found RH Cloud Forms. So my question for the spacewalk devels is this, if Spacewalk supports puppet integration and satellite does not, and cloud forms is a total rewrite of a RH systems management solution. How does the work being done in spacewalk get ported into satellite? And more generally then what is All recent Satellite release is a rebase on some Spacewalk version. However, due to some issues with cobbler, the cobbler version stays on 2.0 in Satellite. I suggest you talk to your Red Hat support representative about the remove_old_puppet_certs_automatically issue so that it can be tracked by Satellite product management properly. -- 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] Our modified columns don't seem to get modified enough
I have created new repo in the WebUI spaceschema=# select * from rhncontentsource ; id | org_id | type_id | source_url | label |created | modified -++-+--+---+---+--- 500 | 1 | 500 | http://jezek | jezek | 2013-01-17 13:38:30.632011-05 | 2013-01-17 13:38:30.632011-05 (1 row) and then I've updated the URL in the WebUI spaceschema=# select * from rhncontentsource ; id | org_id | type_id | source_url | label |created | modified -++-+---+---+---+--- 500 | 1 | 500 | http://jezek/ | jezek | 2013-01-17 13:38:30.632011-05 | 2013-01-17 13:38:30.632011-05 (1 row) The modified column did not get modified. The definition of that table is created timestamp with local time zone default(current_timestamp) NOT NULL, modifiedtimestamp with local time zone default(current_timestamp) NOT NULL and there are no triggers which would force the modified to now(). I believe this is not the only table having the same issue. If the table is only modified from Java via hibernate, we might be able to address the issue there. On the other hand, we better have a solution which works beyond hibernate. Is this an issue we want to address, somehow? -- 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#836984 - fixes the permissions on /var/log/osad log file
On Fri, Dec 07, 2012 at 04:26:49PM -0200, Marcelo Moreira de Mello wrote: On 12/07/2012 05:20 AM, Jan Pazdziora wrote: Hello Folks, Here follow a better looking patch. Please, ignore the previous one. [...] try: -file = open( Logger.logfile, 'a' ) -os.chmod(Logger.logfile, 0600) -file.write( outstring ) -file.close() +fd = os.open(Logger.logfile, os.O_APPEND | os.O_RDWR | os.O_CREAT, 0600) +os.write(fd, outstring) +os.close() Either patch will fail with TypeError: close() takes exactly 1 argument (0 given) Hello Jan, Thanks for heads up. Follow attached an updated version. Pushed to Spacewalk master. 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] update uptime quickly after reboot
On Fri, Oct 19, 2012 at 01:25:31PM +0200, Michael Calmer wrote: Hi, with the new reboot needed feature introduced some month ago, we realized a small issue. If a patch or package was installed which requires a reboot, the system got the yellow banner on the systems details page. If now a reboot is executed and you look at the page again shortly after the host is up, the banner is still there. The reason is, that the uptime value is updated with first invocation of rhn_check which happen in the default config of rhnsd between 2 and 6 hours after rhnsd is started or in case of osad running when the first action is scheduled. Michael, I'm sorry I only now got to your post. I have a question here -- I assume the banner is there simply because the system needs reboot condition is based on the rhnServer.last_boot value, being compared to the package installation time. And until the server tells Spacewalk it has rebooted, Spacewalk assumes it has not. However, cannot the criteria for system needing reboot be amended by also looking at the system's actions, checking if there is a reboot.reboot action which was picked up after the package installation date / package installation action pickup? That way the feature would be purely server-based and work well even with old production clients, and the client parts would be an enhancement of the logic, not a mandatory part of the setup. -- 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.8 has been released
Hello everyone, your wait is now over as we are announcing the release 1.8 of Spacewalk, a systems management solution. The download locations are * http://yum.spacewalkproject.org/1.8/RHEL/5/$basearch/ * http://yum.spacewalkproject.org/1.8/RHEL/6/$basearch/ * http://yum.spacewalkproject.org/1.8/Fedora/16/x86_64/ * http://yum.spacewalkproject.org/1.8/Fedora/17/x86_64/ with client repositories under * http://yum.spacewalkproject.org/1.8-client * http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/1.8/openSUSE_12.1/ * http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/1.8/openSUSE_12.2/ * http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/1.8/openSUSE_Factory/ For fresh installations, please use steps from * https://fedorahosted.org/spacewalk/wiki/HowToInstall If you plan to upgrade from older release, search no more -- the following page will guide you: * http://fedorahosted.org/spacewalk/wiki/HowToUpgrade Features Enhancements in Spacewalk 1.8 * Spacewalk runs on Fedora 17 * Spacewalk can be run on the same machine as Oracle XE 11g * OpenSCAP functionality extended * osa-dispatcher is now systemd service in Fedora * Server-side support for registering ARM clients * Integration with SUSE Studio * Basic ABRT notification * Distribution-channel mapping can be customized per organization * Systems requiring reboot view * Extra packages view * spacewalk-repo-sync now downloads comps information, enabling yum group operations * WebUI and usability improvements * PostgreSQL improvements * Cobbler 2.0 now packaged in Spacewalk repos * Archived actions now can be deleted * Modified API calls: * configchannel.createOrUpdatePath now accepts also binary attribute and has fixed handling of binary files * configchannel.lookupFileInfo and system.getScriptResults now returns base64 encoded content for binary files * system.scap.scheduleXccdfScan can be scheduled for multiple servers and with timestamp to fire the scan * system.provisionVirtualGuest accepts MAC address parameter * New API calls: * channel.software.addRepoFilter, .setRepoFilters, .clearRepoFilters, .removeRepoFilter, .listRepoFilters * errata.cloneAsOriginalAsync, errata.cloneAsync * kickstart.profile.getCfgPreservation, kickstart.profile.setCfgPreservation * schedule.deleteActions * system.scap.listXccdfScans, system.scap.getXccdfScanDetails, system.scap.getXccdfScanRuleResults * system.listSystemsWithExtraPackages, system.listExtraPackages, system.listActiveSystemsDetails * distchannel.listMapsForOrg, distchannel.setMapForOrg * We parted with API call: * distchannel.setDefaultMap The up-to-date API documentation can be found at http://www.spacewalkproject.org/documentation/api/ Contributors Our thanks go to the community members who contributed to this release: Aron Parsons Duncan Mac-Vicar Gael Chamoulaud Joerg Steffens Johannes Renner Jonathan Hoser Joshua Roys Michael Calmer Nigel Jones Paresh Mutha Pierre Casenove Richard Marko Stefan Meyer Steven Hardy Tasos Papaioannou Uwe Gansert William van de Velde https://fedorahosted.org/spacewalk/wiki/ContributorList Some statistics In Spacewalk 1.8, we've seen 258 bugs fixed 1799 changesets committed 2506 commits done User community, reporting issues To reach the user community with questions and ideas, please use mailing list spacewalk-l...@redhat.com. On this list, you can of course also discuss issues you might find when installing or using Spacewalk, but please do not be surprised if we ask you to file bug at https://bugzilla.redhat.com/enter_bug.cgi?product=Spacewalk with more details or full logs. Thank you for using Spacewalk. Happy birthday, Mirek, Michael, and Stephen. -- 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] Release candidate for next Spacewalk release
Hello, the nightly Spacewalk yum repos at http://yum.spacewalkproject.org/nightly/ now contain release candidate for the next Spacewalk release. Please report installation issues and regressions against previous versions you might find. We've added support for running Spacewalk server on the same machine as Oracle XE 11g -- the setup is described at https://fedorahosted.org/spacewalk/wiki/OracleXeSetup Also note that the installation with Oracle backend now requires the latest Instant Client. When running spacewalk-setup, please add the --external-db option to get behaviour similar to previous releases. Without this option, with PostgreSQL backend, spacewalk-setup will attempt to create the database and the database user for 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] Small patch for osad.py for spacewalk hosts using custom ports
On Wed, Oct 17, 2012 at 07:45:04PM -0700, David Johansen wrote: Hi, I recently setup an instance using custom ports, 8080,8443, for the webui. I ran into an issue with OSAD when trying to connect clients. After looking at the code, I noticed that osad was failing because my netloc portion of the url was spacewalk.example.com:8080, which did not match my CN, spacewalk.example.com. I added an if statement to cover that, in /usr/share/rhn/osad/osad.py, that checks for a : in netloc, and if it exists, then it sets netloc to the domain name without the :port. I've never seen a legitimate cert with port numbers included in the common name, so figure this would be a worthy patch to send your way. https://raw.github.com/gist/3909534/92a8eea0b8cac895a9613d77601678cddc4a89ca/osad.py.patch This patch will fail for example for IPv6 addresses. The correct approach would be to use ParseResult's hostname. Except it is not supported on python 2.4. We might need to check for the type and either call hostname or strip the port _from the end_ of the netloc, something like :[0-9]+$. -- 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 nightly now with XE 11 and latest Instant Client
Hello, if you are following Spacewalk nightly yum repos and installing from them, please note that Oracle XE 11g is now supported by the SELinux policy that we ship, and that the dependencies were set and packages rebuilt to use Instant Client in version 11.2.0.3. -- 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 DATE colums are not TIMESTAMPs in Spacewalk master
Hello, the Spacewalk master now has all the columns that were of DATE type in Oracle variant either TIMESTAMP WITH LOCAL TIME ZONE or TIMESTAMP without time zone. This makes the Oracle and PostgreSQL temporal data types equivalent. On the other hand, it might have introduced regressions here or there so if you see something in nightly which could be related to this change, it's probably related to this change. ;-) -- 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] Reason db_name value change in /etc/rhn/rhn.conf?
On Fri, Sep 07, 2012 at 02:22:56PM +0200, Bo Maryniuk wrote: I am wondering what was the reason to make this very awkward change in 1.7 by using URI in db_name in the /etc/rhn/rhn.conf other than because now our Java can connect different way? I'm not sure I correctly understand what you ask about but the oracle_get_database_answers was refactored for 1.3. The explanation is right in that commit message of mine: commit 11df63a4baf949231d1fb52fabf41c64b0753c77 Author: Jan Pazdziora jpazdzi...@redhat.com Date: Tue Jan 18 16:25:24 2011 +0100 Refactored oracle_get_database_answers. We do not want to ask for username and password before we know what database we talk to. Also, we no longer create/change /etc/tnsnames.ora. The db-name in answer file can either refer to service name at db-host (//db-host(:db-port)/db-name) or to a service name specified in tnsnames.ora. This allows the user to set anything in their tnsnames.ora before running spacewalk-setup (think RAC and any advanced options) and just use it. For similar reason, db-protocol is no longer supported. My opinion on that: 1. This is called *db_name*. So let it be the *name*. One of the ways of naming the connect target is eznames, which is exactly what this is using. If you prefer, just setup whatever you want in tnsnames.ora and just use that -- the logic in the setup will then use the name from tnsnames if it figures out it can connect that way. 3. It duplicates values from db_host and db_port, making them obsolete and/or irrelevant. Right. We just leave them empty. We could just not set them up at all in that case. Patch welcome. 4. It adds mess and noise to the configuration: if we already have the URI, why the heck we still have host and port defined? We need to support them for PostgreSQL. -- 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] Reason db_name value change in, /etc/rhn/rhn.conf?
On Fri, Sep 07, 2012 at 03:54:25PM +0200, Bo Maryniuk wrote: The /etc/rhn/rhn.conf has nothing to do with *Oracle* database at all. Right, besides providing database type and connect information, which for Oracle backend turns out to be ... Oracle connection specification. :-P has nothing to do with a particular database vendor. RHN configuration is a place, where *generic* information about *any* database connectivity is specified. Right. For Oracle, both I_AM_NAME_DEFINED_IN_TNSNAMES_ORA and //host.domain:1522/DATABASE_ON_THAT_HOST are valid strings that can be used in lieu of connect specification. Or database name if you will. application. What if I am connecting my Windows Server .Net written app over ODBC to Postgres? -- I am constructing my own URI inside. You have Spacewalk ported to .Net? I can spot here severe logical problem: We just leave them empty ... for Oracle. If PostgreSQL had the same unified way of specifying the database connection target across all three stacks we use, we would not need db_host and db_port at all -- these were introduced specifically for PostgreSQL. The beautiful generic design of that configuration file had to give way to reality. As a result, other components need to parse this URI, remove all the host:port information and extract only a database name. Why? Why would they? All three stacks we use in Spacewalk use that db_name value directly, IIRC. No parsing needed. Why would Spacewalk care about the database name at all? Can you show the part of Spacewalk (code) where having the connect information stored this way (as opposed to creating and overriding /etc/tnsnames.ora which completely prevented people to have any advanced setups) poses a problem? had a personal problem somewhere. In some cases it can be a different syntax, like: user/password@//host:port/database or: (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=host) (PORT=port)))(CONNECT_DATA=(SERVER=DEDICATED) (SERVICE_NAME=database)));User Id=user;Password=password; or: user/password@host/service:dedicated/database; or: //$host/$database?user=$userpassword=$passwordssl=true It can. It might even work with the code as is. What's wrong with 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] Bootstrap image feature
On Wed, Aug 08, 2012 at 11:29:27AM +0200, Uwe Gansert wrote:
On 02.08.2012 11:15, Jan Pazdziora wrote:
* inventing a new architecture bootstrap-linux that automatically
gets the new entitlement during registration.
Could you please explain some more why new architecture is needed?
Won't we actually need to know what architecture (the physical one)
the machine is?
I wanted to clean up the patch today and noticed, that we still need
the architecture.
The architecture is directly connected to the new
bootstrap-entitlement in the database via
rhnServerServerGroupArchCompat table:
insert into rhnServerServerGroupArchCompat ( server_arch_id,
server_group_type)
values (lookup_server_arch('bootstrap-linux'),
lookup_sg_type('bootstrap_entitled'));
insert into rhnServerServerGroupArchCompat ( server_arch_id,
server_group_type)
values (lookup_server_arch('bootstrap-linux'),
lookup_sg_type('provisioning_entitled'));
if a machine registers with that arch, it'll get the
bootstrap-entitlement automatically.
Please correct me if I'm wrong or misunderstood something but I'm
afraid, we still need the arch.
Well, the question still is, why does it have to exist at all (and be
connected)? We should be able to figure out the real architecture on
the running (bootstrapped) machine just fine.
And if we use the activation key method for adding the entitlement
instead of the bootstrap-linux, it shouldn't be 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] small license issues
On Fri, Aug 03, 2012 at 02:20:20PM +0200, Michael Calmer wrote: Hi, Am Donnerstag, 31. Mai 2012, 14:43:49 schrieb Michael Calmer: Hi, our legal guys reviewed the spacewalk packages and found some small issues which should be easy to verify and fix. We found another issue in the package spacewalk-remote-utils. he spec say GPLv3+ but the COPYING file is a GPLv2 one. Which one is correct? The COPYING file. I've now fixed the .spec in Spacewalk master, tagged as spacewalk-remote-utils-1.8.4-1. Thank you for pointing this out. -- 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] I seem to have hit a known fixed satellite bug in spacewalk 1.7
On Thu, Aug 16, 2012 at 05:29:20PM -0400, Paul Robert Marino wrote: Hey guys I seem to have hit a known fixed satellite bug in spacewalk 1.7 https://bugzilla.redhat.com/show_bug.cgi?id=496318 Is there any plan to back port this to spacewalk 1.7 or should I hack my copy my self? Given the fact that the bug was fixed in 2009 in Spacewalk like 0.6, you either are hitting different bug, or we introduced a regression. In any case, we have no current report of whatever issue you might be facing at this point, and we have no known fix. -- 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] CVEs missing in the security patches listing (on Oracle 11)
On Fri, Aug 17, 2012 at 01:02:38PM +0200, Johannes Renner wrote: Hey, apparently the method getColumnLabel() of class ResultSetMetaData returns the column label in uppercase with Oracle 11 (using ojdbc5.jar). Therefore an equals(cve) in SecurityErrataOverview.java is not sufficient anymore and leads to an empty CVEs column in the listing of relevant security errata: Is there a configuration (session level or something) option which would make it lowercase? Because I assume that if this is the case, we will have many more places where we simply expect the column name to be lowercase, so I'd rather make getColumnLabel keep its old behaviour. -- 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] Insert pxt session errors on postgres
On Wed, Aug 15, 2012 at 03:28:40PM +0200, Johannes Renner wrote: Hello, We found a problem with an sql statement not working on postgresql, causing errors when trying to browse perl pages while not logged in to spacewalk. To reproduce, try to navigate to one of these pages when not logged in on a postgres based installation: https://hostname/help/copyright.pxt https://hostname/help/about.pxt Attached please find a patch for the issue. Pushed to master as 93d1d4c850a7ed069dbb8d32f0f026d7a6ddcc21 The quote_literal is probably not needed for the numeric parameter but it should hurt either. 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] Script contents not properly displayed
On Tue, Aug 14, 2012 at 12:18:39PM +0200, Johannes Renner wrote: Hello, we found out that script contents are not properly displayed in the web UI in Systems - Events - History (it's a perl page ...). To reproduce: - choose a system and go to Remote Command - type in some script contents, e.g. a b c d e f g h - schedule the command - go to Events and click on the one just scheduled - in the Details you will see (for the example above): x23212f62696e2f73680a0a61206220632064206520662020672068 which is the ASCII code for #!/bin/sh a b c d e f g h The attached patch fixes the problem by converting the ASCII codes into a string using the pack() function. What Spacewalk version and what database is this exactly? -- 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] option standard_conforming_strings in Pg breaks our code and data.
On Fri, Jun 15, 2012 at 08:28:04PM +0200, Miroslav Suchý wrote:
If you look at commit:
d8744d1693c1fc6e231278dd9a6537f269371192
and the code:
+if self.blob_map:
+for blob_var in self.blob_map.keys():
+ kw[blob_var] = kw[blob_var].replace('\\', '')
This worked fine in default Pg till version 9.0, but the behavior
depends on server side setting of option standard_conforming_strings
(boolean):
http://www.postgresql.org/docs/9.1/static/runtime-config-compatible.html
and this option changed its default value in 9.1. Which caused that
this statement corrupts data if \char appears in blob.
Why we could not use ordinary prepare here?
That would break existing 8.4-based installations, wouldn't it? Do we
have a way to hardcode setting the option upon connect so that we know
it behaves the way we assume even on older versions?
--
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] Script contents not properly displayed
On Tue, Aug 14, 2012 at 03:53:08PM +0200, Johannes Renner wrote: On 08/14/2012 03:36 PM, Stephen Herr wrote: Johannes, Could you ensure in /usr/share/pgsql/postgresql.conf that bytea_output = 'escape', and if not see if that corrects your problem? -Stephen Thanks, setting this option fixes the problem on the postgres 9.1 database we are using. We also set standard_conforming_strings = 'off', do you think it makes still sense in Mirek in https://www.redhat.com/archives/spacewalk-devel/2012-June/msg00023.html noted that the default changed with 9.1. We did not have time to investigate what this change could cause. combination with bytea_output = 'escape'? The bytea_output is about output, standard_conforming_strings is about literals on input. What I believe needs to be done is set these parameters on the per-connection basis (if possible) so that we don't depend on particular PostgreSQL server configuration (and defaults in different versions). -- 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 small typo in spacecmd/src/lib/kickstart.py
On Thu, Aug 09, 2012 at 04:36:03PM +0200, Gael Chamoulaud wrote:
---
spacecmd/src/lib/kickstart.py |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/spacecmd/src/lib/kickstart.py b/spacecmd/src/lib/kickstart.py
index
9a8c1926102b5da9df24694a26f066d9df6ebb3e..1eb1ccf899f17e0fc3b0f41cda54e18473a83094
100644
--- a/spacecmd/src/lib/kickstart.py
+++ b/spacecmd/src/lib/kickstart.py
@@ -1806,7 +1806,7 @@ def do_kickstart_clone(self, args):
print '\n'.join(sorted(profiles))
print
-options.name = prompt_user('Origianl Profile:', noblank = True)
+options.name = prompt_user('Original Profile:', noblank = True)
options.clonename = prompt_user('Cloned Profile:', noblank = True)
Pushed to Spacewalk master as
774ca21ae42238201ea42f699dd8bedb1987a5c9.
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] Bootstrap image feature
On Thu, Aug 02, 2012 at 10:42:01AM +0200, Uwe Gansert wrote: I have attached patches that fit into master. But actually they are more to show what I did and for discussion maybe. The schema-upgrade for example is still missing because I don't know yet in which version that patch will end. We are still aiming for 1.8 if we can make it. In any case, we need to commit the schema upgrades together with the schema population changes or the freshly installed and upgraded installations won't match. By keeping the schema upgrades in sync with the main schema content, we can do the release at any point, even if the feature is only half-finished. The patches are not too big but I'll explain what I did: * inventing a new base entitlement called bootstrap_entitled that has the provisioning feature * the changes in the Web UI are only for adding some ACLs that check this new entitlement and turn off some web-ui features like the Software-tab * inventing a new architecture bootstrap-linux that automatically gets the new entitlement during registration. Could you please explain some more why new architecture is needed? Won't we actually need to know what architecture (the physical one) the machine is? * patching the registration process on the server to accept registration without user/pass or reg-key when bootstrap-linux is registering. Only org_id is needed then. Couldn't we use registration keys for this? The key would be on the image that the machine would PXE boot. I'm a bit worries that extending access control logic based on some hardcoded string will lead to maintenance nightmare and potential security issue. I did not change that database with new tables or columns. Just some data is inserted for the new architecture and entitlement. the system_reg_final.py client is the registration client on the image. It's called final but it's still a development version. Important data during registration is the org_id (default is 1) and the address of the spacewalk server (default is IPAPPEND parameter) There are still some hardcoded values in there but those will be no problem an can be changed. I think we need to discuss how the image will get generated. I'm a bit concerned that by duplicating what seems to be a rhnreg_ks logic, we will end up with two code bases to maintain. If the system_reg_final.py does something which rhnreg_ks cannot do, couldn't we extend rhnreg_ks instead? If you find the time to look at it, that would be great. I hope inventing a new entitlement was a good way for that but thanks to the ACLs, the changes in the webfrontend are quite minimal because of that. The new entitlement I feel is OK. Of course, we will need to check the rest of the UI to see if other parts need to be locked down for it. Because this entitlement not only means allow some particular action, it also implcitly means if no other entitlement is present, don't show these other actions. From this point of view, I am not that sure about the rhn:require acl=not system_has_bootstrap_entitlement(); pieces -- the entitlements should add capabilities, not block them. -- 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 00/10] spacewalk abrt integration
On Wed, Jul 18, 2012 at 03:38:08PM +0200, Richard Marko wrote: Hi, this patchset adds support for collecting information about application crashes handled by abrt. If spacewalk-abrt package is installed, rhn_check will collect number of crashes and send it to the server via XMLRPC API (if server supports it). The data are stored for each system in rhnAbrtInfo table and shown on system detail page (systems/details/Overview.do) under 'Application crashes' header. Later, this feature can be extended to - display data on YourRhn.do page; - collect more information about crashes. Comments welcome! Richard, patches applied to Spacewalk master. If packages build without issues, you should see the feature in Spacewalk nightly repos in a couple of hours. If we hit some issue, I'll let you know. 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] Is there an updated ETA on the release of spacewalk 1.8
On Wed, Jul 18, 2012 at 10:49:04AM -0400, Paul Robert Marino wrote: I have noticed that we have gone past the expected release date set for spacewalk version 1.8 is there any updated ETA on when it it will be released. there are a lot of bug fixes in 1.8 that have not been back ported to 1.7 which are a show stoppers for many people. so I was wondering is While I agree that we fixed a decent amount of bugs, I'd hardly describe them show stoppers in vast majority of the cases. Were any of the bugs regressions against 1.6 that did not have a workaround? there an updated ETA? No updated ETA. My personal estimate is two to three months. Is there a list of what still needs to be completed? From the list on the 1.8 milestone page, we have yet to see some patch for the systemd feature. From things not on the list, the latest cobbler packages in Fedoras and EPEL made Spacewalk unusable. Since upgrade to the next Spacewalk version includes yum upgrade, people would pick the latest cobbler package and ruin their installations. We want to avoid sending people that path. Is there a list of what needs testing so we can help further this along? Features listed on the 1.8 page, as well as all the MODIFIED / ON_QA bugzillas. It would sure be nice to see community chime in with feedback about Spacewalk nightly stability. Please note that the ABRT support is in the Spacewalk nightly yum repos as of ten minutes ago, so people are welcome to start testing 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] Is there an updated ETA on the release of spacewalk 1.8
On Wed, Jul 18, 2012 at 12:43:32PM -0400, Paul Robert Marino wrote: Well a good example of a show stopper is the fact that as far as I know there is still an issue in 1.7 that prevents you from properly registering virtual machines if you are using PostgreSQL as your database backend. This was fixed in 1.8 but never back ported to 1.7 also note it was a bug that didn't effect 1.6 it was a new bug introduced in 1.7 due to other compatibility fixes for PostgreSQL That's bugzilla 811646, right? Modifying the database schema and patching the backend stack should get people going with this one. The Cobbler issue is a massive problem I agree although that can easily be worked around by excluding cobbler in the yum configuration. that being said it may also be prudent to put a copy of the older version of cobbler in the spacewalk repo for the time being. Copy of older package won't help because it would be updated during the next yum update run. So we'd have to build new package with different name or bumped up epoch, make sure upgrades from existing cobbler installations are sane, and start maintaining security issues for it ... something I'm not sure we want to do. For systemd I thought I saw that get added some time ago but if not if someone could put together a bullet list of what needs to be done I will be happy to see if there are any parts I can tackle to help move this along. It's tracked under bugzilla 767034. -- 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] xen distro inherits kernel options
On Wed, Jul 11, 2012 at 01:38:33PM +0200, Uwe Gansert wrote: On 11.07.2012 13:30, Uwe Gansert wrote: Here is a simple patch that copies the kopts to the xen distro. sorry, there is a check missing in the patch if there is a xen distro at all. This patch checks that. Pushed to Spacewalk master, 4fe5b85b5b7b64717c73e633b6c8387804327641. 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-backend-xp package is missing at nightly repo for RHEL6
On Tue, Jul 03, 2012 at 07:03:20PM -0300, Marcelo Moreira de Mello wrote: It seems that spacewalk-backend-xp package is missing at nightly It's expected, the spacewalk-backend-xp package is gone. repo http://spacewalk.redhat.com/yum/nightly/RHEL/6/x86_64/ -- Processing Dependency: spacewalk-backend-server = 1.8.33-1.el6 for package: spacewalk-backend-xp-1.8.33-1.el6.noarch --- Package spacewalk-backend-server.noarch 0:1.8.45-1.el6 will be an update --- Package spacewalk-backend-sql.noarch 0:1.8.33-1.el6 will be updated --- Package spacewalk-backend-sql.noarch 0:1.8.45-1.el6 will be an update --- Package spacewalk-backend-sql-postgresql.noarch 0:1.8.33-1.el6 will be updated --- Package spacewalk-backend-sql-postgresql.noarch 0:1.8.45-1.el6 will be an update --- Package spacewalk-backend-tools.noarch 0:1.8.33-1.el6 will be updated --- Package spacewalk-backend-tools.noarch 0:1.8.45-1.el6 will be an update --- Package spacewalk-backend-xml-export-libs.noarch 0:1.8.33-1.el6 will be updated --- Package spacewalk-backend-xml-export-libs.noarch 0:1.8.45-1.el6 will be an update --- Package spacewalk-backend-xmlrpc.noarch 0:1.8.33-1.el6 will be updated --- Package spacewalk-backend-xmlrpc.noarch 0:1.8.45-1.el6 will be an update -- Finished Dependency Resolution Error: Package: spacewalk-backend-xp-1.8.33-1.el6.noarch (@spacewalk-nightly) Requires: spacewalk-backend-server = 1.8.33-1.el6 Removing: spacewalk-backend-server-1.8.33-1.el6.noarch (@spacewalk-nightly) spacewalk-backend-server = 1.8.33-1.el6 Updated By: spacewalk-backend-server-1.8.45-1.el6.noarch (spacewalk-nightly) spacewalk-backend-server = 1.8.45-1.el6 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest # rpm -q spacewalk-backend-xp spacewalk-backend-xp-1.8.33-1.el6.noarch Fixed in 6240d39588718c5463489c6104f3552076253414. Users of stable Spacewalk releases will never see the error thou because they will not have 1.8.33 to 1.8.37 installed (and want to upgrade from it). In general, rolling upgrades of Spacewalk nightly are expected to cause issues like this. -- 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] 798571 - Timezone definitions outdated for russian TZs
On Mon, Jul 02, 2012 at 05:12:58PM -0300, Marcelo Moreira de Mello wrote: Hello team, Here follow a patch which fixed the issue reported on BZ#798571. Marcelo, are we sure that it's just the description change that is needed? Do the timezones otherwise work as expected on both Perl and Java stacks, or is some logic change needed 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] RFE: spacecmd: functions for softwarechannel_sync and configchannel_sync
On Sun, Jun 10, 2012 at 09:26:08PM +0200, Jörg Steffens wrote: attached are two patches. Patch 1: softwarechannel_sync sync the contents of two software-channels. While the existing softwarechannel_clone creates a new channel, softwarechannel_sync copies the contents from one existing channel into another. Patch 2: configchannel_sync the same for configchannels. Jörg, I've now applied your patches to Spacewalk master, they will land in spacecmd-1.8.10-1 which should appear in Spacewalk nightly yum repos in a couple of hours. 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] The Spacewalk nightly now builds for Fedora 17 instead of 15
On Wed, Jun 06, 2012 at 09:49:06AM +0200, Jan Pazdziora wrote: The Spacewalk nightly now builds for Fedora 17. New yum repos will be available in a couple of days. They are ready. I encourage people to try the repo and report any issues. Please note that only support for the PostgreSQL database backend is present in this Fedora 17 compose. -- 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 Spacewalk nightly now builds for Fedora 17 instead of 15
The Spacewalk nightly now builds for Fedora 17. New yum repos will be available in a couple of days. At the same time, I've stopped Fedora 15 builds and the Fedora 15 nightly yum repos will be removed in a couple of days. -- 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-clone-by-date and timezone
On Tue, May 08, 2012 at 02:23:43PM +0100, Steven Hardy wrote: Hi Jan, Thanks for the reply: On Mon, May 07, 2012 at 12:54:32PM +0200, Jan Pazdziora wrote: Testing on satellite shows that the API provided issue_date is not offset aware, so the comparison works. I was going to implement a workaround in spacewalk-clone-by-date, but first I wanted to check: - Is this expected? No, I'd consider it a bug. Ok, thanks for the clarification - I'll try to revisit this and implement a fix. The problem was fixed in Spacewalk nightly via bug https://bugzilla.redhat.com/show_bug.cgi?id=824583. -- 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-clone-by-date and timezone
On Tue, Mar 20, 2012 at 11:03:40AM +, Steven Hardy wrote: Hi All, I've been testing some spacewalk-clone-by-date patches on both satellite (5.4.1) and spacewalk (nightly, postgresql), and I noticed the following on spacewalk: [root@fedora_satellite utils]# ./spacewalk-clone-by-date --to_date 2007-03-03 -u rhn-admin -l rhel-x86_64-server-5 zzerrtest2 Password: Reading repository information. SHDEBUG issue_date = 2010-06-22 05:00:00+01:00 (type 'datetime.datetime') : to_date = 2007-03-03 00:00:00 (type 'datetime.datetime') Traceback (most recent call last): File ./spacewalk-clone-by-date, line 231, in module sys.exit(abs(main() or 0)) File ./spacewalk-clone-by-date, line 221, in main return cloneByDate.main(args) File /root/spacewalk/utils/cloneByDate.py, line 158, in main tree_cloner.prepare() File /root/spacewalk/utils/cloneByDate.py, line 297, in prepare cloner.prepare() File /root/spacewalk/utils/cloneByDate.py, line 422, in prepare self.errata_to_clone, self.available_errata = self.get_errata() File /root/spacewalk/utils/cloneByDate.py, line 507, in get_errata if err['issue_date'] = self.to_date: TypeError: can't compare offset-naive and offset-aware datetimes As you can see, there is a mismatch between the API-provided issue_date (which is offset-aware), and the script internal to_date (which is not) Testing on satellite shows that the API provided issue_date is not offset aware, so the comparison works. I was going to implement a workaround in spacewalk-clone-by-date, but first I wanted to check: - Is this expected? No, I'd consider it a bug. - I would think storing timestamps in the database in a non-timezone-aware format would be better - could this be a spacewalk/postgresql schema issue? With Oracle backend, we are using date -- no timezones. With PostgreSQL, we are using timestamp with time zone. In general, data inserted to the database are in local time zone (of the database / server). So you are not really losing any information. - If all timestamps should be offset-aware, should spacewalk-clone-by-date assume zero offset for to_date, or inherit from the locale? Use localtime from the locale, I'd say. -- 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] - 816445 Registration fails on kickstart process due a code error in redhat_register snippet
On Thu, Apr 26, 2012 at 02:28:20AM -0300, Marcelo Moreira de Mello wrote: Hello Folks, Following attached a patch which solves the issue reported on BZ#816445. Committed to Spacewalk master. 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] Naming of cloned errata
On Fri, Apr 13, 2012 at 04:02:47PM +0200, Johannes Renner wrote: On 04/11/2012 02:28 PM, Jan Pazdziora wrote: How about having a new database table with prefixes and replacements, where the prefix could be empty (NULL) to mean prepend. Record with the longest matching prefix would provide the replacement string. This way you'd be able to have sane defaults in Spacewalk and every downstream product could customize this mapping table to meet their business requirements. Did I get that right, the table for RH would look like this: Prefix | Replacement RH | CL CL | CM CM | CN CN | CO Or even RHBA- CLBA- RHSA- CLSA- RHEA- CLEA- ... to be on the safer side. ...| ... While for us it would look like this: NULL | CL- CL | CM CM | CN CN | CO ...| ... Or NULL CL- CL- CM- CM- CN- ... When cloning, we wouldn't check if we actually have a clone already, but just lookup the table for the longest match and replace? Do we currently check if a clone already exists? Anyway, I was only proposing a naming, not a logic which determines whether to clone or not. -- 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] Naming of cloned errata
On Wed, Apr 11, 2012 at 11:43:07AM +0200, Johannes Renner wrote: I agree that clones of clones should get CM, CN, etc. instead of CL-CL-kernel*. How would you propose to detect clones for implementing this algorithm? How about having a new database table with prefixes and replacements, where the prefix could be empty (NULL) to mean prepend. Record with the longest matching prefix would provide the replacement string. This way you'd be able to have sane defaults in Spacewalk and every downstream product could customize this mapping table to meet their business requirements. -- 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] ivy
On Wed, Mar 28, 2012 at 10:38:37AM +0200, Tomas Lestach wrote: On Tuesday 27 of March 2012 23:00:53 Miroslav Suchy wrote: Do we still use ivy from jpp? Can we use apache-ivy from Fedora? Where do you see, we use ivy? I believe we do not require ivy in run or build time. Don't we used it in build-jar-dir? If you mean development workstation setup, then I'd say no. We use an old ivy version from the really old 1.7 jpackage repo. I remember Simon hit some troubles, when he wanted to use newer ivy from jpackage 5.0. Output of git grep shows that ivy is also somehow needed when generating documentation. -- 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-dobby
On Wed, Mar 21, 2012 at 02:01:25PM +0100, Duncan Mac-Vicar P. wrote: On 03/21/2012 01:34 PM, Bo Maryniuk wrote: I was looking at Spacewalk Dobby wrapper around Oracle tools and I am wondering if there is any plans to work on it? We find it lack of some features that we would like to have, so we are looking to know what are community plans on this particular software. We are particularly interested to know if dobby needs to gain Postgres support, of if replacing it completely was the plan. Excellent questions that I feel are calling for rigorous discussion. What course of action do you envision in this area? -- 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-dobby
On Wed, Mar 21, 2012 at 03:42:28PM +0100, Bo Maryniuk wrote: to invest into current implementation, which is also in Perl that we would like to get rid of entirely. Since you've touched the subject -- how is the Perl to Java WebUI migration progressing? -- 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] Release candidate for next Spacewalk release
Hello, the nightly Spacewalk yum repo at http://spacewalk.redhat.com/yum/nightly/ now contains release candidate for the next Spacewalk release. Please report installation issues and regressions you might find. -- 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.7 was branched
Hello, new branch SPACEWALK-1.7 was created to become Spacewalk 1.7. Master is now open for changes going to Spacewalk 1.8. -- 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] Outstanding patches? Send them in.
On Wed, Feb 29, 2012 at 04:41:38PM +0100, Jonathan Hoser wrote: Hi! I take it you are still collecting patches? Here's a minute one I came across in 1.6 that I could fix. How about just doing the select kvt.label instead, dropping the column alias altogether? The select kvt.label label seems like identity mapping. -- 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] Outstanding patches? Send them in.
On Mon, Feb 27, 2012 at 02:08:41PM -0500, R P Herrold wrote: Checking the open bugs [1] I see only one that really seems relevant to de-coupling the database from the Oracle backend to a more FOSS license one (pgsql) [2] We now track it as RFE. We don't actually need it -- it's a nice-to-have, it would make things cleaner. Is there a tracking bug that is actually being worked, on this, which I am missing? Which this? The refactoring of spacewalk-setup is not currently being worked on. this one has been re-targetted a couple of times and seems not to be the one to look at Right. It's not a priority but of course, patches are welcome. I see also another piece of low hanging need in [3] 'Migrate SysV script to support systemd at Fedora17' in an uncompleted status, but which has a patch attached I assume Marcelo will review that patch eventually. I assume it's not correct because it does not expose the individual services that create Spacewalk (taskomatic, osa-dispatcher) to systemd, with proper dependencies and such, instead it cements the notion of Spacewalk as a single unit/service. -- 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] Modification of spacewalk-service script
On Sat, Nov 12, 2011 at 09:09:18PM +0100, Jan Pazdziora wrote: Please find attached a proposed patch for this. I've added database.control boolean directly in rhn.conf file. I've modified the spacewalk-service script to manage this parameter. In all cases, oracle is controlled, for compatibility with RH Satellite product. I've left commented out a sleep before starting osa-dispatcher: this sleep allows to get rid of osa-dispatcher error connecting to jabberd. I couldn't find another find to check if jabberd was ready to accept connection. Feel free to either remove it or uncomment it. I'm against this change. The database (PostgreSQL, Oracle XE) is completely independent from the Spacewalk software product and the spacewalk-service script should have no business fiddling with them. If for some reason (what reason, exactly?) you need to restart everything with one script, why not write a wrapper around it? On Mon, Jan 23, 2012 at 10:25:53PM -0500, Marcelo Moreira de Mello wrote: Hello team, Here follow 3 patches which includes a capability to Spacewalk ignore to start some services when running the /usr/sbin/spacewalk-service script. Below is an example after applied the patch excluding the Taskomatic service to be started: # cat /etc/rhn/disabled-services DISABLED_SERVICES=taskomatic Since there were two opposite requests (add PostgreSQL to spacewalk-service, make it possible to remove taskomatic), I've ended up adding support for /etc/rhn/service-list where you can manipulate the $SERVICES list in any way. In Spacewalk master, spacewalk-admin-1.7.3-1. -- 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 review for exportLib.py
On Fri, Feb 03, 2012 at 03:55:53PM +, Parsons, Aron wrote: Can someone verify that this is a sound change? rhn-satellite-exporter is extremely slow on PostgreSQL when getting the file checksums. This speeds it up dramatically. It's the same issue we ran into with PostgreSQL doing a left join on rhnChecksumView in 'query_client_get_file'. PostgreSQL does a sequence scan on a table with millions of rows. I patched it in 1e64dc4546d96c58dd84a88c3c634b2d2ce164a4 but Michael had to fix it in 79e57d3b215340a54e911a073408f0eb7c6afc1f. I just want to be sure my SQL is proper on this one before committing this time. diff --git a/backend/satellite_tools/exporter/exportLib.py b/backend/satellite_t index 1646c58..1f265a2 100644 --- a/backend/satellite_tools/exporter/exportLib.py +++ b/backend/satellite_tools/exporter/exportLib.py @@ -753,7 +753,12 @@ class _PackageDumper(BaseRowDumper): c.checksum_type as checksum-type, c.checksum, pf.linkto, pf.flags, pf.verifyflags, pf.lang from rhnPackageFile pf -left join rhnChecksumView c +left join + (select c.* + from rhnPackageFile pf + inner join rhnChecksumView c + on pf.checksum_id = c.id + where pf.package_id = :package_id) c on pf.checksum_id = c.id, rhnPackageCapability pc where pf.capability_id = pc.id I'm affraid you'd get the same having a table twice in select is mostly a bug response on this one. What are you trying to achieve? This query doesn't even have any lookup_* function. -- 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] function nvl(evr_t, evr_t) does not exist
On Thu, Jan 12, 2012 at 04:55:52PM +, Parsons, Aron wrote:
The following exception is generated when attempting to install a package on
a system, which is a pretty basic function for Spacewalk. I believe it was
reported before at
https://www.redhat.com/archives/spacewalk-list/2011-November/msg00055.html.
[Thu Jan 12 11:12:34 2012] [error] Execution of
/var/www/html/network/software/packages/install_confirm.pxt failed at Thu Jan
12 11:12:34 2012: RHN::Exception: DBD::Pg::st execute failed: ERROR:
function evr_t(unknown, integer, integer) does not exist\nLINE 23:
AND SP.evr_id = PE.id), EVR_T(NULL, 0, ...\n
^\nHINT: No function matches the given name
and argument types. You might need to add explicit type casts.\n RHN::DB
/usr/share/perl5/vendor_perl/RHN/DB.pm 228
Gurjeet Singh suggested a fix for the instantiation of the EVR_T at:
http://www.redhat.com/archives/spacewalk-devel/2009-February/001536.html
--- Scheduler.pm.orig 2012-01-06 08:05:25.0 -0500
+++ Scheduler.pm2012-01-12 11:49:27.820683130 -0500
@@ -660,7 +660,7 @@
FROM rhnServerPackage SP, rhnPackageEvr PE
WHERE SP.name_id = P.name_id
AND SP.server_id = S.id
- AND SP.evr_id = PE.id), ${rhn_class}EVR_T(NULL, 0, 0))
+ AND SP.evr_id = PE.id), ${rhn_class}(NULL, 0, 0)::EVR_T)
(SELECT EVR FROM rhnPackageEVR PE WHERE PE.id = P.evr_id)
)
Fixing DB/Scheduler.pm gets around that issue and EVR_T is instantiated fine.
However, a new issue pops up:
[Thu Jan 12 11:49:37 2012] [error] Execution of
/var/www/html/network/software/packages/install_confirm.pxt failed at Thu Jan
12 11:49:37 2012: RHN::Exception: DBD::Pg::st execute failed: ERROR:
function nvl(evr_t, evr_t) does not exist\nLINE 19:AND ( (NVL((SELECT
MAX(PE.evr)\n ^\nHINT: No function matches the given
name and argument types. You might need to add explicit type casts.
Any input?
The change above would break operations on the Oracle backend so we
cannot use it.
Please use the following patch (against 1.6):
diff --git a/web/modules/rhn/RHN/DB/Scheduler.pm
b/web/modules/rhn/RHN/DB/Scheduler.pm
index ccb478b..e47187a 100644
--- a/web/modules/rhn/RHN/DB/Scheduler.pm
+++ b/web/modules/rhn/RHN/DB/Scheduler.pm
@@ -634,8 +634,6 @@ sub schedule_package_install {
my $query;
my $sth;
- my $rhn_class = '';
-
if ($package_id and $server_set) {
$query = EOQ;
INSERT INTO rhnServerAction (server_id, action_id, status)
@@ -656,14 +654,15 @@ SELECTS.id
AND CP.package_id = P.id
AND PA.id = P.package_arch_id
AND AT.id = PA.arch_type_id
- AND ( (NVL((SELECT MAX(PE.evr)
-FROM rhnServerPackage SP, rhnPackageEvr PE
- WHERE SP.name_id = P.name_id
- AND SP.server_id = S.id
- AND SP.evr_id = PE.id), ${rhn_class}EVR_T(NULL, 0, 0))
-
- (SELECT EVR FROM rhnPackageEVR PE WHERE PE.id = P.evr_id)
-)
+ AND (not exists(
+ select 1
+from rhnServerPackage, rhnPackageEvr evr_installed, rhnPackageEvr
evr_new
+where P.name_id = rhnServerPackage.name_id
+ and S.id = rhnServerPackage.server_id
+ and rhnServerPackage.evr_id = evr_installed.id
+ and P.evr_id = evr_new.id
+ and evr_installed.evr = evr_new.evr
+ )
OR AT.label = 'solaris-patch'
OR AT.label = 'solaris-patch-cluster'
)
@@ -709,7 +708,7 @@ EOQ
elsif ($package_id) {
$query = EOQ;
INSERT INTO rhnActionPackage (id, action_id, name_id, evr_id)
-(SELECT rhn_act_p_id_seq.nextval, ?, P.name_id, P.evr_id FROM rhnPackage P
WHERE P.id = ?)
+(SELECT sequence_nextval('rhn_act_p_id_seq'), ?, P.name_id, P.evr_id FROM
rhnPackage P WHERE P.id = ?)
EOQ
$sth = $dbh-prepare($query);
# warn ins query: $query\n$id, $user_id, .$packages-label;
--
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] [PATCHES] two patches for SUSE support
On Mon, Jan 16, 2012 at 04:48:17PM +0100, Michael Calmer wrote: Do you know where this getPlatform come from? It's in client/rhel/rhn-client-tools/src/up2date_client/platform.py Ahh, thanks. But this is bad. I would like to use the official platform module from python in the same file, but this result in namespace conflicts. The first path in sys.path is . which means, that the result of from platform import dist is a Traceback with ImportError: cannot import name dist What do you think about renaming the up2date_client/platform.py to something like up2date_client/pkgplatform.py ? Does anybody have other ideas how to solve this? Renamed in Spacewalk master and rhn-client-tools-1.7.5-1. Thanks for pointing this issue out. -- 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] [PATCHES] two patches for SUSE support
On Mon, Jan 16, 2012 at 12:15:26PM +0100, Michael Calmer wrote: easier fix. But I would most rather see there if getPlatform() == 'deb' or isThisSuse(): Ok, but looking into it more deeply I wonder how this can work. I cannot find a function called getPlatform() in the module platform (python 2.6/2.7) # python -c from platform import getPlatform Traceback (most recent call last): File string, line 1, in module ImportError: cannot import name getPlatform There is a function platform() but this returns something like this: Linux-2.6.32.49-0.3-default-x86_64-with-SuSE-11-x86_64 I think it does not return only deb on debian. Do you know where this getPlatform come from? It's in client/rhel/rhn-client-tools/src/up2date_client/platform.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] Taskomatic not working after moving from oracle-xe to postgres
On Wed, Dec 21, 2011 at 08:09:03AM -0500, Eric Lake wrote:
On Wed, Dec 21, 2011 at 5:57 AM, Tomas Lestach tlest...@redhat.com wrote:
Looking at the code we've used RHN_TASKO_TEMPLATE_ID_SEQ sequence (not the
RHN_TASKO_RUN_ID_SEQ) for the rhnTaskoRun table.
Would you please check, what's the sequence number of the
RHN_TASKO_TEMPLATE_ID_SEQ in your DB dump generated by the spacewalk-dump-
schema?
I bumped up the last_value in rhn_tasko_run_id_seq to match the
highest id in rhntaskorun but that did not seem to help.
spaceschema=# select * from rhn_tasko_run_id_seq;
sequence_name | last_value | start_value | increment_by |
max_value | min_value | cache_value | log_cnt | is_cycled |
is_called
--++-+--+-+---+-+-+---+---
rhn_tasko_run_id_seq |1329996 | 1 |1 |
9223372036854775807 | 1 | 1 | 1 | f |
f
(1 row)
Here is the rhn_tasko_template_id_seq information.
spaceschema=# select * from rhn_tasko_template_id_seq;
sequence_name | last_value | start_value | increment_by |
max_value | min_value | cache_value | log_cnt | is_cycled |
is_called
---++-+--+-+---+-+-+---+---
rhn_tasko_template_id_seq |1329951 | 1 |1 |
9223372036854775807 | 1 | 1 | 31 | f |
t
(1 row)
You also can verify the RHN_TASKO_TEMPLATE_ID_SEQ sequence number in your
oracle-xe db in case you still have it.
I still have the oracle-xe db around just not exactly sure how to get
the same information from it. I am looking into it.
select * from user_sequences where sequence_name =
upper('rhn_tasko_run_id_seq') ;
select * from user_sequences where sequence_name =
upper('rhn_tasko_template_id_seq') ;
should return information about sequences in 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] Merging channels with postgresql backend
On Wed, Dec 21, 2011 at 10:06:46AM -0500, Eric Lake wrote:
I ran into an issue earlier this week where I synced my centos 6 repo
with the mirrors and received a traceback when I tried to merge it
with my centos 6 test channel that my client systems use. I could get
all the way to the confirmation stage of the merge but when I clicked
confirm I would get a 500 Internal Server Error and the traceback.
The traceback looked like this:
Error message:
RHN::Exception: DBD::Pg::st execute failed: ERROR: missing
FROM-clause entry for table rhn_repo_regen_queue_id_seq at character
[...]
To address that I changed instances of VALUES
(rhn_repo_regen_queue_id_seq.nextval, to VALUES
(sequence_nextval('rhn_repo_regen_queue_id_seq'), in
/usr/lib/perl5/vendor_perl/5.8.8/RHN/DB/ChannelEditor.pm
Once that was addressed it led to another traceback that looked like this:
Error message:
RHN::Exception: DBD::Pg::st execute failed: ERROR: column sysdate
does not exist at character 252
[...]
This one seems to work if instances of sysdate are replaced with
current_timestamp in
/usr/lib/perl5/vendor_perl/5.8.8/RHN/DB/ChannelEditor.pm like this:
[...]
I would try to submit a patch but right now I am trying to see how to
do fix it so that it will work for both postgresql and oracle-xe.
Both fixes are correct and will work both on Oracle and PostgreSQL,
in Spacewalk schema. You might want to crosscheck
https://fedorahosted.org/spacewalk/wiki/PostgreSQLPortingGuide
when in doubt with the proposed approach -- the page lists the
types of issues/errors that we've already seen in the past.
--
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] Taskomatic not working after moving from oracle-xe to postgres
On Wed, Dec 21, 2011 at 10:58:40AM -0500, Eric Lake wrote:
On Wed, Dec 21, 2011 at 9:00 AM, Eric Lake el...@lexmark.com wrote:
SQL select * from user_sequences where sequence_name =
upper('rhn_tasko_template_id_seq') ;
SEQUENCE_NAME MIN_VALUE MAX_VALUE INCREMENT_BY C O
CACHE_SIZE
-- -- -- - -
--
LAST_NUMBER
---
RHN_TASKO_TEMPLATE_ID_SEQ 1 1.E+27 1 N N
20
1330170
I altered the rhn_tasko_template_id_seq last_value to match what the
oracle-xe db had and taskomatic seems to have started working.
If you still have the schema dump that you used to migrate from Oracle,
could you check whether it contains a line which would look like
select pg_catalog.setval('rhn_tasko_template_id_seq', 1330170, false);
? Because the sequences should be set via the schema dump 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] Taskomatic not working after moving from oracle-xe to postgres
On Wed, Dec 21, 2011 at 02:38:54PM -0500, Eric Lake wrote: On Wed, Dec 21, 2011 at 2:26 PM, Jan Pazdziora jpazdzi...@redhat.com wrote: Is it possible that taskomatic was (still) running while you were doing the dump? We process the sequences first, so it's possible that we saw the value 1329890 in the sequence, but before the script got to dump the actual table data, taskomatic processed something, fetched some more values from the sequence, and inserted those values to the table. That was my thought too. I am pretty certain that the service was still running when the backup was running. Yep. You do not want that. ;-) Thank you for confirming this. -- 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#765816 - Add an option into rhncfg-manager to allow file/directory to be uploaded without setting a SELinux context
On Tue, Dec 13, 2011 at 10:31:01PM +0100, Miroslav Suchy wrote: Dne 13.12.2011 17:34, Marcelo Moreira de Mello napsal(a): Thanks your guidelines. I merged all the fixes into a unique patch which follow attached. Please let me know if some change is still needed. Commited as: * 317d907 (HEAD, tag: rhncfg-5.10.22-1, origin/master, origin/HEAD, master) Automatic commit of package [rhncfg] release [5.10.2 * 31c8dce 765816 - Added the option --selinux-context to rhncfg-manager which allows to overwrite the SELinux context from a fil I fixed the typo which prevented the packages from even being built now, rhncfg-5.10.23-1 is now in Koji for all OSes. -- 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] lock_web_contact never return with postgres
On Tue, Nov 29, 2011 at 05:42:38PM +0100, Michael Calmer wrote:
after a little debugging I found out that the following function never return
in case of postgres is used:
package RHN::DB::User;
sub lock_web_contact()
It stops at this query:
'SELECT * FROM web_contact WHERE id = :user_id FOR UPDATE'
It seems, that postgres support FOR UPDATE so I do not understand why it
does not work.
http://www.postgresql.org/docs/9.0/static/sql-select.html#SQL-FOR-UPDATE-SHARE
Maybe DBD:Pg has trouble with it?
$sth-execute_h(user_id = $params{uid});
does not return.
Does somebody has an idea?
On my Spacewalk 1.6 on RHEL 5,
# perl -MRHN::User -e 'RHN::User-lock_web_contact(uid = 2);'
returns just fine. Can you try newer DBD::Pg or something?
--
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] some patches for monitoring on postgres and pylint findings
On Tue, Nov 29, 2011 at 06:03:26PM +0100, Michael Calmer wrote: Hmm I would be happy to apply that part with s/sysdate/current_timestamp/ But I have problem with that alias. Why replacing it only in one file. It is presented in other files as well. I would welcome to remove it in all files or keep it as is. Attached are now 4 patches. One with only the sysdate=current_timestamp and 3 with synonym replaces. There are some other files uses synonyms, but it seems they are not part of a package (only available in git). So maybe a candidate to remove them? monitoring/SputLite/lib/FetchCommands.pm monitoring/SputLite/lib/UploadResults.pm monitoring/SputLite/lib/CommandQueue.pm monitoring/tsdb/cull_deleted_ts_sc_files I've pushed them to Spacewalk master now, 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 reposync more modular
On Mon, Dec 05, 2011 at 03:55:07PM +0100, Ionuț Arțăriși wrote: On 12/02/2011 05:36 PM, Jan Pazdziora wrote: On Fri, Dec 02, 2011 at 05:23:25PM +0100, Ionuț Arțăriși wrote: Hello, I've written a patch to make reposync more modular. The essential thing is moving the argument parsing to the spacewalk-repo-sync script and out of python/site-packages, but there are also a lot of other style improvements. We've already applied those changes and others in our branch, I just merged some of them into the spacewalk branch now. Can you post this as multiple patches, one for each type of change? This will make it easier to review than this one huge patch. Ok, I've chopped that patch up. Here are the 18 resulting patches. Thanks. I've applied and pushed to Spacewalk master the first eleven patches. Starting with the yum_src.py ones, they conflict against current master. Could you rebase them? -- 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 reposync more modular
On Fri, Dec 02, 2011 at 05:23:25PM +0100, Ionuț Arțăriși wrote: Hello, I've written a patch to make reposync more modular. The essential thing is moving the argument parsing to the spacewalk-repo-sync script and out of python/site-packages, but there are also a lot of other style improvements. We've already applied those changes and others in our branch, I just merged some of them into the spacewalk branch now. Can you post this as multiple patches, one for each type of change? This will make it easier to review than this one huge patch. -- 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] client/rhel
On Wed, Nov 30, 2011 at 06:42:54PM +0100, Miroslav Suchy wrote: in the hostname. You should really check (and test) various scenarios, not overwrite the hostname if it already is set from the IPv4 pass, and not set it if you get IP address back. How should I decide which hostname is correct? The current behaviour is to take the IPv4-related hostname. You should not change the behaviour too much. And what should I do with machine with IPv4 address 123.45.56.67 which resolves to machine1.broken.dns and IPv6 address 2620:52:0:2223:20c:29ff:fe0e:d05b which resolves machine2.broken.dns? Use machine1.broken.dns because that's what the code did so far anyway. If you are unable to resolve the hostname using gethostbyaddr() (getfqdn() is essentially wrapper around this one function), then you do not deserve sane data. If user has broken networking, he should fix it in first place. Why should a person be forced to have a valid IPv6 DNS? Hmm what I can do is: hostname_tmp = socket.getfqdn(intf_tmp) if hostname_tmp != intf_tmp: hostname = hostname_tmp But you can admit, that user can be so ugly, that machine with hostname 123.45.56.67 will have IPv4 address 123.45.56.67. I do not think we can catch all possibilities here. We should not regress. -- 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 display of static snippets
On Thu, Dec 01, 2011 at 01:44:25PM +0100, Uwe Gansert wrote: the read only snippets in the web ui need HTML/XML escaping. Especially AutoYaST XML snippets tend to be displayed wrong in the UI without escaping Shouldn't we rather do this in the .jsp? -- 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 display of static snippets
On Thu, Dec 01, 2011 at 04:50:40PM +0100, Uwe Gansert wrote:
On 01.12.2011 13:54, Jan Pazdziora wrote:
On Thu, Dec 01, 2011 at 01:44:25PM +0100, Uwe Gansert wrote:
the read only snippets in the web ui need HTML/XML escaping.
Especially AutoYaST XML snippets tend to be displayed wrong in the
UI without escaping
Shouldn't we rather do this in the .jsp?
you mean
c:out value=${data} escapeXml=true/
in the jsp?
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] client/rhel
On Wed, Nov 30, 2011 at 04:22:40PM +, Miroslav Suchý wrote: client/rhel/rhn-client-tools/src/up2date_client/hardware.py |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) New commits: commit 7c2b37ad9dd2a972e04bb31cbb021047c6572564 Author: Miroslav Suchý msu...@redhat.com Date: Wed Nov 30 17:21:34 2011 +0100 743259 - take hostname of client instead of server diff --git a/client/rhel/rhn-client-tools/src/up2date_client/hardware.py b/client/rhel/rhn-client-tools/src/up2date_client/hardware.py index f2e68d8..d85d5d0 100644 --- a/client/rhel/rhn-client-tools/src/up2date_client/hardware.py +++ b/client/rhel/rhn-client-tools/src/up2date_client/hardware.py @@ -428,11 +428,12 @@ def findHostByRoute(): try: s.settimeout(5) s.connect((server, port)) +intf_tmp = s.getsockname()[0] if family == AF_INET: -intf = s.getsockname()[0] +intf = intf_tmp else: -intf6 = s.getsockname()[0] -hostname = socket.getfqdn(server) +intf6 = intf_tmp +hostname = socket.getfqdn(intf_tmp) except socket.error: s.close() continue I don't think you want to just blindly set what getfqdn returns. In most cases, IPv4 addresses will have better DNS records than IPv6 but you will end up with stuff like # python -c 'from socket import *; print getfqdn(2620:52:0:2223:20c:29ff:fe0e:d05b);' 2620:52:0:2223:20c:29ff:fe0e:d05b in the hostname. You should really check (and test) various scenarios, not overwrite the hostname if it already is set from the IPv4 pass, and not set it if you get IP address back. -- 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] some patches for monitoring on postgres and pylint findings
On Tue, Nov 29, 2011 at 02:40:58PM +0100, Michael Calmer wrote: I hopefully fixed it with commit 6fe5acfe48abd7e07ef2f87da7422a6bf13dbd23 But you should write undef and not under :-) Indeed. -- 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] some patches for monitoring on postgres and pylint findings
On Mon, Nov 28, 2011 at 06:07:27PM +0100, Miroslav Suchy wrote: Dne 28.11.2011 17:33, Michael Calmer napsal(a): Hi, here are 6 patches I made. The first two were findings from pylint, the rest is a try to fix monitoring with postgres. 0006-postgres-seems-to-reject-empty-text-for-stdout-and-s.patch I hesitated about this one. Probably best solution would be to normalize this table and do not put there anything if there is not stderr. I any case, the fix was not correct. You do *not* want to put single-space strings there if you hit the vn_* constraint, you should put in null (undef in Perl), not ' '. See https://fedorahosted.org/spacewalk/wiki/PostgreSQLPortingGuide#empty_string_null I hopefully fixed it with commit 6fe5acfe48abd7e07ef2f87da7422a6bf13dbd23 -- 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-clone-errata.py
On Wed, Nov 23, 2011 at 02:48:43PM +, Speagle, Andy wrote: Hi Team, Please apply the following patch to the rhn-clone-errata.py script. Highlights are: 1) Users can choose to sync all configured channels at once. 2) Default behavior has been changed with regard to errata missing packages. By default, such errata will be skipped unless the user has chosen specifically (via parameter) to ignore missing packages. Thank ye. We have two rhn-clone-errata.py's in Spacewalk master: ./contrib/rhn-clone-errata.py ./scripts/clone-errata/rhn-clone-errata.py Which one is the live one and which one should be deleted? -- 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-clone-errata.py
On Wed, Nov 23, 2011 at 03:14:01PM +, Speagle, Andy wrote: Please apply the following patch to the rhn-clone-errata.py script. Highlights are: 1) Users can choose to sync all configured channels at once. 2) Default behavior has been changed with regard to errata missing packages. By default, such errata will be skipped unless the user has chosen specifically (via parameter) to ignore missing packages. Thank ye. We have two rhn-clone-errata.py's in Spacewalk master: ./contrib/rhn-clone-errata.py ./scripts/clone-errata/rhn-clone-errata.py Which one is the live one and which one should be deleted? The version in ./contrib was the original version offered by Lars is the basis for my version, but can probably be removed at this point. I don't know at what point the ./scripts/clone-errata structure was created, but that's where my developed version ended up. I've applied your patch but I have a couple of comments: I've polished it not to add trailing spaces (do a git diff on your change and it will show you in red) and fixed lines with mixed space/tabs (also shown by gid diff), plus one or two typos. Still, if you do git show on the commit (it's 82788f843583c33827dc660d0f64960c419c4d76 in Spacewalk master), you'll see that the many indentations do not match because one line uses tabs while other one uses spaces. It would be good to be consistent. Also, the next time don't be affraid to make one patch per feature or change -- that way they would be easier to review. Thank you for the contribution. -- 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] Remove markup from error messages
On Tue, Nov 15, 2011 at 02:41:38PM +0100, Johannes Renner wrote: Hello, Markup in error messages is now being escaped since this commit: - a9da89b35581f4eedfb6ca7ddff4343b9ea21f15. It looks like these strong fragments were forgotten when doing: - e0c4ae8dd7093bbe6a12ab4462272fbab573e098 and - 3a03e49904465ec5f16bde31c92e67c0b85ef1b9 Subject: [PATCH] Remove markup from error message in all translation files [...] Subject: [PATCH] Remove markup from another error message Thank you for the find -- your patches are now in Spacewalk master. -- 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] Modification of spacewalk-service script
On Sat, Nov 12, 2011 at 09:52:07PM +0100, Pierre Casenove wrote: Ok no problem, no patch so. If you're against it, I won't insist! Just to answer your email : HTTPD is also quite independant from the spacewalk product and still, it is controlled. And if postgresql gets It is not as independent as we'd like -- we use mod_wsgi/mod_perl, so for example an upgrade of Spacewalk requires restart of httpd. On the other hand, even upgrade of Spacewalk's database schema does not require restart of the underlying database server. restarted with SP up and running, spacewalk needs also to be restarted (connection is lost and never gets restored) This would be a bug, it should be reported as such, investigated and fixed. On Sat, Nov 12, 2011 at 04:54:48PM -0500, Miroslav Suchy wrote: - Original Message - I'm against this change. The database (PostgreSQL, Oracle XE) is completely independent from the Spacewalk software product and the spacewalk-service script should have no business fiddling with them. Define completely independent. It is not true. Spacewalk use it. As it use apache. And tomcat. And jabber. That's true, Spacewalk uses the database. But the database server is like filesystem or network for Spacewalk. No action of the Spacewalk application (not even its upgrade) requires restart of the database. Unlike apache, tomcat, and (presumably) jabberd -- we modify the configuration of apache, tomcat, and jabberd for Spacewalk to work correctly, and for that we need to restart those services. I - personally - would not spent my devel cycles on it, but Pierre is willing to do that and contribute it. We recommend to run Spacewalk on dedicated machine. And I suppose that most users obey this recommendation. So if there is DB instance, it is very likely dedicated to Spacewalk. But yes, it can be used for other purposes as well. For that reason, I wanted to have this option disabled by default. So current behavior will be preserved. [...] As I said, more user already wanted it. And it is much easier and better for users to code this wrapper once, and leave dozen admins to flip one variable as compared to leave dozens admins to write theirs wrapper. The problem is -- it is likely to become maintenance burden in the long run. Noone but few people will use it because the default will be to have the option off, therefore we won't be testing 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] introducing name for scripts in kickstart profiles in the webinterface
On Tue, Nov 01, 2011 at 04:53:15PM +0100, Tomas Lestach wrote: Great patch! I committed it with minor changes (renamed scriptname to script_name and scriptName) as http://git.fedorahosted.org/git/?p=spacewalk.git;a=commitdiff;h=be7996f4740fd642b1c92068ac96b8abfbd1f1b4 Wonderful, that you've included also the schema upgrade scripts with appropriate sha1s. :-) I second the praise. The only tiny issue was with +++ b/schema/spacewalk/upgrade/spacewalk-schema-1.5-to-spacewalk-schema-1.6/101-add_rhnKickstartScript_scriptname.sql.postgresql @@ -0,0 +1,2 @@ +-- oracle equivalent source sha1 ebfe8df38b1935e67ea3ddd3d5937cef6de9ae91 +alter table rhnKickstartScript add column scriptname varchar2(40); where the PostgreSQL version of the upgrade script needs varchar, not varchar2. I've fixed it now. 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] erratas and the client plugin package action
On Mon, Oct 17, 2011 at 04:05:46PM +0200, Ionuț Arțăriși wrote:
The whole point of this patch for us was so that we could install
suse patches with the special zypper way. In order for that to
happen we need to first check if the server supports this new API
command, so we need a new capability.
So can you please apply this patch? (zypp-plugin-spacewalk currently
depends on this capability being provided to install patches
correctly).
Thank you,
Ionuț
From 35e7d4257942ac91c21d7120ed5d874032629b72 Mon Sep 17 00:00:00 2001
From: Michael Calmer m...@suse.de
Date: Wed, 6 Jul 2011 17:51:04 +0200
Subject: [PATCH] add server capability xmlrpc.errata.patch_names'
---
backend/server/rhnCapability.py |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/backend/server/rhnCapability.py b/backend/server/rhnCapability.py
index 1259747..ad6c306 100644
--- a/backend/server/rhnCapability.py
+++ b/backend/server/rhnCapability.py
@@ -186,6 +186,7 @@ def _set_server_capabilities():
'rhncfg.filetype.directory' : {'version' : 1, 'value' :
1},
'xmlrpc.packages.extended_profile' : {'version' : '1-2',
'value' : 1},
'xmlrpc.packages.suse_products' : {'version' : 1, 'value' :
1},
+'xmlrpc.errata.patch_names' : {'version' : 1, 'value' :
1},
Nack -- it does not apply cleanly in Spacewalk master. We don't have
that xmlrpc.packages.suse_products at all so I'm affraid something is
getting lost in the translation.
Also, you might want to put the comment you have in the mail to the
commit message so that we have the documentation of this capability
preserved at least in the commit message.
--
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Spacewalk and OpenID
On Fri, Oct 14, 2011 at 04:31:21PM +0400, Alexey Vasyukov wrote: We have implemented OpenID authentication option for Spacewalk for our installation. Users logged in with OpenID are automatically added to default organization and have access to public channels. Is anybody interested in it? Is it worth preparing and sending a patch? We would definitely love to review a patch! -- 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] NPE when scheduling a package (install/remove/upgrade) action + remote command
On Tue, Oct 11, 2011 at 01:29:29PM +0200, Johannes Renner wrote: I just found out that your fix for the above bug (BZ#691849) is still lacking something: While scheduling a remote command execution BEFORE a package install or upgrade is working, you will still experience an internal server error when scheduling the remote command to be executed AFTER the package installation. Apply the attached patch to fix it. Applied, 30f431a4e8e145b56e450523922b920f7e24470a. 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] - 741476 API system.getDmi() method does not return data when SYSTEM field at RHNSERVERDMI table is null
On Wed, Oct 05, 2011 at 05:04:28PM -0300, Marcelo Moreira de Mello wrote:
On 10/05/2011 04:03 AM, Jan Pazdziora wrote:
Nack.
The first part of your patch reverts change for bug 452956. Unless we
know *exactly* why that change was done for that bug (in other words,
reproduce that original bug, without that patch), we risk a regression
here.
The second part of your patch seems like a noop to me since
StringUtils.defaultString is defined as
Returns either the passed in String, or if the String is null,
an empty String ().
already.
After reviewing the patch follow attach a better looking patch for
this bug. Doing our tests, this patch does not include a regression for
bug 452956.
.../frontend/xmlrpc/serializer/DmiSerializer.java |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
a/java/code/src/com/redhat/rhn/frontend/xmlrpc/serializer/DmiSerializer.java
b/java/code/src/com/redhat/rhn/frontend/xmlrpc/serializer/DmiSerializer.java
index 7fb29ad..1710c2d 100644
---
a/java/code/src/com/redhat/rhn/frontend/xmlrpc/serializer/DmiSerializer.java
+++
b/java/code/src/com/redhat/rhn/frontend/xmlrpc/serializer/DmiSerializer.java
@@ -60,7 +60,7 @@ public class DmiSerializer implements
XmlRpcCustomSerializer {
Dmi dmi = (Dmi) value;
if (dmi.getSystem() == null) {
-return;
+dmi.setSystem();
}
bean.add(vendor, StringUtils.defaultString(dmi.getVendor()));
I still don't think the patch is correct. There is no point in
dmi.setSystem'ing the system -- the StringUtils.defaultString will do
the trick for the output, without modifying the value, which could
potentially cause hibernate want to store it back to the database.
I believe the correct fix is to remove that
if (dmi.getSystem() == null) {
test and branch altogether but if you do that, you need to find out
what is the alternate fix for the bug 452956 in the first place.
It might be the bios thing, it might be something different.
--
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] - 741476 API system.getDmi() method does not return data when SYSTEM field at RHNSERVERDMI table is null
On Tue, Oct 04, 2011 at 07:13:31PM -0300, Marcelo Moreira de Mello wrote: Hello Team, Follow a patch addressed to BZ at $subject. Created an test package and worked as expected. After applied the patch, the results work as expected. Nack. The first part of your patch reverts change for bug 452956. Unless we know *exactly* why that change was done for that bug (in other words, reproduce that original bug, without that patch), we risk a regression here. The second part of your patch seems like a noop to me since StringUtils.defaultString is defined as Returns either the passed in String, or if the String is null, an empty String (). already. -- 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] 1, y, true, yes, on etc
On Mon, Sep 26, 2011 at 09:05:00AM +0200, Jan Pazdziora wrote: On Fri, Sep 23, 2011 at 05:32:40PM +0200, Bo Maryniuk wrote: Besides, I would also argue about /etc/rhn/default/* existence that is *meant* to be edited according to FHS[1], while Spacewalk says Do not do this. Actually entire rhn is in the wrong place inside the /etc directory, because it should be /etc/opt/rhn/... actually. :) Patches were welcome for quite some time -- we track this as bug 621531. It's now addressed in Spacewalk master and will be in Spacewalk nightly repos by EOB today. -- 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#737697 rhn_check fails to deploy some files when the configuration channel have some other files which does not have a valid UID/GID
On Fri, Sep 23, 2011 at 12:09:39PM -0300, Marcelo Moreira de Mello wrote: Yes. rhncfg-client get complains and print into the screen the files which were not able to be deployed. Although, we can see a lot of sysadmin using the rhncfg-client get at %post section in their kickstart, where they will not be able to see such warning too. In this case per example, we have a customer which expects that rhn_check works deploying half of files, but I do agree with you that in some other cases, we don't want the machine to be left in an inconsistent state. I think that we can offer to the users an option to make such behavior with a tunable parameter. Per example, we can add a new option at rhn-actions-control --enable-half-deploy or --enable-unbatch which turns rhn_check able to perform unbatched deployments. Please, check the comment https://bugzilla.redhat.com/show_bug.cgi?id=737698#c1 regarding the customer's expectations. What do you think? My preference would be to keep the current rhn_check (strict) behaviour and change the rhncfg-client get behaviour to - default to the current behaviour on terminal and to strict behaviour of stdout is not a terminal; - have command-line option to force either the strict or non-strict behaviour. -- 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#701344 package profile sync fails if package name has non-ascii char like ® in it
On Thu, Sep 15, 2011 at 07:55:54PM +0530, Paresh Mutha wrote:
Hello,
We had a bugzilla #701344 opened on RHN Satellite where package
profile sync would fail if the package name has non-ascii chars in
it. I have created a patch on this issue.
As it applies to spacewalk as well, I have attached the patch for it.
Regards,
Paresh
From 48288da277e514411ee6ada4ac8d8ca4cf5979a2 Mon Sep 17 00:00:00 2001
From: Paresh Mutha pmu...@redhat.com
Date: Thu, 15 Sep 2011 19:23:31 +0530
Subject: [PATCH 3/3] Fix to handle non-ascii chars in package name
Signed-off-by: Paresh Mutha pmu...@redhat.com
---
backend/server/rhnServer/server_packages.py |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/backend/server/rhnServer/server_packages.py
b/backend/server/rhnServer/server_packages.py
index 29e6b87..6129597 100644
--- a/backend/server/rhnServer/server_packages.py
+++ b/backend/server/rhnServer/server_packages.py
@@ -24,6 +24,7 @@ from types import DictType
from spacewalk.common import log_debug, rhnFault, rhn_rpm
from spacewalk.server import rhnSQL
from server_lib import snapshot_server, check_entitlement
+from types import UnicodeType
UNCHANGED = 0
ADDED = 1
@@ -46,6 +47,8 @@ class dbPackage:
for k in ('name', 'version', 'release', 'epoch', 'arch'):
if pdict[k] == None:
return None
+if type(pdict['name']) == UnicodeType:
+pdict['name'] = unicode.encode(pdict['name'],'utf-8')
I don't like the fact that you are taking a perfectly valid Unicode
string and convert it to a stream of bytes. You should only do that
when you are ready to output the value to an environment which cannot
handle the Unicode strings or which is binary/byte-oriented.
Looking at the bug 701344, you should really investigate what
operation it is that fails, not do a wholesale change of the type.
Nack for now.
--
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] New tracker bug spacewalk-rfe
Hello, I've created new tracking bug spacewalk-rfe and I've moved all unaddressed RFE bugs under this tracker, from space16. The idea is that RFEs will likely take longer time before we have a patch, and changing the space14 to space15 to space16 to space17 blockers gets old, and it does not really mean any progress is made anyway. If you file an RFE or determine that bugzilla is an RFE, please put RFE to the start of this bug's summary line and make this bug block spacewalk-rfe. 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] Duplicate files in perl-NOCPulse-Probe
On Thu, Sep 08, 2011 at 02:08:34PM +0200, Ionuț Arțăriși wrote: Hi, I found more duplicate files. SQLPlus.pm is present in both the main package and the -Oracle subpackage of perl-NOCPulse-Probe. Applied in Spacewalk master as cce816cab750170ad7a58921134c79b0ee9e0a92. 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 27, 2011 at 03:47:39PM +0200, Ionuț Arțăriși wrote: Adding a char to varchar2 definitions would then be step to, and piece of cake. Hm... writing another tool to do what chameleon currently does seems like a massive undertaking. Kudos to Michal Mráka who did just that. The Spacewalk master/nightly build process is now chameleon-free, so if you like, we can move forward with adding the CHAR declaration to the schema definition -- I'll be happy to review a patch. In the patch, you'll also need to amend spacewalk-oracle2postgresql to remove the CHAR from the declaration as PostgreSQL does not support it, and add schema upgrade scripts to modify existing installation. Well, before working on the patch, we should probably decide if the changes should only touch columns where you've already hit the problem, or if you want to change all VARCHAR2 columns in the database. We have multiple columns like LABEL where we only allow limited subset of US-ASCII (typically a-zA-Z0-9_ or something similar), so there it might actually be usefull to keep it BYTE (and explicitly declare it as BYTE) and perhaps also add a CHECK constraint which will enforce this limited subset on the column. -- 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 Thu, Jul 28, 2011 at 05:10:51PM +0200, Duncan Mac-Vicar P. wrote: On 07/28/2011 04:18 PM, Jan Pazdziora wrote: 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. I built slfj without maven. I can make sure it builds on Fedora/RHEL as well if you need it. We actually build lot of Java packages un-mavenizing them first using the maven ant:ant plugin, and then adding this tarball of build.xml to the source list. Maven is nothing you want in your build toolchain. Right. Well, I'll let Tomáš chime in. Currently, spacewalk-slf4j seems to work for Spacewalk's needs but if the standard full slf4j does not bring too much dependency cruft (both buildtime and runtime), we might want to go for it and use your .spec. -- 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] Question about kickstart registration key
On Fri, Aug 26, 2011 at 01:32:14PM +0200, Uwe Gansert wrote:
if I create a kickstart file with the web ui (not uploading but clicking
through the wizard) and I use that profile, a uniq registration key is
created
for that kickstart session (like 1-bde5342234e)
That key is stored together with the reregistration key (re-..) in the
table RHNACTIVATIONKEY which is the connection to the kickstart session.
As far as I can see, the key is for example used to track the installation
state of virtual machines. If the machine registers with that key, the
installation is tagged as finished.
If you don't use the wizard but upload a kickstart profile or an autoyast XML
file, that tracking does not work. No key is created because in
KickstartScheduleCommand.java there is:
if (!cobblerOnly) {
kickstartSession = this.setupKickstartSession(packageAction);
KickstartData data = getKsdata();
if (!data.isRawData()) {
storeActivationKeyInfo();
}
}
if (!data.isRawData()) prevents the key creation - so it happens on purpose
that no key is created for uploaded profiles.
My questions now are.
1. installations with uploaded kickstart files can not be tracked. They will
never finish. Is that wanted or a bug?
I'd say it's a side-effect of the approach we use -- if you upload a
kickstart profile, it will not contain the correct rhnreg_ks in
it to use the activation key, and in the pre-cobbler era we even did
not have snippets to somehow get it in.
2. I think about removing the if-clause above and always create such a key.
Do you see a problem with that? I'm not 100% sure why that restriction to
uploaded kickstart profiles was made. Maybe there is good reason not to
create
a key for it.
That change would require a change in the 'spacewalk/redhat_register'-Snippet
like (just a suggestion)
if [ -n $registration_key ]; then
redhat_management_key=$redhat_management_key,$registration_key
fi
if [ \$key ]; then
rhnreg_ks --serverUrl=$endpoint --sslCACert=$mycert --activationkey=\$key,
$redhat_management_key
else
rhnreg_ks --serverUrl=$endpoint --sslCACert=$mycert --
activationkey=$redhat_management_key
fi
the variable $registration_key is new and can contain the real key that is
used to register a system in the variables of an uploaded profile.
What do you think about that?
Did I overlook something?
I don't think you have. If the approach works in your tests, we'll
love to see a patch. ;-)
--
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 23, 2011 at 06:26:18PM +0200, Bo Maryniuk wrote: The main core of the logger is a separate daemon that serves XML-RPC listener to a localhost only. Then each software component in the Spacewalk is going to send an logging event message through it. Currently, every Spacewalk component talks to one datastore, the underlying database. Why cannot that component log directly to the database to which it already has open connection, rather than trying to log to another daemon which might be down? Logging to the underlying database has the additional benefit of being transactional if you need it to be -- if the action did not take place for whatever reason and it was rolled back, so will the logging event, unless you decide to explicitly commit it, potentially in an autonomous transaction. Daemon is designed in a queue fashion, where request gets immediate response, message is accepted inside an embedded database and then processed accordingly. This way it won't impact software components performance. What if the daemon is down? Will it stop Spacewalk components from working? The API for XML-RPC are intentionally generic: they accept a login ID, a string message and a key/value map. While first two parameters are pretty obvious how to use, Nope. What is the login ID supposed to represent? Impact on a Spacewalk Entire Spacewalk components are going to be altered, where each audit-able action will perform a call. Please give me an example of three different events / code points that you would consider an auditable action. Q: Why not AMQP or other messaging? A: We considered that. But concluded that we rather want it small, straightforward and simple, available everywhere: http://goo.gl/usti8 :) So, what is the size of that daemon and its plugins, compared to AMQP? I'd rather not have yet-another-message-queue system in Spacewalk to maintain when there are already multiple open-source project achieving similar task. If the architecture is generic enough, you should be able to use AMQP instead, shouldn't you? So why not start with using AMQP as the daemon, and making your daemon optional? Q: Why not just another log appender? A: We believe it should be generic, agnostic and reliable. Hence the embedded database and thread black magic are involved among other things. :) I'd consider embedded database and thread black magic to be in direct conflict with the reliable requirement. We are going to open it under Apache Licence 2.0 and contribute back to If the patch should have any chance of being included in Spacewalk upstream, it has to be under GPLv2 as well, since according to http://www.apache.org/licenses/GPL-compatibility.html those two licences are not compatible. the community along with a mega-patch for Spacewalk 1.2 base. it the patch should have any chance of being included in Spacewalk upstream, it has to be a stream of patches again Spacewalk master, not against Spacewalk 1.2. In other words, unless the patch applied without conflicts to Spacewalk master (in which case you'd probably make it a patch against master in the first place), I doubt there will be many people willing/capable of forward porting the changes. -- 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 Wed, Aug 24, 2011 at 01:49:27PM +0200, Bo Maryniuk wrote: On 08/24/2011 01:20 PM, Tomas Lestach wrote: what was the original use/business case for the audit logging add-on? To know who did what, when and from where. 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 do you plan to present the audit information? I plan to send it where it is needed in the way the destination is asking. So it depends. Yes but for the feature to be easily consumable by the system administrators and/or auditors, in needs to have some sort of presentation in the WebUI and possibly be available over API or in reports. We already have something like that in the rhnserveraction and rhnserverhistory tables and in the /network/systems/details/history/history.pxt?sid=sid Web page -- do you plan to amend 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
