Ubuntu

NIS upstart dependency broken for lucid

Reported by harald on 2010-04-25
182
This bug affects 31 people
Affects Status Importance Assigned to Milestone
nis (Ubuntu)
High
Steve Langasek
Declined for Maverick by Martin Pitt
Lucid
High
Unassigned
Natty
High
Unassigned
Oneiric
High
Unassigned

Bug Description

Binary package hint: nis

NIS does not work on lucid: without upstart, it starts anytime, unrelated to net-device-up events. If the passwd/shadow is provided through NIS, it seems completly random, whether username resolution is provided to gdm.

The only fix seems an upstart startscript.

Chuck Short (zulcss) wrote :

This will probably get fixed in maverick and probably a SRU will be required.

Changed in nis (Ubuntu):
importance: Undecided → Wishlist
status: New → Confirmed
Ted Cabeen (ted-cabeen) wrote :

harald, can you describe the upstarts startscript you're using? This bug is burning me too.

harald (harald-net) wrote :

Ted: This is plain lucid, I'm not using custom upstart scripts at all.

Ted Cabeen (ted-cabeen) wrote :

Ahh, so you haven't implemented this? "The only fix seems an upstart startscript."

Paul Elliott (omahn) wrote :
Paul Elliott (omahn) wrote :
Paul Elliott (omahn) wrote :
Paul Elliott (omahn) wrote :
Paul Elliott (omahn) wrote :

Please find attached my first attempt at converting the nis init script to upstart jobs. Please can others review and let me know how these look? I've tested the client side (with ypbind) here and that works well. I've done very little testing with the server components other than checking they startup ok with the upstart jobs.

Emil Sit (emilsit) wrote :

To test these scripts, you should also remove /etc/init.d/nis, correct?

Paul Elliott (omahn) wrote :

Emil, rather than remove, it would probably be safer to just rename the /etc/init.d/nis script to prevent it firing. We have a local package here with the necessary changes and it appears to work fine. After a bit more testing I'll upload for others to review.

In my setup this bug causes excessive boot delays. I want to question the "wishlist" importance.

Paul Elliott (omahn) wrote :

Branch added that switches to upstart for the NIS package in Maverick. We've had a version of this branch running locally for a couple of months now with no known issues although we are only using the client side of the package. I've done very limited testing of the server side. Feedback appreciated.

Nicolas (nicolas-hoeft) wrote :

is this patch being integrated in 10.10?

Why is this bug only "wishlist"? NIS not working properly is a problem in its own right, but the fact that NIS has not been converted to upstart *also* causes problems with autofs - see https://bugs.launchpad.net/ubuntu/+source/nis/+bug/570513 (which is exactly what has bitten us after the upgrade from Hardy). There are still quite a few set-ups (e.g. in small companies) using NIS+autofs and compared to the previous LTS version (Hardy) this is a regression in my opinion. Hence, I would like to add my vote to the necessity of an SRU - this should definitely be fixed in Lucid, given that Lucid is LTS.

Mattias Andersson (matand) wrote :

I agree with #15 -- this needs to be fixed in ASAP (and it should be fixed in the LTS version!) I'm responsible for a whole network that relies entirely on the NIS+autofs functionality (home folders, backups, cluster nodes, etc.) If this doesn't work, then it causes all kinds of unforeseen problems. I have a large number of servers that I want to upgrade to Lucid, but I'm reluctant to do this just because of this problem.

wintermute (technobabble042) wrote :

How should I go about compiling the packages in the branched repo? I'd like to give them a try, but I've never rolled debian packages before.

Clint Byrum (clint-fewbar) wrote :

So, a couple of points regarding this bug..

Re: Wishlist .. I have to agree that this is a regression from the previous LTS, and that it is caused by a race condition. Race conditions are hard to reproduce without introducing something synthetic to slow one of the racers down, but in this case, its clear, nis must delay the start up of a few things like gdm and autofs. I'm raising that to High since nis users really can't be sure their system will boot properly.

Re: moving everything into upstart. This should be done, and on cursory examination, the linked branch looks like it is on the right track. However, doing so in an LTS as an SRU is highly invasive. We can possibly use a similar trick as we used for statd and portmap to block at a certain point in the boot until nis is started, by removing it from /etc/rc#.d and adding two upstart jobs:

# nis

start on runlevel [2345]

pre-start exec /etc/init.d/nis start
post-stop exec /etc/init.d/nis stop
#EOF

# nis-wait

start on starting gdm or starting autofs
stop on started nis or stopped nis

task
normal exit 2
instance $JOB

script
  status nis | grep -q 'start/running' && exit 0
  start nis || true
  logger -t nis-wait -p daemon.info blocking $JOB until nis starts...
  sleep 3600
end script
#EOF

Since this only affects Ubuntu, and I think the problem is well understood, I'm setting the status to Triaged.

Changed in nis (Ubuntu):
status: Confirmed → Triaged
importance: Wishlist → High
tags: added: regression-release
JimWright (jim-jim-wright) wrote :

