IRC chat logs for #ltsp on irc.libera.chat (webchat)


Channel log from 28 February 2015   (all times are UTC)

02:08metal-machine has left IRC (metal-machine!~metal-mac@117.214.222.60, Quit: Leaving)
03:33fiesh has left IRC (fiesh!~fiesh@p508AE68B.dip0.t-ipconnect.de, Ping timeout: 246 seconds)
03:35fiesh has joined IRC (fiesh!~fiesh@p508AE6DD.dip0.t-ipconnect.de)
04:13metal-machine has joined IRC (metal-machine!~metal-mac@202.164.39.10)
04:34
<metal-machine>
alkisq: I am not able to login thin clients. I am using NFS. here is the output for "grep -r ^Exec /usr/share/xsessions"
04:34
http://pastebin.com/520Kex4H
05:11
Is it problem with NFS configuration?
05:56metal-machine has left IRC (metal-machine!~metal-mac@202.164.39.10, Ping timeout: 244 seconds)
05:57adrianorg has left IRC (adrianorg!~adrianorg@189.114.156.128, Ping timeout: 255 seconds)
05:59adrianorg has joined IRC (adrianorg!~adrianorg@187.113.244.78)
06:35metal-machine has joined IRC (metal-machine!~metal-mac@202.164.39.10)
06:36
<metal-machine>
hello still not able to login from thin-client
06:36
any one there?
06:36
:(
06:52
<work_alkisg>
metal-machine: run this on the server: tail -f /var/log/auth.log
06:52work_alkisg is now known as alkisg
06:53
<alkisg>
Then try to login on the thin client, and check the server again to see if you got a successful login message
06:58
<metal-machine>
no i am not getting successful login, the error is something like
06:58
pam_unix(su:auth):conversation failed
06:58
pam_unix(su:auth): auth could not identify password for [root]
06:59
pam_authenticate:Authentication failure
06:59
FAILED su for root by test1
07:00
- /dev/pts/2 test1:root
07:04
[now again tried to boot thin client and new message appears ]
07:05
root-server sshd[4553] Connection closed by 192.168.0.201 [preauth]
07:10
Ok that means the problem is with openssh?
07:11metal-machine has left IRC (metal-machine!~metal-mac@202.164.39.10, Quit: Leaving)
07:11metal-machine has joined IRC (metal-machine!~metal-mac@202.164.39.10)
07:17
<metal-machine>
Any idea?
07:18
<alkisg>
metal-machine: are you trying to login as root?
07:19
metal-machine: it might be an issue with your ssh keys
07:19
!ltsp-update-sshkeys
07:19
<ltsp`>
ltsp-update-sshkeys: If you changed your server IP, you need to run ltsp-update-sshkeys, and if you're using NBD (Ubuntu) you also need ltsp-update-image afterwards
07:19
<alkisg>
you can also try this:
07:19
!screen_08
07:19
<ltsp`>
screen_08: To get a root shell on a Debian thin client, put SCREEN_07=ldm, SCREEN_08=shell and SCREEN_DEFAULT=07 to lts.conf.
07:20
<metal-machine>
I am using Debian wheezy with NFS
07:21
<alkisg>
I know
07:21
So try those 2 sentences, but don't try the ubuntu part
07:21
<metal-machine>
first I run this on root server: ltsp-update-sshkeys 192.168.0.106 debian-app-01
07:22
ltsp-update-sshkeys
07:22
the both of above run without errors
07:22ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz)
07:22
<alkisg>
Then you need LDM_SERVER=ip
07:23
The default name for the LTSP server is "server", so the client ssh doesn't know and doesn't trust server when you've only put its ip and dns in the keys
07:23
Either name .106 as "server" in your /etc/hosts, and run ltsp-update-sshkeys with "server", or change LDM_SERVER
07:24
<metal-machine>
ok I am trying with first
07:26
ok trying to boot thin client
07:27
One more thing I want to confirm . I am creating users in .106.
07:28
is that fine or I have to make only in root server(.105)?
07:28
<alkisg>
The root server is only serving NFS, right?
07:29
If so, you don't need users there, unless you're using nfs4 with authentication etc
07:30
<metal-machine>
Root server is serving boot image. I am sending you the setup
07:31
<alkisg>
No need, try the ssh keys, it's probably that
07:32
<metal-machine>
I used that. Please have a look. I did the same as in setup
07:32
http://pastie.org/9988946
07:33
I feel I am missing some nfs setup part
07:35
<alkisg>
Did you get a shell at screen08?
07:37
<metal-machine>
trying...
07:37
<alkisg>
When you get a local root shell on a client, try those:
07:37
1) alt+ctrl+f8 to switch to the console
07:37
2) getltscfg -a, check the value of SERVER there, or LDM_SERVER
07:38
3) ssh user@<exact ip or name of server>
07:38
4) It will probably prompt you to trust the ssh keys, which is what is going wrong with your setup
07:38
Accept the keys
07:38
5) Switch again to vt7, alt+ctrl+f7. Now you should be able to log in
07:39
<metal-machine>
aah ok Now i got you. :)
07:39
<alkisg>
I.e. I think that the problem is that the client doesn't trust the server because you're mixing IPs, DNS names, the LTSP special "server" name, your MY_SERVER_LIST, etc
07:39
If the above 5 steps allow you to log in, you'll be certain that I was "right"...
07:55gbaman has joined IRC (gbaman!~gbaman@31.205.104.150)
08:02metal-machine has left IRC (metal-machine!~metal-mac@202.164.39.10, Ping timeout: 256 seconds)
08:11gbaman has left IRC (gbaman!~gbaman@31.205.104.150, Remote host closed the connection)
08:12gbaman has joined IRC (gbaman!~gbaman@31.205.104.150)
08:28fiesh has left IRC (fiesh!~fiesh@p508AE6DD.dip0.t-ipconnect.de, Ping timeout: 245 seconds)
08:35gbaman has left IRC (gbaman!~gbaman@31.205.104.150, Remote host closed the connection)
08:39vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
08:52freedomrun has joined IRC (freedomrun!~quassel@BSN-182-152-186.dynamic.siol.net)
08:52freedomrun has joined IRC (freedomrun!~quassel@unaffiliated/freedomrun)
08:55freedomrun has left IRC (freedomrun!~quassel@unaffiliated/freedomrun, Remote host closed the connection)
09:17telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
09:18telex has joined IRC (telex!teletype@freeshell.de)
09:33alkisg is now known as work_alkisg
09:56Heinz2k has joined IRC (Heinz2k!54bd75f8@gateway/web/freenode/ip.84.189.117.248)
10:06
<Heinz2k>
Hi for testing purpose im running LTSP on 14.04 Ubuntu LTSP serving a fat client chroot via NBD. That works without problem. However for some reasons i want to switch back to NFS, i have installed all necessary packages and NFS Server works, however my client cant boot the chroot if the export is ro ( permission issues) exporting chroot as rw works well, but thats not what i want. Is there something special i have to change to make n
10:10
<Hyperbyte>
Yes, it is possibly by mounting an overlayfs on top of NFS, that's what LTSP does for NBD as well. Heinz2k, explain your reason for wanting to switch to NFS.
10:16
<Heinz2k>
LTSP is just running on a tiny vm , due to IO Perfomance i want the thin clients to load the chroot from a NFS Share of our local SAN (much better IO Perfomance) ...
10:26
<Hyperbyte>
Sounds like a plan.
10:26
NFS should be mounted read-only. If it's mounted read-write, clients will get in eachother's way.
10:27
But the OS needs a read-write root to start from. Solution is the same with NBD (as that is also read-only): LTSP mounts an overlay FS (basically, a ramdisk) on top of the root, where all changes are stored.
10:27
If the client reboots, all those changes are gone again.
10:59
<Heinz2k>
Thank you
11:00
so it seems my setup lack overlayfs support
11:02
<Hyperbyte>
Heinz2k, you can check this by typing "mount"
11:02
Typically, you should see the root nbd/nfs mount
11:02
And then another root, with overlayfs (or aufs, not sure which LTSP uses)
11:04
Let me boot a thin client to show you
11:08
I just sent you a PM here on IRC, with a screenshot of 'mount' output on a virtual thin client
11:08
Note /dev/nbd0 mounted ro and overlayfs mounted rw
11:09
LTSP should do this automatically though, for NBD -and- NFS.
11:30
<Heinz2k>
with NBD : overlayfs on / type overlayfs (rw)
11:30
seems to work
11:30
client boots fine
11:36
NFS Fails on bootup : /sbin/init-ltsp/ ........ Permission denied
11:42
<Hyperbyte>
That's different.
11:42
Permission denied doesn't necessarily mean something is read-only.
11:42
In this case, I bet it means your NFS permissions aren't set up correctly.
11:43
You said you were using a NAS... does this NAS preserve Linux file permissions?
11:43
Or SAN.
11:46
<Heinz2k>
Just testing with local VMs right now (1 Server VM 1 Client VM)
11:47
h1@ubuntu:/etc$ sudo exportfs /home <world> /opt/ltsp/amd64 <world>
11:49
../etc/exports
11:49
"/opt/ltsp/amd64 *(ro,no_subtree_check,no_root_squash)"
11:50
tcp 0 0 *:nfs *:* LISTEN root 11876 -
11:51
<Hyperbyte>
Yes, now mount the directory from the SAN.
11:51
<Heinz2k>
Cant .. not at work ;)
11:52
<Hyperbyte>
...
11:52
So you're not actually trying to mount NFS from the SAN?
11:52
But from the local server?
11:52
<Heinz2k>
yes
11:52
NFS Server is on the local machine
11:52
(VM)
11:53
sorry i meant on the LTSP VM
11:55
<Hyperbyte>
!quiet-splash
11:55
<ltsp`>
quiet-splash: to disable the splash screen in Ubuntu, in order to see any boot error messages, run sudo gedit /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default and remove quiet splash plymouth:force-splash vt.handoff=7
11:55
<Hyperbyte>
Forgot all about that, it's been a while since I debugged LTSP. :P
11:55
You might see some useful error messages when you do that.
11:57khildin has joined IRC (khildin!~khildin@ip-213-49-116-57.dsl.scarlet.be)
12:03
<Heinz2k>
send you the corresponding error messages
12:04
thank you for ur help so far
12:04
gotta take care of my child now :) ... but will be online later
12:05
<Hyperbyte>
Sure.
12:06
I've only once or twice used LTSP with NFS backend, to me, it looks like something is going wrong with overlayfs still...
12:06
But the problem could be in your lts.conf as well... I'm not sure.
13:16AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-nugmlyzrmsjuhjjm)
13:45Heinz2k has left IRC (Heinz2k!54bd75f8@gateway/web/freenode/ip.84.189.117.248, Quit: Page closed)
14:57Heinz2k has joined IRC (Heinz2k!54bd75f8@gateway/web/freenode/ip.84.189.117.248)
16:21AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-nugmlyzrmsjuhjjm, Quit: Connection closed for inactivity)
16:33vmlintu has joined IRC (vmlintu!~vmlintu@a91-152-200-70.elisa-laajakaista.fi)
17:20vmlintu has left IRC (vmlintu!~vmlintu@a91-152-200-70.elisa-laajakaista.fi, Ping timeout: 256 seconds)
17:24telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
17:26telex has joined IRC (telex!teletype@freeshell.de)
17:34vmlintu has joined IRC (vmlintu!~vmlintu@a91-152-200-70.elisa-laajakaista.fi)
17:41alkisg_web has joined IRC (alkisg_web!d510e116@gateway/web/freenode/ip.213.16.225.22)
17:48alkisg_web has left IRC (alkisg_web!d510e116@gateway/web/freenode/ip.213.16.225.22, Quit: Page closed)
18:13Heinz2k has left IRC (Heinz2k!54bd75f8@gateway/web/freenode/ip.84.189.117.248, Quit: Page closed)
19:21alkisg_web has joined IRC (alkisg_web!d510e116@gateway/web/freenode/ip.213.16.225.22)
20:12syrius has left IRC (syrius!~syrius@thunder.stormtek.net, Ping timeout: 255 seconds)
20:24syrius has joined IRC (syrius!~syrius@thunder.stormtek.net)
20:31syrius has left IRC (syrius!~syrius@thunder.stormtek.net, Ping timeout: 250 seconds)
20:37syrius has joined IRC (syrius!~syrius@thunder.stormtek.net)
20:52AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-ynrklyvgjwrxmrsg)
21:11
<alkisg_web>
!4k
21:11
<ltsp`>
4k: Imagine a 4k display updated at 60 fps. It needs 3840×2160×32×60 bits per second, i.e. 16 gbps. Normal HD displays need 4 gbps. Thin clients will have much trouble getting all that through the local network...
21:43vmlintu has left IRC (vmlintu!~vmlintu@a91-152-200-70.elisa-laajakaista.fi, Ping timeout: 245 seconds)
21:45fiesh has joined IRC (fiesh!~fiesh@hq.wsoptics.de)
21:54alkisg_web has left IRC (alkisg_web!d510e116@gateway/web/freenode/ip.213.16.225.22, Quit: Page closed)
22:07ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat)
22:53khildin has left IRC (khildin!~khildin@ip-213-49-116-57.dsl.scarlet.be, Quit: I'm gone, bye bye)