Delay during installation of master server

Bug #138436 reported by AlainKnaff on 2007-09-09
2
Affects Status Importance Assigned to Milestone
nis (Debian)
New
Unknown
nis (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: nis

Unlike many other distributions, (K)ubuntu uses the same package both for NIS server and NIS client. And unfortunately messes this feat up.

By default, this is configured to start a client, which leads to a very slow package installation, because it will wait for a server, which doesn't exist (... because itself is meant to be the server ...)

Wouldn't it be possible to either
 * split the package in 2 (or in 3: nis-common, nis-server, nis-client). Probably the other distributions are on to something here!
 * ... or, if that is not possible, use a sane default (such as not starting any services by default, until admin chooses one mode in /etc/default/nis ... or while we're at it, why not prompt the user during installation, in the same way like the NIS domain name is prompted for..)

Oddly enough, even after disabling NISCLIENT in /etc/default/nis, it is _still_ slow. Maybe similar design issues exist elsewhere within the package?

On Wed, Jun 30, 2004 at 11:06:31AM +0200, Petter Reinholdtsen wrote:

> Please split /etc/init.d/nis into /etc/init.d/ypserv and
> /etc/init.d/ypbind to make it possible to restart only the server or
> only the client part of NIS.

I had some vauge thoughts that it might be best to split the entire NIS
package into separate server and client parts - they are distinct
upstream and it'd simplify the whole 'do you want to run a server'
thing. I haven't discussed that with Miquel at all, though, or really
thought it through - and it'd be post-Sarge material.

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

Hi

You're right of corse, autofs should probably start as early as
with mountnfs.sh in single user mode.

Because most people expect autofs to work with NIS, I don't want
to start it before ypbind running though.

nis is started as number 19 in multi-user runlevels, which
leaves me no way to start autfs after ypbind but before other
daemons.

I suggest splitting the nis init script into a part that does an
ypbind and is started right after portmap, and a server part
that can be startet later.

portmap is started in single user mode before mountnfs.sh
(obviously), thus this would allow me to put autofs init in a
sensible place.

HTH, 2ri
--
Help securing email, spread GPG, clearsign all mail. http://www.gnupg.org
.
< hjw> statistics are like a bikini, what they reveal is suggestive,
what they conceal is vital

On Tue, 31 Aug 2004, Arthur Korn wrote:
> You're right of corse, autofs should probably start as early as with
> mountnfs.sh in single user mode.
>
> Because most people expect autofs to work with NIS, I don't want to
> start it before ypbind running though.
>
> nis is started as number 19 in multi-user runlevels, which leaves me no
> way to start autfs after ypbind but before other daemons.

Eesh, yeah, that is tough. It'd be nice if there was a wider range of
numbers that things started on - IE, a few blanks between network service
and starting daemons, where other services that require networking but are
required by the daemons could start. This is exactly what 163116 is
discussing. A bit late now, though. :)

> I suggest splitting the nis init script into a part that does an ypbind
> and is started right after portmap, and a server part that can be
> startet later.
>
> portmap is started in single user mode before mountnfs.sh (obviously),
> thus this would allow me to put autofs init in a sensible place.

That sounds like a great idea to me!

------------------------------------------------------------------------
| nate carlson | <email address hidden> | http://www.natecarlson.com |
| depriving some poor village of its idiot since 1981 |
------------------------------------------------------------------------

On Tue, Aug 31, 2004 at 01:43:51AM +0200, Arthur Korn wrote:

> I suggest splitting the nis init script into a part that does an
> ypbind and is started right after portmap, and a server part
> that can be startet later.

This won't fly terribly well with the fairly common case where the NIS
server is also its own client: the ypbind startup will time out waiting
for the server that isn't running yet. This produces an unwelcome pause
as the system starts up and means that having ypbind running may not
actually be doing any good (since there may be nothing for it to bind to
yet).

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

Mark Brown schrieb:
> On Tue, Aug 31, 2004 at 01:43:51AM +0200, Arthur Korn wrote:
>
> > I suggest splitting the nis init script into a part that does an
> > ypbind and is started right after portmap, and a server part
> > that can be startet later.
>
> This won't fly terribly well with the fairly common case where the NIS
> server is also its own client.

Granted.

So what's keeping ypserv from being started before mountnfs.sh
in S44 so that there is no window where NFS shares are mounted
but NIS users are not yet available?

ciao, 2ri
--
Help securing email, spread GPG, clearsign all mail. http://www.gnupg.org
.
"They all can be blown up!"
"Riff, that's _always_ your plan!"
"It's more of a philosphy."
 -- http://www.sluggy.com/daily.php?date=030521

On Thu, Sep 02, 2004 at 01:07:28AM +0200, Arthur Korn wrote:

> So what's keeping ypserv from being started before mountnfs.sh
> in S44 so that there is no window where NFS shares are mounted
> but NIS users are not yet available?

Off the top of my head /usr on NFS would be an issue.

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

Hi

Mark Brown schrieb:
> On Thu, Sep 02, 2004 at 01:07:28AM +0200, Arthur Korn wrote:
>
> > So what's keeping ypserv from being started before mountnfs.sh
> > in S44 so that there is no window where NFS shares are mounted
> > but NIS users are not yet available?
>
> Off the top of my head /usr on NFS would be an issue.

I've shot over the line I see. Running autofs and nis out of / (ie without
/usr) would probably require too much work for it to be worth
it. So mountnfs.sh needs to run before any of those two.
Automounting /usr doesn't work then, but then it doesn't make
sense to me anyway and running an automounter on / is even
harmful.

