Bug#1022311: python-stdnum: FTBFS: AssertionError: Failed doctest test for test_no_fodselsnummer.doctest

[Arthur de Jong]

On Thu, 2024-05-23 at 13:36 +0200, Santiago Vila wrote:
> Arthur: Would be ok for you if I fix this in bullseye via team
> upload?

Please do, thanks.

I only have limited time available at the moment and have quite a big
backlog of issues to pick up so any help is really welcome.

Thanks,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#1072355: nss-pam-ldapd: upload with maintainer-built binaries cannot migrate

[Arthur de Jong]

On Sat, 2024-06-01 at 14:59 +0200, Chris Hofstaedtler wrote:
> thanks for uploading to unstable. However the upload included
> maintainer-built binaries (for Arch: all and amd64). Migration to
> testing of these is forbidden by release team policy.
> Please upload a new version (no further changes needed) without any
> binaries to let the package migrate.

Thanks. I always seem to be confused about which changes file to upload
:/

Anyway, I've just uploaded 0.9.12-7 which should be source-only again.

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#1061701: nss-pam-ldapd: install PAM and NSS modules into /usr

[Arthur de Jong]

On Wed, 2024-05-29 at 00:59 +0200, Chris Hofstaedtler wrote:
> Please make sure this patch reaches unstable well before the trixie
> transition freeze. Now would be a good time.

Thanks for the reminder. I've uploaded 0.9.12-6 which includes this
change.

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#1070907: python-stdnum: please drop the suggests on SimpleSoap

[Arthur de Jong]

On Sat, 2024-05-11 at 14:26 +0200, Alexandre Detiste wrote:
> Please drop the suggests on python3-pysimplesoap;
> this package would soon be dropped from Debian
> altogheter.

The next upload will drop the suggest (which already was a fallback for
zeep).

Thanks,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#1061701: nss-pam-ldapd: install PAM and NSS modules into /usr

[Arthur de Jong]

On Sun, 2024-01-28 at 20:44 +0100, Michael Biebl wrote:
> We want to finalize the /usr-merge via DEP17 by moving all files to
> /usr. nss-pam-ldapd installs files into /lib; these should be moved
> into the respective canonical locations in /usr/.
> 
> Please find a patch attached. It has been build-tested.

Thanks for your patch. I've uploaded version 0.9.12-5 to experimental
which includes this change.

Kind regards,


-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#1035572: geany crashes often when clicking to switch focus

[Arthur de Jong]

Package: geany
Followup-For: Bug #1035572

On Fri, 2023-05-05 at 18:27 +0200, Arthur de Jong wrote:
> Geany crashes for me on a regular basis. After some experimenting
> I've found a way to reproduce this:
> 
> - start geany
> - from a new terminal open a not-yet-existing file:
>     geany /tmp/some-file.txt
> - click a bit between geany and the terminal window

Today, I can no longer reproduce this even though the version of geany
hasn't changed. The problem might have been in one of the dependencies.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.4.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages geany depends on:
ii  geany-common 1.38-1
ii  libatk1.0-0  2.48.3-1
ii  libc62.37-7
ii  libcairo21.16.0-7
ii  libgcc-s113.2.0-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.76.4-4
ii  libgtk-3-0   3.24.38-2
ii  libpango-1.0-0   1.50.14+ds-1
ii  libpangocairo-1.0-0  1.50.14+ds-1
ii  libstdc++6   13.2.0-1

Versions of packages geany recommends:
ii  sensible-utils  0.0.20

Versions of packages geany suggests:
pn  doc-base  
pn  libvte9   

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#1035572: geany crashes often when clicking to switch focus

[Arthur de Jong]

Package: geany
Version: 1.38-1+b1
Severity: important

Geany crashes for me on a regular basis. After some experimenting I've
found a way to reproduce this:

- start geany
- from a new terminal open a not-yet-existing file:
geany /tmp/some-file.txt
- click a bit between geany and the terminal window

I think I've seen this also with files that do exist but the above
triggers the crash for me after a couple of clicks.

This is running under Gnome desktop with reasonably default settings.

Attached is a gdb backtrace.

Thanks

-- System Information:
Debian Release: 12.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-8-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages geany depends on:
ii  geany-common 1.38-1
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-9
ii  libcairo21.16.0-7
ii  libgcc-s112.2.0-14
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.37-2
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libstdc++6   12.2.0-14

Versions of packages geany recommends:
ii  sensible-utils  0.0.17+nmu1

Versions of packages geany suggests:
pn  doc-base  
pn  libvte9   

-- no debconf information

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --

$ gdb geany
GNU gdb (Debian 13.1-2) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from geany...

This GDB supports auto-downloading debuginfo from the following URLs:
  
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
Reading symbols from 
/local/arthur/.cache/debuginfod_client/30eed5a4b099db1e2e8e0382edabca21dc748da0/debuginfo...
  
(gdb) r
Starting program: /usr/bin/geany 
Downloading separate debug info for system-supplied DSO at 0x77fc9000
[Thread debugging using libthread_db enabled]   
   
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x72fbe6c0 (LWP 15639)] 
   
[New Thread 0x727bd6c0 (LWP 15640)]
[New Thread 0x71e516c0 (LWP 15641)] 
   
[Thread 0x71e516c0 (LWP 15641) exited]
[New Thread 0x71e516c0 (LWP 15642)]
[New Thread 0x70fba6c0 (LWP 15643)]
[Thread 0x71e516c0 (LWP 15642) exited]
[Thread 0x70fba6c0 (LWP 15643) exited]  
   
[New Thread 0x70fba6c0 (LWP 15644)] 
   
[New Thread 0x71e516c0 (LWP 15645)]
[New Thread 0x7fffe3fff6c0 (LWP 15647)]
[Thread 0x71e516c0 (LWP 15645) exited]  
   
[Thread 0x70fba6c0 (LWP 15644) exited]
[New Thread 0x71e516c0 (LWP 15661)] 
   
[New Thread 0x70fba6c0 (LWP 15662)]
[New Thread 0x7fff86ff16c0 (LWP 15663)]
[New Thread 0x7fff867f06c0 (LWP 15664)]
[Detaching after vfork from child process 15665]
[New Thread 0x7fff85bff6c0 (LWP 15670)] 
   
