Re: Conflicting assignment of priviledged ports on boot
> This was already brought up to debian-devel. This thread has more
> solutions, but addresses less problems: what if the service is to be
> started when the package is installed but a RPC programs already
> listens there? The solution of shipping port reservations or of init
> dependencies won't help for this problem.
No, but it would help for most situations. With portreserve, the problem
would occur _only_ when installing a new service, but not after
reboots; moreover, it would occur only with _some_ installations, not
always. And finally, the installation script can locate the error
automatically (by checking whether the port is in use) and can suggest
the installer a solution. This seems to be acceptable (even though
this won't work with unsupervised installations).
The situation would be much better than now, since one can be sure
that once the service is installed, it will work in the future.
> The only real option is to
> change libc/portmap/all RPC services to consult a blacklist of ports
> shipped in libc/portmap.
Waiting for this solution means that probably nothing will change for
the next few years, due to the side-effects of such a change.
portreserve/portrelease, on the other hand, makes things only better,
not worse; it does not interfere with the boot sequence as it is now,
is easy to implement, and it does not interfere with an optimal solution
where bindresvport takes care by itself.
Thus portreserve can bridge the time until agreement
has been reached about the optimal solution, and can be easily removed
then.
Waiting for all-or-nothing doesn't seem very attractive to me.
Gernot
Reply to: