Bug 497847
| Summary: | need send_nsca & nsca to be customized to send/receive packets larger than default | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora EPEL | Reporter: | Daniel Virely <daniel.virely> | ||||
| Component: | nsca | Assignee: | Wart <wart> | ||||
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | el5 | CC: | trast, wart, xavier | ||||
| Target Milestone: | --- | Keywords: | Reopened | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | ActualBug | ||||||
| Fixed In Version: | 2.7.2-7.el5 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2017-04-06 10:38:15 UTC | Type: | --- | ||||
| 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
Daniel Virely
2009-04-27 14:42:37 UTC
hello any update on this request please ? thanks by advance Rgds Daniel Created attachment 354153 [details]
Increase max plugin output size
This is related to https://bugzilla.redhat.com/show_bug.cgi?id=469198, where the max output size increase was backported from nagios cvs. Attached patch increase the max size to 8192 in nsca, to match what's in nagios. Wart, are you ok with the patch ? This looks fine to me. Go ahead and commit it to CVS and rebuild. nsca-2.7.2-7.el4 has been submitted as an update for Fedora EPEL 4. http://admin.fedoraproject.org/updates/nsca-2.7.2-7.el4 nsca-2.7.2-7.el5 has been submitted as an update for Fedora EPEL 5. http://admin.fedoraproject.org/updates/nsca-2.7.2-7.el5 nsca-2.7.2-7.el4 has been pushed to the Fedora EPEL 4 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update nsca'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/EL-4/FEDORA-EPEL-2009-0094 nsca-2.7.2-7.el5 has been pushed to the Fedora EPEL 5 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update nsca'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/EL-5/FEDORA-EPEL-2009-0108 nsca-2.7.2-7.el4 has been pushed to the Fedora EPEL 4 stable repository. If problems still persist, please make note of it in this bug report. nsca-2.7.2-7.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report. I just had a rather interesting expedition through TFS, and it turns out send_nsca and nsca always work on a static packet whose size is determined at compile time. They send/receive this packet in full, even if most of it is garbage, and compute the CRC32 over the whole of this packet. This boils down to 1. this patch causes a lot of network traffic for people who don't need it and more importantly 2. if client and server were compiled with a different MAX_PLUGINOUTPUT_LENGTH, they won't be able to cooperate because the CRC32 will always be wrong Blame upstream for (2), but IMVHO this variable cannot be changed. Not unilaterally at least, and definitely not without warning everyone in the changelog that their setup just so happened to become incompatible with every other distribution's nagios. Hello Can packets sent over the network, be limited to the "useful length" and CRC calculated on that length? ( MAX_PLUGINOUTPUT_LENGTH would be only the max exchangeable size) so that using the new version on the nagios side, would be transparent of older agents? The use of metrics collection in the nagios & send_nsca environnent rapidly reach the max size of the send-nsca packets exchanged over the network. The side effect of the limitation is that there is no return code when packets are truncated when size exceeds 525 char. Thanks Kind Regards Daniel I *think* it should be possible to always pad the packet (and probably it would be better to use nulls instead of garbage so we don't give away old memory) to the 525 bytes used on older versions, but allow a larger transmission. That way, if the packet is shorter it's still compatible and will be truncated as before; if it's longer it'll still be cut off. Of course I haven't stared at the code long enough to figure out whether it's possible to determine packet length simply by reading until data is exhausted. If it's not, we'd need some kind of way to include a length field that doesn't break compatibility. BTW, I just noticed that nagios.org's 3.x changelog says they did some changes to the MAX_PLUGINOUTPUT_LENGTH too. So either they have a better solution, or they don't care much about compatibility either. (The 2.x changelogs aren't online so I can't check when they started doing that.) Upstream bug report : http://tracker.nagios.org/view.php?id=78 I think the best to do for now is to revert the patch and push a new version. Wart, Daniel, Thomas, what do you think ? I agree. Let's remove the patch and rebuild. The original premise of this bug report, that the increased message size is compatible with the latest Nagios in epel5, was incorrect. If Nagios for epel5 ever really changes to support the larger size, then we can come back to this patch. Fedora EPEL 5 changed to end-of-life (EOL) status on 2017-03-31. Fedora EPEL 5 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora or Fedora EPEL, please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |