Discussion:
[Ltsp-discuss] Getent Problem on Ubuntu 16.04
John Halfpenny
2016-12-22 15:27:52 UTC
Permalink
Hi Everyone

We've been running LTSP for a while now on Ubuntu 14.04, and I'm in the
process of upgrading to 16.04.

Our server connects to Windows using kerberos, samba and nslcd to map
attributes to their unix counterparts. This works well, and allows me to
login to a client using Windows credentials and map the drive locally.

However, on Ub1404, to map the home directory I run a script which uses
getent, and the returned string is, e.g. \\server\share\share\username

But on Ub1604, getent does not return this properly, but instead removes
the slashes, e.g. \servershareshareusername

If I run getent on the LTSP server, it works, but not on the client.

I've never seen this before. When I strace getent from the client, it
doesn't even seem to query nsswitch, whereas it does from the server.

e.g. from client:

$ strace -e open getent passwd testac
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
testac:x:2660:513:***@domain.ac.uk
,,,\servershareshareusername:/opt/ltsphome/testac:/bin/bash
+++ exited with 0 +++

But from the server it seems more comprehensive:

$ strace -e open getent passwd testac
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/etc/passwd&
quot;, O_RDONLY|O_CLOEXEC) = 3
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libnss_ldap.so.2", O_RDONLY|O_CLOEXEC) = 3
testac:x:2660:513:***@domain.ac.uk
,,,\\server\share\share\username:/opt/ltsphome/testac:/bin/bash
+++ exited with 0 +++

I know authentication can be one of those tricky subjects, but I don't
personally feel that this is the issue here, whereas the weird behaviour of
getent is. If anyone has any clues or pointers I'd be very grateful,
everything else seems to be working fine.

Best Wishes
John
Alkis Georgopoulos
2016-12-22 22:18:16 UTC
Permalink
Hi John,

open ($CHROOT)/usr/share/ldm/rc.d/X01-localapps
find 2 "read" commands in lines 36 and 46
and replace them with "read -r" so that it doesn't interpret the
backslashes.

I.e.:
IFS=':' read -r LDM_USERNAME dummy pw_uid pw_gid pw_gecos LDM_HOME
pw_shell <<EOF
and:
while IFS=':' read -r gr_name dummy gr_gid dummy; do

If that works, file a bug report in https://bugs.launchpad.net/ltsp/ so
that I can commit the fix.

Cheers,
Alkis Georgopoulos
LTSP developer
Post by John Halfpenny
Hi Everyone
We've been running LTSP for a while now on Ubuntu 14.04, and I'm in the
process of upgrading to 16.04.
Our server connects to Windows using kerberos, samba and nslcd to map
attributes to their unix counterparts. This works well, and allows me to
login to a client using Windows credentials and map the drive locally.
However, on Ub1404, to map the home directory I run a script which uses
getent, and the returned string is, e.g. \\server\share\share\username
But on Ub1604, getent does not return this properly, but instead removes
the slashes, e.g. \servershareshareusername
If I run getent on the LTSP server, it works, but not on the client.
I've never seen this before. When I strace getent from the client, it
doesn't even seem to query nsswitch, whereas it does from the server.
$ strace -e open getent passwd testac
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
+++ exited with 0 +++
$ strace -e open getent passwd testac
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/etc/passwd&
quot;, O_RDONLY|O_CLOEXEC) = 3
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libnss_ldap.so.2", O_RDONLY|O_CLOEXEC) = 3
+++ exited with 0 +++
I know authentication can be one of those tricky subjects, but I don't
personally feel that this is the issue here, whereas the weird behaviour
of getent is. If anyone has any clues or pointers I'd be very grateful,
everything else seems to be working fine.
Best Wishes
John
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freeno
John Halfpenny
2016-12-23 09:16:43 UTC
Permalink
Hi Alkis

Brilliant, that worked!

Thanks for your swift reply, I'll submit a bug report now.

Best Wishes
John
Post by Alkis Georgopoulos
Hi John,
open ($CHROOT)/usr/share/ldm/rc.d/X01-localapps
find 2 "read" commands in lines 36 and 46
and replace them with "read -r" so that it doesn't interpret the
backslashes.
IFS=':' read -r LDM_USERNAME dummy pw_uid pw_gid pw_gecos LDM_HOME
pw_shell <<EOF
while IFS=':' read -r gr_name dummy gr_gid dummy; do
If that works, file a bug report in https://bugs.launchpad.net/ltsp/ so
that I can commit the fix.
Cheers,
Alkis Georgopoulos
LTSP developer
Post by John Halfpenny
Hi Everyone
We've been running LTSP for a while now on Ubuntu 14.04, and I'm in the
process of upgrading to 16.04.
Our server connects to Windows using kerberos, samba and nslcd to map
attributes to their unix counterparts. This works well, and allows me to
login to a client using Windows credentials and map the drive locally.
However, on Ub1404, to map the home directory I run a script which uses
getent, and the returned string is, e.g. \\server\share\share\username
But on Ub1604, getent does not return this properly, but instead removes
the slashes, e.g. \servershareshareusername
If I run getent on the LTSP server, it works, but not on the client.
I've never seen this before. When I strace getent from the client, it
doesn't even seem to query nsswitch, whereas it does from the server.
$ strace -e open getent passwd testac
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
,\servershareshareusername:/opt/ltsphome/testac:/bin/bash
Post by John Halfpenny
+++ exited with 0 +++
$ strace -e open getent passwd testac
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/etc/passwd&
quot;, O_RDONLY|O_CLOEXEC) = 3
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/x86_64-linux-gnu/libnss_ldap.so.2", O_RDONLY|O_CLOEXEC) = 3
,\\server\share\share\username:/opt/ltsphome/testac:/bin/bash
Post by John Halfpenny
+++ exited with 0 +++
I know authentication can be one of those tricky subjects, but I don't
personally feel that this is the issue here, whereas the weird behaviour
of getent is. If anyone has any clues or pointers I'd be very grateful,
everything else seems to be working fine.
Best Wishes
John
------------------------------------------------------------
------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
_____________________________________________________________________
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net
Loading...