Debian Bug report logs - #306465
nis: ypserv can bind to port 636 which causes slapd to fail to start

version graph

Package: nis; Maintainer for nis is Mark Brown <broonie@debian.org>; Source for nis is src:nis.

Reported by: Jens Taprogge <jens.taprogge@post.rwth-aachen.de>

Date: Tue, 26 Apr 2005 19:48:03 UTC

Severity: normal

Tags: confirmed

Merged with 257876

Found in versions 3.11-3, 3.13-2

Done: Mark Brown <broonie@sirena.org.uk>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Miquel van Smoorenburg <miquels@cistron.nl>:
Bug#306465; Package nis. Full text and rfc822 format available.

Acknowledgement sent to Jens Taprogge <jens.taprogge@post.rwth-aachen.de>:
New Bug report received and forwarded. Copy sent to Miquel van Smoorenburg <miquels@cistron.nl>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Jens Taprogge <jens.taprogge@post.rwth-aachen.de>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: nis: ypserv can bind to port 636 which causes slapd to fail to start
Date: Tue, 26 Apr 2005 21:31:09 +0200
Package: nis
Version: 3.13-2
Severity: normal

I have had problems with ypserv binding to port 636 a couple of times.
This port is also used by slapd.  Since slapd is startes after nis, this
causes slapd to be unable to bind and thus fail.

Obviously one work around the problem by specifying a port for ypserv to bind
to.  But this does not make the default setup work.  Perhaps nis should
started after slapd?


-- Package-specific info:

NIS domain: taprogge.wh 


-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.10
Locale: LANG=C, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15)

Versions of packages nis depends on:
ii  debconf                     1.4.30.13    Debian configuration management sy
ii  libc6                       2.3.2.ds1-20 GNU C Library: Shared libraries an
ii  libgdbm3                    1.8.3-2      GNU dbm database routines (runtime
ii  libslp1                     1.0.11a-2    OpenSLP libraries
ii  make                        3.80-9       The GNU version of the "make" util
ii  netbase                     4.21         Basic TCP/IP networking system
ii  portmap                     5-9          The RPC portmapper
ii  sysvinit                    2.86.ds1-1   System-V like init

-- debconf information:
* nis/not-yet-configured:
  nis/domain:



Information forwarded to debian-bugs-dist@lists.debian.org, Miquel van Smoorenburg <miquels@cistron.nl>:
Bug#306465; Package nis. Full text and rfc822 format available.

Acknowledgement sent to Mark Brown <broonie@debian.org>:
Extra info received and forwarded to list. Copy sent to Miquel van Smoorenburg <miquels@cistron.nl>. Full text and rfc822 format available.

Message #10 received at 306465@bugs.debian.org (full text, mbox):

From: Mark Brown <broonie@debian.org>
To: Jens Taprogge <jens.taprogge@post.rwth-aachen.de>, 306465@bugs.debian.org
Cc: control@bugs.debian.org
Subject: Re: Bug#306465: nis: ypserv can bind to port 636 which causes slapd to fail to start
Date: Tue, 26 Apr 2005 21:35:01 +0100
merge 306465 257876
thanks

On Tue, Apr 26, 2005 at 09:31:09PM +0200, Jens Taprogge wrote:

> I have had problems with ypserv binding to port 636 a couple of times.
> This port is also used by slapd.  Since slapd is startes after nis, this
> causes slapd to be unable to bind and thus fail.

This is a general problem with network services that don't need a
particular port and always has been.  The kernel will quite happily hand
out any old port if you don't specify one and they can easily get given
something that another service wants to explictly bind to.

> Obviously one work around the problem by specifying a port for ypserv to bind
> to.  But this does not make the default setup work.

Well, it does work most of the time (as I say, there's always been the
potential for this to go wrong).  It does depend on the particular
environment if something goes wrong - essentially, you've just been
unlucky.

> Perhaps nis should started after slapd?

This won't help since the same issue applies in interaction with any
service that needs a particular port.  In any case, NIS has to start
fairly early since it may be required for important filesystems (via
autofs) and for accounts.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."



Merged 257876 306465. Request was from Mark Brown <broonie@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Miquel van Smoorenburg <miquels@cistron.nl>:
Bug#306465; Package nis. Full text and rfc822 format available.

Acknowledgement sent to Jens Taprogge <jens.taprogge@rwth-aachen.de>:
Extra info received and forwarded to list. Copy sent to Miquel van Smoorenburg <miquels@cistron.nl>. Full text and rfc822 format available.

Message #17 received at 306465@bugs.debian.org (full text, mbox):

From: Jens Taprogge <jens.taprogge@rwth-aachen.de>
To: Mark Brown <broonie@debian.org>
Cc: 306465@bugs.debian.org
Subject: Re: Bug#306465: nis: ypserv can bind to port 636 which causes slapd to fail to start
Date: Tue, 26 Apr 2005 23:29:06 +0200
On Tue, Apr 26, 2005 at 09:35:01PM +0100, Mark Brown wrote:
> merge 306465 257876
> thanks
> 
> On Tue, Apr 26, 2005 at 09:31:09PM +0200, Jens Taprogge wrote:
> 
> > I have had problems with ypserv binding to port 636 a couple of times.
> > This port is also used by slapd.  Since slapd is startes after nis, this
> > causes slapd to be unable to bind and thus fail.
> 
> This is a general problem with network services that don't need a
> particular port and always has been.  The kernel will quite happily hand
> out any old port if you don't specify one and they can easily get given
> something that another service wants to explictly bind to.
> 
> > Obviously one work around the problem by specifying a port for ypserv to bind
> > to.  But this does not make the default setup work.
> 
> Well, it does work most of the time (as I say, there's always been the
> potential for this to go wrong).  It does depend on the particular
> environment if something goes wrong - essentially, you've just been
> unlucky.
> 
> > Perhaps nis should started after slapd?
> 
> This won't help since the same issue applies in interaction with any
> service that needs a particular port.

Yes. I do realize that. But: see below.

> In any case, NIS has to start
> fairly early since it may be required for important filesystems (via
> autofs) and for accounts.

The same is---or at least can be, if ldap is used for authentification
and/or autofs map serving---true for slapd.  But since nis is flexible
in its use of ports it would make more sense IMHO to move it after slapd
which binds to specific ports.  At least if there are no other issues.

The problem can become quite pressing if for some reason it is triggered
on a remote system using ldap/slapd for authentification or autofs: it
can become impossible to log into the system and take care of the issue.

Best Regards
Jens Taprogge

> 
> -- 
> "You grabbed my hand and we fell into it, like a daydream - or a fever."
> 

-- 
Jens Taprogge



Information forwarded to debian-bugs-dist@lists.debian.org, Miquel van Smoorenburg <miquels@cistron.nl>:
Bug#306465; Package nis. Full text and rfc822 format available.

Acknowledgement sent to 306465@bugs.debian.org:
Extra info received and forwarded to list. Copy sent to Miquel van Smoorenburg <miquels@cistron.nl>. Full text and rfc822 format available.

Message #22 received at 306465@bugs.debian.org (full text, mbox):

From: Mark Brown <broonie@debian.org>
To: Jens Taprogge <jens.taprogge@rwth-aachen.de>, 306465@bugs.debian.org
Subject: Re: Bug#306465: nis: ypserv can bind to port 636 which causes slapd to fail to start
Date: Wed, 27 Apr 2005 12:37:16 +0100
On Tue, Apr 26, 2005 at 11:29:06PM +0200, Jens Taprogge wrote:

> The same is---or at least can be, if ldap is used for authentification
> and/or autofs map serving---true for slapd.  But since nis is flexible
> in its use of ports it would make more sense IMHO to move it after slapd
> which binds to specific ports.  At least if there are no other issues.

There's not much room for manouver here: NIS runs at S19 (as does
slapd), wedged between portmap at S18 and the majority of things at S20.
It looks like it would be easier to get the change you're asking for by
getting slapd started earlier (with portmap at S18, say) - it's easier
to move things earlier in the boot process and slapd doesn't have a
portmap to consider.

