[K12OSN] Users can't login

Thu Dec 2 15:09:54 UTC 2010

Barry Cisna wrote:
 >Brian,
 >
 >A few more things to consider.
 >
 >1. You are using an unmanaged switch in your setup?
 >In other words a cheapo plug n play 10/100/(1000) switch.
 >I am trying to picture your setup? You have a dsl into your home with a
 >provided router. Your server is plugged into one of the lan ports, the
 >TC is plugged into another lan port ,correct.
To clarify: my cable service provides a modem that the TV coax
connects to, and that has an Ethernet port. I have a
wireless router connected to the modem, so the router gets
its IP address by DHCP and DNS services from the provider.

All machines at home plug into this router. So the server has
a static IP address, and the client, and various laptops, get
their IP addresses from the LTSP DHCP server. (The router does
NOT have DHCP turned on, and the regular DHCP service is not
running on the server. The only DHCP service is from LTSP.)

 >
 >Nope ,I just thought, this can not work. You are *only* seeing a class C
 >ip address? hhhmmm
I don't know what a class C IP address is, but that may not be relevant.

However - LTSP did work until I upgraded to Fedora13 and
installed LTSP5.2.4.5.

I should revise that. I am not certain that LTSP, per se, isn't working.
As I say, the client clearly finds the image, so I would think that
means that the networking end of things is good, and the image boots
properly, and we get the login screen, but after userid and password
are entered, it returns to the login screen. Maybe it's something
to do with ldm, although that doesn't seem well documented, so it's
hard to make guesses.

 >1a. do 'ifconfig' and copy/paste back the response.

eth0      Link encap:Ethernet  HWaddr 00:1E:8C:68:38:D7
           inet addr:192.168.1.103  Bcast:192.168.1.255  Mask:255.255.255.0
           inet6 addr: fe80::21e:8cff:fe68:38d7/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:543342 errors:0 dropped:0 overruns:0 frame:0
           TX packets:602301 errors:0 dropped:0 overruns:0 carrier:11
           collisions:0 txqueuelen:1000
           RX bytes:305945407 (291.7 MiB)  TX bytes:639198479 (609.5 MiB)

lo        Link encap:Local Loopback
           inet addr:127.0.0.1  Mask:255.0.0.0
           inet6 addr: ::1/128 Scope:Host
           UP LOOPBACK RUNNING  MTU:16436  Metric:1
           RX packets:105465 errors:0 dropped:0 overruns:0 frame:0
           TX packets:105465 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:105169058 (100.2 MiB)  TX bytes:105169058 (100.2 MiB)

ltspbr0   Link encap:Ethernet  HWaddr 62:4C:94:CF:5C:15
           inet addr:172.31.100.254  Bcast:172.31.100.255  Mask:255.255.255.0
           inet6 addr: fe80::604c:94ff:fecf:5c15/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:2588 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:0 (0.0 b)  TX bytes:793267 (774.6 KiB)
 >
 >2. I wasn't clear enough. Can root log into the server * from a thin
 >client*. Not ssh.

No. Root can't login at the GUI login prompt on the client. But
in any case, I think root is prohibited by default from running
a GNOME session.

 >
 >3. I see that tcp 7100 is not listening. This is usually the case
 >although I am not familiar with ltsp5 so this may not be necessary now.
 >
 >4. It appears your ISP is setting the correct setting into your resolve
 >file for 127.0.0.1 as it is listed now.
 >
 >5. Run the command 'hostname' and report back what the response is.
{orpheus:/home/brian/orpheus/ltsp/5.2.4.5_CantLogin}hostname
orpheus

 >
 >6. Open a terminal (as root) and do a ' tail -f /var/log/messages' .
 >After you have the terminal open,try logging into the server from a thin
 >client.
 >Copy/Paste about the last 100 lines into a message here. Maybe something
 >will pop out of what is happening here.
 >

