[Spacewalk-list] Monitoring Disappeared

Paul Robert Marino prmarino1 at gmail.com
Sun Jan 11 05:32:59 UTC 2015 

The Spacewalk monitoring had sever scaling issues it really was never
ready for any sizable production environments. Truth be told it never
got much further than the proof of concept phase in its development.
it had many performance issues and agent deployment process was rather
unreliable.

I am considering doing some initial work on a Nagios configuration
generation via the API's and external scripts,templates, and
Spacewalks built in configuration file deployment. I've written
similar Nagios configuration tools in the past for previous companies
I've worked for so its not a huge stretch for me to write, furthermore
my current employer is planing a large Nagios deployment in the future
and likes me to post my tools I write for managing free software
publicly under my own name as part of my peer review process as long
as they aren't industry specific. I am also considering adding
something like auto configuration of pnp4nagios for graphing but maybe
not that specific project since it looks like its been idle since
2015.

Nagios has a concept most people don't take proper advantage of where
it can have a config.d type directory structure multiple directories
deep. I've been thinking of using that with custom variables to to
activate templates for different Nagios monitoring templates.
This is doable but it will require a good bit of planning first.
For various reasons including efficiency I will try to avoid using
local agents on the boxes being monitored.

Since I am a Perl programmer I will writ it in Perl as part of
https://github.com/prmarino1/Extravehicular-Activity-Admin
I may also utilize my Lib-CIM-Perl project
https://github.com/prmarino1/Lib-CIM-Perl/blob/master/LCP::Query.md
with SBLIM http://sourceforge.net/projects/sblim/ to make some highly
efficient monitoring agents possibly with some DELL OpenManage Agent,
and HP SIM Agent support since they both use derivatives of the CIM
protocol under the hood.

When I come up with a basic design specifications and a project plan,
I will post it on the developers list for review before I start coding
and will be open to suggestions.
That said it will be a few months before I get time to do any coding
so don't expect any thing soon.