I wanted to add "cron" to the list of things that have a race condition with NIS on startup, as I don't think cron has been mentioned in any of the other postings on this issue. If a NIS user has installed a crontab on a NIS client, and NIS has not started by the time cron starts, the result is that user's crontab will be ignored (the condition is logged in the system logs). The user then has to manually resubmit the crontab before cron will reconsider it.

Regards, Jim.

Maciej Puzio (maciej-puzio) wrote :

On my mail server postfix and dovecot depend on nis. Currently this particular dependency is handled properly, because all three daemons are started by means of /etc/rc?.d in the correct order. Please correct me if I am wrong, but I worry that the solution suggested by Clint Byrum in #18 might cause nis to race with postfix or, if postfix is converted to "native upstart", with dovecot. Anyway, the start condition for nis-wait would have to be extended to list all possible nis dependencies, and there could be plenty of them, seeing that nis provides very basic system information such as users, groups, etc. So we would have "start on starting gdm or starting autofs or starting postfix or starting dovecot or starting kdeinit4 or starting ...", and so on.

On Feb 7, 2011, at 4:03 PM, Maciej Puzio <email address hidden> wrote:

> On my mail server postfix and dovecot depend on nis. Currently this
> particular dependency is handled properly, because all three daemons are
> started by means of /etc/rc?.d in the correct order. Please correct me
> if I am wrong, but I worry that the solution suggested by Clint Byrum in
> #18 might cause nis to race with postfix or, if postfix is converted to
> "native upstart", with dovecot.

Right, good point. I've been monkeying with this, and i think the real need is to be able to make sure that anything that needs access to users and groups is blocked by nis, or ldap, or winbind, or puppet... Whatever you use to provide users and groups, has to run first.

The appropriate thing to do is to Develop a policy of variable exporting in upstart jobs.

env NEEDS_ID=1
export NEEDS_ID

adding that to all the services that need Ident would be awfully painful. But having the generic network-services job that has been proposed set it would allow us to just have postfix follow that job, and have nis, winbind, etc use

start on starting NEEDS_ID=1

If something else like autofs needs to start before generic network services it will have to export this variable. This decouples the consumers and providers.

>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/569757
>
> Title:
> NIS upstart dependancy broken for lucid
>
> Status in “nis” package in Ubuntu:
> Triaged
>
> Bug description:
> Binary package hint: nis
>
> NIS does not work on lucid: without upstart, it starts anytime,
> unrelated to net-device-up events. If the passwd/shadow is provided
> through NIS, it seems completly random, whether username resolution is
> provided to gdm.
>
> The only fix seems an upstart startscript.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/nis/+bug/569757/+subscribe

Re: the linked branch, here is a quick review of things I'd suggest changing:

* I understand that the package doesn't use debhelper. But to repeat all of the hard work that has gone into dh_installinit would be asking for bugs later. So you'd also need to add debhelper to the build-depends. After that add a call to dh_installinit and the #DEBHELPER# tag to the end of postinst. Also if you do this, the files are named incorrectly. Rename *.conf to nis.*.upstart . This will trigger dh_installinit to do its magic. Then you can remove all of the lines that install the upstart files in /etc/init.

* start/stop/reload/restart $job in maintainer scripts is going to cause issues. You should at the very least use invoke-rc.d, per Debian Policy 9.3.3. Further, this is all handled by dh_installinit...

* the removal of the old /etc/init.d/nis may accidentally remove the user's local changes to said file, which is in fact a conffile and so must be handled delicately. dh_installinit handles this as well, as long as you don't pass --upstart-only, which you wouldn't as that is only for things that are upstart specific (like wait jobs).

* default env values can and should be set with env stanzas.. so instead of putting START_YPBIND="false" in the first lines of pre-start.. just put env START_YPBIND="false" in the upstart job. This is really just a nit.. as this just makes the job run a tiny bit faster (these variables are parsed out at job load time by upstart instead of by the shell).

* changelog target should be natty since we'll have to fix this there first.

* Given the previous discussions, each of these needs a wait job that is started and waited for by anything needing NIS. One easy way to get "most of the jobs out there" is by blocking runlevel 2. This would work:

# ypbind-wait
start on starting rc RUNLEVEL=2
stop on started ypbind or stopped ypbind

env WAITER=
instance $WAITER$UPSTART_EVENTS
task
normal ext 2

script
  ... normal wait job stuff

The instance argument allows anything that is started before runlevel 2 to block on ypbind as well by doing:

start ypbind-wait WAITER=autofs

This will work as a stop gap until we solve the issue more elegantly with exported variables and a generic waiter job.

tags: added: upstart
Mark Russell (marrusl) wrote :

atd is another one that needs to wait for ypbind.

Jeremy Yoder (jyoder) wrote :

Hopefully this works. I'm attaching a working nis.conf and nis-wait.conf based on the comments so far. Put the files in /etc/init and that should be all that's necessary for most configurations. You shouldn't even need to remove the /etc/rc?.d nis links since it should just determine it's already started and exit.

The start line I used in nis.conf is based on the ypbind.conf file that Paul Elliott wrote, but the rest of the script is from Clint Byrum's suggestion. I also modified the nis-wait.conf to include cron and atd.

No, this isn't a perfect answer, but it works for me. I don't know if it's a complete enough suggestion to cover Maciej Puzio's case but it might be.