NOTE: there are a number of 'dhcpd' messages below. On my system,
dhcpd, dhcpd6 and dhcrelay are all disabled. ltsp-dhcpd is shown
as enabled. I would expect the messages to say 'ltsp-dhcpd', but
that's what I got.

So in these messages, we see the requests from the thin client
as it gets an IP address, and downloads the image.

I am also appending to the end some lines from /var/log/secure that
show the user authenticating.

---------------------------------------------------------------------
from /var/log/messages

Dec  2 08:09:47 orpheus dhcpd: DHCPDISCOVER from 00:13:90:02:9a:ee via eth0
Dec  2 08:09:48 orpheus dhcpd: DHCPOFFER on 192.168.1.116 to 00:13:90:02:9a:ee 
via eth0
Dec  2 08:09:50 orpheus dhcpd: DHCPREQUEST for 192.168.1.116 (192.168.1.103) 
from 00:13:90:02:9a:ee via eth0
Dec  2 08:09:50 orpheus dhcpd: DHCPACK on 192.168.1.116 to 00:13:90:02:9a:ee via 
eth0
Dec  2 08:09:50 orpheus xinetd[2467]: START: tftp pid=28928 from=192.168.1.116
Dec  2 08:09:50 orpheus in.tftpd[28929]: tftp: client does not accept options
Dec  2 08:10:03 orpheus dhcpd: DHCPDISCOVER from 00:13:90:02:9a:ee via eth0
Dec  2 08:10:03 orpheus dhcpd: DHCPOFFER on 192.168.1.116 to 00:13:90:02:9a:ee 
via eth0
Dec  2 08:10:03 orpheus dhcpd: DHCPREQUEST for 192.168.1.116 (192.168.1.103) 
from 00:13:90:02:9a:ee via eth0
Dec  2 08:10:03 orpheus dhcpd: DHCPACK on 192.168.1.116 to 00:13:90:02:9a:ee via 
eth0
Dec  2 08:10:05 orpheus xinetd[2467]: START: nbdrootd pid=28953 
from=::ffff:192.168.1.116
Dec  2 08:10:05 orpheus nbd-server: connect from 192.168.1.116, assigned file is 
/opt/ltsp/images/i386.img
Dec  2 08:10:05 orpheus nbd-server: Size of exported file/device is 314269696
Dec  2 08:10:20 orpheus xinetd[2467]: START: ldminfod pid=28955 
from=::ffff:192.168.1.116
Dec  2 08:10:20 orpheus xinetd[2467]: EXIT: ldminfod status=0 pid=28955 
duration=0(sec)
Dec  2 08:10:20 orpheus xinetd[2467]: START: ldminfod pid=28958 
from=::ffff:192.168.1.116
Dec  2 08:10:20 orpheus xinetd[2467]: EXIT: ldminfod status=0 pid=28958 
duration=0(sec)
Dec  2 08:10:25 orpheus xinetd[2467]: START: nbdrootd pid=28961 
from=::ffff:192.168.1.116
Dec  2 08:10:25 orpheus nbd-server: connect from 192.168.1.116, assigned file is 
/opt/ltsp/images/i386.img
Dec  2 08:10:25 orpheus nbd-server: Size of exported file/device is 314269696
Dec  2 08:10:25 orpheus nbd-server: Disconnect request received.
Dec  2 08:10:25 orpheus xinetd[2467]: EXIT: nbdrootd status=0 pid=28961 
duration=0(sec)
Dec  2 08:15:36 orpheus xinetd[2467]: START: ldminfod pid=29029 
from=::ffff:192.168.1.116
Dec  2 08:15:36 orpheus xinetd[2467]: EXIT: ldminfod status=0 pid=29029 
duration=0(sec)
Dec  2 08:15:36 orpheus xinetd[2467]: START: ldminfod pid=29032 
from=::ffff:192.168.1.116
Dec  2 08:15:36 orpheus xinetd[2467]: EXIT: ldminfod status=0 pid=29032 
duration=0(sec)
Dec  2 08:15:38 orpheus xinetd[2467]: START: nbdrootd pid=29035 
from=::ffff:192.168.1.116
Dec  2 08:15:38 orpheus nbd-server: connect from 192.168.1.116, assigned file is 
/opt/ltsp/images/i386.img
Dec  2 08:15:38 orpheus nbd-server: Size of exported file/device is 314269696
Dec  2 08:15:38 orpheus nbd-server: Disconnect request received.
Dec  2 08:15:38 orpheus xinetd[2467]: EXIT: nbdrootd status=0 pid=29035 
duration=0(sec)
Dec  2 08:15:59 orpheus xinetd[2467]: START: ldminfod pid=29048 
from=::ffff:192.168.1.116
Dec  2 08:15:59 orpheus xinetd[2467]: EXIT: ldminfod status=0 pid=29048 
duration=0(sec)
Dec  2 08:15:59 orpheus xinetd[2467]: START: ldminfod pid=29051 
from=::ffff:192.168.1.116
Dec  2 08:15:59 orpheus xinetd[2467]: EXIT: ldminfod status=0 pid=29051 
duration=0(sec)
Dec  2 08:16:01 orpheus xinetd[2467]: START: nbdrootd pid=29054 
from=::ffff:192.168.1.116
Dec  2 08:16:01 orpheus nbd-server: connect from 192.168.1.116, assigned file is 
/opt/ltsp/images/i386.img
Dec  2 08:16:01 orpheus nbd-server: Size of exported file/device is 314269696
Dec  2 08:16:01 orpheus nbd-server: Disconnect request received.
Dec  2 08:16:01 orpheus xinetd[2467]: EXIT: nbdrootd status=0 pid=29054 
duration=0(sec)
Dec  2 08:16:14 orpheus xinetd[2467]: START: ldminfod pid=29075 
from=::ffff:192.168.1.116
Dec  2 08:16:14 orpheus xinetd[2467]: EXIT: ldminfod status=0 pid=29075 
duration=0(sec)
Dec  2 08:16:14 orpheus xinetd[2467]: START: ldminfod pid=29078 
from=::ffff:192.168.1.116
Dec  2 08:16:14 orpheus xinetd[2467]: EXIT: ldminfod status=0 pid=29078 
duration=0(sec)
Dec  2 08:16:15 orpheus xinetd[2467]: START: nbdrootd pid=29081 
from=::ffff:192.168.1.116
Dec  2 08:16:15 orpheus nbd-server: connect from 192.168.1.116, assigned file is 
/opt/ltsp/images/i386.img
Dec  2 08:16:15 orpheus nbd-server: Size of exported file/device is 314269696
Dec  2 08:16:15 orpheus nbd-server: Disconnect request received.
Dec  2 08:16:15 orpheus xinetd[2467]: EXIT: nbdrootd status=0 pid=29081 
duration=0(sec)
Dec  2 08:24:51 orpheus xinetd[2467]: EXIT: tftp status=0 pid=28928 
duration=901(sec)

---------------------------------------------------------------------------------
Now here's what we see in /var/log/secure when user 'birch' tries to login at
the thin client:

Dec  2 09:01:31 orpheus sshd[30963]: Accepted password for birch from 
192.168.1.116 port 38445 ssh2
Dec  2 09:01:31 orpheus sshd[30963]: pam_unix(sshd:session): session opened for 
user birch by (uid=0)
Dec  2 09:01:32 orpheus sshd[30965]: Received disconnect from 192.168.1.116: 11: 
disconnected by user
Dec  2 09:01:32 orpheus sshd[30963]: pam_unix(sshd:session): session closed for 
user birch

I had posted similar messages some time ago, and was advised to run
ltsp-update-sshkeys before I run sudo ltsp-update-image, which is now
part of my standard procedure. So it seems likely that the image is getting
the correct ssh keys.