So maybe this could work:
rcS.d:
S43portmap
S45mountnfs.sh
S50nis
S60autofs

(nfs-common is not started in S, it's not tremendously important
though, since it only starts statd nowadays).

ciao, 2ri
--
Help securing email, spread GPG, clearsign all mail. http://www.gnupg.org
.
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Binary package hint: nis

Unlike many other distributions, (K)ubuntu uses the same package both for NIS server and NIS client. And unfortunately messes this feat up.

By default, this is configured to start a client, which leads to a very slow package installation, because it will wait for a server, which doesn't exist (... because itself is meant to be the server ...)

Wouldn't it be possible to either
 * split the package in 2 (or in 3: nis-common, nis-server, nis-client). Probably the other distributions are on to something here!
 * ... or, if that is not possible, use a sane default (such as not starting any services by default, until admin chooses one mode in /etc/default/nis ... or while we're at it, why not prompt the user during installation, in the same way like the NIS domain name is prompted for..)

Oddly enough, even after disabling NISCLIENT in /etc/default/nis, it is _still_ slow. Maybe similar design issues exist elsewhere within the package?

AlainKnaff (kubuntu-misc) wrote :

At least, the followup starts can be accelerated by adding the following to /etc/yp.conf :

ypserver 127.0.0.1

Changed in nis:
status: Unknown → New
Mark Brown (broonie) wrote :

Splitting the NIS package is difficult due in part to some minor licensing problems which prevent the package going through new in Debian. There are also some entertaining issues with handling upgrades if the init script is split due to init scripts being conffiles, although nothing insurmountable. The main reason that most distributions do this is actually that the Debian/Ubuntu NIS packages combine code released as three different tarballs for upstream.

The current default is going to be sensible for the majority of systems (setting up a new domain is a relatively uncommon operation) and I would much rather move towards making the client install less manual rather than more so.

Please report the problem with starting up with NISCLIENT=false as a separate issue, including the output produced by the init script as it runs. That sounds like it shouldn't be happening.

Mark Brown (broonie) wrote :

Just to clarify wrt NISCLIENT=false: the init script will wait for up to ten seconds for the client to bind to a server but otherwise it shouldn't wait for anything so if NISCLIENT=false the startup should be fairly quick. The only thing that jumps out at me is that if you are running a slave and have specified the master in /etc/default/nis it will attempt to sync the maps from the master server when it starts which could take a while to time out if the master is unavailaible. Without more information about the lengths of the delays or where in the process they occur it's difficult to comment further. In any case, it's a separate issue to the default configuration being for a NIS client.

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

Changed in nis (Ubuntu):
status: New → Incomplete
Chuck Short (zulcss) on 2009-10-29
Changed in nis (Ubuntu):
status: Incomplete → Confirmed

We are closing this bug report because there was no answer, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

Changed in nis (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.