Jeremy Yoder (jyoder) wrote :
Christian Reis (kiko) on 2011-06-21
summary: - NIS upstart dependancy broken for lucid
+ NIS upstart dependency broken for lucid
Jeremy Yoder (jyoder) wrote :

Could this be targeted for 10.04.3? This is really a pretty bad problem with 10.04, and the 10.04.x releases are going to get further apart after 10.04.3.

Thanks!

Clint Byrum (clint-fewbar) wrote :

Jeremy, this needs to be fixed in Oneiric before we can backport the fix to Lucid. 10.04.3 is coming in just a few weeks, so I'm not sure we'll be able to get it up in time even if the fixed packages for Oneiric and lucid-proposed were uploaded tomorrow.. they'd still need verification.

That said, I'll do anything I can to help, including sponsoring any uploads.

Christian Reis (kiko) wrote :

I'm using a slightly modified version of the ypbind file posted in comment 5 on my diskless clients and it's working fine. The modification is around the starting condition:

# XXX: the original file checks if net-device-up IFACE=!lo, but I can't
# get that to work. And this seems to race a bit with gdm, because the
# user list isn't updated when it is rendered.
start on (filesystem and started portmap)

The file and my directory are posted online: http://bazaar.launchpad.net/~kiko/+junk/init-diskless/view/head:/ypbind.conf

Jeremy Yoder (jyoder) wrote :

Clint,

My attached files based on your original suggestion of two new upstart jobs should do the trick as far as a minimally invasive fix for many users. Anything more substantial would probably be hard to get approved for a point release right?

It looks (from Christian's latest comment) like the start line for my "nis" script should be modified to remove the "net-device-up IFACE!=lo" condition but otherwise I've been running these scripts for months with no issues on an otherwise untouched 10.04.2.

I'm sure you could add these to the existing package faster than I can (and do it right).

Thanks!

Clint Byrum (clint-fewbar) wrote :

Jeremy, thanks for those files. I've looked at what it will take to get those into a package. We need to make sure nis gets reconfigured to stop/start w/ upstart and that is a tiny bit tricky. Working now on an upload for oneiric that will solve this.

Clint Byrum (clint-fewbar) wrote :

Ok, I uploaded nis packages with Jeremy's upstart integration to my PPA for all releases affected and oneiric here:

ppa:clint-fewbar/fixes

Please if someone can give them a try, I'm particularly interested in whether the installation properly disables the init.d script and uses the upstart job instead to call it.

Clint Byrum (clint-fewbar) wrote :

Also I wanted to make one thing clear about 10.04.3. There's really no reason to get excited about it for NIS, since it is not on the CD or part of the kernel in any way. universe is always downloaded from the archive, so 10.04.3 makes no difference.

Jeremy Yoder (jyoder) wrote :

Ah, I didn't realize that about 10.04.3. Thanks for clearing that up.

Also thanks for the quick turnaround on a package update. Unfortunately, installing the new version failed for me:

Preparing to replace nis 3.17-31 (using .../nis_3.17-32ubuntu2~lucid1~ppa1_i386.deb) ...
 * Stopping NIS services [ OK ]
Unpacking replacement nis ...
Processing triggers for ureadahead ...
Processing triggers for man-db ...
Setting up nis (3.17-32ubuntu2~lucid1~ppa1) ...
 Removing any system startup links for /etc/init.d/nis ...
   /etc/rc1.d/K18nis
   /etc/rc2.d/S18nis
   /etc/rc3.d/S18nis
   /etc/rc4.d/S18nis
   /etc/rc5.d/S18nis
dpkg: error processing nis (--configure):
 subprocess installed post-installation script returned error exit status 105
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install. Trying to recover:
Setting up nis (3.17-32ubuntu2~lucid1~ppa1) ...
 Removing any system startup links for /etc/init.d/nis ...
dpkg: error processing nis (--configure):
 subprocess installed post-installation script returned error exit status 105
Errors were encountered while processing:
 nis

For the installation error try to remove /var/lib/dpkg/info/nis.postinst to avoid the error condition.

tags: added: natty

The problem is still in in natty.

Twbecker (twbecker) wrote :

...and still in oneiric. What is it going to take to get this fixed?

Clint Byrum (clint-fewbar) wrote :

Twbecker, can you try the packages in my PPA on oneiric? The postinst seems to be failing for people, but I need some help debugging it as it works fine for me. It appears to fail when trying to start the service, so the output of 'start nis' would be particularly useful after the failure.

Twbecker (twbecker) wrote :

I have a colleague that ran into the issue on Oneiric, I don't have a box handy to test it on. I'll relay this request to him though. My real interest is getting this fixed for 12.04, which I and several other colleagues are planning on moving to when it's released.

Twbecker (twbecker) wrote :
Download full text (3.3 KiB)

From my colleague:

“start nis” didn’t produce any errors, so I re-ran the install with a set –x added to the script. It hit problems in invoke-rc.d, so I ran that standalone with set –x. Results:

# apt-get install nis
Reading package lists... Done
Building dependency tree
Reading state information... Done
nis is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]?
Setting up nis (3.17-32ubuntu2~oneiric1~ppa1) ...
+ set -e
+ umask 022
+ . /usr/share/debconf/confmodule
+ [ ! ]
+ PERL_DL_NONLAZY=1
+ export PERL_DL_NONLAZY
+ [ ]
+ exec /usr/share/debconf/frontend /var/lib/dpkg/info/nis.postinst configure 3.17-32ubuntu1
+ set -e
+ umask 022
+ . /usr/share/debconf/confmodule
+ [ ! 1 ]
+ [ -z ]
+ exec
+ [ ]
+ exec
+ DEBCONF_REDIR=1
+ export DEBCONF_REDIR
+ db_version 2.0
+ _db_cmd VERSION 2.0
+ IFS= printf %s\n VERSION 2.0
+ IFS=
 read -r _db_internal_line
