[K12OSN] k12ltsp as next-server - solved or almost

Wed Feb 8 09:03:38 UTC 2012

Hi Johan,

Several schools in Belgium are LTSP-powered.
http://nl.wikibooks.org/wiki/Linux_Systeembeheer/Linux-scholen

I think that's a far from complete list though, also it doesn't include 
the companies in Belgium that are running LTSP.

You could be the first one in Belgium using the -latest- K12Linux in a 
production environment though.

Congrats on your success!  Gefeliciteerd. ;-)

Kindest regards,

Jan Middelkoop
Recreatie en Zorg Groep B.V.

-- 
Website: http://www.recreatie-zorg.nl/
E-mail: jan at recreatie-zorg.nl
Telefoon: +31 10 714 22 97

Op 08-02-12 09:46, Johan Vermeulen schreef:
> William,
>
> thanks again for the reply.
>
> I was able to log in yesterday morning by logging in to the own ip 
> address, then copying the key from /root/.ssh/known_hosts to 
> /opt/ltsp/i386/etc/ssh/ssh_known_hosts.
>
> I think that's the same result as running ltsp-update-sshkeys.
>
> Thanks to your help, starting next Tuesday, we will have people doing 
> their desktop business with the help of K12Linux.
> Maybe that's a first in Belgium ??!! :-)
>
> greetings, J.
>
>
>
> Op 07-02-12 19:30, William Fragakis schreef:
>> Johan,
>> 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
>> images).
>>
>> Hope this helps,
>> William
>>
>>
>> On Tue, 2012-02-07 at 12:00 -0500, k12osn-request at redhat.com wrote:
>>> From: Johan Vermeulen<jvermeulen at cawdekempen.be>
>>> To: "Support list for open source software in schools."
>>> <k12osn at redhat.com>
>>> Subject: Re: [K12OSN] k12ltsp as next-server - solved or almost
>>> Message-ID:<4F302646.3070207 at cawdekempen.be>
>>> 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
>>> enabling
>>> 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[9413]: tftp: client does not accept
>>> options
>>> Feb  6 16:17:24 server2 rpc.mountd[7744]: authenticated mount request
>>> from 192.168.50.148:678 for /opt/ltsp/i386 (/opt/ltsp)
>>> Feb  6 16:17:40 server2 xinetd[7603]: START: nbdswapd pid=9431
>>> from=::ffff:192.168.50.148
>>> 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
>>> 67108864
>>> Feb  6 16:17:42 server2 xinetd[7603]: START: ldminfod pid=9438
>>> from=::ffff:192.168.50.148
>>> Feb  6 16:17:42 server2 xinetd[7603]: EXIT: ldminfod status=0
>>> pid=9438
>>> duration=0(sec)
>>> Feb  6 16:18:37 server2 xinetd[7603]: START: ldminfod pid=9454
>>> from=::ffff:192.168.50.148
>>> Feb  6 16:18:37 server2 xinetd[7603]: EXIT: ldminfod status=0
>>> pid=9454
>>> duration=0(sec)
>>> *
>>> 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[9228]: Accepted password for root from
>>> 192.168.50.174 port 45240 ssh2
>>> Feb  6 16:11:12 server2 sshd[9228]: pam_unix(sshd:session): session
>>> opened for user root by (uid=0)
>>> Feb  6 16:11:13 server2 sshd[9228]: Received disconnect from
>>> 192.168.50.174: 11: disconnected by user
>>> Feb  6 16:11:13 server2 sshd[9228]: pam_unix(sshd:session): session
>>> closed for user root
>>> Feb  6 16:12:59 server2 sshd[9271]: Connection closed by
>>> 192.168.50.148
>>> Feb  6 16:15:13 server2 sshd[9309]: Connection closed by
>>> 192.168.50.148
>>> Feb  6 16:18:36 server2 sshd[9443]: Connection closed by
>>> 192.168.50.148
>>> *
>>> I think this is the problem: sshd gets closed somehow.
>>> So I tried different firewall configs, but to no avail. Also turned
>>> off
>>> 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.
>>>
>>>
>> _______________________________________________
>> K12OSN mailing list
>> K12OSN at redhat.com
>> https://www.redhat.com/mailman/listinfo/k12osn
>> For more info see<http://www.k12os.org>
>
> _______________________________________________
> K12OSN mailing list
> K12OSN at redhat.com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>