Re: [Spacewalk-devel] Fwd: Kickstart Create Distribution Error - Traceback Included (NIGHTLY)
On Friday 15 of June 2012 20:35:33 Steven Crothers wrote: > Hello everyone, I've been working on trying to fix a few bugs that > I've recently been running into with Spacewalk. > > I was wondering if anyone has run into this specific issue yet. No. I tried it with same spacewalk-java version on RHEL5 and it works for me. Does the /var/kickstart/centos-6-x86_64 path exist on the fs? Does it containt the images directory with the initrd and kernel images? Regards, -- Tomas Lestach RHN Satellite Engineering > > Bugzilla Ticket: > > https://bugzilla.redhat.com/show_bug.cgi?id=832617 > > Environment: > > CentOS 6.2 Latest w/ Fasttrack Patches > PostgreSQL 8.4.11 > Spacewalk installed on PostgreSQL > > Steps to reproduce: > > System -> Kickstart -> Distributions > + Create New Distribution > Label: centos-6-x86_64 > Tree Path: /var/kickstart/centos-6-x86_64 > Base Channel: CentOS 6 x86_64 > Installer Generation: Red Hat Enterprise Linux 6 > Kernel Options: NULL > Post Kernel Options: NULL > * Create Kickstart Distribution > INTERNAL SERVER ERROR > > Traceback: > > 2012-06-15 20:00:52,594 [TP-Processor1] WARN > org.apache.struts.action.RequestProcessor - Unhandled Exception > thrown: class java.lang.NullPointerException > 2012-06-15 20:00:52,594 [TP-Processor1] ERROR > com.redhat.rhn.frontend.servlets.SessionFilter - Error during > transaction. Rolling back > javax.servlet.ServletException: java.lang.NullPointerException >at > org.apache.struts.action.RequestProcessor.processException(RequestProcessor > .java:520) at > org.apache.struts.action.RequestProcessor.processActionPerform(RequestProce > ssor.java:427) at > org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:228 > ) at > com.redhat.rhn.frontend.struts.RhnRequestProcessor.process(RhnRequestProces > sor.java:99) at > org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913) at > org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:462) at > javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at > javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio > nFilterChain.java:290) at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterC > hain.java:206) at > com.redhat.rhn.frontend.servlets.AuthFilter.doFilter(AuthFilter.java:93) at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio > nFilterChain.java:235) at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterC > hain.java:206) at > com.opensymphony.sitemesh.webapp.SiteMeshFilter.obtainContent(SiteMeshFilte > r.java:129) at > com.opensymphony.sitemesh.webapp.SiteMeshFilter.doFilter(SiteMeshFilter.jav > a:77) at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio > nFilterChain.java:235) at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterC > hain.java:206) at > com.redhat.rhn.frontend.servlets.LocalizedEnvironmentFilter.doFilter(Locali > zedEnvironmentFilter.java:67) at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio > nFilterChain.java:235) at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterC > hain.java:206) at > com.redhat.rhn.frontend.servlets.EnvironmentFilter.doFilter(EnvironmentFilt > er.java:108) at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio > nFilterChain.java:235) at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterC > hain.java:206) at > com.redhat.rhn.frontend.servlets.SessionFilter.doFilter(SessionFilter.java: > 55) at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio > nFilterChain.java:235) at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterC > hain.java:206) at > com.redhat.rhn.frontend.servlets.SetCharacterEncodingFilter.doFilter(SetCha > racterEncodingFilter.java:97) at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio > nFilterChain.java:235) at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterC > hain.java:206) at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.j > ava:233) at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.j > ava:191) at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:12 > 7) at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:10 > 2) at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.jav > a:109) at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) > at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190) at > org.apache.jk.common.HandlerRequest.invoke(Hand
Re: [Spacewalk-devel] YUM RHN Lock Plugin
On 06/14/2012 03:37 PM, Jan Hutař wrote: On Wed, 13 Jun 2012 08:49:46 -0400 "Musayev, Ilya" wrote: That is correct. You can also install via RPM. If I'm not mistaken, --noplugings will also cut off rhn-plugin and therefore there will be no rhn repos. Ideally, it would be nice to integrate RHN LOCK with rhn-yum-plugin. That way if system locked - it is truly locked from both aspects (GUI and CLI) and you would not be able to disable lock independently. Hello, of course, yum have "--disableplugin=[plugin]" as well. What I wanted to say is: that plugin might be creating some false feeling of something being disabled/secured. If it is meant more "do not incidentally install packages on locked system", then it is OK. Regards, Jan I believe this is exactly why Ilya wants this integrated with rhn-yum-plugin, so that it could not be disabled separately. -Stephen ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Debian BSP post-mortem
As you may know I visited Debian Bug Squashing Party at Salzburg this week. And together with Bernd Zeimetz we tried to package Spacewalk packages to official Debian repository. And we succeeded in most important stuff. We reviewed, packaged and tested those packages: * python-ethtool * rhnlib (in debian python-rhn) * rhn-client-tools (as oposed to Fedora, all rhn-client-tools, rhn-setup, rhn-check and rhn-setup-gnome in Debian they are all in one package) * rhnsd * apt-spacewalk (transport protocol for apt-get) * and we tested Simon patch for apt. The code was recently refactored, so I had to rebased it and test it. The result is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677871 All packages are: Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. So they should land in Sid soon. And in one month is freeze so few weeks (or months, you know Debian) it can land in stable. We had not time for the rest of packages (rhncfg, osad, rhn-custom-info etc.). So we are still looking for Debian Developer who will package the rest or clients packages. And now some photos: http://www.salzburg-cityguide.at/de/partyzone/detail/debian-bug-squashing-party---conova_102492/debian-bug-squashing-party---conova_87847?page=1#title -- Miroslav Suchy Red Hat Satellite Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
