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.
*/

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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.
*/

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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.

--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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?

--
Matthew Garrett | mjg59@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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

--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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?

--
Matthew Garrett | mjg59@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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.
*/

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel