| Summary: | Enhancement: Move collectd configuration in subdir so Addons can include monitoring files | ||
|---|---|---|---|
| Product: | IPFire | Reporter: | dnl <ipfire> |
| Component: | --- | Assignee: | Adolf Belka <adolf.belka> |
| Status: | MODIFIED --- | QA Contact: | |
| Severity: | Aesthetic Issue | ||
| Priority: | - Unknown - | CC: | adolf.belka, jon.murphy, michael.tremer |
| Version: | 2 | ||
| Hardware: | all | ||
| OS: | Unspecified | ||
| URL: | https://community.ipfire.org/t/suricata-is-not-displayed-in-process-and-process-memory-graphs/9524 | ||
| Attachments: | Example of white / grey colors | ||
|
Description
dnl
2023-03-30 09:57:38 UTC
Hello, I think this is a great idea. Would you like to submit patches for this? Yes, I'll have a go! Hi again, Two issues: 1. I can see how to change the structure in the existing codebase from git, but where do I write a script to migrate existing IPFire systems to this new structure? I think I'd need to modify `ipfire-2.x/lfs/collectd` but I am unclear as to how. Can you think of any examples which I could copy please? 2. I'm afraid I won't be able to contribute this myself as I avoid using my real name online and this breaks your git tags sign off rule. This change I'm doing is trivial, so perhaps it might still be helpful for me to prepare the work for someone else to submit it? It's up to you. Thank you! (In reply to dnl from comment #3) > Hi again, > > Two issues: > > 1. I can see how to change the structure in the existing codebase from git, > but where do I write a script to migrate existing IPFire systems to this new > structure? I think I'd need to modify `ipfire-2.x/lfs/collectd` but I am > unclear as to how. Can you think of any examples which I could copy please? I would say that it is a good start to create the changes in the build environment for a fresh install. Step two should then be looking at what we need to do in the updater. > 2. I'm afraid I won't be able to contribute this myself as I avoid using my > real name online and this breaks your git tags sign off rule. This change > I'm doing is trivial, so perhaps it might still be helpful for me to prepare > the work for someone else to submit it? It's up to you. This is indeed a problem. It is not only about any name being on top of the commit. It is about authorship and the copyright that you are holding on your patches. Would it be helpful if I picked up this bug and put a patch together for it? (In reply to Adolf Belka from comment #5) > Would it be helpful if I picked up this bug and put a patch together for it? I am happy with this :) (In reply to Michael Tremer from comment #4) > This is indeed a problem. It is not only about any name being on top of the > commit. It is about authorship and the copyright that you are holding on > your patches. Thanks Michael. I understand - that makes sense. (In reply to Adolf Belka from comment #5) > Would it be helpful if I picked up this bug and put a patch together for it? Yes please! I actually don't have much free time yet anyway so that would be super helpful. I can give you a git diff but I'm not familiar with patchwork. Would a diff be helpful? The include line in /etc/collectd.conf needs to be 'include "/etc/collectd.d/*"' but otherwise this is totally straightforward. PS: I'm still not sure if I prefer /etc/collectd.d or /etc/collectd.conf.d myself. The latter is very long but makes it clear that the '.conf.d' part refers to a directory for configuration files rater than a mistaken extra .d after collectd (in which the d presumably stands for daemon). (In reply to dnl from comment #8) > PS: I'm still not sure if I prefer /etc/collectd.d or /etc/collectd.conf.d > myself. > The latter is very long but makes it clear that the '.conf.d' part refers to > a directory for configuration files rater than a mistaken extra .d after > collectd (in which the d presumably stands for daemon). Normally "collectd.d" is the standardised way to do this. See init.d, rc.d and so on. Hey Adolf! I found this BZ yesterday. Have you gotten very far on this? If not, then I have some past notes I can share. Hi @Jon. No I haven't gotten round to this bug yet. I have some others that I am still working on. Created attachment 1155 [details]
Example of white / grey colors
Most of my notes are background-ish (gathering info) related.
Obvious stuff:
- not every add-on should get auto-added to collectd (and Status > Services WebGUI).
- some add-ons have little to no info the gather (e.g. apcupsd, avahi-daemon).
- adding too many add-ons will clutter graphs.
- decided what add-on gets a graph is difficult.
Side note: graphs.pl has a limited # of colors and many are currently white/lite grey. See attached image.
Adding a new add-on to the collectd (and the graph) is easy. This could go in the addon install.sh
```
cat <<EOF > "/etc/collectd.d/${addonName}.conf"
<Plugin processes>
Process "${addonName}"
</Plugin>
EOF
/etc/rc.d/init.d/collectd restart
```
As we learned with messagebus and dbus there could be different names for add-ons and their processes. e.g. pmacct vs pmacctd
Sorry that it has taken so long but I am now getting round to this. My proposal would be to do two stages to this. The first being the addition of the /etc/collectd.d/ directory, moving existing collectd files that are currently included, into the collectd.d directory. This change would then enable users to add any additional collectd.xyz files into the system for use with an addon. A second step would then be to raise a new bug for an addon that had data available that would be generally required by all users so that the appropriate config file could be created and the associated plugin if required. A separate bug report would then be created for each addon that required a config file so that as each is completed that bug report can be closed. Patch to create the collectd.d directory and adjust existing collectd profiles such as precache and thermal has been submitted. https://lists.ipfire.org/hyperkitty/list/development@lists.ipfire.org/thread/AWHFVRWB2CARCEKM25PXAGRHNVRSATRH/ https://patchwork.ipfire.org/project/ipfire/list/?series=4389 v2 version of patch submitted after feedback from dev mailing list. https://lists.ipfire.org/hyperkitty/list/development@lists.ipfire.org/thread/QBBC54A7VBVXYJTEASU423TJ726HRUIY/ https://patchwork.ipfire.org/project/ipfire/list/?series=4391 The patch has been submitted into next (will be CU190) |