Now that systemd is used by default, I think it is time to deprecate portreserve.
For those unfamiliar with it, portreserve is a small utility which binds specific network ports early on during the boot process, so that services using those ports can claim them when they start. The point is to avoid accidental clashes when services use random unbound privileged ports.
Currently portreserve has a SysV initscript. It doesn't make a lot of sense to migrate it to a systemd service unit because of the fact that systemd avoids the problem.
Any objections to this?
Relevant bug report: https://bugzilla.redhat.com/show_bug.cgi?id=617331
Tim. */
On Wed, Jun 29, 2011 at 04:48:58PM +0100, Tim Waugh wrote:
Now that systemd is used by default, I think it is time to deprecate portreserve.
For those unfamiliar with it, portreserve is a small utility which binds specific network ports early on during the boot process, so that services using those ports can claim them when they start. The point is to avoid accidental clashes when services use random unbound privileged ports.
Currently portreserve has a SysV initscript. It doesn't make a lot of sense to migrate it to a systemd service unit because of the fact that systemd avoids the problem.
Portreserve is also useful to reserve (not let the OS make use of) ports that are needed by an embedded management controller that intercepts delivery of packets to the port and delivers them to the BMC (e.g. the PowerEdge 1955 BMC). While we've done away with that behavior in newer systems, such are still in production use.
On Wed, Jun 29, 2011 at 12:27:47PM -0500, Matt Domsch wrote:
Portreserve is also useful to reserve (not let the OS make use of) ports that are needed by an embedded management controller that intercepts delivery of packets to the port and delivers them to the BMC (e.g. the PowerEdge 1955 BMC). While we've done away with that behavior in newer systems, such are still in production use.
Is that port number exposed to the OS in any way?
On Wed, Jun 29, 2011 at 06:34:35PM +0100, Matthew Garrett wrote:
On Wed, Jun 29, 2011 at 12:27:47PM -0500, Matt Domsch wrote:
Portreserve is also useful to reserve (not let the OS make use of) ports that are needed by an embedded management controller that intercepts delivery of packets to the port and delivers them to the BMC (e.g. the PowerEdge 1955 BMC). While we've done away with that behavior in newer systems, such are still in production use.
Is that port number exposed to the OS in any way?
Not that I can recall, which is why it was a horrible design. IIRC it was just the remote IPMI port, but there may have been a few others.
I misremembered [1] the system type, it was the PowerEdge 1855, not the newer 1955. So we did fix that particular bit of pain in newer generations. In that case, it was the IPMI port 623/tcp that was snarfing packets.
[1] http://lists.us.dell.com/pipermail/linux-poweredge/2005-November/023606.html
On Fri, Jul 01, 2011 at 12:09:35AM -0500, Matt Domsch wrote:
On Wed, Jun 29, 2011 at 06:34:35PM +0100, Matthew Garrett wrote:
Is that port number exposed to the OS in any way?
Not that I can recall, which is why it was a horrible design. IIRC it was just the remote IPMI port, but there may have been a few others.
That's borderline criminal. Is there any way to identify that such systems have this? Anything in smbios?
On Fri, 2011-07-01 at 00:09 -0500, Matt Domsch wrote:
On Wed, Jun 29, 2011 at 06:34:35PM +0100, Matthew Garrett wrote:
On Wed, Jun 29, 2011 at 12:27:47PM -0500, Matt Domsch wrote:
Portreserve is also useful to reserve (not let the OS make use of) ports that are needed by an embedded management controller that intercepts delivery of packets to the port and delivers them to the BMC (e.g. the PowerEdge 1955 BMC). While we've done away with that behavior in newer systems, such are still in production use.
Is that port number exposed to the OS in any way?
Not that I can recall, which is why it was a horrible design. IIRC it was just the remote IPMI port, but there may have been a few others.
I misremembered [1] the system type, it was the PowerEdge 1855, not the newer 1955. So we did fix that particular bit of pain in newer generations. In that case, it was the IPMI port 623/tcp that was snarfing packets.
[1] http://lists.us.dell.com/pipermail/linux-poweredge/2005-November/023606.html
I had some of the 1850s that had this "feature".
Istr nis binding to 623 and then not working and it utterly mystifying more than one of us for a while as to why that was happening.
-sv
The BMC thing sounds a bit more special-purpose than portreserve, and presumably could be done in its own package that could perhaps be installed as needed depending on the hardware.
So is the next step to deprecate portreserve? What actually needs to be done for that to happen?
Tim. */
On 07/11/2011 03:08 PM, Tim Waugh wrote:
The BMC thing sounds a bit more special-purpose than portreserve, and presumably could be done in its own package that could perhaps be installed as needed depending on the hardware.
So is the next step to deprecate portreserve? What actually needs to be done for that to happen?
I guess figure out what requires portreserve and ping those ?
JBG