In the test environment, did the ltsp server have the same ip address or
was it x.x.x.254?
If the server changes ip address, then you need to run
ltsp-update-sshkeys (and ltsp-update-kernels if you are using nbd
Hope this helps,
On Tue, 2012-02-07 at 12:00 -0500, k12osn-request@redh... wrote:
> From: Johan Vermeulen <jvermeulen@cawd...>
> To: "Support list for open source software in schools."
> Subject: Re: [K12OSN] k12ltsp as next-server - solved or almost
> Message-ID: <4F302646.3070207@cawd...>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
> Hello William, hello All,
> I tested this again today on the production environment.
> 1) on the test environment, clients did log in correctly
> 2) I don't think it's LDAP related, mostly because root can also not
> log in.
> 3) the clients do not log in on the wrong server. I think your advise
> was right, they make the thinclients boot.
> I tested today with the two options in dhcpd.conf and ended up
> them both, it makes no difference.
> so tho thinks are puzling me:
> * this is var/log/messages on thinclient boot :
> *Feb 6 16:17:05 server2 in.tftpd: tftp: client does not accept
> Feb 6 16:17:24 server2 rpc.mountd: authenticated mount request
> from 192.168.50.148:678 for /opt/ltsp/i386 (/opt/ltsp)
> Feb 6 16:17:40 server2 xinetd: START: nbdswapd pid=9431
> Feb 6 16:17:40 server2 nbd-server: connect from 192.168.50.148,
> assigned file is /var/lib/ltsp/swapfiles/QlNwyt
> Feb 6 16:17:40 server2 nbd-server: Size of exported file/device is
> Feb 6 16:17:42 server2 xinetd: START: ldminfod pid=9438
> Feb 6 16:17:42 server2 xinetd: EXIT: ldminfod status=0
> Feb 6 16:18:37 server2 xinetd: START: ldminfod pid=9454
> Feb 6 16:18:37 server2 xinetd: EXIT: ldminfod status=0
> so I am wondering about the EXIT; ldminfod part, but I think it's not
> related to the problem. Or is it?
> * this is /var/log/secure :
> *Feb 6 16:11:12 server2 sshd: Accepted password for root from
> 192.168.50.174 port 45240 ssh2
> Feb 6 16:11:12 server2 sshd: pam_unix(sshd:session): session
> opened for user root by (uid=0)
> Feb 6 16:11:13 server2 sshd: Received disconnect from
> 192.168.50.174: 11: disconnected by user
> Feb 6 16:11:13 server2 sshd: pam_unix(sshd:session): session
> closed for user root
> Feb 6 16:12:59 server2 sshd: Connection closed by
> Feb 6 16:15:13 server2 sshd: Connection closed by
> Feb 6 16:18:36 server2 sshd: Connection closed by
> I think this is the problem: sshd gets closed somehow.
> So I tried different firewall configs, but to no avail. Also turned
> Selinux, that's not it, either.
> I also checked /etc/ssh/sshd_config to make shure to have pam=on.
> So I think it has to do with sshd, but cannot figure out what.
> greetings, J.