+ RET=2.0
+ return 0
+ cd /etc/init.d
+ [ -f nis ]
+ chmod 755 nis
+ install_defaults
+ [ ! -s /etc/default/nis ]
+ return 0
+ . /etc/default/nis
+ NISSERVER=false
+ NISCLIENT=true
+ YPPWDDIR=/etc
+ YPCHANGEOK=chsh
+ NISMASTER=
+ YPSERVARGS=
+ YPBINDARGS=-no-dbus
+ YPPASSWDDARGS=
+ YPXFRDARGS=
+ db_get nis/domain
+ _db_cmd GET nis/domain
+ IFS= printf %s\n GET nis/domain
+ IFS=
 read -r _db_internal_line
+ RET=netapp.com
+ return 0
+ [ ######.com != ]
+ echo netapp.com
+ update-rc.d -f nis remove
 Removing any system startup links for /etc/init.d/nis ...
+ upstart_invoke_rcd start
+ action=start
+ invoke-rc.d --query nis start
dpkg: error processing nis (--configure):
 subprocess installed post-installation script returned error exit status 105
Errors were encountered while processing:
 nis
E: Sub-process /usr/bin/dpkg returned an error code (1)

And from invoke-rc.d:

# invoke-rc.d --query nis start
+ RUNLEVELHELPER=/sbin/runlevel
+ POLICYHELPER=/usr/sbin/policy-rc.d
+ INITDPREFIX=/etc/init.d/
+ RCDPREFIX=/etc/rc
+ BEQUIET=
+ MODE=
+ ACTION=
+ FALLBACK=
+ NOFALLBACK=
+ FORCE=
+ RETRY=
+ RETURNFAILURE=
+ RC=
+ set +e
+ test 3 -eq 0
+ state=I
+ test 3 -gt 0
+ test I != III
+ MODE=query
+ RETURNFAILURE=yes
+ shift
+ test 2 -gt 0
+ test I != III
+ verifyparameter nis
+ test 1 -eq 0
+ test 1 -ne 1
+ return
+ INITSCRIPTID=nis
+ state=II
+ shift
+ test 1 -gt 0
+ test II != III
+ verifyparameter start
+ test 1 -eq 0
+ test 1 -ne 1
+ return
+ ACTION=start
+ state=III
+ shift
+ test 0 -gt 0
+ test III != III
+ test ! -f /etc/init.d/nis
+ sed s/.*\ //
+ /sbin/runlevel
+ RL=2
+ test ! 0
+ test x2 = x0
+ test x2 = x6
+ test x2 = x0
+ test x2 = x6
+ test x2 != x
+ xargs
+ ls -d -Q /etc/rc2.d/S[0-9][0-9]nis
+ SLINK=
+ xargs
+ ls -d -Q /etc/rc2.d/K[0-9][0-9]nis
+ KLINK=
+ xargs
+ ls -d -Q /etc/rcS.d/S[0-9][0-9]nis
+ SSLINK=
+ verifyrclink
+ doexit=
+ test 0 -gt 0
+ test x != x
+ return 0
+ RC=
+ testexec
+ test 0 -gt 0
+ return 1
+ testexec
+ test 0 -gt 0
+ return 1
+ testexec
+ test 0 -gt 0
+ return 1
+ testexec /etc/init.d/nis
+ test 1 -gt 0
+ test -x /etc/init.d/nis
+ return 0
+ test x = x
+ test xquery = xquery
+ RC=105
+...

Read more...

Clint Byrum (clint-fewbar) wrote :

Twbecker, thank you! Bug found.. new packages pushed to my PPA (they will take a while to build), the version should be 3.17-32ubuntu2~oneiric1~ppa2

If those look good (they tested fine here) then this should be ready for upload to precise.

Jeremy Yoder (jyoder) wrote :

Thanks for working on this! Once you get Oneiric/Precise working, are you planning to fix this in Lucid? Lucid is still going to be around for a few more years :)

Excerpts from Jeremy Yoder's message of Fri Jan 27 17:22:47 UTC 2012:
> Thanks for working on this! Once you get Oneiric/Precise working, are
> you planning to fix this in Lucid? Lucid is still going to be around
> for a few more years :)
>

I will discuss it with my fellow SRU team members. I think its worth
fixing like this, and the patch is straight forward enough. But changing
from sysv controlled to upstart is a rather radical change so some users
might not appreciate the change.

