Package: wnpp Version: N/A; reported 2005-09-24 Severity: wishlist Package name : portreserve Version : 0.0.0 Upstream Author : Tim Waugh <twaugh _AT_ redhat.com> URL : http://cyberelk.net/tim/portreserve/ License : GPL Description : The portreserve program aims to help services with well-known ports that lie in the bindresvport() range (currently 600-1023). It prevents programs requesting a port to the libc from occupying a real service's port by occupying it itself, until the real service tells it to release the port (generally in its init script).
Preliminary packages are available at http://people.debian.org/~jfs/portreserve/ The accompanying README.Debian file is attached Regards Javier
portreserve for Debian ---------------------- This package is provided to solve an issue that affects some servers and goes like this: - an RPC server (ypbind, rpc.mountd...) runs on boot and requests a dynamic port < 1024 using glibc's bindresvport(). - The libc provides the RPC server with a service in the 600-1023 with the following formula 'port = (PID % 424) + 600)', unfortunately, this port is the same port of a well known service (cups, laps, kadmin, rsync, or SSL-enabled IMAP, IRC and POP3 servers) which has not yet started. - the well-known service tries to start later in the boot sequence and fails because the port is assigned If you look at /etc/services you will see that the services affected with this issue are typically: 631 IPP == CUPS 636 LDAPS 749 Kerberos V kadmin 783 SpamAssasin 873 rsyncd 992-995 SSL-enabled telnet and ftp, IMAP, IRC, and POP3 It has been suggest a number of times to add these ports to a blacklist in libc but the glibc maintainers are against this as the affected services might change with time (Note: sometimes this has been requested in portmap, which is wrong since portmap does not assign ports, just registers them after being assigned). Typically local admins would fix this issue by changing the boot order of services so that the server with the static well-known port was started first, but sometimes this is not an option (i.e. mail servers that rely on information maps from NIS). Another option for local admins has been to assign static ports to the RPC services _if_ the service allows for this (like using '-p' with ypserv or ypbind). This also helps in setting up packet filters for RC services. What can I do fix this issue? ----------------------------- (Written for admins, but maintainers can adapt this easily to their packages too) If you are running some of the servers above and are affected by this issue you need to a) Create a /etc/portreserve/$server file with a single line, the name of the service port as found in /etc/services or a service number b) Modify the /etc/init.d/$server file and add this before the service is started: [ -x "`which portrelease`" ] && portrelease $server Notice that some package maintainers might gradually add this by default so you might find that has already been done for you. If it hasn't you might want to submit a bug to the Debian package quoting the above and asking the maintainer to 'Recommend' portreserve. That way you will not have to maintain these local changes yourself. Possible issues: ---------------- If an RPC service is already running and you install a new package that provides a daemon that requires the same port the installation will fail _even_ if the package uses portreserve and portreserve is installed. There is no way around this, since it would not make sense to have portrserve pre-configured for all possible services that require static ports if an admin is never going to install them and it's more manageable to have packages provide the services than having a central blacklist. In any case, admins that want to use portreserve as a blacklist regardless of the service being installed can do that through /etc/portrelease Further references: ------------------ Debian BTS: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=261484 [portmap] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=306465 [nis] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=257876 [nis] Red Hat's Bugzilla: https://bugzilla.redhat.com/103401 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154800 Debian mailing lists: http://lists.debian.org/debian-devel/2004/10/threads.html#00292 http://lists.debian.org/debian-devel/2005/09/thrd3.html#01062 -- Javier Fernandez-Sanguino Pen~a <[EMAIL PROTECTED]>, Sat, 24 Sep 2005 16:07:56 +0200
signature.asc
Description: Digital signature
