Bug 846866

Summary: Submitting updated unit file for munin-node and two new units
Product: [Fedora] Fedora Reporter: Jóhann B. Guðmundsson <johannbg>
Component: muninAssignee: d. johnson <drjohnson1>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: drjohnson1, ingvar, jvanek, kevin
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-01-01 02:48:02 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Updated munin-node unit
none
introducing munin-fcgi-html.service
none
introducing munin-fcgi-graph.service none

Description Jóhann B. Guðmundsson 2012-08-09 00:29:39 UTC
Created attachment 603138 [details]
Updated munin-node unit

Description of problem:

Added the Documentation feature removed no longer necessary syslog.target in the After= line.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Jóhann B. Guðmundsson 2012-08-09 00:35:00 UTC
Created attachment 603140 [details]
introducing munin-fcgi-html.service

See http://munin-monitoring.org/wiki/CgiHowto

Comment 2 Jóhann B. Guðmundsson 2012-08-09 00:43:46 UTC
Created attachment 603141 [details]
introducing munin-fcgi-graph.service

see http://munin-monitoring.org/wiki/CgiHowto2

We probably should add the relevant fcgi magic to the munin apache conf file and or in a separated one + I'm wondering if munin does not beling in /usr/share/munin and if we should not split out the plugins into separated packages with correct perl dependency on them ( or install all the required perl modules for all the shipped plugins )? 

Then there is a question if we should not create a munin wikipage on fedoraprojects wiki along with test cases...

Comment 3 d. johnson 2012-08-09 03:41:15 UTC
Making the .service file change is trivial, but I do have a question.  Can I use the same (revised) service file in f16/f17/f18, or is this feature change specific to f18+ ?

The fcgi magic is already in the munin-async package, not sure what you mean otherwise?

For plugins, the java-plugin is in another package entirely, but munin-node contains the remaining.  (Due to the dep-tree pulled in for java specifically)

The reason the bulk of the plugins exist in munin-node is so that "munin-node-configure" can run and auto-configure a base set of plugins that the node would likely be able to use.

How would you break up the plugins differently?

Open to suggestions, and as always: Patches Welcome!

Comment 4 Jóhann B. Guðmundsson 2012-08-09 08:32:35 UTC
(In reply to comment #3)
> Making the .service file change is trivial, but I do have a question.  Can I
> use the same (revised) service file in f16/f17/f18, or is this feature
> change specific to f18+ ?

You can make the change on all releases. The Documentation part in the status output however wont be displayed on F16. 

Anything pointing to /var/run should be fixed to point directly to /run instead along with using /usr/bin,/sbin instead of /bin/sbin in $path but it's non trivial and that problem probably lands on some community member to clean up in the distant future.

> The fcgi magic is already in the munin-async package, not sure what you mean
> otherwise?

Those unit file exist for nginx which does does not spawn your FCGI-process automatically at least according to that upstream documentation

> For plugins, the java-plugin is in another package entirely, but munin-node
> contains the remaining.  (Due to the dep-tree pulled in for java
> specifically)
> 
> The reason the bulk of the plugins exist in munin-node is so that
> "munin-node-configure" can run and auto-configure a base set of plugins that
> the node would likely be able to use.
> 
> How would you break up the plugins differently?


There are two flaws to our implementation that administrators are dealing with to deliver that perfect out of the box experience. 


Missing perl packages for plugins and missing configuration for plugins so I would either. 

A) 
package each plugin or group of plugins from /usr/share/munin/plugins in a   separate munin plugin sub package with the correct perl dependency and configuration file

B)

 Install all the needed perl packages for all those plugins to work as well as all the configuration files needed for those plugins to work.

Comment 5 d. johnson 2013-01-09 17:14:25 UTC
I think this may be resolved now. Can you verify 2.0.9-3+ works as expected ?

(At this time, there is a 2.0.10-1 in queue for build as well to resolve additional bugs)

Comment 6 Fedora End Of Life 2013-04-03 15:46:25 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 7 Fedora Admin XMLRPC Client 2013-05-19 19:51:34 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.