The Precise Pangolin has reached end of life, so this bug will not be
fixed for that release
** Changed in: nss-pam-ldapd (Ubuntu Precise)
Status: Confirmed => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://b
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: nss-pam-ldapd (Ubuntu Precise)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/806761
lucid has seen the end of its life and is no longer receiving any
updates. Marking the lucid task for this ticket as "Won't Fix".
** Changed in: nss-pam-ldapd (Ubuntu Lucid)
Status: New => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is su
Given the amount of work that went into this ticket it is indeed sad to
see that upstart is now no longer the init system of Ubuntu. I guess it
would be nice to fix Precise and Trusty via an SRU.
Should the main task be set to wontfix? Is upstart still developed at
all?
--
You received this bu
Ah... I had failed to notice the component from was universe. I believed,
incorrectly, that it was a Canonical-supported component.
I'll switch to SSSD.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/
Adam Thompson: That attitude really isn't productive, nor is calling out
Canonical even correct. This package isn't in "main", which means it is
supported by the community, not Canonical.
The bug expired because it stayed in an "incomplete" state for 60 days,
after feedback was given to the submit
Per #54... yes, but for one thing: 14.04 LTS is still in the support
cycle for several more years, and we're just now starting to deploy
14.04 across the board for developer desktops at work.
Because I have more than one AD server, I'm using "uri DNS" (see
https://bugs.launchpad.net/ubuntu/+source
CADT, anyone? As we're waiting for a fix to come out, the bug expires
because we're all waiting. I guess that's one way to "solve" the
problem...
** Changed in: nss-pam-ldapd (Ubuntu)
Status: Expired => Incomplete
--
You received this bug notification because you are a member of Ubuntu
@GB you might be able to work around the problem with an Upstart script,
but you're probably better off getting the latest version of nslcd
installed. 0.8.4 is fairly out-of-date, so it's likely the issue has
been resolved in a newer release.
--
You received this bug notification because you are
Our nslcd (0.8.4) keeps crashing on Ubuntu 12.04, like so:
[2221821.130260] nslcd[17641]: segfault at 0 ip 004159c8 sp
7f11fd78b6a0 error 4 in nslcd[40+21000]
[4448958.894131] nslcd[31759]: segfault at 0 ip 004159c8 sp
7fa87d3826a0 error 4 in nslcd[40+21000]
and
That I did - though I forgot to set the if-up.d script executable. :P That
caused a pile of headaches until I checked my assumptions!
Interesting. Despite my longtime use of Ubuntu flavors, I'd barely gotten
used to the switch to Upstart! Ah, well. :)
Thanks,
Ricky
On Tue, May 6, 2014 at 6:06
Hi Ricky, thanks for taking a look at this! Sorry I didn't get a chance
to follow up sooner.
Unfortunately it looks like futher efforts on this patch aren't
worthwhile: Ubuntu will soon be moving to the systemd init system. See
http://www.markshuttleworth.com/archives/1316. In the meantime, it
sho
Ok, so I took it upon myself to make some of the requested changes, as far as
my current ability and worktime allows:
* Cleared the trailing whitespace.
* Updated the nslcd.init patch to use init_is_upstart
However, while I can update a patch, I have no knowledge as yet on
how/where to specify th
[Expired for nss-pam-ldapd (Ubuntu) because there has been no activity
for 60 days.]
** Changed in: nss-pam-ldapd (Ubuntu)
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net
You have trailing whitespace in debian/nslcd.nslcd-k5start.upstart on
line 4 and 43
In debian/nslcd.init , please use the mechanism described in
https://wiki.ubuntu.com/UpstartCompatibleInitScripts to check if upstart
is the init system, and check in targets besides the "start" target.
Please run
Ah, I misunderstood the current state of the package. Sure, I'll take a
look at the init script and see whether we can't get it included in an
Ubuntu revision, as I see upstream would prefer to have it validated
downstream first.
** Changed in: nss-pam-ldapd (Ubuntu)
Status: Fix Released =>
Hi Luke, thanks for the good news!
Please note that rev 10 of the patch uses debug mode ("-d"), which
Arthur (the upstream maintainer) does not recommend. I've attached
another patch rev that follows the upstream recommendation by using the
foreground ("-n") commandline switch. It is otherwise ide
0.8.13-3 is in trusty, so the patch contributed here has been included
in Ubuntu. As such, I'm marking the bug "fix released" and unsubscribing
~ubuntu-sponsors.
Thank you for working through this process to get your contribution
merged!
** Changed in: nss-pam-ldapd (Ubuntu)
Status: In Pro
Errata: my problem seems to be unrelated to this bug. It was caused
because of a huge growth in our LDAP directory over the lasts weeks. The
new data is generated from an application that has nothing to do with OS
users and groups, so I could solve it writting some LDAP filters in
nslcd.conf.
My a
Arthur,
My problem seems to be a race condition between nslcd and nslcd-k5start,
as Calleb pointed it out in an old post. I put a sleep nearly the end of
k5start_start function in my Ubuntu 12.04 /etc/init.d/nslcd script, and
it works much better. I don't see more "ldap_result() timed out" at boot
Excellent, many thanks!
On Sun, Aug 18, 2013 at 6:25 AM, Arthur de Jong wrote:
> I've merged your change upstream in both the 0.8 and 0.9 branches.
> Attached is a patch that should be suitable for dropping in
> debian/patches for version 0.8.13-2.
>
> ** Patch added: "implement-nofork.patch"
>
I've merged your change upstream in both the 0.8 and 0.9 branches.
Attached is a patch that should be suitable for dropping in
debian/patches for version 0.8.13-2.
** Patch added: "implement-nofork.patch"
https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+attachment/3776774/+
I'd agree that "expect fork" looks like the correct approach, and until the
latest release, using that stanza seemed to work without issue.
It's true that adding functionality to accommodate a service management
system is a poor separation of concerns, but nslcd's generation of a PID
file does est
According to the mailing list post you would expect that "expect fork"
should be the right thing to do.
If you really want to implement a command-line switch for this (I think
it is a bit silly to have to do this for upstart), please name it -n
(this seems to be used by a few daemons that provide
Good to know about the PID file, but as far as I know, there is no
mechanism in Upstart for utilizing PID files. This is an intentional design
decision, see
https://lists.ubuntu.com/archives/upstart-devel/2008-August/000735.html(the
section on the "pid file" stanza being removed)
Is there any tech
Currently nslcd does not support not forking into the background outside
of debug mode.
The pid of nslcd can be reliably determined by looking at
/var/run/nslcd/nslcd.pid.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.l
Hi Arther,
Good to know. I think the behavior I'm seeing is most likely a result of
some change to Upstart, because I'm using the same modified 0.8.10-1
package that I've used in the past. Even so, the process ID that Upstart
decides to track is very definitely incorrect whether I track the first
It is not recommended to run nslcd in debug mode in production.
Anyway, on start-up nslcd will call daemon() to daemonise. I thought
that daemon() called fork() twice but according to the manual page it
only forks once. After that, it starts a number of threads (configured
by the threads option in
Another patch rev: after upgrading to Raring (nss-pam-ldapd 0.8.10), the
expect fork stanza no longer behaves correctly. Running script to
determine fork count (http://upstart.ubuntu.com/cookbook/#how-to-
establish-fork-count) indicated 6 calls to fork or clone when nslcd
starts.
To address this i
Juan,
Can you provide some more information on your boot sequence? nslcd
should only hang if it has been started before networking is available
(which shouldn't happen because of the init scripts dependencies).
If your connection to the LDAP server is otherwise reliable you could
also reduce the
Thanks Caleb. I have not tested your upstart script yet, but I could
speed up the boot by calling sleep for 10 seconds in nslcd init script
when starting, before doing anything else.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
http
Juan,
If nscld timeouts are causing slow boot times (which may or may not be the
case in the situation you describe--I'd recommend disabling nslcd to see if
the boot time improves), I don't know of clean solution except the init
scripts that I've written and attached to this bug report.
HTH
On
I think that this bug is affecting me at boot. I am having a very slow
boot (2 minutes approximately), with some nslcd timeouts. After that,
the computer works ok. My distribution is Ubuntu 12.04. Can you suggest
me how to workaround it?. Thanks.
--
You received this bug notification because you
I recommend giving in to this temptation. ;) I'm happy to help with
testing in any way I can.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/806761
Title:
Feature Request: Upstart scripts for nslcd
* Most mail-servers start on event runlevel 2-5 or started via init
scripts. Runlevel event is not emitted, until static-network-up event
(network configured) and since nslcd is kicked-off from network
configuration, nslcd will come up before staic-network-up/runlevel
events. Thus there are suffici
Okay, another patch rev and a big-huge post addressing Arthur's last
concerns (thanks again to him for taking the time to review the patch).
-Regarding serialization of network interface bring-ups, I've addressed
this by running the flock command asynchronously. As far as I can tell,
this doesn't
Another revision, this time using the correct target state when calling
the wait-for-start script, per http://upstart.ubuntu.com/cookbook/#job-
states
** Patch added: "Path Rev 8"
https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+attachment/3639332/+files/nslcd-upstart-8.deb
I noticed an error in the k5start Upstart script: the settings in the
/etc/defaults/nslcd file were being overridden. I've attached a revised
patch.
Still working on my reply to Arthur's latest.
** Patch added: "Patch Rev 7"
https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/
I have been looking at trying to integrate the patch but I still don't
have a really good feeling about this whole upstart thing and I don't
really have a proper way to test this.
For example I still don't really understand why the whole thing with the
if-up file is required. It seems like a very
Okay, I've attached revised scripts that should be compatible with
Debian Wheezy (to the extent that I can readily test, which is a Wheezy
build using pbuilder). The lack of a separate System V init script for
nslcd-k5start does not seem to cause any issues.
All the technical issues Arthur raised
Ah, good to know. Thanks for the link.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/806761
Title:
Feature Request: Upstart scripts for nslcd
To manage notifications about this bug go to:
https://b
It may be useful to know that Debian just added some information to policy
regarding init systems other than SysV init and even some notes specific to
upstart:
http://www.debian.org/doc/debian-policy/ch-opersys.html#s-alternateinit
--
You received this bug notification because you are a member
Hi Arthur,
Thanks for looking at this, and taking the time to give your feedback.
- If Upstart isn't part of the base Debian install, I'd agree that
dropping the init script doesn't make sense, although the race
conditions that the Upstart scripts aim to address wouldn't be
addressed. Do you know
Hi, I've had a quick look at the patch (Patch rev5) but there are a few
problems/questions for inclusion into Debian:
- Debian is currently preparing for the next stable release and as such I don't
think I will upload this change to Debian unstable any time soon as it could
interfere with gettin
s/merge/sync/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/806761
Title:
Feature Request: Upstart scripts for nslcd
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/
Hi,
As the Debian Maintainer seems to be interested to include this fix in
Debian, and there isn't currently a delta between Debian and Ubuntu in
Quantal, it would be really good to get this support into Debian first,
and merge the package once this has happened.
Therefore, I'd like to request th
So, any further recommendations or fixes? If not, what's the next step?
Should I be coordinating with Arthur to get this merged upstream?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/806761
Title:
New revision. Changes:
-much cleaner mechanism for avoiding races in if-up.d script (thanks Clint!)
-Longer timeout waiting for credentials cache from k5start, to make sure
timeout errors from k5start get logged.
** Patch added: "Patch rev 5"
https://bugs.launchpad.net/ubuntu/+source/nss-pam
Hi Client,
No worries about the response time. I really appreciate your help in
making these scripts as excellent as possible.
The recommended method for serializing start attempts is working well.
I'll dogfood the change for a day or so, then post a revised patch.
--
You received this bug noti
Hi Caleb, sorry for not responding sooner I've been quite busy.
You really just need to serialize your attempts to start nslcd. This is
actually doable pretty easily. Do this in your if-up.d script:
flock /etc/init/nslcd.conf start wait-for-state WAIT_FOR=nslcd
WAITER=$INTERFACE WAIT_STATE=starte
Hi James,
Well, that's embarrassing--I did upload the wrong file. Thanks for
pointing that out. The correct patch file is attached.
I'll take a look at the instance stanza as well--it'd be be nice to have
a more elegant solution to that interface issue.
** Patch added: "Upstart script patch, cor
Hi Caleb,
Thanks for keeping the momentum going on this. I notice though that you are
still using $K5START_LOGFILE which really
isn't required now. Have you maybe attached an older version of the patch in
#13 by mistake?
Regarding your comment about good and bad interfaces, the Upstart
'instanc
I'm assuming the lack of comments indicates that there are no violent
objections to the path I'm taking. The current revision has been working
quite well on my system, as well as a testbed VM. So, I'm re-subscribing
ubuntu-sponsors and attaching the revised patch.
Overview of changes:
-changed "s
One further point: I don't think we can replace the defaults file with
env stanzas, because some of the variables that can be overridden in the
defaults file require expansion, which the env stanza doesn't support.
--
You received this bug notification because you are a member of Ubuntu
Bugs, whi
Hi Clint,
I can see how first recommended change ("start on runlevel [2345]" and
an if-up.d script) is an improvement: the if-up.d script makes sure we
try to start nslcd *every* time an interface comes up, not just the
*first* one.
However, I'm encountering another race condition with the if-up.
Hi Clint! Many thanks for taking the time to review the patch! I'm
revising the scripts based on your feedback and should have a new
debdiff soon.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/806761
Hi Caleb! Thanks for taking a crack at integrating these into Ubuntu.
This is really great and even though my review below is long, I have to
say that this is a great first attempt at a really difficult problem
space. :) I'm going to unsubscribe ubuntu-sponsors for now, but please
do re-subscribe s
** Changed in: nss-pam-ldapd (Ubuntu)
Importance: Undecided => Wishlist
** Changed in: nss-pam-ldapd (Ubuntu)
Status: Confirmed => Triaged
** Changed in: nss-pam-ldapd (Ubuntu)
Status: Triaged => In Progress
** Changed in: nss-pam-ldapd (Ubuntu)
Assignee: (unassigned) => Ca
Okay, after reading the Daemon Behavior section of the Upstart cookbook
(http://upstart.ubuntu.com/cookbook/#daemon-behaviour), I've settled on
a solution that I'm reasonably happy with: looping in a post-start
script until the ticket cache is detected on the file system _or_ a
timeout occurs (so w
The odd behavior turned out to be a race condition between the nslcd and
nslcd-k5start scripts: per the Upstart docs
(http://upstart.ubuntu.com/cookbook/#expect), Upstart assumes the job
has started after the first PID that is generated in the script, unless
an expect stanza is present. So, Upstart
Thinking more about the way the sasl_mech and krb5_ccname options were
handled, I saw that the logic in the nslcd-k5start file wasn't very good
--we should only be looking for the kinit and k5start binaries if the
user enabled Kerberos, either through the defaults file override, or
with the nslcd.c
Hi Arther,
Thanks for taking the time to review the patch. :)
The motive for Upstart scripts instead of a init.d script is simple:
with the init.d script, I couldn't find a simple way to guarantee nslcd
started _after_ a network connection was available. At the time I logged
the feature request (
I've been looking into integrating the patch into Debian. The spelling
fix was easy so that will be done with the next upload ;)
However, I have a few questions about the upstart scripts:
- Why was the init script dropped? Isn't it better to keep both so that systems
without upstart can still sta
The attachment "upstart scripts for nslcd" of this bug report has been
identified as being a patch in the form of a debdiff. The ubuntu-
sponsors team has been subscribed to the bug report so that they can
review and hopefully sponsor the debdiff. In the event that this is in
fact not a patch you
Here's a debdiff against nss-pam-ldap 0.8.10 with the required changes.
** Patch added: "upstart scripts for nslcd"
https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+attachment/3213474/+files/nslcd-upstart.debdiff
--
You received this bug notification because you are a mem
** Changed in: nss-pam-ldapd (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/806761
Title:
Feature Request: Upstart scripts for nslcd
To manage notifications
Please incorporate these into 12.04!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/806761
Title:
Feature Request: Upstart scripts for nslcd
To manage notifications about this bug go to:
https://bug
67 matches
Mail list logo