On Tue, Jan 6, 2015 at 10:46 AM, Stephen Herr <sherr at redhat.com> wrote:
> To be a little more helpful about downgrading:
>
> Old versions of the rpms are not kept around in the nightly repos but you
> should be able to download them from our koji builder:
> http://koji.spacewalkproject.org/koji/index
>
> Downgrading to spacewalk-java-2.3.109 and spacewalk-backend-2.3.27 (and
> related sub-packages) should get you 99% of the way there.
>
> -Stephen
>
>
>
> On 01/06/2015 10:33 AM, Stephen Herr wrote:
>>
>> You can downgrade the rpms to before the change and things will continue
>> to work as well as they did before. If you'd like to keep the newer rpms
>> and proceed with dropping monitoring you can fix the error you're
>> getting by manually applying the schema changes that your db does not
>> already have (upgrade spacewalk-schema, use spacewalk-sql to run the
>> upgrade scripts found in
>>
>> /etc/sysconfig/rhn/schema-upgrade/spacewalk-schema-2.2-to-spacewalk-schema-2.3/
>> ). Specifically the 020-rhnInfoPane* script is the one that will fix
>> your current error.
>>
>> Unfortunately there is currently not a less-manual way to keep a nightly
>> install's database updated, this is one of the reasons that running
>> nightly is hard / not recommended. The spacewalk-schema-upgrade tool
>> only can handle upgrading from one Spacewalk release to another (eg from
>> Spacewalk 2.0 to 2.2), it does not handle upgrading from one minor
>> release of spacewalk-schema-2.3.x to another spacewalk-schema-2.3.y. You
>> have to keep track of your db upgrading manually if you're going to run
>> nightly.
>>
>> -Stephen
>>
>> On 01/06/2015 08:42 AM, Francisco Cardoso wrote:
>>>
>>> Thank you for the reply, stupidly inherited a problem.
>>> No way to downgrade right ?
>>>
>>> Regards,
>>>
>>> FC
>>>
>>> -----Original Message-----
>>> From: Cliff Perry [mailto:cperry at redhat.com]
>>> Sent: 06 January 2015 13:24
>>> To: francisco.cardoso at gmail.com; spacewalk-list at redhat.com
>>> Subject: Re: [Spacewalk-list] Monitoring Disappeared
>>>
>>> On 06/01/15 12:36, Francisco Cardoso wrote:
>>>>
>>>> During one of the updates on the nightly,
>>>>
>>>> My monitoring tab has disappeared and I started to get a 500 message
>>>> on the overview.
>>>>
>>>> 2015-01-06 12:20:47,909 [TP-Processor3] WARN
>>>> org.apache.struts.action.RequestProcessor - Unhandled Exception thrown:
>>>> class java.lang.IllegalArgumentException
>>>>
>>>> 2015-01-06 12:20:47,910 [TP-Processor3] ERROR
>>>> com.redhat.rhn.frontend.servlets.SessionFilter - Error during
>>>> transaction. Rolling back
>>>>
>>>> javax.servlet.ServletException: java.lang.IllegalArgumentException:
>>>> Could not find ACL handler show_monitoring in statement:
>>>> "show_monitoring()". Available ACL handlers: [can_access_channel,
>>>> errata_editable, formvar_exists, is, is_protected, is_satellite,
>>>> need_first_user, org_channel_family, org_entitlement, org_role,
>>>> system_feature, system_has_management_entitlement,
>>>> system_has_virtualization_entitlement, system_is_in_ssm,
>>>> system_is_virtual, trust_channel_access, uid_role, user_authenticated,
>>>> user_can_manage_channels, user_role]
>>>>
>>>>                   at
>>>> org.apache.struts.action.RequestProcessor.processException(RequestProc
>>>> essor.java:520)
>>>>
>>>>                   at
>>>> org.apache.struts.action.RequestProcessor.processActionPerform(Request
>>>> Processor.java:427)
>>>>
>>>>                   at
>>>> org.apache.struts.action.RequestProcessor.process(RequestProcessor.jav
>>>> a:228)
>>>>
>>>>                   at
>>>> com.redhat.rhn.frontend.struts.RhnRequestProcessor.process(RhnRequestP
>>>> rocessor.java:102)
>>>>
>>>>                   at
>>>> org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913
>>>> )
>>>>
>>>>                   at
>>>> org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:449)
>>>>
>>>>                   at
>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
>>>>
>>>>                   at
>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>>>>
>>>>                   at
>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
>>>> cationFilterChain.java:290)
>>>>
>>>>                   at
>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
>>>> lterChain.java:206)
>>>>
>>>>                   at
>>>> com.redhat.rhn.frontend.servlets.AuthFilter.doFilter(AuthFilter.java:1
>>>> 27)
>>>>
>>>>                   at
>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
>>>> cationFilterChain.java:235)
>>>>
>>>>                   at
>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
>>>> lterChain.java:206)
>>>>
>>>>                   at
>>>> com.opensymphony.sitemesh.webapp.SiteMeshFilter.obtainContent(SiteMesh
>>>> Filter.java:129)
>>>>
>>>>                   at
>>>> com.opensymphony.sitemesh.webapp.SiteMeshFilter.doFilter(SiteMeshFilte
>>>> r.java:77)
>>>>
>>>>                   at
>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
>>>> cationFilterChain.java:235)
>>>>
>>>>                   at
>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
>>>> lterChain.java:206)
>>>>
>>>>                   at
>>>> com.redhat.rhn.frontend.servlets.LocalizedEnvironmentFilter.doFilter(L
>>>> ocalizedEnvironmentFilter.java:67)
>>>>
>>>>                   at
>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
>>>> cationFilterChain.java:235)
>>>>
>>>>                   at
>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
>>>> lterChain.java:206)
>>>>
>>>>                   at
>>>> com.redhat.rhn.frontend.servlets.EnvironmentFilter.doFilter(Environmen
>>>> tFilter.java:100)
>>>>
>>>>                   at
>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
>>>> cationFilterChain.java:235)
>>>>
>>>>                   at
>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
>>>> lterChain.java:206)
>>>>
>>>>                   at
>>>> com.redhat.rhn.frontend.servlets.SessionFilter.doFilter(SessionFilter.
>>>> java:57)
>>>>
>>>>                   at
>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
>>>> cationFilterChain.java:235)
>>>>
>>>>                   at
>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
>>>> lterChain.java:206)
>>>>
>>>>                   at
>>>> com.redhat.rhn.frontend.servlets.SetCharacterEncodingFilter.doFilter(S
>>>> etCharacterEncodingFilter.java:97)
>>>>
>>>>                   at
>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
>>>> cationFilterChain.java:235)
>>>>
>>>>                   at
>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
>>>> lterChain.java:206)
>>>>
>>>>                   at
>>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperVa
>>>> lve.java:233)
>>>>
>>>>                   at
>>>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextVa
>>>> lve.java:191)
>>>>
>>>>                   at
>>>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.ja
>>>> va:127)
>>>>
>>>>                   at
>>>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.ja
>>>> va:102)
>>>>
>>>>                   at
>>>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValv
>>>> e.java: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(HandlerRequest.java:291)
>>>>
>>>>                   at
>>>> org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:769)
>>>>
>>>>                   at
>>>> org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.jav
>>>> a:698)
>>>>
>>>>                   at
>>>> org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocke
>>>> t.java:891)
>>>>
>>>>                   at
>>>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPo
>>>> ol.java:690)
>>>>
>>>>                   at java.lang.Thread.run(Thread.java:701)
>>>>
>>>> Caused by: java.lang.IllegalArgumentException: Could not find ACL
>>>> handler show_monitoring in statement: "show_monitoring()". Available
>>>> ACL
>>>> handlers: [can_access_channel, errata_editable, formvar_exists, is,
>>>> is_protected, is_satellite, need_first_user, org_channel_family,
>>>> org_entitlement, org_role, system_feature,
>>>> system_has_management_entitlement,
>>>> system_has_virtualization_entitlement, system_is_in_ssm,
>>>> system_is_virtual, trust_channel_access, uid_role, user_authenticated,
>>>> user_can_manage_channels, user_role]
>>>>
>>>>                   at
>>>> com.redhat.rhn.common.security.acl.Acl.evalAcl(Acl.java:454)
>>>>
>>>>                   at
>>>> com.redhat.rhn.manager.acl.AclManager.hasAcl(AclManager.java:81)
>>>>
>>>>                   at
>>>> com.redhat.rhn.domain.user.Pane.isValidFor(Pane.java:152)
>>>>
>>>>                   at
>>>> com.redhat.rhn.frontend.action.YourRhnAction.getDisplayPanes(YourRhnAc
>>>> tion.java:144)
>>>>
>>>>                   at
>>>> com.redhat.rhn.frontend.action.YourRhnAction.execute(YourRhnAction.jav
>>>> a:100)
>>>>
>>>>                   at
>>>> org.apache.struts.action.RequestProcessor.processActionPerform(Request
>>>> Processor.java:425)
>>>>
>>>> Anyone else having this issue ?
>>>>
>>>> Attached a log of the catalina.out
>>>>
>>>> Thanks all help in advance.
>>>>
>>>> FC
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Spacewalk-list mailing list
>>>> Spacewalk-list at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>>>>
>>>
>>> This is expected. We removed Monitoring in the nightly as part of
>>> readiness
>>> for the Spacewalk 2.3 release.
>>>
>>> We noted this within the release notes for 2.2:
>>>
>>> https://fedorahosted.org/spacewalk/wiki/ReleaseNotes22
>>> " The Spacewalk team is looking in future releases to drop support for
>>> Solaris clients and the Monitoring component of Spacewalk. They
>>> continue to
>>> be supported in their current state for the Spacewalk 2.2 release.
>>> Anyone currently using either of the capabilities may wish to consider
>>> alternatives for their needs. "
>>>
>>> And I've mentioned this in a few email threads over the past months.
>>>
>>> In December on the spacewalk-devel list it was noted that the merge was
>>> about to land that would remove the monitoring feature from the code.
>>>
>>> Regards,
>>> Cliff
>>>
>>> _______________________________________________
>>> Spacewalk-list mailing list
>>> Spacewalk-list at redhat.com
>>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>>>
>>
>> _______________________________________________
>> Spacewalk-list mailing list
>> Spacewalk-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list

More information about the Spacewalk-list mailing list