Re: [Spacewalk-devel] Fwd: Package: rhnpush-5.5.71-2.fc21 Tag: f21-rebuild Status: failed Built by: ausil
On Mon, Jun 09, 2014 at 09:40:41AM -0400, Stephen Herr wrote: > I've been looking at rhnpush recently, I'll fix it up. I think the fix needs to go to the pylint rules to turn those checks off -- some of the whitespace errors seem quite absurd and would mean changing big chunks of code just for the sake of changing it. -- 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] 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
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 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
[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 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 or +-- implied, includ
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
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] pltcl question
and ROLLBACKs, or I hope we are doing it in the tomcat context at least. > anyway be sure that it is called before any operation that could involve > logging; Before the first operation that could involve logging, setLogAuth is actually more 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] [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] [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] 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- > > 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] Twitter Bootstrap: Standardizing the CSS framework?
On Fri, Jul 26, 2013 at 03:06:47PM +0200, Duncan Mac-Vicar P. wrote: > > Yes, we do all development on SUSE Manager and then rebase against > master what we want to upstream. It makes total sense. It may make sense from SUSE's point of view. Not sure it makes sense from upstream project health point of view. > - Spacewalk code is very "distro" oriented. In what way? In the way that the team tries hard to release binary signed rpms with each release to allow the administrators just upgrade the software without having to compile it? > It is not possible right now > to "run" it from the source tree. What are the patches to make it possible? > It needs packaging and "productizing" > in order to run it. We figured that's exactly how our users would want to use it. > Spacewalk is very tied to Fedora in this regard. Not really -- all recent Spacewalk releases were done both on Fedoras *and* on RHEL 5 and 6. > Running vanilla Spacewalk on SUSE would be a big effort and %ifdefs in > the spec files (like they are in our tree. /srv/www vs /var/www anyone) Why didn't you send those %ifdefs for review? If this is the only thing which blocks you do do Spacewalk vanilla releases on SUSE, I'm sure the Spacewalk team will be happy to consider those patches for master. > - If you do a feature in Spacewalk master, you just do it and commit it. > We have to ask for review and then the feature may not be accepted. > Therefore the inverse work-flow, cherry-picking in our tree what looks > good to upstream, makes more sense. There are SUSE developers who have commit access to Spacewalk git, based on their history of providing sensible bug fixes and contributions. Trust is built over time. If you start with small fixes and features, if the patches are clean against master and they are correct and not disturbing the rest of the Spacewalk, you will build trust for future big changes that you may have planned. > - Stuff like porting pages, happened as the side-effect of features we > will have anyway in our tree but we don't know yet if we will be > accepted upstream, The longer you wait and the longer you hack in your tree, the bigger the patchset will be when you decide to show ti upstream, and the harder will be for upstream to easily accept the feature. > so we can't start the other way around, and we can't > decide whether we do or not a feature based on whether upstream will > take it or not (like it happened with SSH push). Check that communication again. I raised some general questions about the overall client -- server mechanism, issues that we saw with it in the past, and how it could be improved. I did not see answer that would indicate willingness to work on existing issues to improve the situation and maybe get the ssh push feature in as a well aligned part of the future setup. It was presented as mostly additional code which increased the complexity of the code (duplication of the scheduling functionality), solution that you propose in one form without being prepared to contribute to improving the overall setup. > We should really figure out a "run from source" here :-) In the Spacewalk team, some developers run Spacewalk in their developer's setup which I assume is equivalent to the "run from source" wish. It's not my preferred approach as it in the past lead to different setup being used than what we then released to users, leading to missed bugs. However, I can well understand the desire to do so for some reason, so if there are any patches to make it easier, just submit them for review. -- 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] L10N : translation of spacewalk java frontend blocked on Transifex
On Fri, Apr 12, 2013 at 02:58:09PM +0200, Jan Pazdziora wrote: > 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 Ummm. *Now*. > https://fedora.transifex.com/projects/p/spacewalk/resource/java_java/ > https://fedora.transifex.com/projects/p/spacewalk/resource/java_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] 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] SSH Push Feature Proposal
y targeted fashion. The IT of that organization would still need to allow access _to_ the DMZ to sshd ports on those machines. You can always have Spacewalk Proxy in DMZ2, having client talk to the proxy and that proxy to the Spacewalk, if your IT does not want to open the ports in the DMZ configuration directly. In both cases, the HTTP requests run by rhn_check / yum will end up on that Spacewalk server 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] [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] 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
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
[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
Re: [Spacewalk-devel] [PATCH] - BZ#836984 - fixes the permissions on /var/log/osad log file
On Thu, Dec 06, 2012 at 04:00:52PM -0200, Marcelo Moreira de Mello wrote: > On 12/06/2012 03:42 PM, Marcelo Moreira de Mello 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) -- 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 on BZ 838033
On Tue, Oct 09, 2012 at 09:33:11AM +0200, Pierre Casenove wrote:
> Hello list,
> I've opened and analyzed this BZ during summer.
> As this BZ is a blocker to me (in order to deploy Spacewlak on solaris
> clients), I would like to help resolve it.
> >From my point of view, this BZ can be adressed in 2 ways (see comment #3):
> - Remove the couple of lines in the client code creating the ZipFile object
> - update python to version 2.6 in the Solaris packages
>
> Which solution do you prefer? If you prefer to rebase the Solaris
> client on latest code version et python 2.6, I can't do it, mais I can
> test the resulting packages.
> In case you prefer the first one, I can come up with a patch.
I prefer getting rid of that ZipFile object if possible, and either work
with that "tdir" directory, or amend that unzip operation to give use
the first file (dir?) name in that zip (which is what the
zf.namelist()[0].split('/')[0]
line seems to achieve).
--
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] http service fails to start after space walk installation
On Mon, Nov 19, 2012 at 04:32:18PM +, Bolaji Jibodu wrote: > Hello; > I just encountered some problems trying to start the apache service after the > installation of spacewalk application. I followed the official instructions > on https://fedorahosted.org/spacewalk/wiki/UserDocs which ran through smootly > but I am unable to diagnose the error it throw up below. > > I have the ipaddress and the hostname added to the /etc/hosts file. When I > add ServerName as localhost on the httpd.conf file and try to start the > apache service it just states that the service failed without any errors. The > error below is generated without having the ServerName directive on the > http.conf file. Any help would be apprieciated... many thanks > > [root@ld-sw-pup tomcat6]# service httpd start > Starting httpd: httpd: Could not reliably determine the server's fully > qualified domain name, using ld-sw-pup.acas.com for ServerName >[FAILED] Check /var/log/httpd/*error_log*. I suspect the problem is not related to that "Could not reliably ..." 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] [PATCH] extend API call errata.setDetails to support issue_date and update_date
On Thu, Nov 15, 2012 at 06:37:37PM +0100, Tomas Lestach wrote: > On Wednesday 14 of November 2012 16:09:59 Jörg Steffens wrote: > > > > currently, the API allows to create and modify most attributes of > > erratas, but the functionality for setting the issue- and update-date is > > missing. > > > > The first attached patch adds this functionality to the API call > > errate.setDetails. > > I committed both patches to spacewalk. > > http://git.fedorahosted.org/cgit/spacewalk.git/commit/?id=4d2c9204d5e91e0ed76060a47ac8d3e1c6e84603 > http://git.fedorahosted.org/cgit/spacewalk.git/commit/?id=b0524cc7fa1de90398e8b7d3762555324dd5c4f5 And it broke the checkstyle: https://koji.spacewalkproject.org/koji/taskinfo?taskID=116265 :-( -- 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] Spacewalk 1.8 was branched
Hello, new branch SPACEWALK-1.8 was created to become Spacewalk 1.8. Master is now open for changes going to Spacewalk 1.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] 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] Inconsistency in xmlrpc ChannelSerializer
On Thu, Oct 25, 2012 at 10:14:22AM +0200, Michael Calmer wrote: > > > How hard would it be to move to (say) Apache XML-RPC which supports > > nil? > > Hmm, is "nil" part of the standard or very typical? I think we should take It's an extension. > care also of the client side. If there are a lot of client libs not > supporting > "nil", we should not do such a change. True. -- 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] Inconsistency in xmlrpc ChannelSerializer
On Wed, Oct 24, 2012 at 12:57:47PM +0200, Michael Mraka wrote: > Michael Calmer wrote: > % Hi, > % > % a user found an inconsistency in the ChannelSerializer. > % > % Calling channel.software.associateRepo() return a channel struct > % which contains the key "yumrepo_last_sync". It is documented as > % dateTime.iso8601 . But the result for a "never synced" channel is an empty > % "string". > % > % The reason can be found in > % java/.../rhn/frontend/xmlrpc/serializer/ChannelSerializer.java Line 125 > % > % In case getLastSynced() returns null, an empty string is added via the > helper > % and not a Date object. > % > % I see two possible fixes: > % > % 1) return "new Date(0)" instead of an empty string (01/01/1970) > % > % 2) break the API and declare "yumrepo_last_sync" as optional and do not > return > %this key in case the repo was not synced yet. > % > % Which fix would you prefer? Are there other possible fixes? > > Hi Michael, > > the second option is the preferred one. How hard would it be to move to (say) Apache XML-RPC which supports nil? -- 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 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 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=$user&password=$password&ssl=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] 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 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] 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] 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] [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] 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] 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:///help/copyright.pxt > https:///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 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] 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 \ 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 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] [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 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] Bootstrap image feature
On Wed, Aug 01, 2012 at 10:42:16AM +0200, Uwe Gansert wrote: > Hi, > > during hackweek here at SUSE, I did a feature for bootstrapping new > machines with Spacewalk/SUSE Manager. > It works so far but I'd like to show it to you and ask if you are > interested in the feature and what you think in general about it. > > I introduced the feature here: > http://suse.gansert.net/?p=542 > > maybe you can tell me what you think about it? Uwe, it looks very cool. Do you have a stream of patches for 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] 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] 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] [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] [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 () : > to_date = 2007-03-03 00:00:00 () > Traceback (most recent call last): > File "./spacewalk-clone-by-date", line 231, in > 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] Added systemd unit files
On Fri, Apr 13, 2012 at 02:40:33PM -0300, Pablo Hess wrote: > > In the past, we've faced issues with tomcat when starting it -- the > > service tomcat6 start would return even if the applications weren't > > loaded yet, so any HTTP/ajp request would fail. See the lsof hack in > > spacewalk-service. How is this issue addressed in the proposed systemd > > approach? > > The current approach doesn't address this, but we could use systemd's > socket functionality: systemd itself is able to open the socket and > queue incoming requests, only releasing them for processing when the > consumer side (tomcat6) comes up -- xinetd style. Would this be acceptable? I don't like changing the way tomcat6 operates, compared to its default setup in the operating system. -- 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: > > | CL- > CL | CM > CM | CN > CN | CO > ...| ... Or 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] Added systemd unit files
On Mon, Apr 02, 2012 at 06:42:40PM -0300, Pablo Hess wrote: > Hello Folks, > > In an effort to port Spacewalk's sysV init script to the > all-new-and-shiny systemd, Marcelo Mello and I have created quite a few > "unit files" (systemd speak for init script). > > Due to service dependencies, we want to propose a new layout to make > it compatible with the systemd approach. [...] > Current status > > > Currently, the main spacewalk unit file (spacewalk.target) issues > start/stop/restart/reload commands to all its dependencies. However, > spacewalk-tomcat6.service is facing a few issues when stopping: In the past, we've faced issues with tomcat when starting it -- the service tomcat6 start would return even if the applications weren't loaded yet, so any HTTP/ajp request would fail. See the lsof hack in spacewalk-service. How is this issue addressed in the proposed systemd approach? -- 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] Outstanding patches? Send them in.
On Sun, Mar 25, 2012 at 01:39:35AM +0100, Jonathan Hoser wrote: > Hi again, > > am working on a fresh installation of SW 1.7, > > and again encountered the issue I suggested a patch for. > This time, I applied the suggested variant > "Select label from [...]" and it is working all the same. > > It is triggered on a rhn_register call from a client. > Please find the corresponding patch attached. Thank you, applied to Spacewalk master as 412087e1d1e3714c76c0fce72a9ca8a94897a5de -- I've just tweaked the commit message to match what we are doing here. > Btw - is it just me or is the auto deployment of rhn-* client libs > from SW-generated kickstarts *really* lacking? > I only see it trying to install pyOpenSSL, libxml2-python and rhnlib - > my take is that these are definitly not sufficient for running the > KS-included step of > "Red Hat management server registration" as obviously the above don't > install the rhn_register > and other binaries. > > Maybe I'm doing something wrong, but I really expected this to work > out-of-the-box without respecifying the rhn-* client rpms to install. Supporting the general situation is obviously more complex than targetting just RHELs, which is where the code comes from. What is your proposal? -- 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
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
[Spacewalk-devel] Spacewalk 1.7 released
Hello friends of the walks in space, we are happy to announce the release 1.7 of Spacewalk, a systems management solution. The download locations are * http://spacewalk.redhat.com/yum/1.7/RHEL/5/$basearch/ * http://spacewalk.redhat.com/yum/1.7/RHEL/6/$basearch/ * http://spacewalk.redhat.com/yum/1.7/Fedora/15/x86_64/ * http://spacewalk.redhat.com/yum/1.7/Fedora/16/x86_64/ with client repositories under * http://spacewalk.redhat.com/yum/1.7-client * http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/1.7/openSUSE_11.4/ * http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/1.7/openSUSE_12.1/ * http://download.opensuse.org/repositories/systemsmanagement:/spacewalk:/1.7/openSUSE_Factory/ * http://miroslav.suchy.cz/spacewalk/debian For fresh installations, please use steps from * https://fedorahosted.org/spacewalk/wiki/HowToInstall If you plan to upgrade from older release, the following page can be helpful: * http://fedorahosted.org/spacewalk/wiki/HowToUpgrade Features & Enhancements in Spacewalk 1.7 * Monitoring is now working on the PostgreSQL database backend, making both database backends feature-comparable * OpenSCAP integration -- for details, see https://fedorahosted.org/spacewalk/wiki/Scap * Fully asynchronous clearing of orphaned monitoring data * Stock rhnpush is able to push debian packages * New spacewalk-clone-by-date tool * Numerous spacecmd enhancements * Improved messages printed when certificate activation fails * Modified API calls: * channel.software.getDetails returns empty strings instead of omitting attributes * configchannel.createOrUpdatePath, createOrUpdateSymlink, getEncodedFileRevision, getFileRevision, getFileRevisions, lookupFileInfo, system.config.createOrUpdatePath, createOrUpdateSymlink, lookupFileInfo, and system.provisioning.snapshot.listSnapshotConfigFiles now return contents_enc64 field which identifies whether contents is Base64-encoded * system.comparePackages and system.comparePackageProfile return package_arch value * system.provisionVirtualGuest default values now match those on the WebUI * New API calls: * configchannel.getEncodedFileRevision * system.scap.scheduleXccdfScan The up-to-date API documentation can be found at * http://spacewalk.redhat.com/documentation/api/ Contributors Our thanks go to the community members who contributed to this release: * Aron Parsons * Jiří Mikulka * Joerg Steffens * Joshua Roys * Michael Calmer * Pierre Casenove * Simon Lukasik * Speagle, Andy * Steven Hardy * https://fedorahosted.org/spacewalk/wiki/ContributorList You can view the history of Spacewalk from its start to 1.7 at * http://www.youtube.com/watch?v=jsx6cGmBtzg Some statistics In Spacewalk 1.7, we've seen * 49 bugs fixed * 1246 changesets committed * 1581 commits done Reporting errors To report issues with Spacewalk, please use mailing list spacewalk-l...@redhat.com to reach the user community. We might ask you to file bugzilla at http://bugzilla.redhat.com/ with more details or full logs. From now on, errors related to PostgreSQL database backend are considered bug defects vs. missing capabilities. Thank you for using Spacewalk. -- 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
[Spacewalk-devel] Outstanding patches? Send them in.
Hello Spacewalk hackers, it's that time of year again -- we are aiming for the next Spacewalk release. If you have a patch in stash which you'd like to see included, don't wait any longer and send it to the mailing list (or push it if you have commit access and you are comfortable with your changeset). 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] Review patch for satellite-sync performance increase on PostgreSQL
On Wed, Feb 01, 2012 at 08:01:19PM +, Parsons, Aron wrote: > I'm not sure if anyone else is using satellite-sync with PostgreSQL, but it's > quite slow when diffing packages; almost unusable right now. I wanted to run > by a possible fix with everyone since the sync code is somewhat complicated > and I'm not super-familiar with all of it. > > diff --git a/backend/satellite_tools/satsync.py > b/backend/satellite_tools/satsync.py > index 488d23e..b391200 100644 > --- a/backend/satellite_tools/satsync.py > +++ b/backend/satellite_tools/satsync.py > @@ -884,13 +884,14 @@ Please contact your RHN representative""") % > (generation, sat_cert.generation)) > _query_compare_packages = """ > select p.id, c.checksum_type, c.checksum, p.path, p.package_size, > TO_CHAR(p.last_modified, 'MMDDHH24MISS') last_modified > - from rhnPackage p, rhnChecksumView c > - where p.name_id = lookup_package_name(:name) > + from rhnPackage p > +inner join rhnPackageName pn on pn.id = p.name_id > +inner join rhnChecksumView c on p.checksum_id = c.id > + where pn.name = :name > and p.evr_id = lookup_evr(:epoch, :version, :release) > and p.package_arch_id = lookup_package_arch(:arch) > and (p.org_id = :org_id or > (p.org_id is null and :org_id is null)) > - and p.checksum_id = c.id [...] > I noticed 'lookup_package_name' creates a new record in rhnPackageName if > it's not found, but 'satellite-sync' will create that record just fine later > on for non-existent package names (I assume from another call to > 'lookup_package_name', I didn't actually look, just tested syncing with > unique package names). Since that is the case, I don't see any detrimental > effects from this fix. Let me know if you see anything wrong with it. > Well, you won't get records for new packages with your change -- it's exactly the lookup_package_name which causes the rhnPackageName to become populated. It's not about the record being populated later -- the main problem is that the semantics of this _query_compare_packages SQL would become different with your 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] 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] 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] 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 = <= evr_new.evr
+ )
OR AT.label = 'solaris-patch'
OR AT.label = 'solaris-patch-cluster'
)
@@ -709,7 +708,7 @@ EOQ
elsif ($package_id) {
$query = <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 "", line 1, in > 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 02:38:54PM -0500, Eric Lake wrote: > On Wed, Dec 21, 2011 at 2:26 PM, Jan Pazdziora 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] Taskomatic not working after moving from oracle-xe to postgres
On Wed, Dec 21, 2011 at 02:20:16PM -0500, Eric Lake wrote:
> On Wed, Dec 21, 2011 at 1:46 PM, Jan Pazdziora wrote:
> > 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.
>
> Looks like the line was there but the value was not 1330170. So the
> import process pulled in what was in the dump correctly. Not sure why
> the value was low in the dump though.
>
> grep "select pg_catalog.setval('rhn_tasko_template_id_seq', "
> spacewalk-oracle-10-24-11.dump
> select pg_catalog.setval('rhn_tasko_template_id_seq', 1329890, false);
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.
--
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 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] 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 08:09:03AM -0500, Eric Lake wrote:
> On Wed, Dec 21, 2011 at 5:57 AM, Tomas Lestach 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] [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] [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] fix display of static snippets
On Thu, Dec 01, 2011 at 05:30:18PM +0100, Uwe Gansert wrote: > On 01.12.2011 17:08, Jan Pazdziora 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 > >> > >>in the jsp? > > patch attached Thanks, applied to master, 9315f4073f2fa5c50a7b4b8cce0639b0830ea678. -- 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] 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] 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] [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 > > 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] [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] 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] 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ý
> 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 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
