Re: Conflicting assignment of priviledged ports on boot, once again

[Bernd Eckenfels]

In article <20090716105202.ga18...@logic.at> you wrote:
> What is currently the expert way to avoid/handle such port conflicts
> in Debian?

Afaik the outcome was, that daemons should only use random priveledged ports
which are not in services file.

Gruss
Bernd


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Conflicting assignment of priviledged ports on boot, once again

[Julien BLACHE]

Gernot Salzer  wrote:

Hi,

> What is currently the expert way to avoid/handle such port conflicts
> in Debian?

/etc/bindresvport.blacklist

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer -  
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Conflicting assignment of priviledged ports on boot, once again

[Gernot Salzer]

Hi,

what is the collected wisdom nowadays on how to avoid random port
conflicts when booting?

In 2005 I wrote:
"On boot some daemons (like nis/ypbind) obtain priviledged ports
via portmap/bindresvport(). Portmap assigns ports that are not in use
at the time of request, usually above 600. This strategy sometimes
conflicts with daemons that rely on fixed ports and that
start after ypbind (like cups, slapd): they find that their port
is already in use."
[http://lists.debian.org/debian-devel/2005/09/msg01062.html]
(My description then was not accurate, since portmap only registers
port bindings; but otherwise the issue remains.)

I went on to suggest that Debian adopt the portreserve/portrelease
approach [http://cyberelk.net/tim/software/portreserve/], which would
solve many problems. In the ensuing discussion people acknowledged
that there is a problem and that portreserve would help in most
situations, but apparently it was not considered serious enough.

In 2009, I'm still bitten by this problem, and it seems that not much
has changed in Debian. Portreserve is available as package, but no
service drops on installation the required info in /etc/portreserve .
(It seems that Fedora in adopting this approach, though
[https://fedoraproject.org/wiki/Features/Portreserve]).

What is currently the expert way to avoid/handle such port conflicts
in Debian?

Thanks,
   Gernot


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org