Bug 429329

wouldn't it be better to configure e.g. xinetd to "listen" on the port? I found it stupid to create & maintain new daemon, even if it is such small thing.

Can xinetd reserve ports without having a real binary to run and handle requests on that port?

Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.

OpenIPMI now ships xinetd service, which, when enabled, binds to UDP port 623 and does not allow portmap or any other service to bind to the port. The service does not do anything useful, it just silently consumes all incoming UDP packets.

As consequence, OpenIPMI.rpm now depends on xinetd.

I thought about shipping the service file as /usr/share/doc/OpenIPMI/rmcp.xinetd, which would require user to manually install xinetd and copy the service configuration to /etc/xinetd/ when he/she is interested in the service. This solution would relax the dependency on xinetd, on the other hand I consider the manual copying less user friendly and it makes future update of the config file difficult.

What about ports 663 and 664? It seems like those were the ports that I've usually seen hardware silently steal. Should they be added to this config too?

(In reply to comment #9)
> What about ports 663 and 664? It seems like those were the ports that I've
> usually seen hardware silently steal. Should they be added to this config too?  

Given that those are the two ports that caused this bug to be filed, I would hope so!

(In reply to comment #9)
> What about ports 663 and 664? 

664 is ASF Secure Remote Management and Control Protocol, I agree it should be blocked and I'll add it to the service.

But what is port 663? IPMI specification does not reference this port and IANA says "PureNoise"...

Could we add a release note stating that this "fix" has to be enabled by hand, i.e. by changing the "disable = yes" line within the /etc/xinet.d/rmcp file?

Release note added. If any revisions are required, please set the 
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

New Contents:
Some IPMI-enabled hardware makes use of UDP ports 623 (ASF Remote Management and Control Protocol) and 664 (ASF Secure Remote Management and Control Protocol) which corrupts other traffic on these ports, causing symptomes like autofs mounts hanging. The OpenIPMI package provides a configuration file for xinetd that prevents other services from using these ports, so that they do not interfere with IPMI. On affected systems, the fix has to be enabled manually by setting "disabled = no" for the appropriate port(s) in /etc/xinetd.d/rmcp and (re)starting xinetd service.

Release note updated. If any revisions are required, please set the 
"requires_release_notes"  flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

Diffed Contents:
@@ -1 +1,9 @@
-Some IPMI-enabled hardware makes use of UDP ports 623 (ASF Remote Management and Control Protocol) and 664 (ASF Secure Remote Management and Control Protocol) which corrupts other traffic on these ports, causing symptomes like autofs mounts hanging. The OpenIPMI package provides a configuration file for xinetd that prevents other services from using these ports, so that they do not interfere with IPMI. On affected systems, the fix has to be enabled manually by setting "disabled = no" for the appropriate port(s) in /etc/xinetd.d/rmcp and (re)starting xinetd service.+some IPMI-enabled hardware makes use of UDP ports 623 (ASF Remote
+Management and Control Protocol) and 664 (ASF Secure Remote Management and
+Control Protocol), which corrupts other traffic on these ports, causing
+symptoms such as autofs mounts hanging. The OpenIPMI package provides a
+configuration file for xinetd that prevents other services from using these
+ports, so that they do not interfere with IPMI. On affected systems, the
+fix has to be enabled manually by setting "disabled = no" for the
+appropriate port(s) in /etc/xinetd.d/rmcp and (re)starting the xinetd
+service. (BZ#429329)

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-1312.html

It was a heavy-handed fix to require xinetd to be installed.  Of course when xinetd installs, it defaults to running.  Basic configuration guidelines 101: turn off and uninstall daemons you don't need, but now that would break this pseudo-dependency.  And it IS a false dependency: OpenIPMI does NOT require xinetd.  But not installing xinetd is no longer an option, and unfortunately it's not even so simple as to disable xinetd globally, because we do use it some places.  So this will now require completely new workarounds in our configuration management settings to differentiate and handle the different cases, with the risk of mistakes and disabling xinetd where it is needed.

Manual intervention is already required to enable this fix, why would it have been too much to both edit a file AND copy a file?  Couldn't it have been accomplished with rpm triggers?  And when will RedHat GET that such a fix as this is security significant, unacceptable to your government customers and probably most corporate customers with a clue?  (Sorry, but my aggravation is high because this isn't the first time that updates have resulted in new and unrelated daemons installed and running.)

Actually, it was just simply a mistake to do this.  Other packages put files into /etc/xinetd.d/ without requiring xinetd itself.  /etc/xinetd.d/ is owned by the filesystem package.