If nothing else, I will make sure to setup a backport PPA just for lucid.

exactt (giesbert) on 2012-02-10
tags: added: oneiric
Steve Langasek (vorlon) on 2012-02-28
Changed in nis (Ubuntu):
assignee: nobody → Steve Langasek (vorlon)
Steve Langasek (vorlon) wrote :

I've taken on the task of trying to get this fixed for precise using native and idiomatic upstart jobs for each of the services. It's not directly backportable to lucid, as it depends on upstart's wait-for-state generic helper instead of doing things directly in the nis-wait job, adds a versioned dependency on rpcbind for upstart support in that package, and references the 'failsafe-boot' event. The first of these can be addressed for backporting by using Jeremy's implementation, and the second can use an alternative dependency on the upstart-enabled portmap package. The third can be replaced with 'network-device-up INTERFACE!=lo', I guess.

Honestly if I'd had the sense to read through the bug log all the way to the end before poking at this, I think I would've just gone with Jeremy's implementation. But now having gone to the effort of splitting the init script up into proper per-service upstart jobs, I think that's the better way forward for precise rather than a halfway measure of a nis-sysv job.

I've pushed these changes to lp:ubuntu/nis. Clint, what do you think? If we're introducing upstart jobs in an SRU anyway, I'm not sure it matters terribly if we're completely removing the init script vs. wrapping it, so I think it would be better to go all the way and avoid having to do two separate init script transitions.

Steve Langasek (vorlon) wrote :

Note that this implementation only has 'start on starting autofs or starting am-utils', because these are the only packages in Debian unstable whose init scripts declare a 'Should-Start: ypbind' except for cron, and cron has been fixed to now be able to pick up new NSS information after startup.

Jeremy's implementation also references gdm, lightdm, and atd. I think if these are going to be included, we should also coordinate with Debian to get 'Should-Start' added to the init scripts.

Changed in nis (Ubuntu):
status: Triaged → Fix Committed
Steve Langasek (vorlon) on 2012-02-28
Changed in nis (Ubuntu Lucid):
importance: Undecided → High
status: New → Triaged
Changed in nis (Ubuntu Natty):
importance: Undecided → High
Changed in nis (Ubuntu Oneiric):
status: New → Triaged
importance: Undecided → High
Changed in nis (Ubuntu Natty):
status: New → Triaged
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nis - 3.17-32ubuntu2

---------------
nis (3.17-32ubuntu2) precise; urgency=low

  * Convert to native upstart jobs, with a versioned dependency on
    upstart (>= 0.9.7-2) because we use the wait-for-state job. LP: #569757.
  * Depend on rpcbind (>= 0.2.0-6ubuntu1) instead of portmap to ensure our
    upstart job dependencies are satisfied.
 -- Steve Langasek <email address hidden> Tue, 28 Feb 2012 03:29:44 +0000

Changed in nis (Ubuntu):
status: Fix Committed → Fix Released
Jeremy Yoder (jyoder) wrote :

Is that change to CRON backported to Lucid? I'm guessing not, but that would be nice.

As for gdm/lightdm/atd I think the crucial one there is atd. The login stuff probably takes long enough to start that NIS will be up by then (plus that's nowhere near an exhaustive list of *dm's and adding all of them is probably the wrong way to go).

I'm torn on whether to add the upstart wrappers or completely replace init.d with upstart in Lucid. I guess I'd lean towards the more minimal change to Lucid and having the new system in Precise, but I defer to your expertise. As long as one of them happens I think we're good.

Somehow I missed Clint's reply to my message, but since NIS is pretty darn hosed in Lucid without one of these workarounds, I can't see how anyone would mind it actually working out of the box. Even if the change breaks the duct tape things people have done for 2 years to work around this bug, at least they can back those things out once and count on it not breaking again. Also, the type of people who are really going to care are going to check the changelogs before they update :)

Thanks guys!

Steve Langasek (vorlon) on 2012-03-10
Changed in nis (Ubuntu Lucid):
status: Triaged → In Progress
Changed in nis (Ubuntu Natty):
status: Triaged → In Progress
Changed in nis (Ubuntu Oneiric):
status: Triaged → In Progress

Hello harald, or anyone else affected,

Accepted nis into lucid-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in nis (Ubuntu Lucid):
status: In Progress → Fix Committed
tags: added: verification-needed
Clint Byrum (clint-fewbar) wrote :

Hello harald, or anyone else affected,

Accepted nis into natty-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in nis (Ubuntu Natty):
status: In Progress → Fix Committed
Changed in nis (Ubuntu Oneiric):
status: In Progress → Fix Committed
Clint Byrum (clint-fewbar) wrote :

Hello harald, or anyone else affected,

Accepted nis into oneiric-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Jeremy Yoder (jyoder) wrote :

Tested the proposed package in Lucid and it appears to depend on Upstart 0.9.7-2 but Lucid only has 0.6.5-8. So trying to upgrade marks "nis" as broken and wants to remove it.

I confirm nis from lucid-proposed is uninstallable due to dependency on upstart (>= 0.9.7-2) and probably same problem will occurs on natty since natty has upstart 0.9.7-1 and 0.9.7-1.1 in natty-proposed