I feel that it is way too late in the game to contemplate changing the
NIS startup in such a manner for sarge.  There has been some talk of
restructuring things for etch (for example, in order to allow starting
autofs earlier) so it should probably be considered then.

If the OpenLDAP daemon were only called ldapd...  :)

> The problem can become quite pressing if for some reason it is triggered
> on a remote system using ldap/slapd for authentification or autofs: it
> can become impossible to log into the system and take care of the issue.

Fortunately the crossover between NIS and LDAP usage should be
relatively low.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."



Information forwarded to debian-bugs-dist@lists.debian.org, Miquel van Smoorenburg <miquels@cistron.nl>:
Bug#306465; Package nis. Full text and rfc822 format available.

Acknowledgement sent to Jens Taprogge <jens.taprogge@rwth-aachen.de>:
Extra info received and forwarded to list. Copy sent to Miquel van Smoorenburg <miquels@cistron.nl>. Full text and rfc822 format available.

Message #27 received at 306465@bugs.debian.org (full text, mbox):

From: Jens Taprogge <jens.taprogge@rwth-aachen.de>
To: 306465@bugs.debian.org
Cc: Torsten Landschoff <torsten@debian.org>
Subject: Re: Bug#306465: nis: ypserv can bind to port 636 which causes slapd to fail to start
Date: Wed, 27 Apr 2005 14:18:04 +0200
Torsten Landschoff cced.  The short story is: slapd can fail to start if
one of the nis services grabs one of slapd's ports. My suggestion was to
move nis behind slapd in the startup process.