[New Thread 0x7fff853fe6c0 (LWP 15671)]
[Thread 0x7fff85bff6c0 (LWP 15670) exited]
[New Thread 0x7fff85bff6c0 (LWP 15672)]
[New Thread 0x7fff84b036c0 (LWP 15673)]
[Thread 0x7fff85bff6c0 (LWP 15672) exited]
[Thread 0x7fff84b036c0 (LWP 15673) exited]
[Thread 0x7fff853fe6c0 (LWP 15671) exited]
[New Thread 0x7fff853fe6c0 (LWP 15674)]
[New Thread 0x7fff84b036c0 (LWP 15675)]
[Thread 0x7fff853fe6c0 (

Bug#1033919: svn2cl: svn2cl --html fails due to usrmerge

[Arthur de Jong]

On Mon, 2023-04-03 at 23:39 +0200, H.-Dirk Schmitt wrote:
> The `--html` option fails on bookworm,
> 
> Due to the usrmerge the script is now invoked as `/bin/svn2cl`.
> This leads to an error in the determination of the  snv2cl.xss file.

Thanks for pointing this out (on my system I still had /usr/bin in my
PATH before /bin). I've applied another fix than the one you provided
(one that is also included "upstream").

I've uploaded a version 0.14-3 with a fix to unstable.

Thanks!

-- 
-- arthur - art...@arthurdejong.org - https://arthurdejong.org/ --



signature.asc
Description: This is a digitally signed message part

Bug#1033919: svn2cl: svn2cl --html fails due to usrmerge

[Arthur de Jong]

On Mon, 2023-04-03 at 23:39 +0200, H.-Dirk Schmitt wrote:
> The `--html` option fails on bookworm,
> 
> Due to the usrmerge the script is now invoked as `/bin/svn2cl`.
> This leads to an error in the determination of the  snv2cl.xss file.

Thanks for pointing this out (on my system I still had /usr/bin in my
PATH before /bin). I've applied another fix than the one you provided
(one that is also included "upstream").

I've uploaded a version 0.14-3 with a fix to unstable.

Thanks!

-- 
-- arthur - art...@arthurdejong.org - https://arthurdejong.org/ --



signature.asc
Description: This is a digitally signed message part

Bug#1031979: libnss-ldapd: Entries for passwd and shadow are cleared on upgrade when system locale is sv_SE.UTF-8

[Arthur de Jong]

On Sun, 2023-02-26 at 10:50 +0100, Arne Nordmark wrote:
> The search for enabled services in /etc/nsswitch.conf breaks when
> using the Swedish locale.
> 
> LANG=C sed -n 
> 's/^[[:space:]]*\([a-z]*\)[[:space:]]*:.*[[:space:]]ldap\([[:space:]].*\)\?/\1/p'
>  /etc/nsswitch.conf | xargs
> 
> gives "passwd group shadow" which is correct, whereas
> 
> LANG=sv_SE.UTF-8 sed -n 
> 's/^[[:space:]]*\([a-z]*\)[[:space:]]*:.*[[:space:]]ldap\([[:space:]].*\)\?/\1/p'
>  /etc/nsswitch.conf | xargs
>
> gives "group".

Interestingly, I cannot reproduce this on unstable (I generated the
proper locale and use LC_ALL instead of LANG to override all LC_*
variables I had set), also minimising the problem doesn't show this
issue:

echo "shadow: " | LC_ALL=C sed -n 
's/^[[:space:]]*\([a-z]*\)[[:space:]]*:.*/\1/p'
echo "shadow: " | LC_ALL=sv_SE.UTF-8 sed -n 
's/^[[:space:]]*\([a-z]*\)[[:space:]]*:.*/\1/p'

(both return the same output for me)

Anyway, I'll change the maintainer scripts to force the C locale so we
have consistent rexex processing by sed, grep and other tools.

Thanks for reporting the issue!

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#1030597: /usr/share/doc/lsb-base/README.Debian: file points to itself for more information

[Arthur de Jong]

Package: lsb-base
Version: 11.5
Severity: minor
File: /usr/share/doc/lsb-base/README.Debian

Ony my system /usr/share/doc/lsb-base/README.Debian contains:

  ...
  * The "lsb-base" package includes a number of functions used by init.d
scripts in some LSB packages.

For documentation of those functions (and those added for Debian's use),
please see the README.Debian file in that package.
  ...

Please update the README.Debian in lsb-base with a reference to where
to find the documentation for the functions that can be used in init.d
scripts.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lsb-base depends on:
ii  sysvinit-utils  3.06-2

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#1023460: in debian/nslcd.config, guess_ldap_uri returns the IP address instead of the name of the server

[Arthur de Jong]

On Fri, 2022-11-04 at 11:00 -0400, Marvin Renich wrote:
> When nslcd is installed [...] guess_ldap_uri tries to find an
> appropriate ldap server using some heuristics.  If it finds a host
> [...] it returns the IP address of the host rather than the name.

The original reason for this was that if you use LDAP for host name
lookups having a host name in nslcd.conf causes problems.

I think that is reasonably uncommon and agree that the host name would
make more sense to provide as a suggestion. This behaviour will be
changed in the next upload (uploads are not very frequent).

Thanks,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#1022311: python-stdnum: FTBFS: AssertionError: Failed doctest test for test_no_fodselsnummer.doctest

[Arthur de Jong]

On Sun, 2022-10-23 at 14:50 +0200, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

A fix has just been uploaded and is part of version 1.18-1.

If this ever needs to be backported for some reason the fix is trivial:
https://arthurdejong.org/git/python-stdnum/commit/?id=1003033fa0e97726d92f47231f96cf02fb35869a

-- 
-- arthur - art...@arthurdejong.org - https://arthurdejong.org/ --



signature.asc
Description: This is a digitally signed message part

Bug#1018584: python-stdnum: build-depends on python3-nose or uses it for autopkgtest

[Arthur de Jong]

Control: tags -1 + upstream pending

On Sun, 2022-08-28 at 21:51 +0300, Dmitry Shachn
> Your package still uses nose [1], which is an obsolete testing
> framework for Python, dead and unmaintained since 2015 [2][3].

The upstream repo switched from nose to pytest:
https://arthurdejong.org/git/python-stdnum/commit/?id=8a28e388890f0bcd0ada9df846562080bda96bf3

This will be included in the next upload.

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#989409: nss-pam-ldapd's autopkgtest fails with OpenLDAP 2.5

[Arthur de Jong]

On Fri, 2022-02-18 at 19:11 -0800, Ryan Tandy wrote:
> I removed "pwdMustChange: TRUE" from the policy and then the tests 
> passed. Not sure if this is the correct fix, but at least I don't 
> currently see anything in test_pamcmds.expect that would be expecting
> a forced reset?

Applying this change makes the autopkgtest pass again (this change has
just been merged in Git). That means that the expected functionality of
nss-pam-ldapd is tested properly.

The tests currently don't test the forced password reset by the user
functionality (presence of pwdReset on a user account) and it seems
that exact behaviour differs between LDAP server implementations (the
password policy controls differ and the return code of the BIND
operation may also differ).

It seems that currently nslcd (default configuration) rejects the login
if a password change is needed on OpenLDAP 2.5. This can be worked
around by setting "pam_authc_search NONE" in nslcd.conf which should
not cause issues with most OpenLDAP LDAP servers.

I plan to upload a new version of the package soon. If anyone has any
concerns regarding e.g. insufficient testing of the above use case,
please let me know.

Kind regards,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#900253: nslcd: disabling ppolicy breaks authentication

[Arthur de Jong]

On Sat, 2022-01-08 at 20:19 +0100, Nicolas Peugnet wrote:
> I just ran into this bug. If I understand correctly it should have
> been fixed by this commit:
> 
> which is in Debian since version 0.9.12-1.
> 
> Just to be sure Arthur, would setting this option to "no" indeed make
> the OpenLDAP server stop logging entries like the following?
> 
> slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1

Yes, the pam_authc_ppolicy option is used to disable requesting that
control, see
https://arthurdejong.org/nss-pam-ldapd/nslcd.conf.5#pam_authc_ppolicy

While the option was added in 0.9.7 it was non-functional until it was
fixed in 0.9.12.

> And would it be a good idea to back-port this patch to stable ?

The missing control logged by the LDAP server should not be harmful in
any way because it is marked as not critical which means it is just a
warning that can be ignored.

I doubt this would be severe enough an issue to warrant an update for
bullseye.

-- 
-- arthur - art...@arthurdejong.org - https://arthurdejong.org/ --



signature.asc
Description: This is a digitally signed message part

Bug#1002047: reportbug: nslcd silently modifies /etc/nslcd.conf on upgrade, breaking authentication

[Arthur de Jong]

Control: tags -1 + pending

On Mon, 2021-12-20 at 22:03 +0100, Thomas Fargeix wrote:
> The postinst script of nslcd silently modifies the configuration file
> /etc/nslcd.conf on package upgrades. It rewrites or adds settings
> without notification to the administrator.

Thanks for this report.

> In my case, the script appended "base dc=olddomain,dc=example,dc=org"
> during the dist-upgrade from Buster to Bullseye. After reboot, remote
> and local login to the server was broken except for root due to this
> change.

The base option is used by nslcd for both the post-login check
(pam_authc_search) as well as the authorisation check
(pam_authz_check). If you don't specify one on start-up nslcd will
contact the LDAP server and try to get one from the server.

It turns out that the debconf scripts were not expecting the base
option to be absent from nslcd.conf causing an old cached version of
the value to be used.

> It also failed to consider the more precise "bases" that were already
> configured.

The debconf configuration does not support changing these options but
they should be retained on any changes that happen through debconf.

> I would have expected the script to not modify the existing
> configuration or at least to warn me it had been modified.

I've had a quick look into adding logging (which would be nice) but
that would require some restructuring in the postinst script because we
now use sed to change nslcd.conf unconditionally. The postinst is
already overly complex and I would like to avoid making it even longer.

Kind regards,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#819961: nslcd: package upgrade fails in postinst due to uncommon characters in bindpw config parameter

[Arthur de Jong]

Control: tags -1 + pending

On Mon, 2021-12-20 at 21:07 +0100, Thomas Fargeix wrote:
> /var/lib/dpkg/info/nslcd.postinst chocked on a randomly generated 
> password during my dist-upgrade from Buster to Bullseye, interrupting
> and blocking the dist-upgrade and leaving the system in an unstable 
> state (for that reason, I propose to raise the severity to a 
> release-critical one).

Thanks for pointing this out, the detailed report and the testing you
did.

> I don't understand why the postinst script needs to rewrite the
> existing  configuration file with sed, so I let you decide what can
> be the best fix, however I would suggest avoiding to try to escape a
> random password string and put it in a regex.

The reason nslcd.conf is modified during postinst is because most of
the options are managed through debconf. The nslcd.conf is parsed and
fed into the debconf database and the postinst loads the new values
into the config.

There was also an additional bug in that single-character passwords
were accidentally removed. That shouldn't be that big of an issue but a
fix for unstable is incoming anyway.

Kind regards,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#989409: nss-pam-ldapd's autopkgtest fails with OpenLDAP 2.5

[Arthur de Jong]

Control: tags -1 + patch

Hi Ryan,

On Fri, 2021-06-04 at 11:19 -0700, Ryan Tandy wrote:
> Hi. The attached patch updates the test slapd config to support
> OpenLDAP 2.5 in addition to 2.4.

Thanks for the patch. I've applied it in the upstream repo and I plan
to make a new release soon.

> However the test_pamcmds script fails with the new version. The login
> with the correct password fails, the issue seems to be (from
> nslcd.log):
> 
> nslcd: [a88611]  DEBUG: got 
> LDAP_CONTROL_PASSWORDPOLICYRESPONSE (Password must be changed)
> nslcd: [a88611]  DEBUG: myldap_search(base="cn=Veronica 
> Sefcovic+uid=vsefcovic,ou=lotsofpeople,dc=test,dc=tld", 
> filter="(objectClass=*)")
> nslcd: [a88611]  ldap_result() failed: Insufficient 
> access: Operations are restricted to bind/unbind/abandon/StartTLS/modify 
> password
> 
> Still looking into it, not sure why the new ppolicy wants the
> password changed after it was just reset earlier.

Do you know at which step this failed in the test_pamcmds test? In
general I found ppolicy controls during authentication to be somewhat
confusing, especially when a password was about to expire or needed to
be changed.

This heavily depends on the LDAP server implementation but it could be
that the bind operation succeeds (with ppolicy control messages) but
the search that is done afterwards fails (e.g. because the connection
can only be used to change the password). By default nslcd does a
search operation to check whether the bind operation was actually
successful (there are LDAP servers that, for some bind operations, do
not return a proper error but do not have a working session
afterwards). This can be configured with the pam_authc_search option.

Kind regards,

-- 
-- arthur - art...@arthurdejong.org - https://arthurdejong.org/ --



signature.asc
Description: This is a digitally signed message part

Bug#939259: webcheck: Python2 removal in sid/bullseye

[Arthur de Jong]

On Mon, 2020-07-27 at 00:42 -0400, Sandro Tosi wrote:
> 9 months have passed and i dont see any progress on this porting to
> python3: last commits on https://arthurdejong.org/git/webcheck are
> from 2013 (!)
> 
> Are you still interested in this program (which you wrote)? should we
> just remove it from Debian entire?

Hi Sandro,

Thanks for the reminder.

I haven't really found the time to work on webcheck for a while now so
if removing it from Debian makes migration easier that would be fine.
If anyone is willing to help test/port a new version that would be
really welcome though.

Kind regards,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#699114: O: libnss-ldap -- NSS module for using LDAP as a naming

[Arthur de Jong]

On Tue, 2020-07-07 at 22:04 +0200, Chris Hofstaedtler wrote:
> Do any of you think the situation has changed since 2013?
> 
> Personally I would not want to have once popular NSS and PAM
> libraries in the next stable release, if upstream has vanished a long
> time ago.

Looking at the popcon stats (which may not be very representative
because large workstation networks are unlikely to participate):
https://qa.debian.org/popcon-graph.php?packages=libnss-ldap%20libpam-ldap%20libnss-ldapd%20libpam-ldapd%20libnss-sss%20libpam-sss&show_installed=on&want_legend=on&want_ticks=on&date_fmt=%25Y-%25m&beenhere=1

It seems that all three alternatives are currently about equally
popular. It does seem that the old implementation popularity is
steadily declining and sssd is gaining popularity.

There are still a few use cases for at least libpam-ldap that are not
covered by libpam-ldapd (e.g. #845681) (I don't know if sssd covers
those).

While upstream is inactive for both libnss-ldap and libpam-ldap for a
few years now, there do not appear to be any RC bugs in them. Given the
kind of code it is also unlikely that any new vulnerabilities will be
found in them which haven't been found in the last 15 years or so. If
they become a burden or risk I would be more eager to say remove them,
but the current costs of keeping them around is so low that the
benefits for their users probably outweigh them.

Then again, I don't have a very strong opinion on it so if someone has
a good reason to remove them I won't object. At least I'm not going to
step up to become maintainer of those packages ;).

Kind regards,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#958092: virtualenv: PIP fails with No module named 'pip._vendor.six'

[Arthur de Jong]

Package: virtualenv
Version: 20.0.17-1
Severity: important

Creating a virtualenv no longer works:

$ mkdir /tmp/a
$ cd /tmp/a
$ virtualenv venv
created virtual environment CPython3.8.2.final.0-64 in 443ms
  creator CPython3Posix(dest=/tmp/a/venv, clear=False, global=False)
  seeder FromAppData(download=False, contextlib2=latest, webencodings=latest, 
setuptools=latest, pip=latest, retrying=latest, pep517=latest, requests=latest, 
packaging=latest, certifi=latest, distro=latest, html5lib=latest, 
chardet=latest, distlib=latest, progress=latest, appdirs=latest, 
pkg_resources=latest, msgpack=latest, pytoml=latest, CacheControl=latest, 
wheel=latest, colorama=latest, lockfile=latest, pyparsing=latest, 
urllib3=latest, idna=latest, six=latest, via=copy, 
app_data_dir=/home/arthur/.local/share/virtualenv/seed-app-data/v1.0.1.debian)
  activators 
BashActivator,CShellActivator,FishActivator,PowerShellActivator,PythonActivator,XonshActivator
$ ./venv/bin/pip --version
Traceback (most recent call last):
  File "./venv/bin/pip", line 5, in 
from pip._internal.cli.main import main
  File "/tmp/a/venv/lib/python3.8/site-packages/pip/_internal/cli/main.py", 
line 10, in 
from pip._internal.cli.autocompletion import autocomplete
  File 
"/tmp/a/venv/lib/python3.8/site-packages/pip/_internal/cli/autocompletion.py", 
line 9, in 
from pip._internal.cli.main_parser import create_main_parser
  File 
"/tmp/a/venv/lib/python3.8/site-packages/pip/_internal/cli/main_parser.py", 
line 7, in 
from pip._internal.cli import cmdoptions
  File 
"/tmp/a/venv/lib/python3.8/site-packages/pip/_internal/cli/cmdoptions.py", line 
24, in 
from pip._internal.exceptions import CommandError
  File "/tmp/a/venv/lib/python3.8/site-packages/pip/_internal/exceptions.py", 
line 10, in 
from pip._vendor.six import iteritems
ModuleNotFoundError: No module named 'pip._vendor.six'

I have tried with --download and --no-download, removing ~/.cache/pip
but have not found a way to make a working virtualenv.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages virtualenv depends on:
ii  python3-virtualenv  20.0.17-1

virtualenv recommends no packages.

virtualenv suggests no packages.

-- no debconf information

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#953026: python-stdnum fails to validate new Dutch BTW/VAT number format

[Arthur de Jong]

Control: fixed -1 python-stdnum/1.13-1
Control: forwarded -1 https://github.com/arthurdejong/python-stdnum/issues/182
Control: tags -1 + fixed-upstream

On Tue, 2020-03-03 at 14:57 +0100, Harald Welte wrote:
> The problem is that from January 1st, Dutch BTW (VAT) numbers can
> have two valid formats, and python stdnum < 1.13 only understands the
> old format.  This creates various failures in downstream application
> software that relies on stdnum.nl.btw accepting all valid VAT
> numbers.

This has been fixed in 1.13-1 which is available in unstable and
testing.

There are a few possibilities for addressing this:

* introducing a backport package of 1.13-1 (for buster and stretch)
* uploading fixes to proposed-updates so they will be part of the next
  point release

Which pages in Debian does this break for you? I know that Tryton has a
dependency on python-stdnum and I know that at least Odoo used to use
the packages that were shipped by the distribution (I think recent
versions use a virtualenv though).

Due to the nature of the numbers that are supported by python-stdnum
there will always be a the possibility that the implementation will lag
behind legislative or other changes.

The easiest work-around for third-party or other software not shipped
as part of Debian is to use a virtualenv to install a recent version of
python-stdnum.

Please let me know what you think should be the correct cause of
action.

Kind regards,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#951536: Debian Bug Tracking System

[Arthur de Jong]

On Mon, 2020-02-17 at 21:57 +0100, Ingo wrote:
> On first login after boot up on the linux console with a local user I
> have to wait one minute to get a shell prompt. After first login I
> can logoff and login as usual without delay.

This is weird. I suspect this is related to the mechanism that nslcd
uses to authenticate itself to the LDAP server. I'm afraid I don't know
all the details of SASL/GSSAPI/Kerberos protocols and how OpenLDAP uses
them.

> The account is a local unix account with entries in /etc/passwd and
> /etc/group and does not has a posixAccount on the ldap directory.
> Authorization against the ldap server is done with SASL Proxy
> Authorization.

One way to work around this particular problem is to use the
nss_initgroups_ignoreusers option to exclude group lookups for local
user accounts.

> The bug is only seen when quering for the group account. This can
> simply verified with removing the 'ldap' postfix at the line
> group:  files ldap
> in /etc/nsswitch.conf. Without 'ldap' on that line I can first login
> after boot up without delay.

The reason that this lookup occurs is because nslcd supports having
local users in LDAP groups (the NSS subsystem generally supports
this). On login the secondary groups of a user are looked up resulting
in this LDAP search.

> As shown in the debug log below the dbus-daemon is timing out the
> attempt of nslcd to connect to the ldap server.

The logs show two queries: a lookup for the groups of user local which
comes from the login process (pid 362) and one for the groups of user
nslcd which comes from dbus-daemon (pid 345).

Apparently, some part of the SASL/GSSAPI/Kerberos authentication
triggers a dbus lookup. The dbus authentication (the second query in
nslcd) fails with a timeout and the whole thing fails. If that is true
  nss_initgroups_ignoreusers nslcd
should be sufficient to fix this.

Can you confirm?

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#939259: webcheck: Python2 removal in sid/bullseye

[Arthur de Jong]

On Mon, 2019-09-02 at 15:09 +0200, Stefano Rivera wrote:
> Your package either build-depends, depends on Python2, or uses
> Python2 in the autopkg tests.  Please stop using Python2, and fix
> this issue by one of the following actions.
> 
> - Convert your Package to Python3.

I would like to do this but it requires some time that I don't have a
lot of available at the moment. Any help will we appreciated.

The upstream repo has a lot of changes relative to the latest release
because there was a plan to improve performance and make the tool a bit
more lightweight (most of that was done). While the code in the repo
should be reasonably stable it is not as nice as it could be and I
would also like to switch to using requests and a few other things but
it kind of lost focus on it :(

Anyway, help is very welcome.

I'm also not too adverse to removal from testing to help the Python 2
migration along.

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#900253: nslcd: disabling ppolicy breaks authentication

[Arthur de Jong]

On Sun, 2019-09-22 at 01:01 +0900, Marc Dequènes wrote:
> As I can see this part of the code did not change in 0.9.10.

Hi Marc,

Sorry for not responding sooner.

There are two nslcd implementations: nslcd and pynslcd. The pynslcd
implementation is more experimental and does not handle
pam_authc_ppolicy properly.

The nslcd implementation for which you filed the bug should handle the
option properly, e.g. see 
https://arthurdejong.org/git/nss-pam-ldapd/tree/nslcd/myldap.c#n587

This option has been in nss-pam-ldapd since 0.9.7 so if you are seeing
this with nslcd, could you report the exact error your LDAP server is
logging?

The pynslcd implementation does not yet support this in a released
version but I just pushed a fix to Git:
https://arthurdejong.org/git/nss-pam-ldapd/commit/?id=fea0f5e

Thanks,

-- 
-- arthur - art...@arthurdejong.org - https://arthurdejong.org/ --



signature.asc
Description: This is a digitally signed message part

Bug#923784: update-ca-certificates: corrupts ca-certificates.crt on full root file system

[Arthur de Jong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Control: tags + patch

I have created a merge request in Salsa for this:
https://salsa.debian.org/debian/ca-certificates/merge_requests/2

- -- 
- -- arthur - adej...@debian.org - http://people.debian.org/~adejong --

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJcfrYlAAoJECqLdGgQ4K/BnngP/ilZ2mOYKDI7bEkcwGVWUra6
w2I2akNBTYbkcpWB89N9AUhR32Q7kS0ihfOhbA/+wxEhuzZC2ATwT70Ks9NwlHh8
V9KUNUrJTQRioE2PJoNI/ESw5NmJ+lFw+QUW6+aisCjt/tuBxS8ILwh5O93r+v99
Dl+wjtyYPqoSQ0I3TMRp+QJcaQaU7zqANC4d0vzdfjRdQKnKLOqOi65OIkgzdTMf
zmDi4sxgNEXukgg1WtIurrxzVVy4YJGHkj1cJk4aiSHqr7Br4GIKLGHgUx8YolT7
hvZ/Ql7Wq+9HCF/U3FcpVzX46GeWq7Y/Uat++t4Gbcx7kF6YfoFWxzfO/VGk5NtT
c8k8IKbq0UWrMw3W5/nOv/4h8fzyb26p0Y0LPDQJiYThzUYfOhF5oVvYotyt1Kua
83D1KF4+qwT4fUh/qu8ad3I1anhI8/b0hF0fs8QpNHcn+4Hx36cAluQiYC3BryiO
ei9ubFQo1hV0D8Qig9jPZHvX3AXak92Y3klvp3aXKmUqaK78xjuS2jBqkejQmDW+
iO0k3tu6TgZvEirYdwuqd5zOMjQu1Ccsi3RHMpX4CuhhrV6t9lW2XuPbQOHmLbYZ
JDE+EiKjOqJDC0DeiaId8uAn+uAPjSlpqMg7KyDz702c2WxYGh7sAIcOqTxSPHMM
k1kR/RQfx1nejY2CYPUj
=a93d
-END PGP SIGNATURE-

Bug#923784: update-ca-certificates: corrupts ca-certificates.crt on full root file system

[Arthur de Jong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Package: ca-certificates
Version: 20161130+nmu1+deb9u1
Severity: normal
File: /usr/sbin/update-ca-certificates

If the root file system is full update-ca-certificates will corrupt the 
/etc/ssl/certs/ca-certificates.crt file.


The script will create a temporary file and move the new certificate 
bundle in place but the temporary file may be on a different file system 
(/tmp) which means the move is not atomic.


- -- System Information:
Debian Release: 9.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-8-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ca-certificates depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  openssl1.1.0j-1~deb9u1

- -- 
- -- arthur - adej...@debian.org - https://people.debian.org/~adejong --

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJcfmbJAAoJECqLdGgQ4K/BkM0P/RintkRODLwBoTyuBMUQx5Lc
ByWL/LqCdYq+41HPSmoGkKrV95dpA8787QpJZrCnEi0wKx5Evo1YR5/0fE0Ar9t7
sLxlIPf/zcqoRxcyeZm+N8VehvvwRGBH9mXtq9KKrbC65/LgB3OCsQftXljhlyV6
5P9rJkHqgAMTTqXaSBmg/S+DP2BQHepL+YO4BuEqSgaGONwL1YVim1tJ2vy2lLhw
l8zV1+4yrwtcx+GHl0L0Sz3ZdbpwKofdFDXLeE9jPWLdKiYIMhGR3sMBe+HkZGJZ
/1lXDnWTD5askuOjvwl9MqSjJtbV+bHoeKwGTE61/Ls9JzS4HpyH6nBxQo3k0xD8
hNuJR6mZBsf9NfNpLgjbTGrCckgOQdG5DcT2+BiXACdxk3xSOvO6III7WgCBTlUp
RGDfLdCMBKyYME31P5sof5uoL87qffXh52d7QUNzlttduH58OJw8J3zx9lSspqw+
kmJaObxT9SWqfeYnNoRvOIP+eaec51BuBCF1+f/btoHcQVbVBQwgaBQ37DX4Ihnz
t7cRd3p/94ZEwlZRNTWnYob0KXSatylpr5A45XiwSMlTEdONIpK25JHZgZxkCFv9
xehM6EDFil2vKTbNj8dHg00zbHRsyq+bXzI7pAcj7vUAeQCFZpjG2OsoBo+wvmXO
XyaFadebxdG5w7ToGA0K
=T3NE
-END PGP SIGNATURE-

Bug#916789: nslcd: Proposal Of Systemd NSLCD

[Arthur de Jong]

Control: merge 916789 892730

On Tue, 2018-12-18 at 17:25 +0100, Kevin Ariza wrote:
> I have one proposal to solve the problem for add systemd .service
> file, which is the following:
> 
> [Unit]
> Description=NSLCD Systemd Unit Debian
> After=multi-user.target
> 
> [Service]
> ExecStart=/usr/sbin/nslcd
> Restart=on-failure
> KillSignal=SIGQUIT
> Type=forking
> StandardError=syslog
> StandardOutput=syslog
> WorkingDirectory=/var/run/nslcd
> NotifyAccess=all
> RuntimeDirectory=nslcd
> 
> [Install]
> WantedBy=multi-user.target

Thanks for providing the service file. The introduction of a systemd
service file that also handles k5start if Kerberos authentication is
enable is tracked in #892730 and a pull request that is in progress is
available at:

https://salsa.debian.org/debian/nss-pam-ldapd/merge_requests/1

Feel free to provide additional comments.

Kind regards,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#877002: nslcd installation broken: missing ca-certificates.crt

[Arthur de Jong]

On Wed, 2019-01-16 at 15:43 -0800, Sunil Mohan Adapa wrote:
> It would be nice to have fix for this in time for buster. Please
> consider uploading the proposed fix.

I've comitted a fix and will upload soon. Thanks for the patch and
chasing me (I've been quite busy recently).

Thanks,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#903840: nslcd unattentded upgrade fails/hangs at unter URI path

[Arthur de Jong]

On Sun, 2018-07-15 at 09:48 -0700, Matt Weatherford wrote:
> I went to upgrade my debian 9 system today and got a prompt at the
> nslcd upgrade to enter the uri path.  I entered this and the upgrade
> hung.  I am running upgrades over ssh sessions in non-interactive
> mode and wonder if there is something about this upgrade that is
> breaking the script nslcd is running.

Just to be clear: this problem happened when upgrading from 0.9.7-2 to
0.9.7-2+deb9u1?

I recently fixed an issue related to the nslcd start-up that could
result in a delay of 1 minute if nscd is used (will be fixed in
0.9.10). Another issue I have seen is that restarting slapd can take a
long time.

Depending on how your configuration was done normal upgrades of nslcd
should not prompt for configuration and there shouldn't have been any
major changes to this since around 0.9.1 (nothing major in the
packaging between jessie and stretch).

> It seems the new script is parsing the nslcd.conf file and making
> changes and / or normalizing things. Is there a changelog that I can
> review to better understand what is happening here?

The whole debconf configuration is a bit tricky because we need to
support debconf pre-seeding, load configuration from an existing
configuration file and we have some magic to detect sane defaults if no
pre-seeding was done and no existing configuration is in place.

> What additional info would be helpful to you that I can gather?

If you can reproduce the problem a log of the upgrade and where it was
hanging would be useful.

> Versions of packages nslcd suggests:
> pn  kstart  
> 
> -- debconf information:
>   nslcd/ldap-auth-type: SASL
>   nslcd/ldap-sasl-krb5-ccname: /var/run/nslcd/nslcd.tkt
>   nslcd/ldap-sasl-mech: EXTERNAL

If you are using Kerberos authentication for the connection to the LDAP
server you may want to use kstart to keep the ticket fresh.

Thanks,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#872798: nslcd: can be killed by the OOM Killer, DoS

[Arthur de Jong]

On Tue, 2017-08-22 at 00:52 +0200, Vincent Lefevre wrote:
> Control: severity -1 normal
> 
> (fixing the typo in the Control line)

Thanks, I somehow never get these right ;)

> Perhaps not unique to nslcd, but the consequences are the worst when
> nslcd is killed: one can no longer access to the machine.

That is true. It is probably also true for systemd, udev and similar
processes but some of these also seem to tweak oom priority.

> I suppose that a workaround based on this in /etc/init.d/nslcd could
> be after "start-stop-daemon --start ...":
> 
>   status=$?
>   if [ $status -eq 0 ]; then
> echo -1000 > /proc/`cat $NSLCD_PIDFILE`/oom_score_adj
>   fi
>   log_end_msg $status
>   ;;

That should be a workaround for now.

Thanks,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#872798: nslcd: can be killed by the OOM Killer, DoS

[Arthur de Jong]

Control: sevirity -1 normal

On Mon, 2017-08-21 at 13:17 +0200, Vincent Lefevre wrote:
> Severity: grave
> Justification: causes non-serious data loss and DoS from an end user.

The severity is a bit questionable and, at the very least not a flaw in
or unique to nslcd. Any local user that does not have resource limits
applied to them can DoS the whole system easily so I'm lowering the
severity to normal.

> It appears that nslcd can be killed by the OOM Killer when some user
> process takes all the memory. In such a case, it is no longer
> possible to connect to the machine by SSH. Thus this is DoS by an end
> user, with possible data loss concerning what is running on the
> machine.

The OOM is indeed a bit of Russian roulette on your system. You can
tune it a bit with vm.panic_on_oom and vm.overcommit_memory sysctls or
perform the following action that is equivalent to what newer nslcd
does:

echo -1000 > /proc/`cat /var/run/nslcd/nslcd.pid`/oom_score_adj

The patch should be pretty easy to backport though. I've put it on my
list but can't really guarantee a turn-around-time.

Thanks,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#863964: systemd does not restart nslcd after a segfault

[Arthur de Jong]

On Sat, 2017-06-03 at 14:12 +, Sergio Gelato wrote:
> I've now successfully tested the fix from #827444 on both jessie and
> stretch.
> 
> Specifically, I created
> /etc/systemd/system/nslcd.service.d/forking.conf with the following
> contents:
> 
> [Service]
> Type=forking
> PIDFile=/var/run/nslcd/nslcd.pid
> RemainAfterExit=no
> Restart=on-failure

Hi Sergio,

Thanks for your service description. I am a bit reluctant to add
restart-on-crash to nslcd and it could be a security risk in general
for daemons.

One reason for this is that it potentially turns a denial of service
vulnerability into something much worse (e.g. remote code execution).
This is especially true when address space randomisation is used.

If, for example, there is a flaw in a daemon that you can use to
trigger remote code execution only in a certain percentage of exploit
attempts (and otherwise causing a crash) with auto-restart you will
have more attempts at the exploit. If I read the systemd documentation
correctly it has some mechanisms to limit this though
(StartLimitIntervalSec and StartLimitBurst).

Another issue is that if a daemon crashes there certainly is a bug
somewhere. If the service is silently restarted on crashes the bug will
less likely be reported and fixed leaving a bug around longer.

The biggest reason however for not switching to a systemd service file
is that I want to keep is starting k5start if nslcd.conf has sasl_mech
and krb5_ccname configured. This is now implemented in the init script
and configurable in /etc/default/nslcd. I have not been able to figure
out how to do this in systemd yet.

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#861212: nslcd: certificate authentication fails with Unknown authentication method: SASL(-4)

[Arthur de Jong]

On Thu, 2017-05-04 at 23:01 -0700, Matt Weatherford wrote:
> Update:  I logged this bug further down the stack, as it was also 
> affecting the "ldap-utils" package (ldapsearch and ldapwhoami also)
> 
> I got some feedback that led us to determine that our LDAP server on 
> CentOS was offering up a LOT of certificate options... scaling those 
> back made the system including nslcd work again.
> 
> the other bug is Bug#861838

Thanks for following up. Since the bug is not in nss-pam-ldapd I am
inclined to close this bug report. Any progress on this can be tracked
in #861838 further.

Thanks,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#861212: nslcd: certificate authentication fails with Unknown authentication method: SASL(-4)

[Arthur de Jong]

On Thu, 2017-04-27 at 20:25 -0700, Matt Weatherford wrote:
> Im sure you have many, many other projects going but I am motivated
> to solve this problem - is there anything else I can try on my
> side?  I've sent you nslcd debug info ...  anything else I can do?

Sorry for not replying sooner. Your ldapsearch output shows that at
least the problem is not per se in nss-pam-ldapd ;)

To get more debugging info from nslcd you could specify -d twice when
running nslcd. This also enables extra debugging in libldap which
produces a lot of output but I don't think it will include extra debug
output of the TLS library (GnuTLS on Debian).

For ldapsearch you could try passing -d1 to get debug output. I assume
the ldapsearch in your script works on older versions? From my
experience I think the certificates and keys can only be configured in
a configuration file (e.g. ldaprc in the current directory).

Maybe comparing the debug output from Debian 7 and 9 will provide some
more insights?

One thing that you could try is add the DN to bind as as binddn instead
of leaving it empty. You should probably be able to get the DN from an
ldapwhoami query on older versions of Debian.

Another thing that could help is looking in the server logs to see if
any problem is logged there (it could be a TLS version or cypher-suite
mismatch).

I don't think there should be much issues with how the key, CSR and CRT
are generated. GnuTLS should be able to handle files generated by
OpenSSL file as far as I know. Location of the files should also not be
an issue.

I have not doen client certificate authentication recently and not on
Debian.

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#861212: nslcd: certificate authentication fails with Unknown authentication method: SASL(-4)

[Arthur de Jong]

On Tue, 2017-04-25 at 16:53 -0700, Matt Weatherford wrote:
> debian 7 install works fine with certificate auth.
> Debian 9 install with same config files appears to not work and
> throws these erros:
> 
> Apr 25 16:41:08 nori nslcd[1376]: [52255a]  failed to
> bind to LDAP server ldap://ldi.s.uw.edu: Unknown authentication
> method: SASL(-4): no mechanism available:
> Apr 25 16:41:08 nori nslcd[1376]: [52255a]  no available
> LDAP server found: Unknown authentication method: Bad file descriptor
> Apr 25 16:41:13 nori nslcd[1376]: [9cf92e]  no available
> LDAP server found: Server is unavailable: Bad file descriptor

Does running nslcd in debug mode provide more information?

> contents of /etc/nslcd.conf:
> 
> uri ldap://ldi.s.uw.edu
> ssl start_tls
> 
> tls_cacertfile  /etc/ssl/ldi/InCommonCA.crt
> tls_cert/etc/ssl/ldi/ldi-client.crt
> tls_key /etc/ssl/ldi/ldi-client.key
> 
> sasl_mech   EXTERNAL

So the client-side certificate is used for authentiction and that is
where it appears to fail.

Can you make the connection using the ldapsearch command-line tool? The
nslcd daemon does not do any TLS handling itself and only passes
configuration options to libldap but there are differences between TLS
libraries used.

Kind regards,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#859432: nss-pam-ldapd shouldn't disable PIE

[Arthur de Jong]

Control: tags -1 + pending

On Mon, 2017-04-03 at 16:10 +0300, Adrian Bunk wrote:
> With gcc in stretch defaulting to PIE, hardening=+all,-pie changed
> semantics from "enable hardening but not PIE" to "enable all
> hardening and explicitely disable the default PIE".
> The latter is usually not intended.

Thanks for pointing this out and including a patch. This will be fixed
in the next upload.

Thanks,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#859452: libpam-ldapd: mixing with libnss-ldap does not work

[Arthur de Jong]

On Mon, 2017-04-03 at 19:52 +0200, Laurent Bonnaud wrote:
>  - libpam-ldapd + libnss-ldap  -> fails

This works for me. Note that for this to work you have to include ldap
in the shadow map in nsswitch.conf because otherwise pam_unix rejects
the login. You should also be able to map the userPassword attribute to
"*" using the nss_override_attribute_value in /etc/libnss_ldap.conf but
I couldn't get that to work.

Can you post the relevant part of auth.log for the above configuration?

Thanks,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#858883: nslcd : missing symbols : _nss_ldap_version and _nss_ldap_enablelookups

[Arthur de Jong]

On Mon, 2017-04-03 at 19:02 +0200, Laurent Bonnaud wrote:
> This system had libnss-ldap installed, indeed.  I purged this
> package, installed libnss-ldapd instead, but I still get the
> warnings:

Are you sure, can you run?

dpkg -S /lib/x86_64-linux-gnu/libnss_ldap.so.2
dpkg --get-selections | grep ldap
ldd /lib/x86_64-linux-gnu/libnss_ldap.so.2

> BTW I had LDAP working with libnss-ldap but now with libnss-ldapd it
> does not work any longer (but this is for another bug report...)

Having the wrong NSS module installed should also explain this.

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#858826: nslcd: confusing error messages during package installation

[Arthur de Jong]

Control: tags -1 + pending

On Mon, 2017-03-27 at 12:41 +0200, Laurent Bonnaud wrote:
> below is a full log of this package's installation.  What I found
> confusing is:
> 
>  - the error message
> Warning: The home dir /var/run/nslcd/ you specified can't be
> accessed: No such file or directory
> 
>  - the message
> Not creating home directory `/var/run/nslcd/'.
> 
>  - the fact that at the end the /var/run/nslcd/ directory is created.

The errors are from the command

adduser --system --group --home /var/run/nslcd/ \
--gecos "nslcd name service LDAP connection daemon" \
--no-create-home \
nslcd

that is run during nslcd postinst. There are a few ways to return Two
ways come to mind to hide the error message:

- change the --home parameter (e.g. to /) (the home directory should
  not be used for anything)
- remove --no-create-home option

The second option should have the least troubling messages so that
should be part of the next upload to unstable.

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#858608: spotweb: Wrong mysql-client dependency

[Arthur de Jong]

Package: spotweb
Version: 20130826+dfsg3-4
Severity: important   

Dear Maintainer,

The mysql-client dependency in spotweb is wrong which results in
forcing the installation of MariaDB over an existing MySQL
installation.

The dependency on
  default-mysql-client
should be
  default-mysql-client | virtual-mysql-client
to also allow either the installation of the MariaDB client or the
MySQL client. Note that the recommends on the server-part does have
this alternative.

Thanks,

-- System Information:
Debian Release: 9.0   
  APT prefers testing 
  APT policy: (900, 'testing'), (800, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#851134: Info received (Bug#851134: nslcd crashes when losing contact with its server)

[Arthur de Jong]

Control: severity -1 important

On Tue, 2017-02-07 at 12:42 -0500, James Valleroy wrote:
> Any update on this bug? Is it possible the severity could be lowered
> until the analysis is complete?
> 
> I have some packages (plinth, freedombox-setup) that depend on nslcd,
> so I'm hoping that it won't be removed from testing.

Lowering severity to important because I haven't been able to reproduce
this issue yet and the package works in most configurations.

I have done some tests with a simple ldaps:// connection and haven't
been able to trigger a crash in nslcd.

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#851134: Info received (Bug#851134: nslcd crashes when losing contact with its server)

[Arthur de Jong]

On Mon, 23 Jan 2017, Elizabeth Myers wrote:

I can't reproduce it with nslcd -d. It happens reliably outside of it
though. I will try to get a core dump.


You probably want to avoid adding the core file to the bug report since it 
will probably contain your client's private SSL key.


If you want me to look at it you can send the file to me securely via:
  https://arthurdejong.org/upload/
I will remove the file after analysing it.

--
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --

Bug#851134: nslcd crashes when losing contact with its server

[Arthur de Jong]

Hi Elizabeth,

I have been trying to reproduce this (nslcd 0.9.7-1, slapd 2.4.40+dfsg-
1+deb8u2).

I have not been able to reproduce this when not using SSL and the
following nslcd.conf also works without problems for me:

uid nslcd
gid nslcd
uri ldaps://192.168.12.1/
base dc=thuis,dc=net
tls_reqcert never
tls_cacertfile /etc/ssl/certs/ca-certificates.crt
reconnect_invalidate passwd,group

This leaves the following settings (mostly client-side certificates)
which I haven't tested yet:

sasl_mech EXTERNAL
tls_reqcert demand
tls_cacertfile /etc/ssl/certs/cacert.pem
tls_key /etc/ssl/private/alakazam_ldap.key
tls_cert /etc/ssl/certs/alakazam_ldap.pem

Now setting up CA infra for my test environment to see if I can
reproduce this but it is a bit of a pain to integrate this into my
scripts.

Having a backtrace would be very helpful.

Thanks,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#851564: nslcd fails to start: postinst sets tls_cacertdir wrong

[Arthur de Jong]

Control: found -1 nss-pam-ldapd/0.9.4-2
Control: tags -1 + pending

On Mon, 2017-01-16 at 12:55 +0100, Thomas Wallrafen wrote:
> See the attached ncslcd.conf file (the version before the
> upgrade).

Thanks for providing the info.

I tracked the bug down to a problem in the parsing of the configuration
file. The bug itself was present in nss-pam-ldapd at least since 0.7.13
but it could only be triggerred since 0.9.4-2 if you have a
tls_cacertdir option specified.

This option will most likely be ignored on Debian because I understand
that GnuTLS does not use it. It is also not configured by default which
probably explained why this was not found earlier.

You can probbaly safely remove or comment out the tls_cacertdir option
in nslcd.conf without any ill effects.

This fix is pretty simple and a patch is attached for reference. I will
prepare a fix for unstable and try to get a fix into jessie soon.

Thanks,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --
Index: debian/changelog
===
--- debian/changelog	(revision 2159)
+++ debian/changelog	(working copy)
@@ -3,8 +3,10 @@
   * recommend ca-certificate which is needed due to adding tls_cacertfile by
 default (see #750949) and the checking of tls_cacertfile in 0.9.7
 (closes: #836720)
+  * fix parsing of nslcd.conf tls_cacert option in package configuration
+(closes: #851564)
 
- -- Arthur de Jong   Wed, 07 Sep 2016 23:10:45 +0200
+ -- Arthur de Jong   Tue, 17 Jan 2017 14:42:28 +0100
 
 nss-pam-ldapd (0.9.7-1) unstable; urgency=medium
 
Index: debian/nslcd.config
===
--- debian/nslcd.config	(revision 2157)
+++ debian/nslcd.config	(working copy)
@@ -27,7 +27,7 @@
   if [ -z "$RET" ] || [ "$force" = "force" ]
   then
 # the first part avoids getting options that have an optional MAP parameter
-cfgfile_value=`sed -n '/^'"$cfg_param"'[[:space:]]\(aliases\|ethers\|group\|hosts\|netgroup\|networks\|passwd\|protocols\|rpc\|services\|shadow\)[[:space:]]/!s/^'"$cfg_param"'[[:space:]]*\([^[:space:]].*[^[:space:]]\)[[:space:]]*$/\1/ip' "$cfgfile" | head -n 1`
+cfgfile_value=`sed -n '/^'"$cfg_param"'[[:space:]][[:space:]]*\(aliases\|ethers\|group\|hosts\|netgroup\|networks\|passwd\|protocols\|rpc\|services\|shadow\)[[:space:]]/!s/^'"$cfg_param"'[[:space:]][[:space:]]*\([^[:space:]].*[^[:space:]]\)[[:space:]]*$/\1/ip' "$cfgfile" | head -n 1`
 [ -n "$cfgfile_value" ] && db_set "$debconf_param" "$cfgfile_value"
   fi
   # we're done


signature.asc
Description: This is a digitally signed message part

Bug#851564: nslcd fails to start: postinst sets tls_cacertdir wrong

[Arthur de Jong]

Hi,

On Mon, 2017-01-16 at 11:52 +0100, Thomas Wallrafen wrote:
> The aforementioned setting is probably added to the file via the
> postinstall script of the nslcd package.  If one removes the line
> tls_cacertfile dir /etc/ssl/certs from the file /etc/nslcd.conf and
> runs
> # dpkg --configrue -a
> the line reappers and nslcd is still unable to start.

Can you post your whole nslcd.conf file? Previously there was a
tls_cacert option that got renamed to tls_cacertfile. There is also a
tls_cacertdir option but that should not be used on Debian.

Also can you provide your debconf settings from

# debconf-get-selections | grep ^nslcd | grep -v password

Thanks,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#851134: nslcd crashes when losing contact with its server

[Arthur de Jong]

On Thu, 2017-01-12 at 04:16 -0600, Elizabeth Myers wrote:
> When restarting the OpenLDAP server, nslcd often crashes on multiple
> servers with the following messages logged (I know they're not
> helpful but it's what I have at the moment):
> 
> nslcd[14819]: segfault at 0 ip 7fdc51502ce4 sp 7fdc4e553fe0
> error 4 in libsasl2.so.2.0.25[7fdc514fb000+1a000]
> traps: nslcd[10619] general protection ip:7f0977bd322b
> sp:7f0974465bb0
> error:0 in libc-2.24.so[7f0977b5c000+195000]

Can you install the following packages and try to reproduce the crash:
  libc6-dbg
  libgnutls30-dbgsym
  libgssapi-perl-dbgsym
  libkrb5-dbg
 
libldap-2.4-2-dbg
  libsasl2-2-dbgsym
  libsasl2-modules-db-dbgsym
 
libsasl2-modules-dbgsym
(for installing the -dbgsym packages you probably need to add another
repo to APT, see https://wiki.debian.org/AutomaticDebugPackages)

If you could run nslcd under gdb and trigger the crash:

# gdb /usr/sbin/nslcd 
...
(gdb) r -d
...
   try to force the crash
...
(gdb) thread apply all bt full

Alternatively sometimes valgrind provides very useful crash
information.

Judging by the backtrace the crash is in libsasl2 which is used by
libldap so I expect the bug to be in one of those packages but we
probably need more information.

Thanks,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#777125: sysvinit-utils: service cmd with systemd shows, but did not stop duplicate instances of nslcd

[Arthur de Jong]

Control: tags -1 + moreinfo

On Thu, 2015-02-05 at 11:15 +0100, Hermann Lauer wrote:
> during some "service {start,stop,restart,status} nslcd" usage
> there are for unknown reasons two instances of nslcd running:

Given that this is a 0.9.4 version of nslcd, there was a fix in 0.9.6-4 
(bug #814881) as Felipe pointed out.

That bug would result in the init script stopping before nslcd had
actually terminated causing problems for restarts that do a stop/start
via the init script instead of restart.

Can you still reproduce this issue with a more recent version of nslcd?

Thanks,

-- 
-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#845443: jessie-pu: package nss-pam-ldapd/0.9.4-3+deb8u2

[Arthur de Jong]

On Wed, 2016-11-23 at 14:19 +0100, Salvatore Bonaccorso wrote:
> nss-pam-ldapd's nslcd under the conditions as described in #814881
> might fail to restart. nslcd restart which is stop+start with
> systemd, is racy, and might lead to nslcd not running after a
> restart. Ferenc has posted his analysis in
> https://bugs.debian.org/814881#39
> confirming that the debdiff fixes the issue.

Thanks for picking this up and sorry for not working on this.

At the very least I can confirm that the debdiff has the correct change
to fix #814881 and I support getting this fixed in jessie.

Thanks and sorry,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#754248: [Python-modules-team] Bug#754248: python-virtualenv: Error when attempting to create a python2.6 virtualenv

[Arthur de Jong]

On Mon, 2016-11-14 at 10:28 -0500, Barry Warsaw wrote:
> On Nov 13, 2016, at 10:14 PM, Arthur de Jong wrote:
> > I just ran into this today and I can confirm that the above fix
> > allows me to move forward with a Python 2.6 virtualenv. Can you fix
> > this for unstable?
> 
> Yes, I'll upload this fix to unstable momentarily.

Thanks.

Just managed to get everything working with the python2.6 from wheezy :)

-- 
-- arthur - art...@arthurdejong.org - https://arthurdejong.org/ --


signature.asc
Description: This is a digitally signed message part

Bug#754248: python-virtualenv: Error when attempting to create a python2.6 virtualenv

[Arthur de Jong]

On Thu, 2015-01-08 at 06:08 +0200, Stefano Rivera wrote:
> Hi John (2015.01.08_05:24:06_+0200)
> > ++'/usr/share/python-wheels/{0}-*.whl'.format(project))
> > -+'/usr/share/python-wheels/{}-*.whl'.format(project))
> 
> That's simple enough that it is reasonable to apply. However we've
> probably missed the boat for Debian Jessie.

I just ran into this today and I can confirm that the above fix allows
me to move forward with a Python 2.6 virtualenv. Can you fix this for
unstable?

I know Python 2.6 is no longer supported within Debian but I want to
run some tests with a locally-compiled Python 2.6 to ensure that my
code still works with that if needed.

Thanks,

-- 
-- arthur - art...@arthurdejong.org - https://arthurdejong.org/ --


signature.asc
Description: This is a digitally signed message part

Bug#717235: proftpd requests the whole passwd database at each login

[Arthur de Jong]

On Tue, 2016-09-20 at 14:37 +0200, Hilmar Preuße wrote:
> 
> An alternative is to do setpwent()/getpwent()/setpwent() which should
> abort the started search without wasting too much time trying to
> search LDAP entries in our environment.
> 
> 
> ...and this is exactly what has been implemented in upstream. ;-)

From a quick look that seems to be the implementation. I haven't done
any testing though but this should work in any case.

I still question the usefulness of setpwent()/getpwent() in the first
place as there is no guarantee that any resources opened for setpwent()
are used for other getpw{nam,uid}() calls.

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#836720: nslcd should recommend ca-certificates

[Arthur de Jong]

Control: tags -1 + pending

On Mon, 2016-09-05 at 05:21 +, Mathias Gibbens wrote:
> During installation nslcd failed to start, and I saw this error in
> the log:
> 
> > connection daemon: nslcdnslcd: /etc/nslcd.conf:28: tls_cacertfile:
> > error accessing /etc/ssl/certs/ca-certificates.crt: No such file or
> > directory
> 
> Installing the ca-certificates package created the ca-
> certificates.crt file which is expected by the default configuration
> of nslcd. I also tested installing nslcd on another identically
> configured test server, but purposefully installed the ca-
> certificates package before installing nslcd. That install finished
> without issue.
> 
> I think nslcd should recommend the ca-certificates package.

Thanks for pointing this out.

The next upload will add a recommends on ca-certificates. The added
checking of tls_cacertfile in 0.9.7 with the change for #750949
triggered this.

Thanks,

-- 
-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#825244: nslcd: Allow arbitrary maps via getent.ldap(1)

[Arthur de Jong]

Hi,

On Tue, 2016-05-24 at 20:43 -0400, Daniel Richard G. wrote:
> I want to have an autofs mount for these so that they are accessible,
> but I need to query a "unixHomeDirectory" attribute in LDAP (homedirs
> are spread across multiple servers so I can't just construct a path
> from the username) and the "homeDirectory" slot is already spoken
> for.

The tricky bit here is that autofs, while partially configured in
/etc/nsswitch.conf does not use the C library NSS layer for these
lookups. You can use LDAP to export automounter maps but these will not
go through nslcd.

Maybe I don't understand your use case completely.

> My company LDAP server has a "thumbnailPhoto" attribute for each
> user, which is some kind of base64-encoded image that is likely the
> same user photo shown in the Outlook mail client.
> It would be lovely to show this as a "user picture" in LightDM, or
> perhaps elsewhere in the Linux desktop, without needing to configure
> a separate LDAP client to get at it.

The problem here is that this also does not go through the NSS
subsystem so will not reach nslcd. Extracting these pictures and
updating local copies should be pretty simple with a small script.

A long time ago I made something like that for gdm (probably no longer
works with the most recent version), see
https://arthurdejong.org/ldapgdmfaces/

> An "automount" map is supported by libnss-ldap, and while first-class 
> support for this in libnss-ldapd would be nice, I can foresee greater
> flexibility in being able to specify multiple sources for automount
> definitions (e.g. "automount1", "automount2", ...)

I understand that the automounter map in nss_ldap is mainly for
platforms that use the NSS layer for this. On Linux auotfs uses a
custom lookup module that works well (supports mapping attributes
etc.). The autofs-ldap package is reasonably flexible and I've seen
environments where all automounter maps are in LDAP.

At one point I did have a look into providing an autofs lookup module
that would direct requests to nslcd but the main benefit would be to
centralise configuration while that may not always be what you want
(e.g. having automounter maps on a different LDAP server than user
accounts).

I would gladly help integrating an autofs lookup module and automounter
map support in nslcd but for me personally the current software
solution works without any real problems.

For some background see:
  https://bugs.debian.org/638007

Anyway, patches for implementing automounter lookups in nslcd and
perhaps an autofs lookup module are welcome and I will do my best to
try to integrate them into nss-pam-ldapd.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --

signature.asc
Description: This is a digitally signed message part

Bug#825153: nslcd: Numerous ' request denied by validnames option' log entries

[Arthur de Jong]

On Tue, 2016-05-24 at 19:01 -0400, Daniel Richard G. wrote:
> After picking through the backtrace, I've found exactly what is
> generating the request. Below, I've copied the entire shell function
> in question (from /usr/share/bash-completion/bash_completion), and
> have marked the offending line:
[...]
> There are other instances of "~*" in the file, but they all have a
> backslash escaping the tilde.

Good find. Thanks for tracking this down!

> > Would you agree that this appears to be a bug in bash-completion?

I would think so. Please file a bug against bash-completion.

Thanks,
-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --

signature.asc
Description: This is a digitally signed message part

Bug#825153: nslcd: Numerous ' request denied by validnames option' log entries

[Arthur de Jong]

On Tue, 2016-05-24 at 16:24 -0400, Daniel Richard G. wrote:
> > No, I'm pretty sure it is some sort of lookup that is meant to
> > return nu users at all or a misconfiguration somewhere.
> 
> If I can find what is doing this, should the behavior be
> considered a bug?

At the very least it is weird behaviour. I don't expect any NSS module
would return useful information. It could be a compat lookup thing but
I thought it only worked on "+" entries, not "*" and those entries are
only supported in flat files (/etc/passwd, /etc/shadow).

If you could track it down I would be very interested to know why some
application would do that. If this is some kind of standard use of the
API I'm not aware of perhaps that would be an argument to change the
behaviour of nslcd.

Running nslcd in debug mode will show application pids that perform the
request, that will probably help in tracking it down.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --

signature.asc
Description: This is a digitally signed message part

Bug#825153: nslcd: Numerous ' request denied by validnames option' log entries

[Arthur de Jong]

On Tue, 2016-05-24 at 03:27 -0400, Daniel Richard G. wrote:
> I am seeing relatively frequent entries of this form in syslog:
> 
> May 24 03:04:23 darkstar nslcd[1187]: [3c9869]  request denied by 
> validnames option
> 
> While I am uncertain as to what causes this, at one point it appeared
> to be associated with tab completion at a shell prompt. (At the same
> time, however, I can't reproduce this reliably that way.)

I'm not really sure what triggers it but I also see this in the logs a
lot. I just ignore it. It could be that nscd makes it more difficult to
trigger because it sometimes also caches negative hits. Furthermore,
the application may be caching it.

> I claim ignorance as to why this request occurs (is this really
> supposed to return a list of all users?)

No, I'm pretty sure it is some sort of lookup that is meant to return
nu users at all or a misconfiguration somewhere.

> But given that this request comes up fairly often, and does not
> appear to be the result of a misconfiguration, it would be helpful to
> have a way of keeping this noise out of the log. The "*" request
> could be specifically ignored, while continuing to log other
> instances of failed validnames matching.

To not report it as an invalid name you could set validnames to

/^[a-z0-9._@$()*]([a-z0-9._@$() \\~-]*[a-z0-9._@$()~-])?$/i

but that is a bit ugly and it results in a useless LDAP search each
time.

> (Incidentally, "nss_disable_enumeration yes" does not address this.)

No. The "*" lookup is just to look up a user with that name. The
function call can also return only one passwd entry so it is not meant
to be a wildcard. As such it is not covered by nss_disable_enumeration.

Not sure this will be fixed in nss-pam-ldapd any time soon.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --

signature.asc
Description: This is a digitally signed message part

Bug#820025: python-pskc-doc: missing Breaks+Replaces: python-pskc (<< 0.4)

[Arthur de Jong]

On Mon, 2016-04-04 at 22:35 +0200, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package fails to upgrade
> from 'testing'.
> It installed fine in 'testing', then the upgrade to 'sid' fails
> because it tries to overwrite other packages files without declaring
> a Breaks+Replaces relation.

Thanks for pointing this out and thanks for the testing. I'll upload a
fix shortly.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#814881: nslcd is stopped after service restart

[Arthur de Jong]

Control: tags -1 + pending

On Tue, 2016-02-16 at 10:09 +0100, Michael Braun wrote:
> After installing some unrelated program using apt-get, it was
> discovered that nslcd needs a restart und I was promted to restart it
> (among other services).

Were you using needrestart for this?

I've had needrestart not correctly restart at least ntp, rpcbind and
mailman. I suspect there is a bug in needrestart and or the combination
with systemd but I've not been able to track it down.

> The logs when the error occured read:
> 
> Feb 15 12:12:01 gate nslcd[26487]: caught signal SIGTERM (15), shutting down
> Feb 15 12:12:01 gate nslcd[21177]: Stopping LDAP connection daemon: nslcd.
> Feb 15 12:12:01 gate nslcd[21302]: version 0.9.4 starting
> Feb 15 12:12:04 gate nslcd[26487]: thread 2 is still running, shutting down 
> anyway
> Feb 15 12:12:04 gate nslcd[26487]: version 0.9.4 bailing out
> Feb 15 12:12:06 gate nslcd[21302]: accepting connections
> Feb 15 12:12:06 gate nslcd[21231]: Starting LDAP connection daemon: nslcd.

The last line I think is systemd writing a log entry using the nslcd.
The lines are out of order for some reason and the new daemon in
started while the old one is still shutting down.

The problem could be that the init script is not called with restart
but with separate stop and start actions (this is slightly different).
I will update the init script to ensure that stop also only returns
when nslcd has actually stopped.

Thanks for pointing this out. This could also be the issue with some of
the other services that have not been restarted correctly.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#794686: nslcd start script does not report starting failure

[Arthur de Jong]

On Thu, 2016-02-11 at 14:13 +0300, Nikolay Shaplov wrote:
> This bug was not fixed for debian jessie, as I can see... 
> And I think it should be fixed in all supported distributives, as it
> can cause problems.

Thanks for reminding me. I uploaded a new version for jessie yesterday.

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#785053: jessie-pu: package nss-pam-ldapd/0.9.4-3+deb8u1

[Arthur de Jong]

On Fri, 2016-01-01 at 17:16 +, Adam D. Barratt wrote:
> Apologies for the repeated delay. :-| Please go ahead.

Just when I wanted to wrap this up, another important bug popped up
with a trivial fix :)

The bug is #811476 which has a trivial fix that has been in testing for
a long time and affects people who put IPv6 addresses in LDAP. A patch
that can be dropped in debian/patches is attached.

To not delay this process much longer I'll upload 0.9.4-3+deb8u1 with
the fixes for #759544, #794686 and #794068 which were previously
approved in about a week.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --

Description: Fix uninitialised variable
 This fixes a bug in the NSS library when encountering IPv6 addresses in
 the hosts map.
Author: Mark R Bannister 
Origin: upstream, http://arthurdejong.org/git/nss-pam-ldapd/commit/?id=ed8b312f0968ce4fd9059b0ebb52d993cf3cdf36
Bug-Debian: https://bugs.debian.org/811476

---
 nss/hosts.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/nss/hosts.c
+++ b/nss/hosts.c
@@ -99,7 +99,7 @@ static nss_status_t read_one_hostent(TFI
 }
 else
 {
-  SKIP(fp, tmpint32);
+  SKIP(fp, tmp2int32);
 }
   }
   /* null-terminate address list */


signature.asc
Description: This is a digitally signed message part

Bug#811476: libnss-ldapd: getent hosts crashes with nss-ldapd and mixed IPv4/IPv6 reading

[Arthur de Jong]

Control: tags -1 + patch fixed-upstream
Control: fixed -1 nss-pam-ldapd/0.9.5-1

On Tue, 2016-01-19 at 10:55 +0100, Simon Bin wrote:
> The version 0.9.4 of libnss-ldapd contains a flaw that makes the
> `getent hosts` command and similar name resolution crash when the
> LDAP directory contains mixed IPv4 and IPv6 ipHostNumbers.

The fix for this is here which can be trivially backported to jessie:

http://arthurdejong.org/git/nss-pam-ldapd/commit/?id=ed8b312f0968ce4fd9059b0ebb52d993cf3cdf36

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#803316: python-stdnum: new feature eu.vat.check_vies does not work

[Arthur de Jong]

Control: tags -1 + fixed-upstream
Control: tags -1 + pending

On Wed, 2015-10-28 at 18:19 +0100, Lionel Elie Mamane wrote:
> >>> stdnum.eu.vat.check_vies_approx('BE555445','BE87785')
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python2.7/dist-packages/stdnum/eu/vat.py", line 157,
> in check_vies_approx
> return _get_client.checkVatApprox(
> AttributeError: 'function' object has no attribute 'checkVatApprox'

Thanks for pointing this out. Your patch has been merged upstream:
  
http://arthurdejong.org/git/python-stdnum/commit/?id=2881b86206f01bdc50fb5c9e171189b42ea55ebf

The whole VIES code was not automatically tested to avoid overloading
the online service but I've added a few tests that will not be part of
the upstream code but only run before each release. This also resulted
in this fix:
  
http://arthurdejong.org/git/python-stdnum/commit/?id=96c8151e07e5800f8396d10778615024e61abc6f

These fixes will be in the next upload. Thanks again for the patch.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#737079: nscd crashes on netgroup lookups

[Arthur de Jong]

On Thu, 2015-10-15 at 00:29 -0400, Carlos O'Donell wrote:
> The upstream glibc community has been working hard to rectify these
> issues, and Red Hat in particular spent a lot of time making the
> netgroup caching as bullet-proof as possible. If you have real bugs,
> please file them upstream and come talk to the community.

Sorry, didn't mean te offend anyone. I'm sure nscd has seen a lot of
improvements since the last time I had a look at it. It was very
complex though. Then again caching is one of the two hard things in
computer science ;)

> > Not all NSS interfaces are consistent in terms of memory
> > management, return codes, etc. so there could be something
> > wrong.
> 
> They should be consistent. Again, if you find something wrong, please
> file a bug. The upstream glibc community is radically different now
> and certainly more accepting of discussions on these issues.

At least the _nss_xxx_initgroups_dyn() function is expected to grow the
passed groupsp buffer itself instead of returning NSS_STATUS_TRYAGAIN+
ERANGE like most other functions. The Solaris NSS implementation
(although far from perfect and having many nasty other "features") uses
an initialiser that returns a backend pointer that is passed to all
functions to allow memory and other resource management in the NSS
module itself. Also having a single return code and avoiding messing
with errno would also be nicer.

However, I'm not filing a bug about this because I think keeping a
stable interface at this point is still better than improving the
existing interface.

All your efforts on nscd and libc are very much appreciated!

Anyway, I'm willing to test some patches to see if we can improve the
nscd version in sid (2.19-22) and/or jessie (2.19-18+deb8u1) but I'm
having a hard time reproducing the bug I originally filed.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#737079: nscd crashes on netgroup lookups

[Arthur de Jong]

On Wed, 2015-10-14 at 07:56 +, Mike Gabriel wrote:
> The Debian Edu team heavily relies on NIS netgroups coming from
> LDAP. So any help with this in Debian jessie is highly appreciated!!!

The last time I looked at nscd code I was not very happy ;) Also, nscd
has a long history of instability and returning incorrect results.

I think there are a few options:

- Backport the fixes mentioned in #800523 and hope that they fix the
  issues seen and don't introduce many new regressions. Not sure this
  is suitable for stable (you'd have to ask the release team). This
  needs extensive testing in any case.
- Disable netgroup caching in nscd. While this is the safest option it
  is sub-optimal because it causes a performance hit. Then again, I
  don't think the number of netgroup calls are huge: some mount ACLs,
  .rhosts logins (does anybody use those any more) and some special
  handing using the compat provider for /etc/passwd and /etc/group.
- Switching to unscd is probably equivalent to disabling netgroup
  caching because I don't think it has netgroup support.

Btw, if anyone thinks this is something that libnss-ldapd does wrong,
please let me know. Not all NSS interfaces are consistent in terms of
memory management, return codes, etc. so there could be something
wrong.

I've been playing a bit with the sid version (2.19-22) but I havent
found an easy way to trigger the original crash I reported in #737079.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#801217: modplugtools: Please reference shuf instead of randomize-lines

[Arthur de Jong]

On Thu, 2015-10-08 at 09:24 +0200, gurkan wrote:
> Here?
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799414
> Either wrong bug number, or I look at the wrong place?

Sorry, indeed wrong bug number, please see #801171:
  https://bugs.debian.org/801171

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#801171: Please remove this package

[Arthur de Jong]

Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: randomize-lines -- ROM; deprecated, replaced by shuf

On Wed, 2015-10-07 at 09:19 +0200, martin f krafft wrote:
> Since this is deprecated and the shuf coreutil replaces it
> adequately, please reassign this bug to ftp.debian.org and retitle
> it into a removal request.

Good point. Since randomize-lines works, has not seen any bug reports
or required any work in ages and had a reasonable popcon rating for a
long time I've been holding off on removing it. Also it being one of my
first open source projects probably had something to do with it ;)

Anyway, please remove randomize-lines. Shuf is at least smarter with
large files and is a decent replacement (I think rl still is faster in
some scenarios). There is one reverse Suggests in modplugtools because
it is referenced in a manual page (filed #801217 for that).

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#801217: modplugtools: Please reference shuf instead of randomize-lines

[Arthur de Jong]

Source: modplugtools
Version: 0.5.3-1.1
Severity: normal
Tags: patch

Since randomize-lines is about to be removed (see #799414) the
modplugplay manual page should probably reference shuf instead of rl
for playing modules in random order.

Attached is a patch with the relevant changes.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --

diff -Nru modplugtools-0.5.3/debian/changelog modplugtools-0.5.3/debian/changelog
--- modplugtools-0.5.3/debian/changelog	2014-10-14 22:59:38.0 +0200
+++ modplugtools-0.5.3/debian/changelog	2015-10-07 16:23:12.0 +0200
@@ -1,3 +1,10 @@
+modplugtools (0.5.3-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Replace randomize-lines with shuf from coreutils.
+
+ -- Arthur de Jong   Wed, 07 Oct 2015 16:22:35 +0200
+
 modplugtools (0.5.3-1.1) unstable; urgency=low
 
   * NMU
diff -Nru modplugtools-0.5.3/debian/control modplugtools-0.5.3/debian/control
--- modplugtools-0.5.3/debian/control	2011-05-03 15:03:31.0 +0200
+++ modplugtools-0.5.3/debian/control	2015-10-07 16:23:22.0 +0200
@@ -9,7 +9,6 @@
 Package: modplug-tools
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Suggests: randomize-lines
 Description: Modplug playing console tools
  These are command line players for the following module formats:
  669, amf, ams, dbm, dmf, dsm, far, it, j2b, mdl, med mod, mt2, mtm, okt,
diff -Nru modplugtools-0.5.3/debian/modplugplay.1 modplugtools-0.5.3/debian/modplugplay.1
--- modplugtools-0.5.3/debian/modplugplay.1	2011-02-21 16:45:55.0 +0100
+++ modplugtools-0.5.3/debian/modplugplay.1	2015-10-07 16:24:10.0 +0200
@@ -25,9 +25,8 @@
 .IP "\fB+\fP   louder"
 .IP "\fB-\fP   softer"
 .SH EXAMPLES
-You can play your modules in random order using the help of
-randomize-lines, with this command
-.IP "modplugplay `ls|rl`"
+You can play your modules in random order with this command
+.IP "modplugplay `ls|shuf`"
 
 or
 .IP "modplugplay `ls *.mod | iselect -am`"


signature.asc
Description: This is a digitally signed message part

Bug#798942: Does not fail over to another server when server is unwilling to perform

[Arthur de Jong]

On Mon, 2015-09-14 at 12:41 +0200, Bernhard Schmidt wrote:
> Due to a local configuration error we had a new slapd deployed on a
> server that requires authentication (our normal servers don't, yet). 
> nslcd tried to connect to the server (which was unwilling to perform) 
> but did not fail over to the other servers.

nslcd only fails over for errors that indicate a problem connecting to
the server. The "unwilling to perform" error only shows up after the
search operation was already started (e.g. BIND was successful) and
when getting the results.

> I think "unwilling to perform" can has other causes as well and 
> should trigger a failover to another server.

This can be fixed by adding LDAP_UNWILLING_TO_PERFORM to end of the
 myldap_get_entry() function in myldap.c. I will see if this can be
added in a portable way (I'm not 100% sure that it is available on all
supported platforms).

Also, there could be some cases where retry-ing this would hide real
configuration errors.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#799414: nss-pam-ldapd: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Arthur de Jong]

Control: tags -1 + pending

On Fri, 2015-09-18 at 20:50 -0300, Adriano Rafael Gomes wrote:
> Please, Could you update the Brazilian Portuguese Translation?
> 
> Attached you will find the file pt_BR.po. It is UTF-8 encoded and it 
> is tested with msgfmt and podebconf-display-po.

Thanks for the updated translation. It will be in the next upload.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part

Bug#785053: jessie-pu: package nss-pam-ldapd/0.9.4-3+deb8u1

[Arthur de Jong]

On Sat, 2015-08-29 at 15:26 +0200, Julien Cristau wrote:
> Sorry for the delay in getting back to you.
> 
> Please feel free to upload 0.9.4-3+deb8u1.

Thanks. In the meantime, two more bugs arose in nss-pam-ldapd that I
would like to fix in jessie.

The first (#794686) is an RC bug with a one-line fix. The problem was
that the exit code of the init script was wrong in some cases.

I would also like to get #794068 fixed. This fixes password policy
expiration. Instead of forcing the user to change their password, a
warning message should be presented to the user instead. I have just
uploaded the fix to unstable.

Attached is a debdiff with the changes.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --
diff -Nru nss-pam-ldapd-0.9.4/debian/changelog nss-pam-ldapd-0.9.4/debian/changelog
--- nss-pam-ldapd-0.9.4/debian/changelog	2014-09-28 15:08:58.0 +0200
+++ nss-pam-ldapd-0.9.4/debian/changelog	2015-08-30 13:58:54.0 +0200
@@ -1,3 +1,14 @@
+nss-pam-ldapd (0.9.4-3+deb8u1) stable; urgency=low
+
+  * fix-issues-withdaemonising.patch, avoid-signal-race.patch: patches to
+fix issues with daemonising nslcd and avoid a race condition in signal
+handling during start-up (closes: #759544)
+  * ensure proper return code of init script (closes: #794686)
+  * fix-ppolicy-expiration-warnings.patch: fix password policy expiration
+warnings (closes: #794068)
+
+ -- Arthur de Jong   Sun, 30 Aug 2015 13:00:00 +0200
+
 nss-pam-ldapd (0.9.4-3) unstable; urgency=low
 
   * use-ip-range-for-tests.patch: use a different IP range for running the
diff -Nru nss-pam-ldapd-0.9.4/debian/nslcd.init nss-pam-ldapd-0.9.4/debian/nslcd.init
--- nss-pam-ldapd-0.9.4/debian/nslcd.init	2014-06-08 00:33:57.0 +0200
+++ nss-pam-ldapd-0.9.4/debian/nslcd.init	2015-08-30 13:53:17.0 +0200
@@ -174,5 +174,3 @@
   exit 1
   ;;
 esac
-
-exit 0
diff -Nru nss-pam-ldapd-0.9.4/debian/patches/avoid-signal-race.patch nss-pam-ldapd-0.9.4/debian/patches/avoid-signal-race.patch
--- nss-pam-ldapd-0.9.4/debian/patches/avoid-signal-race.patch	1970-01-01 01:00:00.0 +0100
+++ nss-pam-ldapd-0.9.4/debian/patches/avoid-signal-race.patch	2015-08-30 11:19:41.0 +0200
@@ -0,0 +1,71 @@
+From: Arthur de Jong 
+Subject: Avoid signal race condition on start-up
+
+This only restores the signal mask after signal handlers are in place
+and the daemon has completely daemonised to avoid a race condition in
+the start-up phase of nslcd where a signal could be sent to nslcd
+causing it to quit or fail to write information to the parent process.
+
+This also block signals sooner in an attempt to avoid race conditions.
+
+Origin: upstream, http://arthurdejong.org/git/nss-pam-ldapd/commit/?id=1d3b19b1ecd3b10f36e8925e8a752a28e3e74b56
+Origin: upstream, http://arthurdejong.org/git/nss-pam-ldapd/commit/?id=530cc24c83dd5d2d347acb40d64c3ae06a43a293
+Bug-Debian: http://bugs.debian.org/759544
+
+--- a/nslcd/nslcd.c
 b/nslcd/nslcd.c
+@@ -648,6 +648,17 @@ int main(int argc, char *argv[])
+ #ifdef HAVE_PTHREAD_TIMEDJOIN_NP
+   struct timespec ts;
+ #endif /* HAVE_PTHREAD_TIMEDJOIN_NP */
++  /* block all these signals so our worker threads won't handle them */
++  sigemptyset(&signalmask);
++  sigaddset(&signalmask, SIGHUP);
++  sigaddset(&signalmask, SIGINT);
++  sigaddset(&signalmask, SIGQUIT);
++  sigaddset(&signalmask, SIGABRT);
++  sigaddset(&signalmask, SIGPIPE);
++  sigaddset(&signalmask, SIGTERM);
++  sigaddset(&signalmask, SIGUSR1);
++  sigaddset(&signalmask, SIGUSR2);
++  pthread_sigmask(SIG_BLOCK, &signalmask, &oldmask);
+   /* close all file descriptors (except stdin/out/err) */
+   daemonize_closefds();
+   /* parse the command line */
+@@ -785,17 +796,6 @@ int main(int argc, char *argv[])
+ }
+ log_log(LOG_DEBUG, "setuid(%d) done", (int)nslcd_cfg->uid);
+   }
+-  /* block all these signals so our worker threads won't handle them */
+-  sigemptyset(&signalmask);
+-  sigaddset(&signalmask, SIGHUP);
+-  sigaddset(&signalmask, SIGINT);
+-  sigaddset(&signalmask, SIGQUIT);
+-  sigaddset(&signalmask, SIGABRT);
+-  sigaddset(&signalmask, SIGPIPE);
+-  sigaddset(&signalmask, SIGTERM);
+-  sigaddset(&signalmask, SIGUSR1);
+-  sigaddset(&signalmask, SIGUSR2);
+-  pthread_sigmask(SIG_BLOCK, &signalmask, &oldmask);
+   /* start worker threads */
+   log_log(LOG_INFO, "accepting connections");
+   nslcd_threads = (pthread_t *)malloc(nslcd_cfg->threads * sizeof(pthread_t));
+@@ -815,8 +815,7 @@ int main(int argc, char *argv[])
+   exit(EXIT_FAILURE);
+ }
+   }
+-  pthread_sigmask(SIG_SETMASK, &oldmask, NULL);
+-  /* install signalhandlers for some signals */
++  /* install signal handlers for some signals */
+   install_sighandler(SIGHUP, sig_handler);
+   install_sighandler(SIGINT, sig_handler);
+   install_sighandler(SIGQUIT, sig_handler);
+@@ -827,6 +

Bug#794068: AW: Bug#794068: libpam-ldapd: unable to login when ldap-server sends password expiration warning

[Arthur de Jong]

On Mon, 2015-08-17 at 09:06 +, Uibel, Joerg wrote:
> Thank you for the upstream fix. While I realize that you prefer to 
> get a whole new upstream release into jessie, I wonder if there's any 
> reason not to backport the relevant changes [1-3] to the nss-pam
> -ldapd_0.9.4-3 source? I rebuilt the package with these patches 
> applied on my test system and it seems to work just fine.

The changes for this fix can be easily backported (same for #794686).
However, the changes for fixing #759544 (the original reason for making
a new jessie version) are a little more involved. The daemonizing code
in 0.9.5 has seen much more testing than that of a patched 0.9.4
version.

Anyway, I'll see if I can ping the release team again.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#794068: libpam-ldapd: unable to login when ldap-server sends password expiration warning

[Arthur de Jong]

Control: tags -1 + fixed-upstream

On Thu, 2015-07-30 at 09:22 +, Uibel, Joerg wrote:
> I'm using the OpenLDAP password policy overlay on my ldap-servers to
> implement password expiration. The attribute pwdExpireWarning is set 
> to 10 days.
> Unfortunately it doesn't only print a warning to the user when his 
> password is about to expire, but also prevents him from logging in, 
> even if the password has not expired yet!
> 
> This problem is already described in the nss-pam-ldapd-users 
> mailinglist:
>  http://lists.arthurdejong.org/nss-pam-ldapd-users/2015/msg00088.html

This has just been fixed upstream and will be part of the next upstream
release.

This could be fixed in jessie without too much effort. I've been
working on a new version of jessie (https://bugs.debian.org/785053) but
have had little response from the release team so far.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#794686: nslcd start script does not report starting failure

[Arthur de Jong]

Control: tags -1 + pending

On Wed, 2015-08-05 at 20:02 +0300, Nikolay Shaplov wrote:
> Package: nslcd
> Version: 0.9.4-3
> Severity: serious
> Justification: fails to build from source

Justification is not right but the init script return code is not
according to policy so I'll leave it at serious.

> # /etc/init.d/nslcd stop
> [ ok ] Stopping nslcd (via systemctl): nslcd.service.
> # /etc/init.d/nslcd start
> [ ok ] Starting nslcd (via systemctl): nslcd.service.
> 
> It does not report any problem, not to the console, not to the syslog

It does report a problem to stderr but systemd seems to hide it when
the return code is 0 (that was incorrect).

The fix is to remove the last "exit 0" from /etc/init.d/nslcd.

Thanks for reporting this.

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#792871: python-daemon: signal_map handling wrong

[Arthur de Jong]

Package: python-daemon
Version: 2.0.5-1
Severity: important
Tags: patch

If you initialise DaemonContext with a signal_map as documented you get
the following:

>>> import daemon, signal
>>> with daemon.DaemonContext(signal_map={signal.SIGTERM: 'terminate'}):
... pass
... 
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/daemon/daemon.py", line 380, in 
__enter__
self.open()
  File "/usr/lib/python2.7/dist-packages/daemon/daemon.py", line 362, in open
set_signal_handlers(signal_handler_map)
  File "/usr/lib/python2.7/dist-packages/daemon/daemon.py", line 883, in 
set_signal_handlers
signal.signal(signal_number, handler)
TypeError: signal handler must be signal.SIG_IGN, signal.SIG_DFL, or a callable 
object

As a workaround, you can pass a unicode string (u'terminate').

The attached patch uses basestring instead of unicode for comparison
which ensures that the correct terminate handler is installed as
documented.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-daemon depends on:
ii  python-docutils   0.12+dfsg-1
ii  python-lockfile   1:0.10.2-2
ii  python-pkg-resources  17.0-1
pn  python:any

python-daemon recommends no packages.

python-daemon suggests no packages.

-- no debconf information

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --
Description: fix handling of signal_map values
 This fixes the case where a non-unicode 'termniate' string is passed 
 via the signal_map argument to the DaemonContext constructor.
 The reason this appears to work in the tests is due to
 from __future__ import unicode_literals
Author: Arthur de Jong 

--- a/daemon/daemon.py
+++ b/daemon/daemon.py
@@ -483,7 +483,7 @@ class DaemonContext:
 """
 if target is None:
 result = signal.SIG_IGN
-elif isinstance(target, unicode):
+elif isinstance(target, basestring):
 name = target
 result = getattr(self, name)
 else:


signature.asc
Description: This is a digitally signed message part

Bug#788084: python-stdnum: Please use a maintained soap library instead of deprecated python-suds.

[Arthur de Jong]

Control: forcemerge 774948 788084
Control: tags 774948 + fixed-upstream
Control: tags 774948 + pending

your package is listed as a Reverse Depend of the python-suds
> package, which is now deprecated due to long time missing upstream
> maintenance as well as missing compatibility for Python3 (#783029,
> #774948, #782970). It is planned to remove python-suds before the
> release of stretch.
> 
> Please consider to migrate your package to use a maintained soap
> library (like pysimplesoap, at the time of writing in NEW).

This is a duplicate of #774948. Upstream now supports pysimplesoap
(which still isn't in unstable) as an alternative to suds:
http://arthurdejong.org/git/python-stdnum/commit/?id=a1a134e91b0ca3ccdff69929c4555c62e10c8714

Again, the SOAP functionality is only a minor part of python-stdnum
which is why suds is only suggested.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#783644: python-stdnum: new feature: EU VAT VIES check _with_ proof (certificate)

[Arthur de Jong]

Control: tags -1 + pending

On Tue, 2015-04-28 at 23:02 +0200, Lionel Elie Mamane wrote:
> I'm not eager for a single function to return differently structured
> data depending on an argument that does not look like it should
> influence this part of the structure. Having two functions emphasises
> the difference..

Sorry for not responding sooner. I've finally got around to looking
into this and I've merged your patch upstream with a few small tweaks.

I did rename the function to check_vies_approx to match the name used
in VIES a little better.

See:
http://arthurdejong.org/git/python-stdnum/commit/?id=8fe44f98a0d8709912ddf7fc383c14d72472d819

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#789616: [Evolution] Bug#789616: evolution-plugins: Face header too long

[Arthur de Jong]

Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=751462

On Wed, 2015-06-24 at 13:32 +0200, Emilio Pozuelo Monfort wrote:
> Thanks for the patch. Can you please send it upstream and let us know
> the bug url?

Sure. I put the relevant details and patch here:
https://bugzilla.gnome.org/show_bug.cgi?id=751462

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#789616: evolution-plugins: Face header too long

[Arthur de Jong]

Control: reassign -1 evolution-data-server 3.16.3-1
Control: tags -1 + patch

On Mon, 2015-06-22 at 21:31 +0200, Arthur de Jong wrote:
> which means the first line ends up as 1003 characters. While this
> technically may be a bug in that software it is probably much easier 
> to work around this in evolution than it is to fix all the deployed 
> mail systems out there.

Attached is a quilt patch that seems to work for me (also see face
header in this mail). The patch is for the evolution-data-server
package.

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --
Description: Protect header wrapping against reflowing
 This changes the line wrapping of headers to ensure that the first line 
 of rewrapped headers do not just consist of the header name but instead 
 contains the first bit of the value.
 .
 This ensures that programs that rewrap or reflow headers (such as 
 mailman) do not accidentally result in headers that are longer than 
 998 characters.
Author: Arthur de Jong 
Bug-Debian: https://bugs.debian.org/789616

--- a/camel/camel-mime-utils.c
+++ b/camel/camel-mime-utils.c
@@ -5236,12 +5236,9 @@ camel_header_fold (const gchar *in,
 g_string_truncate (out, out->len - 1);
 g_string_append_c (out, '\n');
 g_string_append_c (out, spc);
-			} else {
-g_string_append (out, "\n\t");
+outlen = 1;
 			}
 
-			outlen = 1;
-
 			/* check for very long words, just cut them up */
 			while (outlen + len > CAMEL_FOLD_MAX_SIZE) {
 tmplen = CAMEL_FOLD_MAX_SIZE - outlen;


signature.asc
Description: This is a digitally signed message part

Bug#785053: jessie-pu: package nss-pam-ldapd/0.9.4-3

[Arthur de Jong]

On Thu, 2015-06-04 at 21:04 +0200, Arthur de Jong wrote:
> On Mon, 2015-05-11 at 23:12 +0200, Arthur de Jong wrote:
> > I would like to fix #759544 in jessie.
> 
> Just to clarify, #759544 seems to affect people who use systemd and
> network-manager together with nslcd. The bug is a race condition in
> nslcd that results in a failed start-up of nslcd which means LDAP 
> users are not able to log in.

Hi,

Apparently my mails to this bug never ended up on the debian-release
list so I'd like to re-raise this issue. See the BTS for more details
and debdiffs.

Please let me know what you think.

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#789616: evolution-plugins: Face header too long

[Arthur de Jong]

On Mon, 2015-06-22 at 19:55 +0200, Arthur de Jong wrote:
> When using the face plugin to configuring an image, a Face header is
> added to outgoing email. For common sizes of images this results in
> lines that are too long.
> 
> RFC 2822 section 2.1.1 specifies the maximum line length to be 998.

It seems that Evolution correctly creates the header with wrapped
headers as:

  Face:
  ... 997 more characters ...
  ...

However, some mail handling software (at least mailman and apparently
also the Debian list software) seems to rewrite the header resulting in
the following:

  Face:... 997 more characters ...
  ...

which means the first line ends up as 1003 characters. While this
technically may be a bug in that software it is probably much easier to
work around this in evolution than it is to fix all the deployed mail
systems out there.

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#789616: evolution-plugins: Face header too long

[Arthur de Jong]

Package: evolution-plugins
Version: 3.16.3-1
Severity: important

When using the face plugin to configuring an image, a Face header is
added to outgoing email. For common sizes of images this results in
lines that are too long.

RFC 2822 section 2.1.1 specifies the maximum line length to be 998.

This resulted in some of my mails to be silently dropped.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages evolution-plugins depends on:
ii  evolution3.16.3-1
ii  libc62.19-18
ii  libcamel-1.2-52  3.16.3-1
ii  libcanberra0 0.30-2.1
ii  libebook-1.2-16  3.16.3-1
ii  libebook-contacts-1.2-1  3.16.3-1
ii  libecal-1.2-18   3.16.3-1
ii  libedataserver-1.2-203.16.3-1
ii  libevolution 3.16.3-1
ii  libgdk-pixbuf2.0-0   2.31.4-2
ii  libglib2.0-0 2.44.1-1
ii  libgtk-3-0   3.16.4-2
ii  libical1a1.0-1.3
ii  libnotify4   0.7.6-2
ii  libpst4  0.6.59-1
ii  libxml2  2.9.2+dfsg1-3

Versions of packages evolution-plugins recommends:
ii  cinnamon [notification-daemon]  2.6.8-1
ii  gnome-shell [notification-daemon]   3.16.2-4
ii  mate-notification-daemon [notification-daemon]  1.8.2-2
ii  notification-daemon 3.17.2-2
ii  xfce4-notifyd [notification-daemon] 0.2.4-3+b1

evolution-plugins suggests no packages.

-- no debconf information

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#780320: nslcd group queries not working in jessie

[Arthur de Jong]

On Fri, 2015-05-22 at 21:44 +0200, Torsten Landschoff wrote:
> Any hint how this can be fixed? I'd be up to patch the source and build 
> a new package for our local systems.

Could you provide the relevant bits of nslcd.conf (leave out any
passwords) and output from nslcd -d when the error occurs?

Also, can you provide more information on which LDAP server is used?

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#759544: please fix in jessie

[Arthur de Jong]

On Sun, 10 May 2015, Meik Hellmund wrote:
Please provide a patched version of nslcd for jessie-updates. I just 
upgraded a larger installation of Debian servers and desktop clients to 
jessie and was bitten by this bug.


Progress on getting this fixed in jessie can be tracked at
https://bugs.debian.org/785053

Thanks,

--
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#785053: jessie-pu: package nss-pam-ldapd/0.9.4-3

[Arthur de Jong]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

I would like to fix #759544 in jessie.

There is a fix already in 0.9.5-2 in testing and unstable
(avoid-signal-race.patch as seen in the package).

I see a couple of ways to solve this:

- prepare 0.9.4-3+deb8u1

  This will require backporting the patch from 0.9.5-2 and a few related
  changes that ended up in 0.9.5 upstream. This would introduce the
  least number of changes but the biggest downside of this is that it
  will be a new, less tested combination of changes compared to the
  other solutions.

- prepare 0.9.5-2~deb8u1

  This will be based on the current version in testing and is probably
  the most stable and well tested version currently available that
  includes the fix. The 0.9.5 release otherwise mostly contains small
  fixes. The only new feature is adjusting the Out-Of-Memory killer.
  Making the module name configurable at build time results in a bit of
  a diff but impact should be limited.

- prepare 0.9.6-1~deb8u1

  The new (to be released) upstream version will include the fix but
  also includes a number of new features.

I think 0.9.5-2~deb8u1 would result in the best overall quality of the
package in stable but 0.9.4-3+deb8u1 would result in a smaller debdiff.

Please let me know what you think.

Thanks,

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#783644: python-stdnum: new feature: EU VAT VIES check _with_ proof (certificate)

[Arthur de Jong]

On Tue, 2015-04-28 at 19:09 +0200, Lionel Elie Mamane wrote:
> Please add a new function to stdnum.eu.vat so that when one does a
> VIES VAT number check, one gets a proof (certificate) that one did the
> check, as defence against the VAT administration later putting this in
> doubt. This certificate is provided by the VIES service, if one
> provides one's own VAT number.

Thanks for the patch. What do you think about combining it in one
function (see attachment)? I would like to include this upstream.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#640774: Stopping nslcd no longer

[Arthur de Jong]

On Fri, 2015-04-17 at 19:28 +0200, أحمد المحمودي wrote:
> Please find /etc/pam.d/common-auth attached.

I have been playing around with pam_ccreds and I think the bug is in
that package or a configuration mix-up.

Anyway, if I disable shadow lookups via ldap in /etc/nsswitch.conf I got
it to work, otherwise the PAM stack fails with:

authpriv.err su[9407]: pam_acct_mgmt: Authentication failure

which seems to indicate that something is going wrong in the account
(authorisation) part of PAM. I've added debug to pam_unix and pam_ldap
in /etc/pam.d/common-account but neither module seems to be logging
anything.

Without shadow lookups via LDAP at least pam_ldap logs in the account
check that it can't connect to nslcd if it is not running. Also, now
login works (but slow) if nslcd is still running but the LDAP server is
reachable.

Some background on the intricacies of the PAM stack can be found here:
https://bugs.debian.org/583492

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#774948: python3-stdnum: stdnum.eu.vat.check_vies needs suds

[Arthur de Jong]

Control: severity -1 normal
Control: tags -1 + help

On Fri, 2015-01-09 at 12:40 +0100, Lionel Elie Mamane wrote:
> ImportError: No module named 'suds'
> 
> An Internet search suggests suds itself is not available for Python3,
> but there seems to be several forks that are.

A while back I did some research into SOAP libraries for Python and was
a bit disappointed with the support available (that was specifically for
providing a SOAP server).

From the SOAP libraries available in Debian it seemed that SUDS was the
easiest to use. From a quick search I can't find any Python SOAP library
for Python3.

I'm lowering severity because this affects only a minor bit of
python-stdnum.

Anyway, patches to support more or other SOAP libraries are more than
welcome.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#705568: libpam-ldapd: LDAP Authentication failure with cached credentials

[Arthur de Jong]

On Wed, 2015-04-15 at 19:13 +0200, أحمد المحمودي wrote:
> In 0.9.4-3 revision, Account-Type is Primary, so I applied your
> changes for the Account: entry, yet neither local nor LDAP users can
> login (even if LDAP server is reachable), and I found the following
> in /var/log/auth.log:
> 
> Apr 15 18:40:22 myhostname login[13808]: PAM pam_parse: expecting non-zero; 
> [... new_authtok_reqd=done ignore=ignore user_unknown=ignore 
> authinfo_unavail=0 default=bad]

authinfo_unavail=0 is not valid. You should probably specify
authinfo_unavail=ignore or something else depending on how you want your
PAM stack to look.

If you provide your full /etc/pam.d/common-account file, I can have a
look. Also, please clarify which changes you made to which file.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#640774: Stopping nslcd no longer

[Arthur de Jong]

On Wed, 2015-04-15 at 19:07 +0200, أحمد المحمودي wrote:
> I am experiencing the issue of login failure with cached credentials,
> yet stopping nslcd no longer helps, rather I get this
> in /var/log/auth.log:
> Apr 15 18:19:42 myhostname login[13342]: pam_ldap(login:auth): error opening 
> connection to nslcd: No such file or directory

Could you provide the contents of /etc/pam.d/common-auth?

The default configuration has
  auth [success=1 default=ignore] pam_ldap.so minimum_uid=1000 use_first_pass
which is supposed to ignore PAM_AUTHINFO_UNAVAIL and continue with the
next PAM module.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#782652: nslcd: Does not start at boot when uri set to DNS

[Arthur de Jong]

On Wed, 2015-04-15 at 18:36 +0200, أحمد المحمودي wrote:
> This bug might be related to #626603

It could be related. In general, if nslcd is started before DNS is
available, it can have issues with lookups. The DNS option for uri makes
this especially problematic because a DNS lookup is performed at
start-up (when reading the configuration file) to find the LDAP servers.

I'm not sure if the dependencies in the LSB headers in the init script
are correctly honoured by systemd and I've found that especially when
using network-manager DNS availability during boot it is very
undeterministic.

It would be nicer if nslcd could lookup the SRV records on the first
search (and possibly refresh them once in a while).

Patches welcome ;)

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#782554: libpam-ldapd: pam-configs/ldap should consult /etc/login.defs for UID_MIN setting

[Arthur de Jong]

On Tue, 2015-04-14 at 15:28 +0930, Phil Nitschke wrote:
> We inherited a legacy system where user's UIDs are less than 1000.
> We set the UID_MIN value in /etc/login.defs, but whenever libpam-ldapd is
> updated, it specifies minimum_uid=1000 and users cannot log in.

I also manage a legacy system with uid below 1000. We have made
modifications to minimum_uid in /etc/pam.d/common-* and have not seen
any changes on upgrades. The pam-auth-update command is supposed to keep
manual changes to those files intact.

> I suggest having the postinst script run a couple tests, e.g.
> 
> MINUID=`grep "^UID_MIN" /etc/login.defs | awk '{print $2}'`
> 
> Then if $MINUID != 1000, use it to update the values in /usr/share/pam-
> configs/ldap, prior to running pam-auth-update.

I don't think the postinst is allowed to modify files under /usr so this
would quickly turn into something ugly with a symlink.

Perhaps it is possible to modify minimum_uid in /etc/pam.d/common-* from
the postinst but this also sounds very fragile to me.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#759544: nslcd: fails 'sometimes' to start at boot (systemd?)

[Arthur de Jong]

Control: found -1 nss-pam-ldapd/0.9.1-1
Control: tags + pending

On Mon, 2015-04-13 at 15:36 +0200, Bernhard Schmidt wrote:
> I still think it is caused by a race between the ifupdown trigger and
> nslcd startup.

Thanks for prodding me about this. I've spent some more time trying to
track this down and I managed to find a reproducible scenario with some
tweaking (introducing sleeps at strategic places in the code and keep
firing signals at nslcd).

The problem was caused by a race condition in the start-up code
regarding signal handling. It should be fixed in:
http://arthurdejong.org/git/nss-pam-ldapd/commit/?id=530cc24c83dd5d2d347acb40d64c3ae06a43a293

A work-around for people experiencing this issue would be to comment out
the kill-line in /etc/network/if-up.d/nslcd.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#780320: nslcd: Fails to return group names

[Arthur de Jong]

On Wed, 2015-03-11 at 19:27 -0600, Daniel Fussell wrote:
> Running nslcd on sid generally works, but is not able to get group
> names from ldap, reporting the following errors when requesting
> information on a user with the id command:
> 
> nslcd: [9478fe] DEBUG: connection from pid=2735 uid=2345 gid=4274
> nslcd: [9478fe]  DEBUG: 
> myldap_search(base="ou=groups,ou=, 
> dc=,dc=,dc=", 
> filter="(&(objectClass=posixGroup)(gidNumber=1217))")
> nslcd: [9478fe]  ldap_result() failed: Protocol error: paged 
> results control could not be decoded
[...]
> Installing nslcd from wheezy and running "nslcd -d" shows all queries working 
> with the same nslcd.conf, and all names resolve properly.

Can you provide some information on the LDAP server used?

The only relevant difference I can think of between 0.8 and 0.9 versions
of nss-pam-ldapd is that 0.9 requests an additional control from the
LDAP server for group queries. This is currently not configurable
because the LDAP server is supposed to ignore controls it doesn't
understand.

If you are not using the member attribute in group searches you could
set
  map group member ""
as a workaround in nslcd.conf to disable member attribute expansion
altogether.

Kind regards,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#780284: nss-pam-ldapd: Descriptions do not explain why to use this over lib{pam, nss}-ldap

[Arthur de Jong]

Control: tags -1 + help

On Wed, 2015-03-11 at 12:23 -0400, Samuel Bronson wrote:
> The descriptions of your binary packages do not describe the key
> advantage that your modules provide over the "reference"
> implementation, which is summarized by one of your users thus:
> 
>   libnss-ldapd is a fresh implementation written by Arthur de
>  Jong, which doesn't install TLS and LDAP libraries into every single
>  running program
> 
>   Instead [it] loads a shim that talks over a socket to nslcd, a
>  dedicated daemon.
> 
> He thinks maybe you meant to be modest in your descriptions, but IMO
> this would be a silly reason not to mention reasons one might (or
> might not) prefer a package over its competitors.

Improvements to the description are more than welcome ;) Some more
information can be found here:
  http://arthurdejong.org/nss-pam-ldapd/

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#759544: nslcd: fails 'sometimes' to start at boot (systemd?)

[Arthur de Jong]

On Wed, 2015-03-04 at 16:59 +0100, Rike-Benjamin Schuppner wrote:
> On Sun, 04 Jan 2015 00:42:42 +0100 Bernhard Schmidt 
>  wrote:
> > This sounds like 
> > http://arthurdejong.org/git/nss-pam-ldapd/commit/?id=1d3b19b1ecd3b10f36e8925e8a752a28e3e74b56
> > could help here. Unfortunately I wasn't able to reproduce the problem
> > so testing the patch won't help.
> 
> No luck with this patch for me. Still getting the ‘unable to daemonize’ 
> messages in the log. Of course it would be more helpful, if the nslcd 
> daemon would be able to give a better error code to systemd.

Thanks for providing your test feedback.

Could you also test
http://arthurdejong.org/git/nss-pam-ldapd/commit/?id=a726d291b0f6794abec0a0192cf2b2a742648e4a
to see if that helps. It should give a little more information on why
start-up failed.

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#759544: Bug#772342: debian-edu-config: mounting homedirs via NFS doesn't work reliably

[Arthur de Jong]

tags 759544 + help
thanks

On Wed, 2014-12-10 at 22:32 +0100, Holger Levsen wrote:
> Raising the severity of 759544 as 20% failure rate surely has a "major impact 
> on the usuability of the package"...
> 
> Please see 772342 to learn how 759544 affects debian-edu-config.

Any help in tracking this down is highly appreciated. Since I've
switched to putting network configuration into /etc/network/interfaces
and ignoring network-manager my setup with NFS and nslcd is not failing
during boot.

I've seen two issues with nslcd start-up:
- one that logs "unable to daemonize" in some cases (the patches
  mentioned earlier in this bug report may fix this)
- one when using TLS (also see https://bugs.debian.org/643948)

Also nslcd is supposed to be started after networking has been brought
up (LSB headers) but this doesn't seem to work in all cases.
Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#759544: nslcd: fails 'sometimes' to start at boot (systemd?)

[Arthur de Jong]

On Fri, 2014-08-29 at 17:22 +0200, Andreas B. Mundt wrote:
> Hm. Any other hints how to pin down the issue?

Sorry to not get back to you sooner. Can you try these patches:

http://arthurdejong.org/git/nss-pam-ldapd/commit/?id=a726d291b0f6794abec0a0192cf2b2a742648e4a
http://arthurdejong.org/git/nss-pam-ldapd/commit/?id=1d3b19b1ecd3b10f36e8925e8a752a28e3e74b56

Thanks,

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Bug#760287: please set nslcd as preferred provider of nslcd-2

[Arthur de Jong]

Control: tags -1 + pending

On Tue, 2014-09-02 at 08:13 -0700, Ryan Tandy wrote:
> With two providers of nslcd-2 and no preferred one declared, apt-get (at 
> least on two systems of mine) chooses pynslcd instead of nslcd.
> 
> Please consider changing the nslcd-2 dependency to 'nslcd | nslcd-2', at 
> least while pynslcd still carries the big EXPERIMENTAL warning.

Thanks, very good point. I'll upload a new version soon that adds this
preferred dependency.

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part