[Spacewalk-devel] FYI: adventures in the AWS jungle
Hey every one,I just did a POC of Spacewalk in AWS and I thought that I would just let everyone know how it went.So first let me say it failed sadly due to a couple of annoying little issues.First I found that it is not compatible with RDS hosted PostgreSQL. Note I did not test wit RDS oracle yet but I may briefly just out of curiosity. this was due to the fact that RDS doesn't give you full superuser privileges it actually leaves a few permission out one of which is needed during installation. For me this wasn't a definite show stopper.The real issue was getting the agent to work on Amazon Linux. A few things popped up first it seems like Amazon Linux even though it's based on RHEL 6 is missing a package python-gudev is not included in Amazon Linux also a few other python dependencies for some reason weren't detected by yum such as python-OpenSSL. I was able to compile python-gudev fairly easily and track down most of the missing dependencies by using "yum provides" but finally there was a dependencies that broke the registration involving a call to hardware_hal that I could not easily track down and that was the clincher for me.That said I did figure out how to handle a number of potential issues for other distributions in AWS.The biggest revelation is autoscaling now you can do lambda functions as part of the Lifecycle of instances. So one of the things that you can do is deregulated instances that autoscaling has terminated via a lambda function there is a catch to this there must be an external database with Metadata about the instance because the only thing the lambda function knows is the instance I'd and can't lookup the data about the instance after its been terminated. Amazon has a lot of well documented examples of this particularly they have an example of how to have autoscaling create and remove CNAMEs in route 53. Registration is easy there are plenty of ways to handle that like via the user Metadata and configuration management tools so I won't get too deep into that.As for the Amazon Linux yum repository that is fairly easy to get imported and the updates reopen includes errata which imported seamlessly.The one problem I found is in the path to the repositories they spit the releases into 9 per year prefixed with the year. Now you can substitute that with "latest" when downloading the mirror list but not on the repositories themselves.This actually raised an issue I've been thinking about for a long time which is why can't we support mirror lists. I plan to write this up a little better in an RFE but the biggest issue there is usually the mirrors have variables that get replaced by yum. If we wanted to clone that behavior in spacewalk-repo-sync then we would probably want to define them as key Value pairs on the channel that way we could use the same mirror list with multiple channels with different architectures and or distribution release numbers.What I did find is in my opinion spacewalk was significantly better than any of the tools being offered by Amazon for patch management so if the agent install issue on amazon Linux can be addresses and maybe we can get a few other minor details ironed out than Spacewalk might become a contender in AWS for patch management in the futureI'll send out some more details on my exact finding in a future email. Sent from my BlackBerry - the most secure mobile device ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Travis CI for Spacewalk git
on the subject Ubuntu I may be creating the client packages for 2.3 on Ubuntu trusty soon if I do I will publish them on launchpad. I'm not sure yet if i will have the time to take over maintaining the packages for Ubuntu but it is a possibility. The problem is I would need to figure out how to handle supporting multiple versions of spacewalk. I was wondering if it would be possible to publish apt repos on yum.spacewalkproject.org using the same structure. On Fri, Jun 5, 2015 at 10:53 AM, Paul Robert Marino prmari...@gmail.com wrote: Any chance you can get it to do deb packages too :) On Fri, Jun 5, 2015 at 10:32 AM, Jan Dobes jdo...@redhat.com wrote: Hello Spacewalkers, as you may already noticed, we enabled Travis CI [1] for Spacewalk Github account several weeks ago. Since then, few bugs were fixed and now it works with every package in our git except some thirdparty packages in 'spec-tree' directory (if they are explicitly requiring Oracle RPMs or are not buildable on Fedora 21 for any reason). The only thing we are testing at the moment is if we are able to build RPM package(s) from sources - yes, we are building RPMs on Travis Ubuntu machines! Basically, it's just syntax check where we are compiling java classes, running checkstyle, pylint etc. It's beneficial mainly for pull request processing - contributor can see why his patch didn't pass and post additional patch shortly, doesn't have to wait days until someone tries his patch and pokes him back. It's also fork-friendly, so you can easily enable building for your own account. Currently, builds are triggered on every new or updated pull request and push into master branch. Only packages affected by these commits will be built. [1] https://travis-ci.org/spacewalkproject/spacewalk Regards, -- Jan Dobes Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Travis CI for Spacewalk git
Any chance you can get it to do deb packages too :) On Fri, Jun 5, 2015 at 10:32 AM, Jan Dobes jdo...@redhat.com wrote: Hello Spacewalkers, as you may already noticed, we enabled Travis CI [1] for Spacewalk Github account several weeks ago. Since then, few bugs were fixed and now it works with every package in our git except some thirdparty packages in 'spec-tree' directory (if they are explicitly requiring Oracle RPMs or are not buildable on Fedora 21 for any reason). The only thing we are testing at the moment is if we are able to build RPM package(s) from sources - yes, we are building RPMs on Travis Ubuntu machines! Basically, it's just syntax check where we are compiling java classes, running checkstyle, pylint etc. It's beneficial mainly for pull request processing - contributor can see why his patch didn't pass and post additional patch shortly, doesn't have to wait days until someone tries his patch and pokes him back. It's also fork-friendly, so you can easily enable building for your own account. Currently, builds are triggered on every new or updated pull request and push into master branch. Only packages affected by these commits will be built. [1] https://travis-ci.org/spacewalkproject/spacewalk Regards, -- Jan Dobes Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [Spacewalk-list] Did any one notice Ubuntu and debian added kickstart support to their installer some time last year
by the way if any one is curious https://help.ubuntu.com/lts/installation-guide/amd64/ch04s06.html has information on the current kickstart compatibility for Ubuntu Trusty it looks pretty close to compatible with RHEL 6 and a lot of whats missing can probably be handled with snippets. https://help.ubuntu.com/lts/installation-guide/amd64/ch04s06.html On Tue, Jun 2, 2015 at 6:44 PM, Paul Robert Marino prmari...@gmail.com wrote: hey Phil I'm testing some of your scripts so far so good. I'm thinking I may if i have time write some patches to some and submit them via a pull request. I gennerally dont like the idea of putting user names and passwords as command line options because they show up in ps and top so in my scripts i alway give users the option to use environment variables for them instead. That said the ones Ive tested so far are working as well or better than I expected. good job! Thanks for publicly publishing them with your blog. I still haven't gotten around to testing adding kickstart distros but I will probably get to it in the next coupe of days. when I'm done I intend to submit a list of RFE's so we can get it to work through the web interface. the first one is already published here https://bugzilla.redhat.com/show_bug.cgi?id=1227499 and there will be more to come. Ive already determined that the list of distros seems to be hard coded in the page and should be moved to the database in fact there are already tables in the database which contain most of the information needed. infact the API uses the database table rhnksinstalltype whats missing from the database is the breed and list of path information. there also seems to be a way to add an externally managed kickstart tree that im looking into next. The more i think about it though the simplest long term solution would be for spacewalk to get this information from http://www.cobblerd.org/signatures/latest.json like cobbler does. could also allow spacewalk in the future to automatically create a distro tree from an ISO image. Does any one else have any ideas on this before I write an RFE? On Tue, May 5, 2015 at 8:17 PM, prmari...@gmail.com wrote: That's awesome but I think you may be able to avoid the changing the url= to ks= issue by using Centos6 instead of 7 as the distro. That said it shouldn't be too hard to update the interface to accept debian and or ubuntu as a valid distro type since cobbler already supports it. Sent from my BlackBerry 10 smartphone. *From: *the.cyp...@gmail.com *Sent: *Tuesday, May 5, 2015 19:55 *To: *spacewalk-l...@redhat.com *Reply To: *spacewalk-l...@redhat.com *Subject: *Re: [Spacewalk-list] Did any one notice Ubuntu and debian added kickstart support to their installer some time last year I wrote a blog post about getting spacewalk to work with kickstarting Ubuntu/Debian. http://www.devops-blog.net/spacewalk/kickstarting-and-provisioning-ubuntu-systems-with-spacewalk Best, Phil Am Dienstag, 5. Mai 2015 um 22:10 schrieb prmari...@gmail.com: It looks like koan is now even included too Sent from my BlackBerry 10 smartphone. *From: *prmari...@gmail.com *Sent: *Tuesday, May 5, 2015 16:07 *To: *Spacewalk Users List; spacewalk-devel *Subject: *Did any one notice Ubuntu and debian added kickstart support to their installer some time last year Hello every one it's been a while. I suddenly found my self working with Ubuntu and was looking through the documentation and it looks like they both support kickstart files now. I also noticed that cobbler has documentation about debian and ubuntu too Sent from my BlackBerry 10 smartphone. ___ Spacewalk-list mailing list spacewalk-l...@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list ___ Spacewalk-list mailing list spacewalk-l...@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [Spacewalk-list] Did any one notice Ubuntu and debian added kickstart support to their installer some time last year
hey Phil I'm testing some of your scripts so far so good. I'm thinking I may if i have time write some patches to some and submit them via a pull request. I gennerally dont like the idea of putting user names and passwords as command line options because they show up in ps and top so in my scripts i alway give users the option to use environment variables for them instead. That said the ones Ive tested so far are working as well or better than I expected. good job! Thanks for publicly publishing them with your blog. I still haven't gotten around to testing adding kickstart distros but I will probably get to it in the next coupe of days. when I'm done I intend to submit a list of RFE's so we can get it to work through the web interface. the first one is already published here https://bugzilla.redhat.com/show_bug.cgi?id=1227499 and there will be more to come. Ive already determined that the list of distros seems to be hard coded in the page and should be moved to the database in fact there are already tables in the database which contain most of the information needed. infact the API uses the database table rhnksinstalltype whats missing from the database is the breed and list of path information. there also seems to be a way to add an externally managed kickstart tree that im looking into next. The more i think about it though the simplest long term solution would be for spacewalk to get this information from http://www.cobblerd.org/signatures/latest.json like cobbler does. could also allow spacewalk in the future to automatically create a distro tree from an ISO image. Does any one else have any ideas on this before I write an RFE? On Tue, May 5, 2015 at 8:17 PM, prmari...@gmail.com wrote: That's awesome but I think you may be able to avoid the changing the url= to ks= issue by using Centos6 instead of 7 as the distro. That said it shouldn't be too hard to update the interface to accept debian and or ubuntu as a valid distro type since cobbler already supports it. Sent from my BlackBerry 10 smartphone. *From: *the.cyp...@gmail.com *Sent: *Tuesday, May 5, 2015 19:55 *To: *spacewalk-l...@redhat.com *Reply To: *spacewalk-l...@redhat.com *Subject: *Re: [Spacewalk-list] Did any one notice Ubuntu and debian added kickstart support to their installer some time last year I wrote a blog post about getting spacewalk to work with kickstarting Ubuntu/Debian. http://www.devops-blog.net/spacewalk/kickstarting-and-provisioning-ubuntu-systems-with-spacewalk Best, Phil Am Dienstag, 5. Mai 2015 um 22:10 schrieb prmari...@gmail.com: It looks like koan is now even included too Sent from my BlackBerry 10 smartphone. *From: *prmari...@gmail.com *Sent: *Tuesday, May 5, 2015 16:07 *To: *Spacewalk Users List; spacewalk-devel *Subject: *Did any one notice Ubuntu and debian added kickstart support to their installer some time last year Hello every one it's been a while. I suddenly found my self working with Ubuntu and was looking through the documentation and it looks like they both support kickstart files now. I also noticed that cobbler has documentation about debian and ubuntu too Sent from my BlackBerry 10 smartphone. ___ Spacewalk-list mailing list spacewalk-l...@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list ___ Spacewalk-list mailing list spacewalk-l...@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Solaris and Monitoring - add deprecation notice for SW 2.2 release
That sounds reasonable. The monitoring never worked as well or as efficiently as I would have hoped it really never got out of beta. We may in the future consider replacing it with something like Nagios integration it wouldn't be too hard if we urilized an include directory directive in the Nagios config. Then we would just need to generate a file per host. that would also be in line with the way RHOS is going because last I looked at it Nagios was the monitoring solution of choice. The loss of the Solaris support would be a shame if it were actively being developed; but considering it doesn't support the latest version of Solaris, and doesn't have a maintainer its completely understandable What I'm really curious about is since I use it is multi-org functionality. Are there any plans to add multi-tenant functionality simmilar to OpenStack Keystone. Right now if I have an admin that has to support multiple orgs (business units/subsidiaries) I need to create an account with a different username for each org they support. It would be extremely useful if they had a drop down list of the orgs they have access to after they login. This way they can just login with a single username and select the org they want to administrate. There is also a buisness case for this functionality on access.redhat.com many companies use third party support companies to supplement their in house IT staff and in these cases it useful for someone at one of these IT support service companies to do the same. This has been discussed many times on this list before and I think most people are in agreement that this or something similar needs to be done but as far as I've seen it hasn't been made a priority. On Tue, Jul 15, 2014 at 7:12 AM, Cliff Perry cpe...@redhat.com wrote: So, we are thinking of removing Solaris and Monitoring from Spacewalk in the future releases. This may be Spacewalk 2.3, or later, but I want to start sharing this idea out and get any feedback from others, if there is objection. As a side note, we will release Spacewalk 2.2 on EL5, (notice was placed that SW 2.1 was last on EL5). This is because we are still working/waiting for EL7 pkgs in EPEL to be ready that will allow us to release future Spacewalk on EL7. Regards, Cliff ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Action Chain XML-RPC API
Interesting Idea
The first thing that pops into my mind is where is the task sequence
number. this looks all well and good but there are going to be times
when for one reason or an other some one will need to update a task or
add a new task in the middle.
Additionally I disagree with the simplified names and my reason is
here https://bugzilla.redhat.com/show_bug.cgi?id=834569
incidentally this is still a valid bug in 2.1 nightly when I last checked.
while it might be nice to give the user a simplified version it can
cause unforeseen problems down the line especially when you mix
multiple distros which may have packages with identical NERVA so its
critical that the programer be able to exactly set the package ID
The same goes for the profile name because in multi-org configurations
you may wind up with multiple hosts with the same name in different
organizations.
you need to make the programer specify the org name or number.
The thing you need to keep in mind is in the future I know many of the
people who have deployed multi-org configurations want the ability to
create mulit-org (or muilti-tenant in cloud speak ) because its often
discussed on the list and I am fairly positive there is at least on
RFE on the subjects. users for example most of my users only need
access to their org which is mapped to their business unit but since I
support them all along with a few others I need access to every org
along with a few colleagues of mine so what we are doing right now is
creating users unique users for our selves in each org which is not
ideal to say the least. also I have other users who provide support
for the systems in two business units because one is a subsidiary of
the other but they still want every thing divided into their own org's
so they at least give the appearance of not having any interdependence
in case they decide to sell or spin off the subsidiary in the future.
If the you add the org id or name now its not a big deal but if you do
not it may force us to preform a root canal on the code later.
Finally my last question is why write a whole task chain scheduler
from scratch? why not consider making a plugin API to integrate with
existing schedulers like JobScheduler for example or any thing
similar.
On Mon, Feb 3, 2014 at 10:32 AM, Bo Maryniuk b...@suse.de wrote:
Hello everyone.
We are developing here Action Chain feature, where you can add some actions
(install/remove/verify/etc package or other things) to the Chain, making sort
of one-shot batch. These actions won't be executed, until you execute the
entire chain.
We are also developing the XML-RPC API for it and they are already working in
our branch. :)
Here how do they look like. For example, in Python you could call:
client = xmlrpc
sid = client.login
# To list them
for chain in client.actionchains.listChains():
print chain.get(name)
# Add some package removal.
# Note: the IP is optional, IPv6 accepted too
client.actionchains.addPackageRemoval(sid,
myfantasticserver, 12.34.56.78,
[{name : alsa-lib, version : 1.0.22,},
{name : some-name, version : 1.2.3.4,},],
My Chain)
# Remove actions from some chain:
client.actionchains.removeActions(My Chain, [Package Install, Reboot])
# Remove the whole chain
client.actionchains.removeChains([My Chain])
You may ask: Why no 101 for system instead? Why no 23445323 instead
for a package? It is simple: you, as an admin in the datacenter, you have an
RPM database, and you can --queryformat it and AWK it the way that your
XML-RPC Python script will understand it right away.
Adding IDs is possible too, but mainly we looked to operate the packages and
systems at human-compatible way.
What you think?
--
Bo Maryniuk
SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg)
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
I find television very educating. Every time somebody turns on the set, I go
into the other room and read a book.
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] On quality of patches
There is an other factor here that no one has mentioned. Recently I've found and reported a lot of bugs in the nightly repo. Where they came from is usually some one updates a portion of the code to fix a specific issue but since a portion of that code is called by multiple parts of the web interface it may break other pages than the one the developer is focused on.I think we need a map of what these shared file and functions effect so we can do more formal QA testing in the future-- Sent from my HP Pre3On Jan 30, 2014 7:33, Duncan Mac-Vicar P. dmacvi...@suse.de wrote: On 30/01/14 11:57, Matej Kollar wrote: Hi all. We welcome community contributions and we want to maintain some level of quality. Natural expectation is that every proposed patch is tested for the functionality. I fully agree with you that this is not acceptable. Now, I think your diagnostic is IMHO neither fair or correct. This does not have to do with the "community contributions" but with the setup of the project itself. We sometimes have sent patches that are very strictly reviewed, sometimes needing change multiple times to get a reviewer happy. Then next day our internal testsuite fails only to realize that someone with direct commit access did a big refactoring and committed very broken code in a big patch that was not reviewed by anyone and which quality was also obviously not the best. We asked ourselves, what is the point of reviewing "some of them"?. Not only code but also design decisions and way of approaching solutions. Sometimes this happens with our own patches, depending on the reviewer, they may get committed faster. The setup of the review process is broken. - All code should be committed in similar units (features/branches) - All code should be able to be reviewed and vetoed by everyone OpenStack has this model working quite successfully. Every patch is reviewed with +1, and they need a certain amounts of ACKS to get committed. Everyone can review and people learn in the process, and it is a great source of inspiration for other projects. We care about quality and you can see that we not only contributed our own testsuite in early 2011 with the first release of our own product, but then focused lot of contributions in having the testsuites enabled and working again. But all this is pointless if the process has holes. Right now it depends on a lot of luck to be useful. We suggested not long time ago in the mailing list to move to a github approach where code could be submitted only with pull-requests that need to be reviewed. Policies could be created that at least 2-3 acks is needed to merge a feature. People can study those reviews and learn in the process. Continuous integration could be setup on top of this process, to have up to date results. But what you are seeing, the process is kind of designed to produce those results, which is a process where code has different ways to arrive to master, which different quality outcomes. -- Duncan Mac-Vicar P. - http://www.suse.com/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] missing dependancies for spacewalk nightly build
I don't know if someone purposely fixed this or there had just been a glitch the night befor in the nightly build but this looks like it has been corrected as of this morning. On Sun, Jan 19, 2014 at 9:49 AM, Paul Robert Marino prmari...@gmail.com wrote: For RHEL 6 the spacewalk nightly build is complaining about 2 missing dependancies -- Finished Dependency Resolution Error: Package: spacewalk-branding-2.1.20-1.el6.noarch (spacewalk-nightly) Requires: font-awesome = 4.0.0 Error: Package: spacewalk-branding-2.1.20-1.el6.noarch (spacewalk-nightly) Requires: roboto = 1.2 I cant find any thing via yum that provides either of these. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] missing dependancies for spacewalk nightly build
For RHEL 6 the spacewalk nightly build is complaining about 2 missing dependancies -- Finished Dependency Resolution Error: Package: spacewalk-branding-2.1.20-1.el6.noarch (spacewalk-nightly) Requires: font-awesome = 4.0.0 Error: Package: spacewalk-branding-2.1.20-1.el6.noarch (spacewalk-nightly) Requires: roboto = 1.2 I cant find any thing via yum that provides either of these. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Patch fixing paths in Perl code
I found a bug in some of the perl pages where there was a link to
/network/systems/details/probes/index.pxt?sid=${sid} instad of the new path to
/rhn/systems/details/probes/ProbesList.do?sid=${sid}
I tracked it down to one of the modules and corrected the path this is
related to but not the actual fix for
https://bugzilla.redhat.com/show_bug.cgi?id=1053787
--- /home/pmarino/spacewalk-code/spacewalk/web/modules/sniglets/Sniglets/Servers.pm.orig 2014-01-15 15:50:09.651061366 -0500
+++ spacewalk/web/modules/sniglets/Sniglets/Servers.pm 2014-01-15 15:51:34.224715046 -0500
@@ -274,27 +274,27 @@
if ($data-{MONITORING_STATUS} eq CRITICAL) {
$ret-{icon} = 'monitoring-crit';
$ret-{status_str} = 'Critical probes';
-$ret-{system_link} = /network/systems/details/probes/index.pxt?sid=${sid};
+$ret-{system_link} = /rhn/systems/details/probes/ProbesList.do?sid=${sid};
}
elsif ($data-{MONITORING_STATUS} eq WARNING) {
$ret-{icon} = 'monitoring-warn';
$ret-{status_str} = 'Warning probes';
-$ret-{system_link} = /network/systems/details/probes/index.pxt?sid=${sid};
+$ret-{system_link} = /rhn/systems/details/probes/ProbesList.do?sid=${sid};
}
elsif ($data-{MONITORING_STATUS} eq UNKNOWN) {
$ret-{icon} = 'monitoring-unknown';
$ret-{status_str} = 'Unknown probes';
-$ret-{system_link} = /network/systems/details/probes/index.pxt?sid=${sid};
+$ret-{system_link} = /rhn/systems/details/probes/ProbesList.do?sid=${sid};
}
elsif ($data-{MONITORING_STATUS} eq PENDING) {
$ret-{icon} = 'monitoring-pending';
$ret-{status_str} = 'Pending probes';
-$ret-{system_link} = /network/systems/details/probes/index.pxt?sid=${sid};
+$ret-{system_link} = /rhn/systems/details/probes/ProbesList.do?sid=${sid};
}
elsif ($data-{MONITORING_STATUS} eq OK) {
$ret-{icon} = 'monitoring-ok';
$ret-{status_str} = 'OK';
-$ret-{system_link} = /network/systems/details/probes/index.pxt?sid=${sid};
+$ret-{system_link} = /rhn/systems/details/probes/ProbesList.do?sid=${sid};
}
return $ret;
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Patch fixing paths in Perl code
I found the fix for https://bugzilla.redhat.com/show_bug.cgi?id=1053787
its in the same file
patch attached which stacks on top of my previous patch to fix the
links in the pages effected.
On Wed, Jan 15, 2014 at 3:57 PM, Paul Robert Marino prmari...@gmail.com wrote:
I found a bug in some of the perl pages where there was a link to
/network/systems/details/probes/index.pxt?sid=${sid} instad of the new path to
/rhn/systems/details/probes/ProbesList.do?sid=${sid}
I tracked it down to one of the modules and corrected the path this is
related to but not the actual fix for
https://bugzilla.redhat.com/show_bug.cgi?id=1053787
--- spacewalk/web/modules/sniglets/Sniglets/Servers.pm.firstpatch 2014-01-15 15:51:34.224715046 -0500
+++ spacewalk/web/modules/sniglets/Sniglets/Servers.pm 2014-01-15 16:34:19.959693643 -0500
@@ -168,7 +168,7 @@
my $ret = {};
if ($data-{LOCKED}) {
-$ret-{icon} = 'fa fa-1-5x spacewalk-icon-locked-system';
+$ret-{icon} = 'system-locked';
$ret-{status_str} = 'System locked';
$ret-{status_class} = 'system-status-locked';
$ret-{message} = 'more info';
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Things that needs to be dobne before next release.
There are still quite a few bugs I've found in 2.1 I'm a little busy right now but I should be able to submit bug reports on Sunday here is one I already put in https://bugzilla.redhat.com/show_bug.cgi?id=1048981 and I can confirm as of the latest nightly build it still isn't fixed. I also have found places where the WebUI crashes and sends traceback emails. one place I can think of right of the top of my head is when you try driiling into a monitoring probe /rhn/systems/details/probes/ProbeDetails.do that always crashes in 2.1. and I know there are a few more that crash as well. also this isnt a new bug its been around for a while I just havent had the time yet to figure out if it effects only the WebUI or if it effect the command line as well, when you delete a channel if it has a scheduled reposync it never delets the sync from taskomatic so you get 2 emails one saying that a reposync bundle failed and then an other saying its working again. sofar the only way ive found to fix this when it happens is to go into the database and manually delete the job from the tables. On Thu, Jan 9, 2014 at 10:14 AM, Silvio Moioli smoi...@suse.de wrote: On 01/09/2014 01:26 PM, Matej Kollar wrote: * Bare-metal systems management Some more automatic tests are being worked on in SUSE Manager by my colleague Martin Seidl. I will commit patches for any bug that is discovered if it also affects Spacewalk. Apart from that, coding is considered finished SUSE Manager side, and I also consider the Spacewalk rebase basically finished - please report any defects or issues that block upstreaming so that I can try to find a solution. Thanks, -- Silvio Moioli SUSE LINUX Products GmbH Maxfeldstraße 5, 90409 Nürnberg Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] [PATCH] Avoid a possible concurrency issue on RhnSet update
I'm a little rusty on my Oracle but in PostgreSQL I think this could be resolved using the Isolation level within the transaction, and possibly snapshots within the transaction http://www.postgresql.org/docs/9.2/interactive/sql-set-transaction.html An other possibility is to request an exclusive lock could be requested for queries which have this potential but that method should be avoided if possible. On Tue, Sep 3, 2013 at 8:33 AM, Tomas Lestach tlest...@redhat.com wrote: Hello Silvio, to be honest, I personally do not like seeing DB index names in the application code. (Btw. does it work on PG, when the index name is stated uppercase?) Isn't it possible to use 'SELECT FOR UPDATE' in these cases? (The other transaction would need to wait till the first one commits.) Hi, The attached patch attempts to fix an issue we found while running some Selenium-based automated UI tests. Basically multiple requests that involve an RhnSet can overlap if the user is clicking very quickly and that might result in an ISE because RHNSET.RHN_SET_USER_LABEL_ELEM_UNQ is violated. We verified that using a system's Errata page, specifically in code that gets executed from ErrataList.do to ErrataConfirm.do. In particular, if you check a box selecting an errata in ErrataList.do then an AJAX call is fired to DWRItemSelector.select(), which among other things updates the underlying rhnset by adding a row. Then, if you very quickly click on Apply Errata, ListRhnSetHelper will also try to add the same row because DWRItemSelector hasn't finished yet and, in case of particularly bad luck, the RDBMS will complain that the unique constraint has been violated. AFAIU this is possible from an RDBMS point of view since, both in the Oracle and in Postgres, the READ COMMITTED transaction isolation level is used. This means that a transaction can see data changing if other transactions COMMIT during its lifetime [2]. No, if both transactions start at the same time and one of them commits, the other transaction does not see those changes. If the other transaction makes the same changes, it fails first at commit time on the mentioned index. Regards, -- Tomas Lestach Red Hat Satellite Engineering, Red Hat Reproducing this issue is not very easy, since it is RDBMS, network and server-load dependent. We succeeded in reliably repeat it in SUSE Manager on Oracle using Selenium IDE for Firefox[1] to automate the clicks. Of course, this can also happen at more human time scales if, for example, server is under heavy load. The attached patch just ignores constraint violations in this specific case, as I see no point in throwing an exception when the row to INSERT is simply already there. AFAIU that does not have unwanted side-effects, but review is nevertheless very welcome. Regards, [1] http://docs.seleniumhq.org/download/ [2] http://www.postgresql.org/docs/9.2/static/transaction-iso.html -- Silvio Moioli SUSE LINUX Products GmbH Maxfeldstraße 5, 90409 Nürnberg Germany ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] I think i found an bug in the clone channel page no spacewalk 1.9
Thanks Michael-- Sent from my HP Pre3On Jun 7, 2013 4:18 AM, Michael Mraka michael.mr...@redhat.com wrote: Paul Robert Marino wrote:% hey I havent had time to check if the is know or not but i ran into an% issue which crashed the clone channel page on spacewalk 1.9 on my servers.% right now im just making a note of it ill check for and possibly file a% ticket latter if one doesnt already exist.% % here is the trace% % [Thu Jun 06 12:10:38 2013] [error] Traceback sent to% pmarino@myemployer.comat% /usr/share/perl5/vendor_perl/PXT/ApacheHandler.pm line 563.% [Thu Jun 06 12:23:35 2013] [error] Couldn't open file:% /usr/share/spacewalk/web//network/software/channels/manage/manage_channels_header.pxi...Hi Paul Robert,this bug has been fixed in master by 939873574a6bfc8106ac5f74dbba80bbbcd24686(spacewalk-web-1.10.22-1).Regards,--Michael MrákaSatellite Engineering, Red Hat___Spacewalk-devel mailing listSpacewalk-devel@redhat.comhttps://www.redhat.com/mailman/listinfo/spacewalk-devel___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Feature request: External Errata Mailer / Daily Digest
Really think we need to fix the handling of errata I during a reposync. This is actually a relatively new feature in spacewalk and even a new feature for yum repos we (as in the people on this list) asked for in both.The reason why its spamish is because currently the way its being handled the version number on all of the erratas is getting incremented every time you sync a repo.If you notice errata synced by other scripts don't do this they send emails once and that's it.Here is what needs to be done to fix it.1) There needs to be a check to see if the errata already exist in the spacewalk server. If not add it. If so we need to do a second check.2) the second check would be to see if all the packages mentioned in the errata which exist in the channel are present in the version of the errata on the spacewalk server. If so do not modify the existing errata in the spacewalk server. If not then add the appropriate packages and publish the update which will increment the version number. This will ensure only errata which have really been updated to be send out emails.-- Sent from my HP Pre3On May 29, 2013 9:38 PM, Ben Galliart b...@steadfast.net wrote: The Errata mailer for Spacewalk is more chatty/spam-ish than I care for. For example, it will re-generate separate email for each pending errata for the EPEL each time spacewalk-repo-sync is run. I would like to have better control over the format and frequency of Errata mails from Spacewalk. At the same time, I would like the customers using Spacewalk to be able to continue to use the web interface to subscribe/unsubscribe from getting errata notices. I'm running into the following limitations with Spacewalk: (1) The generation of errata emails is hardwired into rhn.jar via the ErrataMailer.class (2) The Spacewalk API does not expose the settings in user preferences for email notifications Possible work-arounds that I am considering: (1) Query the user preferences directly from postgresql (2) Setup a script to modify the rhn.jar whenever spacewalk-java package is updated so ErrataMailer no longer generates mail (3) Setup a daily cron to digest the number of errata and systems into a single email per user What I would like to have long-term is the option in Spacewalk to have ErrataMailer.class call an external script or program and provide via stdin the user id, email address, errata id, org id, channel id and affected systems. It will then be up to the external program on how/when to format and mail the information. I feel that Spacewalk should be modular enough that a Spacewalk administrator can "plug-in" their own errata mailer handler and still be able to expect it to continue to be forward compatible with minor updates to Spacewalk. Currently, I don't see how to accomplish this task without monitoring rhn.jar for updates and re-applying a patch to the class each time. I am open to any comment or advice. Thanks ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Branch for Spacewalk 1.9 has been created
Woo hoo I can't wait to try it on my test box.-- Sent from my HP Pre3On Mar 4, 2013 2:14 PM, Stephen Herr sh...@redhat.com wrote: Hi everyone, We have a new branch, SPACEWALK-1.9, to track our next release of Spacewalk. Spacewalk nightly builds will now be for Spacewalk 1.10. -Stephen Herr ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Errata api problem
Well I understand your point about mixing distros but more often than not often they are the same and with Scientific Linux they are always the same as RHEL's. also there is a bigger concern mixing architectures and releases in a single errata is common place even in RHN. Ive seen instances where a 32bit library or app on x86_64 requires a 64bit dependance on the x86_64 version of the distro this happens for various reasons. Ive also seen instances where onarch packages weren't actually architecture independent this often happens with Perl modules where a new version added XS code and the package maintainer didn't catch it. In these cases it would represent a significant problem. On Wed, Nov 21, 2012 at 3:20 PM, Franky Van Liedekerke liede...@telenet.be wrote: On Tue, 20 Nov 2012 22:28:07 -0500 Paul Robert Marino prmari...@gmail.com wrote: I'm not sure if I should classify this as bug or an rfe but either way ill put in a ticket tommorow. I ran into an intresting problem. There is a common case where you have for example centos channels and scientific linux channels where you may have different packages with the same name in different base channels. It would be nice to be able to publish a single errata with multiple base channels from different distros that could cover them all but what I've found in testing is there seems to be no way to do that safely. When you try to do that the package from one channel gets published into the other resulting in a duplicate package in the other channels the first one being the original package for that distro the second being the package from the first channel. This is actually a common problem and complaint for most of the errata sync scripts. The resultt is it breaks yum and by extention anacondas ability to use the channel. After a bit of investigation I found it was a limitation of the api, I haven't dug into the database yet but. This is something that needs investigation because it would eleviate a lot of the dificulties users have with the errata sync scripts. Why try to combine errata's from different distro's? It seems like a very bad idea: one should know for which distro/base channel the errata is. And a CentOS errata might totally not be related to a redhat errata, even if it has the same name (the packages might be different). The way I coded it up: get a list of packages per channel and then compare these with the ones mentioned in the errata. Easy and simple ... of course I only do one-on-one channel errata sync, but it never failed me yet. For those interested (shameless adv): one errata script for both redhat and/or centos errata sync's, without cross contamination issues and with proxy support (but only one channel at the time): https://github.com/liedekef/spacewalk_scripts Franky ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Errata api problem
I'm not sure if I should classify this as bug or an rfe but either way ill put in a ticket tommorow. I ran into an intresting problem. There is a common case where you have for example centos channels and scientific linux channels where you may have different packages with the same name in different base channels. It would be nice to be able to publish a single errata with multiple base channels from different distros that could cover them all but what I've found in testing is there seems to be no way to do that safely. When you try to do that the package from one channel gets published into the other resulting in a duplicate package in the other channels the first one being the original package for that distro the second being the package from the first channel. This is actually a common problem and complaint for most of the errata sync scripts. The resultt is it breaks yum and by extention anacondas ability to use the channel. After a bit of investigation I found it was a limitation of the api, I haven't dug into the database yet but. This is something that needs investigation because it would eleviate a lot of the dificulties users have with the errata sync scripts. ___ 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
without more info from the httpd logs and possibly your Apache configuration files we really cant help you. what i can tell you is the server name is probably not the cause of the problem. On Mon, Nov 19, 2012 at 11:32 AM, Bolaji Jibodu bola...@sfwltd.co.uk 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] [root@ld-sw-pup tomcat6]# /sbin/service oracle-xe restart Shutting down Oracle Database 11g Express Edition instance. Stopping Oracle Net Listener. Starting Oracle Net Listener. Starting Oracle Database 11g Express Edition instance. [root@ld-sw-pup tomcat6]# /usr/sbin/spacewalk-service restart Shutting down spacewalk services... Stopping RHN Taskomatic... RHN Taskomatic was not running. Stopping cobbler daemon: [ OK ] Stopping rhn-search... Stopped rhn-search. Stopping MonitoringScout ... [ OK ] Stopping Monitoring ... [ OK ] Shutting down osa-dispatcher: [ OK ] Stopping httpd:[FAILED] Stopping tomcat6: [ OK ] Terminating jabberd processes ... Stopping s2s: [ OK ] Stopping c2s: [ OK ] Stopping sm: [ OK ] Stopping router: [ OK ] Done. Starting spacewalk services... Initializing jabberd processes ... Starting router: [ OK ] Starting sm: [ OK ] Starting c2s: [ OK ] Starting s2s: [ OK ] Starting tomcat6: [ OK ] Waiting for tomcat to be ready ... Starting httpd: httpd: Could not reliably determine the server's fully qualified domain name, using ld-sw-pup.a.com for ServerName [FAILED] Starting osa-dispatcher: [ OK ] Starting Monitoring ... [ OK ] Starting MonitoringScout ... [ OK ] Starting rhn-search... Starting cobbler daemon: [ OK ] Starting RHN Taskomatic... Bolaji Jibodu Linux Infrastucture System Engineer SFW Ltd Southern House, Station Approach, Woking, Surrey, GU22 7UY Switchboard : 01483 722219 email: bola...@sfwltd.co.uk Registered in England No. 2740301 VAT No. 591 7842 02 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] I think I found the root cause of the PostgreSQL Idle in transaction connection build up.
Well you are right there is nothing in the change log that idicates that this issue existed or how its fixed. But as I said it seems to fix it there is probably a side effect fix that was not planed but seems to work. The results are rediculously obvious initialy now honestly I think it needs a few days of testing to prove it, and I would like for others to confirm it but from my initial test it on one of my development instances it looks good. I would like other people to test it because I'm not using monitoring on that instance and I only have a few systems attached to it but the difference is so obvious there is deffinitly something there. By the way I've seen the change log betwean 701to 702 but I haven't seen the change log betwean 702 and 703 and I looked its not on their site or in the source package as far as I could initialy tell. While I admit I can't point to a reason in the change log why, it at least initialy seems to work. I think if any thing it may be a compound correction of multiple bugs that may of fixed a larger harder to pinpoint issue. On Nov 6, 2012 12:01 AM, Tom Lane t...@redhat.com wrote: Paul Robert Marino prmari...@gmail.com writes: Ive been doing some testing and I am fairly positive I found out why the number of connections in PostgreSQL increases and its not a spacewalk bug at all. It looks like its a JDBC bug [ and is fixed in 8.4-703 ] This is really interesting, but I looked through the upstream commit logs, and I can't see any patches between 8.4-701 and 8.4-703 that look like they'd cure a connection leak such as you're describing. There are a couple of fixes for possible loss-of-protocol-sync issues, but it doesn't seem like that would result in silent leakage; the symptoms would be pretty obvious. Have you poked into the client-side state to see what that end thinks it's doing with the idle connections? regards, tom lane ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] please review the updates to ticket 809897
I've confirmed the fix and attached a git diff of the patch applied to the SPACEWALK-1.7 branch which Ive tested as well. https://bugzilla.redhat.com/show_bug.cgi?id=809897 Thank you ___ 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
Hmm I hadn't noticed the date on the ticket just that the symptoms were identical. There may be also some other factors here I am running postgresql 9.1 and while I didn't see a trace back I didn't check the postgresql logs. Ill take a look and see if there are any bad queries. I've already had to. Back port several patches from 1.8 to 1.7 to make it work. By the way in case there is any question yes I will be submitting git patches made against the 1.7 branch of the git repo as soon as I'm done with testing On Aug 17, 2012 3:39 AM, Jan Pazdziora jpazdzi...@redhat.com wrote: 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 ___ 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
Ive done a little more digging I haven't found the problem yet but I
can eliminate a few things
1) its not a regression in the code
2) There is nothing in the PostgreSQL logs that indicate a failed
query so i dont think the fact that I'm using PostgreSQL 9.1 is
causing the issue.
I have added the patches mentioned here
https://www.redhat.com/archives/spacewalk-devel/2012-March/msg00056.html
and
https://bugzilla.redhat.com/show_bug.cgi?id=809936
Im fairly sure the issue is here
java/code/src/com/redhat/rhn/manager/kickstart/KickstartScheduleCommand.java
because this only seems to happen when i schedule a box to rekickstart
via the web interface.
some how this doesn't seem right to me specifically I think this
function may be getting called with a usage limit of 0 but to be
honest Im not sure why in this context you would ever need it to be
any thing else other than 1.
/**
* Create a one time activation key for use with a kickstart
* @param creator of the key
* @param ksdata associated with the key
* @param server being kickstarted (can be null)
* @param session associated with the kickstart (NOT NULL)
* @param note to add to key
* @param usageLimit to apply to the key. null for unlimited.
* @return ActivationKey that has been saved to the DB.
*/
public static ActivationKey createKickstartActivationKey(User creator,
KickstartData ksdata,
Server server,
KickstartSession session,
Long usageLimit,
String note) {
// Now create ActivationKey
ActivationKey key = ActivationKeyManager.getInstance().
createNewReActivationKey(creator,
server, note, session);
key.addEntitlement(ServerConstants.getServerGroupTypeProvisioningEntitled());
key.setDeployConfigs(false);
key.setUsageLimit(usageLimit);
if (KickstartVirtualizationType.paraHost().
equals(ksdata.getKickstartDefaults().getVirtualizationType())) {
//we'll have to setup the key for virt
key.addEntitlement(ServerConstants.getServerGroupTypeVirtualizationEntitled());
}
ActivationKeyFactory.save(key);
// Add child channels to the key
if (ksdata.getChildChannels() != null
ksdata.getChildChannels().size() 0) {
Iterator i = ksdata.getChildChannels().iterator();
log.debug(Add the child Channels);
while (i.hasNext()) {
key.addChannel((Channel) i.next());
}
}
log.debug(** Saving new token);
ActivationKeyFactory.save(key);
log.debug(** Saved new token: + key.getId());
return key;
}
Ill create a bug report latter today
On Fri, Aug 17, 2012 at 9:00 AM, Paul Robert Marino prmari...@gmail.com wrote:
Hmm
I hadn't noticed the date on the ticket just that the symptoms were
identical.
There may be also some other factors here I am running postgresql 9.1 and
while I didn't see a trace back I didn't check the postgresql logs. Ill take
a look and see if there are any bad queries. I've already had to. Back port
several patches from 1.8 to 1.7 to make it work. By the way in case there is
any question yes I will be submitting git patches made against the 1.7
branch of the git repo as soon as I'm done with testing
On Aug 17, 2012 3:39 AM, Jan Pazdziora jpazdzi...@redhat.com wrote:
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
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Is there an updated ETA on the release of spacewalk 1.8
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 there an updated ETA? Is there a list of what still needs to be completed? Is there a list of what needs testing so we can help further this along? ___ 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:10 PM, Jan Pazdziora jpazdzi...@redhat.com wrote: 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? 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 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. 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. 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. 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. Ill see about setting up a development 1.8 box latter this week 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 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Fwd: [Fedora Update] [comment] cobbler-2.2.1-1.el5
I saw that cobbler was updated to version 2.2 on epel6 yesterday On Apr 13, 2012 11:53 AM, James Hogarth james.hoga...@gmail.com wrote: RHEL6 should not be broken. Just EL5 and that fixed adelton in commit 7e7129fe35d0bd0e762a947eddb3e761797466bc That's odd... I'm on C6.2 . I'll give it another go later over the weekend and if it obviously breaks try and document what's going on... ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Submission of a script I would like to contribute
Hello every one I have created a Perl script to update and list the default channel map in spacewalk via the XMLRPC API and my current employer who shall remain nameless has authorized me to share it under the terms of the GPL. This is a partial workaround to https://bugzilla.redhat.com/show_bug.cgi?id=786705 reactivation key do not preserve my custom base channel Since this script uses the XMLRPC API unlike the method mentioned in the ticket this script should work for PostgreSQL and Oracle however I've only tested it against PostgreSQL. There is also a man page embedded in the script in POD format so the pod2(man|text|html|etc...) tools can be used to extract it. it depends on the following Perl modules strict Frontier::Client Getopt::Long Pod::Usage Term::ReadKey Note: This script does NOT do the more controversial part of the workaround namely dropping the constraint on the description field in the rhnserverhistory table which may or may not be a PostgreSQL specific bug. I hope people find it useful enough to add into the git repository Thank You Paul Robert Marino spacewalk-dist-channel-map.pl Description: Binary data ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] trying to find a work around to a known bug
Well I somewhat agree this is a work around and after the bug in the
insert to the server history log is fixed the constraint should be re
added via the following sql statement by any one who has implemented
the work around
ALTER TABLE ADD CONSTRAINT vn_rhnserverhistory_details CHECK
(((details)::text ''::text));
As for why the trace I included in the ticket does explain it.
the table contains the history log for changes to the hosts profile.
during the re registration process it updates the release information
in the hosts profile, unfortunately there is a bug in the code where
its only giving a summary and leaving whats suppose to be the full
description in the history log blank. the only thing this should
effect is views of the hosts history,
As for the first part
spaceschema=# select id,channel_arch_id from rhnChannel where
label='sci-linux-6_2';
id | channel_arch_id
-+-
109 | 513
(1 row)
spaceschema=# insert into rhnDistChannelMap
(os,release,channel_arch_id,channel_id) VALUES
('sl-release','6.2','513','109');
is a sound hack. There should be a way to do this from the web
interface and or the command line but as far as I've been able to
determine there isn't one currently although there are API calls for
it,
I may write a script to do it if there isn't already an established
method to do it that I've missed.
Although the distchannelmap does not resolve the fact that the base
channel from the second key is being ignored. if the base channel in
the second key where being honored then the base_channel_rel_archid
function in the database wouldn't be getting called in the first place
to determine the base channel.
as for the
On Fri, Mar 23, 2012 at 4:16 AM, Michael Mraka michael.mr...@redhat.com wrote:
Paul Robert Marino wrote:
% for any one whos interested here is the workaround i found
% I had to do several alterations to the database
%
%
% spaceschema=# select id,channel_arch_id from rhnChannel where label
% ='sci-linux-6_2';
% id | channel_arch_id
% -+-
% 109 | 513
% (1 row)
% spaceschema=# insert into rhnDistChannelMap
% (os,release,channel_arch_id,channel_id) VALUES
% ('sl-release','6.2','513','109');
% spaceschema=# alter table rhnserverhistory drop constraint
% vn_rhnserverhistory_details;
%
%
% oh by the way if any one is wondering the reason why im dropping the
% constraint is if you don't it just breaks again latter with this error
Well, I really wonder why you're dropping it. Do you know what's its
purpose? Are you sure about consequences of your change?
Be prepared to random unexpected errors in future. Moreover you
might not be able to upgrade schema in the future.
I strongly discourage anyone from doing such modifications.
% because of an on the bug the workaround brought to light.
%
%
% ERROR: new row for relation rhnserverhistory violates check
% constraint vn_rhnserverhistory_details
% STATEMENT:
% insert into rhnServerHistory
% (id,
% server_id,
% summary,
% details)
% values
% (sequence_nextval('rhn_event_id_seq'),
% 110018,
% E'Updated system release from 6.2 to 6.2',
% E'')
%
Regards,
--
Michael Mráka
Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] trying to find a work around to a known bug
oh and by the way setting a default on the field wont fix it either
because it actually explicitly inserting a blank entry
On Fri, Mar 23, 2012 at 9:48 AM, Paul Robert Marino prmari...@gmail.com wrote:
Well I somewhat agree this is a work around and after the bug in the
insert to the server history log is fixed the constraint should be re
added via the following sql statement by any one who has implemented
the work around
ALTER TABLE ADD CONSTRAINT vn_rhnserverhistory_details CHECK
(((details)::text ''::text));
As for why the trace I included in the ticket does explain it.
the table contains the history log for changes to the hosts profile.
during the re registration process it updates the release information
in the hosts profile, unfortunately there is a bug in the code where
its only giving a summary and leaving whats suppose to be the full
description in the history log blank. the only thing this should
effect is views of the hosts history,
As for the first part
spaceschema=# select id,channel_arch_id from rhnChannel where
label='sci-linux-6_2';
id | channel_arch_id
-+-
109 | 513
(1 row)
spaceschema=# insert into rhnDistChannelMap
(os,release,channel_arch_id,channel_id) VALUES
('sl-release','6.2','513','109');
is a sound hack. There should be a way to do this from the web
interface and or the command line but as far as I've been able to
determine there isn't one currently although there are API calls for
it,
I may write a script to do it if there isn't already an established
method to do it that I've missed.
Although the distchannelmap does not resolve the fact that the base
channel from the second key is being ignored. if the base channel in
the second key where being honored then the base_channel_rel_archid
function in the database wouldn't be getting called in the first place
to determine the base channel.
as for the
On Fri, Mar 23, 2012 at 4:16 AM, Michael Mraka michael.mr...@redhat.com
wrote:
Paul Robert Marino wrote:
% for any one whos interested here is the workaround i found
% I had to do several alterations to the database
%
%
% spaceschema=# select id,channel_arch_id from rhnChannel where label
% ='sci-linux-6_2';
% id | channel_arch_id
% -+-
% 109 | 513
% (1 row)
% spaceschema=# insert into rhnDistChannelMap
% (os,release,channel_arch_id,channel_id) VALUES
% ('sl-release','6.2','513','109');
% spaceschema=# alter table rhnserverhistory drop constraint
% vn_rhnserverhistory_details;
%
%
% oh by the way if any one is wondering the reason why im dropping the
% constraint is if you don't it just breaks again latter with this error
Well, I really wonder why you're dropping it. Do you know what's its
purpose? Are you sure about consequences of your change?
Be prepared to random unexpected errors in future. Moreover you
might not be able to upgrade schema in the future.
I strongly discourage anyone from doing such modifications.
% because of an on the bug the workaround brought to light.
%
%
% ERROR: new row for relation rhnserverhistory violates check
% constraint vn_rhnserverhistory_details
% STATEMENT:
% insert into rhnServerHistory
% (id,
% server_id,
% summary,
% details)
% values
% (sequence_nextval('rhn_event_id_seq'),
% 110018,
% E'Updated system release from 6.2 to 6.2',
% E'')
%
Regards,
--
Michael Mráka
Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] trying to find a work around to a known bug
for any one whos interested here is the workaround i found
I had to do several alterations to the database
spaceschema=# select id,channel_arch_id from rhnChannel where label
='sci-linux-6_2';
id | channel_arch_id
-+-
109 | 513
(1 row)
spaceschema=# insert into rhnDistChannelMap
(os,release,channel_arch_id,channel_id) VALUES
('sl-release','6.2','513','109');
spaceschema=# alter table rhnserverhistory drop constraint
vn_rhnserverhistory_details;
oh by the way if any one is wondering the reason why im dropping the
constraint is if you don't it just breaks again latter with this error
because of an on the bug the workaround brought to light.
ERROR: new row for relation rhnserverhistory violates check
constraint vn_rhnserverhistory_details
STATEMENT:
insert into rhnServerHistory
(id,
server_id,
summary,
details)
values
(sequence_nextval('rhn_event_id_seq'),
110018,
E'Updated system release from 6.2 to 6.2',
E'')
On Mon, Mar 19, 2012 at 5:22 PM, Paul Robert Marino prmari...@gmail.com wrote:
hello every one
I trying to find a work around to a know bug that several people have
seen in spacewalk 1.7, 1.6 and Satellite 5.4.x
here is the bug report https://bugzilla.redhat.com/show_bug.cgi?id=786705
the short description is that when you kickstart a host it works fine
but when you re kickstart a host the rhnreg_ks command barfs on the
reactivation key,
it seems as though the reactivation key is not setting the base
channel correctly and if a second key is included that specifies a
custom base channel it is ignored.
I've figured out that if i can update the channel dist map in the
database i might be able to work around it but i cant find a way to do
it through the gui or any of the command line tools.
does any one know a way to manually update the channel dist map easily
or will i need to write a script my self to do it.
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] trying to find a work around to a known bug
hello every one I trying to find a work around to a know bug that several people have seen in spacewalk 1.7, 1.6 and Satellite 5.4.x here is the bug report https://bugzilla.redhat.com/show_bug.cgi?id=786705 the short description is that when you kickstart a host it works fine but when you re kickstart a host the rhnreg_ks command barfs on the reactivation key, it seems as though the reactivation key is not setting the base channel correctly and if a second key is included that specifies a custom base channel it is ignored. I've figured out that if i can update the channel dist map in the database i might be able to work around it but i cant find a way to do it through the gui or any of the command line tools. does any one know a way to manually update the channel dist map easily or will i need to write a script my self to do it. ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