On Wed, Apr 27, 2005 at 12:37:16PM +0100, Mark Brown wrote:
> On Tue, Apr 26, 2005 at 11:29:06PM +0200, Jens Taprogge wrote:
> 
> > The same is---or at least can be, if ldap is used for authentification
> > and/or autofs map serving---true for slapd.  But since nis is flexible
> > in its use of ports it would make more sense IMHO to move it after slapd
> > which binds to specific ports.  At least if there are no other issues.
> 
> There's not much room for manouver here: NIS runs at S19 (as does
> slapd), wedged between portmap at S18 and the majority of things at S20.
> It looks like it would be easier to get the change you're asking for by
> getting slapd started earlier (with portmap at S18, say) - it's easier
> to move things earlier in the boot process and slapd doesn't have a
> portmap to consider.

I agree. Should I file a bug against slpad?

> 
> I feel that it is way too late in the game to contemplate changing the
> NIS startup in such a manner for sarge.  There has been some talk of
> restructuring things for etch (for example, in order to allow starting
> autofs earlier) so it should probably be considered then.
> 
> If the OpenLDAP daemon were only called ldapd...  :)
> 
> > The problem can become quite pressing if for some reason it is triggered
> > on a remote system using ldap/slapd for authentification or autofs: it
> > can become impossible to log into the system and take care of the issue.
> 
> Fortunately the crossover between NIS and LDAP usage should be
> relatively low.

-- 
Jens Taprogge



Information forwarded to debian-bugs-dist@lists.debian.org, Mark Brown <broonie@debian.org>:
Bug#306465; Package nis. Full text and rfc822 format available.

Acknowledgement sent to Gernot Salzer <salzer@logic.at>:
Extra info received and forwarded to list. Copy sent to Mark Brown <broonie@debian.org>. Full text and rfc822 format available.

Message #32 received at 306465@bugs.debian.org (full text, mbox):

From: Gernot Salzer <salzer@logic.at>
To: 306465@bugs.debian.org
Cc: Gernot Salzer <salzer@logic.at>
Subject: portreserve/portrelease
Date: Fri, 16 Sep 2005 14:55:24 +0200
Hi,

portreserve/portrelease [1] seems to solve the problem.
Why not add portreserve to future Debian releases
together with appropriate modifications to all packages
containing programs depending on fixed ports?
See also the discussion on Bugzilla [2].

Best regards,
   Gernot

[1] http://cyberelk.net/tim/portreserve/
[2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103401




Information forwarded to debian-bugs-dist@lists.debian.org, Mark Brown <broonie@debian.org>:
Bug#306465; Package nis. Full text and rfc822 format available.

Acknowledgement sent to Mark Brown <broonie@sirena.org.uk>:
Extra info received and forwarded to list. Copy sent to Mark Brown <broonie@debian.org>. Full text and rfc822 format available.

Message #37 received at 306465@bugs.debian.org (full text, mbox):

From: Mark Brown <broonie@sirena.org.uk>
To: Gernot Salzer <salzer@logic.at>, 306465@bugs.debian.org
Subject: Re: Bug#306465: portreserve/portrelease
Date: Sat, 17 Sep 2005 16:41:53 +0100
[Message part 1 (text/plain, inline)]
On Fri, Sep 16, 2005 at 02:55:24PM +0200, Gernot Salzer wrote:

> portreserve/portrelease [1] seems to solve the problem.
> Why not add portreserve to future Debian releases
> together with appropriate modifications to all packages
> containing programs depending on fixed ports?

This suggestion would probably be better made on debian-devel?
Obviously (given this bug report) this wouldn't actually have any effect
on the NIS package.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."
[signature.asc (application/pgp-signature, inline)]

Message sent on to Jens Taprogge <jens.taprogge@post.rwth-aachen.de>:
Bug#306465. Full text and rfc822 format available.

Message #40 received at 306465-submitter@bugs.debian.org (full text, mbox):

From: Javier Fernández-Sanguino Peña <jfs@computer.org>
To: debian-devel@lists.debian.org
Cc: 257876-submitter@bugs.debian.org, 306465-submitter@bugs.debian.org, 261484-submitter@bugs.debian.org
Subject: Portreserve package alternative solution (was Re: Conflicting assignment of priviledged ports on boot)
Date: Sat, 24 Sep 2005 17:51:45 +0200
[Message part 1 (text/plain, inline)]
On Fri, Sep 23, 2005 at 04:54:56PM +0200, Gernot Salzer wrote:
> 
> Well, the problem has been around since at least 2002, so I'd prefer to start
> doing something about it.

Ok, ok. Just for the sake of those being bitten by this bug I've made
portreserve packages and sent and ITP. Packages are currently available at
http://people.debian.org/~jfs/portreserve/

I'm ccing the bug submitters to have them test that solution and see if it
works for them. In any case, bugs might need to be merged and/or renamed to
wishlist once portreserve is available. All the steps on how to avoid this
issue using portreserve are described in the upstream README file and
Debian's README.Debian file in the package.

We also need to coordinate with other distros (such as Red Hat or SuSE).

Regards

Javier
[signature.asc (application/pgp-signature, inline)]

Tags added: confirmed Request was from broonie@sirena.org.uk (Mark Brown) to control@bugs.debian.org. Full text and rfc822 format available.

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Fri, 07 Sep 2007 07:29:50 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Fri Apr 18 10:39:06 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.