marking as verification-failed

tags: added: verification-failed
removed: verification-needed
Martin Pitt (pitti) wrote :

I removed the lucid-proposed package again, and reset the verification tags for oneiric/natty.

2012-03-15 17:53:55 INFO Removing candidates:
2012-03-15 17:53:55 INFO nis 3.17-31ubuntu0.10.04.1 in lucid
2012-03-15 17:53:55 INFO nis 3.17-31ubuntu0.10.04.1 in lucid amd64
2012-03-15 17:53:55 INFO nis 3.17-31ubuntu0.10.04.1 in lucid armel
2012-03-15 17:53:55 INFO nis 3.17-31ubuntu0.10.04.1 in lucid i386
2012-03-15 17:53:55 INFO nis 3.17-31ubuntu0.10.04.1 in lucid ia64
2012-03-15 17:53:55 INFO nis 3.17-31ubuntu0.10.04.1 in lucid powerpc
2012-03-15 17:53:55 INFO nis 3.17-31ubuntu0.10.04.1 in lucid sparc
2012-03-15 17:53:55 INFO Removed-by: Martin Pitt
2012-03-15 17:53:55 INFO Comment: broken SRU, uninstallable; LP #569757

Changed in nis (Ubuntu Lucid):
status: Fix Committed → Triaged
Martin Pitt (pitti) wrote :

2012-03-15 17:56:08 INFO Removing candidates:
2012-03-15 17:56:08 INFO nis 3.17-31ubuntu0.11.04.1 in natty
2012-03-15 17:56:08 INFO nis 3.17-31ubuntu0.11.04.1 in natty amd64
2012-03-15 17:56:08 INFO nis 3.17-31ubuntu0.11.04.1 in natty armel
2012-03-15 17:56:08 INFO nis 3.17-31ubuntu0.11.04.1 in natty i386
2012-03-15 17:56:08 INFO nis 3.17-31ubuntu0.11.04.1 in natty powerpc
2012-03-15 17:56:08 INFO Removed-by: Martin Pitt
2012-03-15 17:56:08 INFO Comment: broken SRU, uninstallable; LP #569757

Changed in nis (Ubuntu Natty):
status: Fix Committed → Triaged
tags: added: verification-needed
removed: verification-failed
Steve Langasek (vorlon) wrote :

yep, sorry about that. Packages reuploaded for lucid and natty with the dependency relaxed.

Jeremy Yoder (jyoder) wrote :

Steve/Martin:

I'm not seeing the updated nis package in lucid-proposed. Should I be?

Thanks!

On Tue, Mar 20, 2012 at 03:25:13PM -0000, Jeremy Yoder wrote:
> I'm not seeing the updated nis package in lucid-proposed. Should I be?

The package has not yet been accepted into lucid-proposed, sorry. It'll
have to wait for the next SRU team processing run.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Jeremy Yoder (jyoder) wrote :

Is it in a PPA somewhere I can try it? If getting into -proposed is hard, seems like it should be tested first :)

Steve Langasek (vorlon) wrote :

On Tue, Mar 20, 2012 at 04:12:24PM -0000, Jeremy Yoder wrote:
> Is it in a PPA somewhere I can try it? If getting into -proposed is
> hard, seems like it should be tested first :)

No, but you can grab it from the queue and build from source if you want to:

  https://launchpad.net/ubuntu/lucid/+queue?queue_state=1

Hello harald, or anyone else affected,

Accepted nis into lucid-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in nis (Ubuntu Lucid):
status: Triaged → Fix Committed
Steve Langasek (vorlon) wrote :

A user has contacted me privately to report a regression with the package in -proposed:

> I think I updated the nis package yesterday through the ubuntu update
> process.
> This morning nis did not work anymore. The solution was that
> /etc/init/ypbind.conf
> is waiting for a local server which is obviously not running when you
> use another server.

> I commented out the lines 43-45 and now it's working.

The issue here is a wrong check in the ypbind pre-start script. We're accidentally trying to start ypserv in all cases that we're running ypbind, when we should only be trying to start it if NISSERVER is set to a value other than false.

Marked verification-failed; I'll work on preparing a new package.

tags: added: verification-failed
removed: verification-needed
Steve Langasek (vorlon) on 2012-03-28
Changed in nis (Ubuntu Lucid):
status: Fix Committed → In Progress
Changed in nis (Ubuntu Oneiric):
status: Fix Committed → In Progress
Changed in nis (Ubuntu Natty):
status: Triaged → In Progress
Jeremy Yoder (jyoder) wrote :

Is that what broke? I tried it Monday and my NIS broke and reverting didn't fix it. I never checked the configs though. Thanks!

Chris Halse Rogers (raof) wrote :

Hello harald, or anyone else affected,

Accepted nis into oneiric-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in nis (Ubuntu Oneiric):
status: In Progress → Fix Committed
tags: removed: verification-failed
tags: added: verification-needed
Chris Halse Rogers (raof) wrote :

Hello harald, or anyone else affected,

Accepted nis into lucid-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in nis (Ubuntu Lucid):
status: In Progress → Fix Committed
Jeremy Yoder (jyoder) wrote :
Download full text (3.3 KiB)

I'm having numerous problems installing the -proposed package on Lucid.

Sometimes the upgrade succeeds, sometimes it fails. I haven't been able to figure out why yet (I think I'm starting from the same state each time, but maybe there's a file somewhere I'm not considering).

If the package upgrade WORKS:
1) I get the following output:
Preparing to replace nis 3.17-31 (using .../nis_3.17-31ubuntu0.10.04.3_i386.deb) ...
 * Stopping NIS services [ OK ]
 * Stopping NIS services [ OK ]
 Removing any system startup links for /etc/init.d/nis ...
   /etc/rc1.d/K18nis
   /etc/rc2.d/S18nis
   /etc/rc3.d/S18nis
   /etc/rc4.d/S18nis
   /etc/rc5.d/S18nis
Unpacking replacement nis ...
Processing triggers for ureadahead ...
Processing triggers for man-db ...
Setting up nis (3.17-31ubuntu0.10.04.3) ...
ypbind start/running, process 18583
ypserv stop/pre-start, process 18612

2) There are several upstart jobs installed in /etc/init: start-ypbind.conf, yppasswd.conf, ypserv.conf, ypxferd.conf
3) Reverting the package to the older version leaves behind the /etc/init/*yp*.conf scripts behind

If the package upgrade FAILS:
1) I get the following output:

Preparing to replace nis 3.17-31 (using .../nis_3.17-31ubuntu0.10.04.3_i386.deb) ...
 * Stopping NIS services [ OK ]
 * Stopping NIS services [ OK ]
 Removing any system startup links for /etc/init.d/nis ...
   /etc/rc1.d/K18nis
   /etc/rc2.d/S18nis
   /etc/rc3.d/S18nis
   /etc/rc4.d/S18nis
   /etc/rc5.d/S18nis
Unpacking replacement nis ...
Processing triggers for ureadahead ...
Processing triggers for man-db ...
Setting up nis (3.17-31ubuntu0.10.04.3) ...
ypbind start/running, process 16988
start: Unknown job: ypserv
invoke-rc.d: initscript ypserv, action "restart" failed.
dpkg: error processing nis (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 nis
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install. Trying to recover:
Setting up nis (3.17-31ubuntu0.10.04.3) ...
ypbind start/running, process 17062
start: Unknown job: ypserv
invoke-rc.d: initscript ypserv, action "restart" failed.
dpkg: error processing nis (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 nis

2) Only one upstart jobs is installed in /etc/init: ypbind.conf

3) When I tell aptitude to revert back to the older NIS package, it leaves /etc/init/ypbind.conf behind

In BOTH cases, after a server reboot, NIS doesn't come up correctly.

I was able ...

Read more...

tags: added: verification-failed
removed: verification-needed
Chris Halse Rogers (raof) wrote :

Hello harald, or anyone else affected,

Accepted nis into natty-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in nis (Ubuntu Natty):
status: In Progress → Fix Committed
tags: removed: verification-failed
tags: added: verification-needed

Jeremy,

On Fri, Mar 30, 2012 at 06:11:04PM -0000, Jeremy Yoder wrote:
> I'm having numerous problems installing the -proposed package on Lucid.

> Sometimes the upgrade succeeds, sometimes it fails. I haven't been able
> to figure out why yet (I think I'm starting from the same state each
> time, but maybe there's a file somewhere I'm not considering).

> If the package upgrade WORKS:

<snip>

This is all expected behavior.

> If the package upgrade FAILS:
> 1) I get the following output:

<snip>
> Setting up nis (3.17-31ubuntu0.10.04.3) ...
> ypbind start/running, process 16988
> start: Unknown job: ypserv
> invoke-rc.d: initscript ypserv, action "restart" failed.
<snip>

> 2) Only one upstart jobs is installed in /etc/init: ypbind.conf

This indicates the package is in an inconsistent state, probably because at
some point you removed the upstart jobs from the old SRU version of nis by
hand from the /etc/init directory.

Please check whether installing the package with dpkg -force-confmiss -i
/path/to/nis.deb fixes this problem for you.

> In BOTH cases, after a server reboot, NIS doesn't come up correctly.

Can you provide any more detail as to how it fails to come up correctly?

You might use 'exec > /var/log/nis-debug.log 2>&1' as the first line of the
pre-start script in /etc/init/ypbind.conf to capture any errors here. (And
if there are no errors in that log, do the same thing for 'script' and
'post-start script', noting of course that each exec will clobber the
previous ones.)

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

I have installed 3.17-31ubuntu0.10.04.3 on lucid after purging the previous version including our hand crafted upstart configuration.
- Installation went fine
- I have tested the function as a NIS client successfully
- starting after reboot works, it also survives a suspend/resume cycle

But I noticed that there isn't any log output, neither in the console messages at boot time nor in the syslog.

I injected an error by misspecifying the nis domain. This also did not produce any output anywhere that might help to debug.

I think (but I am no sure) that you would see more output with the current stock nis package.

Jeremy Yoder (jyoder) wrote :

The host I had been testing on has died a horrible death. I'm trying to find a new place to test this. On the bright side, the new host won't have ever had the old -proposed package to interfere with the upgrade, so if that was my problem, it should just work.

Fingers crossed.

Steve Langasek (vorlon) wrote :

Thanks for the testing, Ernst.

> I think (but I am no sure) that you would see more output with the current stock nis package.

Yes, that's true, because the output from init scripts is sent to the console at boot time. But I don't think that's something that should be a blocker for this SRU, since that output is only relevant for debugging, not for normal operation.

Jeremy, I'll wait for your test results before considering this verified.

Steve Langasek (vorlon) wrote :

Jeremy, any word on testing this nis SRU?

Jeremy Yoder (jyoder) wrote :

Unfortunately I lost access to the box I had been using for testing and I haven't been able to bring up a similar box to run the test on. To make matters worse, I've now left the job that this was all for :(

I had really hoped to test this before my last day but the stars never quite aligned. I tried creating a VM for testing but it couldn't talk to our NIS domain, so that didn't pan out. I requested a new machine to replace the one that died but it didn't show up before I left.

Not sure how to proceed on this. I can see if someone there could test it for me but I don't have high hopes.

If anyone else can verify the fix, that would be great!

just to add a data point: starting 2012-04-19 my lucid machine is working with 3.17-31ubuntu0.10.04.3 from proposed with. A few nis accounts are being used regularly. There have been a large number of suspend resume cycles and various reboots without any nis related problems.

Clint Byrum (clint-fewbar) wrote :

Thanks Ernst. I'll take that as a verification for lucid. This should progress to lucid-updates soon.

tags: added: verification-done verification-done-lucid
Steve Langasek (vorlon) wrote :

I'm marking this verification-failed on account of bug #993291, which is fixed in precise and quantal but which is still present in the version of the nis package in the -proposed queue.

tags: added: verification-failed
removed: verification-done verification-needed
Steve Langasek (vorlon) wrote :

Since bug #993291 only affects the upgrade path from a previous SRUed version to a later version that includes this bug fix, it should only impact the following upgrades:

 lucid->precise
 natty->oneiric
 oneiric->precise

So the only supported upgrade path from lucid is the one to precise, and precise's preinst has the fix, so it should be safe to publish the lucid SRU, which requires no further changes.

The oneiric SRU should be updated, so that when the *natty* SRU is published, it doesn't result in failures on natty->oneiric upgrade.

And we can apply the same fix to natty as well, but there's no supported upgrade path from lucid to natty so I'm not sure it makes a difference really. I'm happy to update the natty SRU if that's the consensus.

Steve Langasek (vorlon) on 2012-08-01
tags: added: verification-needed
removed: verification-failed

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

Scott Kitterman (kitterman) wrote :

Seems like it's without controversy to release the lucid SRU, so I've done that.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nis - 3.17-31ubuntu0.10.04.3

---------------
nis (3.17-31ubuntu0.10.04.3) lucid-proposed; urgency=low

  * debian/nis.ypbind.upstart: don't try to start ypserv if NISSERVER=false.

nis (3.17-31ubuntu0.10.04.2) lucid-proposed; urgency=low

  * Drop the upstart versioned dependency, so that we aren't depending on a
    version of upstart only available in oneiric and later.

nis (3.17-31ubuntu0.10.04.1) lucid-proposed; urgency=low

  * Backport from precise:
    - Convert to native upstart jobs, with a versioned dependency on
      upstart (>= 0.9.7-2) because we use the wait-for-state job.
      LP: #569757.
    - Depend on portmap (>= 6.0.0-1ubuntu2.1) to ensure our upstart job
      dependencies are satisfied.
  * Don't block gdm, lightdm, or atd on ypbind, since these services never
    declared that they want it, so we shouldn't change this in an SRU. It
    is at least much easier for an admin to make this change locally now if
    they want the DM to block on ypbind.
  * Use 'net-device-up IFACE!=lo' as a start condition, as supported in
    lucid, instead of 'static-network-up' and 'failsafe-boot' which were
    introduced in oneiric.
  * We also don't have the wait-for-state job in upstart prior to oneiric,
    so implement our wait handling by hand in the relevant jobs.
 -- Steve Langasek <email address hidden> Wed, 28 Mar 2012 16:36:23 -0700

Changed in nis (Ubuntu Lucid):
status: Fix Committed → Fix Released

Hello harald, or anyone else affected,

Accepted nis into oneiric-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/nis/3.17-32ubuntu1.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in nis (Ubuntu Natty):
status: Fix Committed → Won't Fix

The fix for the this bug has been awaiting testing feedback in the -proposed repository for oneiric for more than 90 days. Please test this fix and update the bug appropriately with the results. In the event that the fix for this bug is still not verified 15 days from now the package will be removed from the -proposed repository.

tags: added: removal-candidate
Brian Murray (brian-murray) wrote :

The version of nis in oneiric-proposed has been removed as the bugs it was fixing (including this one) were not verified in a timely fashion.

Changed in nis (Ubuntu Oneiric):
status: Fix Committed → Triaged
tags: removed: verification-needed
tags: removed: removal-candidate
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers