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


Channel log from 21 September 2017   (all times are UTC)

00:23ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection)
00:33vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
01:02mmarconm has left IRC (mmarconm!~mmarconm@191.217.39.241, Ping timeout: 248 seconds)
01:50adrianor1 has joined IRC (adrianor1!~adrianorg@177.156.63.127)
01:53adrianorg has left IRC (adrianorg!~adrianorg@189.58.238.64.dynamic.adsl.gvt.net.br, Ping timeout: 248 seconds)
02:27dgroos has joined IRC (dgroos!~dagro001@vpn.mpls.k12.mn.us)
02:29
<dgroos>
Hi! Continuing working on solving AD issue with the pbis-open software (used to be called “likewise-open”)
02:30
The people at pbis have been giving ideas… This morning they mentioned that:
02:30
“PBIS needs to be in the pam configuration to handle authentication. Sounds like they are conflicting pam configuration.”
02:31
(‘they’ being the client in ltsp-pnp and pbis)
02:32
Where would be the “pam configurations” on the client? Using ltsp-pnp 16.04.3 fat ubuntu clients.
02:52dgroos_ has joined IRC (dgroos_!~dagro001@63.225.132.145)
02:54dgroos has left IRC (dgroos!~dagro001@vpn.mpls.k12.mn.us, Ping timeout: 240 seconds)
02:54dgroos_ is now known as dgroos
03:00dgroos has left IRC (dgroos!~dagro001@63.225.132.145, Quit: dgroos)
04:52Statler has joined IRC (Statler!~Georg@p579FE005.dip0.t-ipconnect.de)
05:55ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
06:05fnurl has left IRC (fnurl!~fnurl@36-231-218-223.dynamic-ip.hinet.net, Read error: Connection reset by peer)
06:05fnurl has joined IRC (fnurl!~fnurl@1-160-58-134.dynamic-ip.hinet.net)
06:36mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk)
07:17Statler has left IRC (Statler!~Georg@p579FE005.dip0.t-ipconnect.de, Remote host closed the connection)
07:37markit has joined IRC (markit!~marco@host179-38-static.243-95-b.business.telecomitalia.it)
07:42Statler has joined IRC (Statler!~Georg@p579FF4E1.dip0.t-ipconnect.de)
09:54ricotz_ has joined IRC (ricotz_!~ricotz@p5B2A9A59.dip0.t-ipconnect.de)
09:54ricotz_ has joined IRC (ricotz_!~ricotz@ubuntu/member/ricotz)
09:54ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Ping timeout: 248 seconds)
13:34eu^851015366dyna has joined IRC (eu^851015366dyna!55653542@gateway/web/freenode/ip.85.101.53.66)
13:34
<eu^851015366dyna>
hi
13:35
hii
13:35eu^851015366dyna has left IRC (eu^851015366dyna!55653542@gateway/web/freenode/ip.85.101.53.66, Client Quit)
13:41lucascastro has joined IRC (lucascastro!~lucas@189.90.38.210.jupiter.com.br)
14:21mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving)
15:17ricotz_ is now known as ricotz
15:39
<sutula>
alkisg: From yesterday, couldn't log into thin clients because of some home directory problem, and you suggested pastebin of /proc/mounts:
15:39
https://hastebin.com/raw/kiwaqayugu
15:40
Indeed, mount of home directory isn't present...where do I look next?
15:41
Is that mount done in a script on the client? If you can point me to the script doing the mount, I can debug from there.
15:41lucascastro has left IRC (lucascastro!~lucas@189.90.38.210.jupiter.com.br, Remote host closed the connection)
15:51markit has left IRC (markit!~marco@host179-38-static.243-95-b.business.telecomitalia.it, Quit: Konversation terminated!)
16:17
<||cw>
sutula: first thing i'd check is logs on the server to see if it's denying them
16:22
<sutula>
||cw: Thanks, the odd thing is that it's not likely a server config thing because reverting back to the prior client image makes everything work again. Either something odd changed, or... That's why it might be good for me to execute the commands on the client manually and see what is failing.
16:25
<||cw>
sure, but it might give a clue about what the client is asking for that it doens't like
16:26
<sutula>
ty, will see what I can dig up
16:31vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
16:55
<alkisg>
sutula: are you sure you didn't change something in lts.conf, like LOCALAPPS=False?
16:55
Also, is that pastebin *after* you logged in with the xterm session?
16:57
<sutula>
alkisg: Looking, and pastebin is *after* xterm session
16:58
<alkisg>
sutula: ok, run `getltscfg -a` from epoptes root console for that client
16:58
getltscfg -a | nc termbin.com 9999
16:58
This puts it to pastebin...
16:59
(don't do that if you have sensitive data like LDM_PASSWORD...)
16:59
Also, you can try to manually mount sshfs /home to see if you get any error messages
16:59
<sutula>
Looking at lts.conf, my only additions are:
17:00
LDM_PASSWORD_HASH=True (put there because of problem unlocking fat clients)
17:00
LDM_THEME= (some path that seems to be working)
17:01
RM_SYSTEM_SERVICES="...bunch of stuff..."
17:01asd__ has joined IRC (asd__!96a5a212@gateway/web/freenode/ip.150.165.162.18)
17:01
<alkisg>
sutula: do you have access to the client via epoptes?
17:01
<sutula>
All the above used to be working...no lts.conf changes afaict
17:02
alkisg: Not immediately...need to rebuild non-working image and deploy before I can test, unless there's a quick way to use the image I built before the revert.
17:02
<alkisg>
Yes, ltsp-update-image -r /
17:02
This reverts to the previous version
17:02
(only the working and the previous versions are kept; none before the previous one)
17:03
<sutula>
OK, will come back
17:03
<alkisg>
Anyway, if you can get access ping me to check this remotely, I think it'll be 10 times faster that way
17:08asd__ has left IRC (asd__!96a5a212@gateway/web/freenode/ip.150.165.162.18, Ping timeout: 260 seconds)
17:13
<sutula>
alkisg: http://termbin.com/l23c
17:15
fwiw, the RM_SYSTEM_SERVICES of minetestserver doesn't work :-( but that's a little problem for me to understand later
17:20* sutula figures out that "minetestserver" --> "minetest-server", probably, based on what's listed in the services subdirectory...will change that later
17:23lucascastro has joined IRC (lucascastro!~lucas@170.78.53.20)
17:25
<alkisg>
sutula: lts.conf seems ok
17:26
<sutula>
alkisg: Is there a mount command I can try to get some diagnostics?
17:27
<alkisg>
sutula: you can manually test sshfs, yes, it's easy to google for a command if you don't know how
17:27
sshfs username@server: /home/localdir or something
17:28
<sutula>
trying
17:30
alkisg: So for example, sshfs sutula@server:/home/sutula /tmp/sutula does mount fine. It prompts for a password.
17:33
alkisg: I think I have a mess on my hands that may be of my own making, but thought it was working. It has to do with where the home directories are located on my filesystems.
17:34
On the thin client even without the sshfs mount, I am seeing the symlink from /home to the actual disk where the home directories are located.
17:35
Of course, the client doesn't have that filesystem mounted.
17:35
<vagrantc>
ah, yes.
17:35
our homedir mounting is rather simplistic
17:35
<sutula>
Still, sshfs should be able to work (and probably was working) but maybe now the ltsp-manager is getting confused about what to mount.
17:36
<vagrantc>
but the symlink is kind of messy
17:36
ltsp-manager doesn't handle the mounting ... does it?
17:36
it's just basically a frontend to ltsp-update-image and adduser type stuff
17:36
<sutula>
What's the "most supportable way" to handle the case where /home --> /somewhere else?
17:37
I'm guessing I could add a manual mount to lts.conf
17:37
?
17:37
<vagrantc>
/home is a symlink?
17:37
or /home/user is a symlink?
17:37
<sutula>
The first, /home is a symlink
17:38
<vagrantc>
huh ... would think that would work...
17:38
since you're mounting /home/user
17:38
<sutula>
...and it was :)
17:39
vagrantc: Symptom right now is that after rebuilding a new image, either the user's home fails to mount via sshfs or maybe it's not even trying to mount...not sure yet
17:39
<vagrantc>
ah.
17:39
<sutula>
Does the client log it's actions somewhere?
17:40
<vagrantc>
mount -o loop /opt/ltsp/amd64.img /mnt .... ls -l /mnt/home
17:41
sutula: i'm guessing this is an issue during image creation
17:41
but it could also be during boot ...
17:42* vagrantc wonders if bind-mounting /home rather than symlinking it would work better
17:42
<vagrantc>
you still might end up with the homedirs copied into the image in the other location, though
17:43
<sutula>
vagrantc: I could exclude them both...have already added some exclusions
17:43
The bind-mounting is an interesting idea and would cut through one layer of OS redirection.
17:43
<vagrantc>
at any rate, identifing what the problem really is before changing things would be good. :)
17:44taterme has joined IRC (taterme!~ident@2602:30a:c067:8a30:214:d1ff:fe3a:f0ac)
17:44
<sutula>
vagrantc: Can you point me to the code that's getting executed on the client at boot time, so I can dig in and see what's happening?
17:44
<vagrantc>
would give a slight performance boost, probably ... as it would entirely remove resolving the symlink
17:44
sutula: i'm more interested in looking at what's in the image's /home
17:45
<sutula>
oh I see, per your prior comment. Now I understand what you meant.
17:47
<vagrantc>
but, dpkg -S localapps ... look for something in ldm rc.d or something
17:47
that should tell you the code to look in
17:48
dpkg -S X01-localapps
17:48
<sutula>
vagrantc: OK, I can see the difference between working and nonworking.
17:48
The working image has /home as an empty directory
17:49
the non-working one has copied the symlink
17:49
which is going to break, obviously, when it tries to sshfs mount the home of the user being logged in.
17:50
<vagrantc>
as long as /home points to another directory in the image, it should be fine
17:50
bind-mounting should work around it anyways
17:50
<sutula>
Right, but it points to a subdirectory that's not mounted on the client.
17:50
I'll try the bind-mount...thanks for the idea!
17:51
<vagrantc>
an empty subdirectory on the client should be fine
17:51
<alkisg>
INIT_COMMAND_CREATE_HOME="mkdir -p /actual/home/dir"
17:51
<vagrantc>
or that
17:51
<alkisg>
This should help in quickly un-breaking the symlink
17:51
<vagrantc>
i bet you'll get slightly better performance with bind-mounts ... but maybe not enough to warrant anything
17:52
alkisg, as usual, has an elegant workaround :)
17:52
<sutula>
I like the bind-mount because it will also avoid similar problems to the above, in other subsystems.
17:52
OK, anyway, thanks very much guys!!!
17:52
<alkisg>
Just include the dir in the original file system
17:52* vagrantc wonders what changed that made it break
17:52
<alkisg>
As long as an empty dir of the symlink target is there, it should work
17:53
<sutula>
vagrantc: I'm guessing I built an image, then did all the moving around of the home directories as I was working on the disk config.
17:53
<vagrantc>
sutula: new OS version or something? or just one day it stopped working?
17:53
ah
17:53
<sutula>
The next build after that never worked.
17:53
<vagrantc>
that makes sense
17:54
<sutula>
Again, thanks. You guys are awesome.
17:54
<alkisg>
We're using mkdir -p to create the home dir
17:54
If that's inside a broken symlink, it doesn't work
17:54
It's a user error, it's too much to recursively remove broken symlinks...
17:54
Of course better error messages would help :)
17:56
<sutula>
alkisg: I also never tried epoptes (didn't get that far before) and am truly amazed with the functionality.
17:58
<alkisg>
Eh, just the basic tasks a teacher and a sysadmin need from the computer lab :)
18:06
<vagrantc>
alkisg: don't know if you saw or much care, but i converted ltspfs to python3 :)
18:06
alkisg: it was pretty trivial ... just running 2to3 on them ...
18:22
alkisg: i'm thinking i'd like to work on a new ltsp and/or ldm upload soonish ...
18:28
<alkisg>
vagrantc: sound nice! Did you test ltspfs to see if it still works?
18:29
<vagrantc>
alkisg: yes, i even tested it. :)
18:30
alkisg: i'm fairly sure it would actualyl work with either python 2 or python3, technically, but i "forced" the issue with /usr/bin/python3
18:30
i suppose upstream would be better to not force it that way
18:30
since there are some distros where bin/python >= 3
18:30
<alkisg>
Nah I'm very fine with dropping support for anything pre-16.04 or pre-stretch :)
18:30
pre systemd etc etc
18:31
Eh ok now I got it, but i'm still ok with it :D
18:32
<vagrantc>
you don't really use ltspfs, anyways
18:32
but i'd like to try and do the same for ldm ... not sure if there's any python in ltsp
18:32
<alkisg>
I think some things for cluster? Or those are not upstream?
18:32
<vagrantc>
ah, jetpipe
18:32
not upstream
18:32
<alkisg>
That too, right
18:34
!print
18:34
<ltsp>
I do not know about 'print', but I do know about these similar topics: 'fatclient-printers', 'printer'
18:34
<alkisg>
!printer
18:34
<ltsp>
printer: Quick how-to: RCFILE_01="/usr/sbin/jetpipe /dev/usb/lp0 9100 &" in lts.conf, reboot client, then go to server's add printer dialog, and specify network printer → jetdirect → ltsp123.local
18:34
<alkisg>
!jetpipe
18:34
<ltsp>
jetpipe: (#1) Jetpipe -script has founded to be unstable in some cases. You can try C written (but limited) Jetpipe from GitHub https://github.com/bilange/jetpipe or switch it to USB/IP and use these scripts http://pastebin.com/Ltdi2TCL Support AIO devices as well., or (#2) jetpipe has a bug in some Ubuntu versions, to manually start it, put something like this in lts.conf: RCFILE_01="/usr/sbin/jetpipe /dev/usb/lp0 9100 &"
18:35
<alkisg>
What was the other one called... that is packaged for debian... p<somenumber...>
18:35
<vagrantc>
p910nd
18:36
i think they all lack some feature the others support, of course :)
18:37
wouldn't cups work out of the box for most usb printers?
19:02
<alkisg>
It's hard to install drivers on fat clients
19:03
It's more convenient to forward the printers to the server and share them from there
19:04
<vagrantc>
ah
19:14
<sutula>
Doesn't happen by default so maybe add a note in the wiki to share out the cups printers (based on my recent experience).
19:27
<vagrantc>
well, i think cups is prevented from starting on clients by default
19:31
<alkisg>
ltsp doesn't modify the server. ltsp-manager should run cupsctl _share_printers=1 on initial-setup...
19:52lucascastro has left IRC (lucascastro!~lucas@170.78.53.20, Remote host closed the connection)
19:52Statler has left IRC (Statler!~Georg@p579FF4E1.dip0.t-ipconnect.de, Remote host closed the connection)
20:39ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
20:48bella^Gestor has joined IRC (bella^Gestor!bf36169f@gateway/web/freenode/ip.191.54.22.159)
21:07
<bella^Gestor>
I'm running Ubuntu 17.04. I installed ltsp-manager from the greek schools repo (16.04 package). No joy. I've even installed virtualbox on the same machine to try to boot via ipxe. I saw the <next-server> value, which should be the tftp server, hasn't been specified. Any suggestions? How can I confirm that my LTSP server setup is running correctly?
21:09
BTW, I must use a non-modifiable DHCP server running on an ISP-provided router.
21:53lucascastro has joined IRC (lucascastro!~lucas@138.68.106.79)
22:14Freejack has left IRC (Freejack!~quassel@unaffiliated/freejack, Ping timeout: 264 seconds)
22:18Freejack has joined IRC (Freejack!~quassel@unaffiliated/freejack)
22:20alazyworkaholic has joined IRC (alazyworkaholic!~alan@191.54.9.85)
22:21
<vagrantc>
bella^Gestor: it fails to boot at all?
22:25ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 246 seconds)
22:26ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
22:27
<alazyworkaholic>
vagrantc: Hi, I'm the same person as bella^gestor - different location now, trying to set it up with a different machine. No, it doesn't even boot. On a real machine on the same lan, I am not sure the DHCP gets assigned at all. With iPXE via virtualbox, I confirmed that at least it gets a DHCP address from the router.
22:32
<vagrantc>
alazyworkaholic: is dnsmasq running? did it configure anything in /etc/dnsmasq.d/ltsp* ?
22:38
<alazyworkaholic>
vagrantc: I'm starting over just now on another computer. I think dnsmasq may have been the problem, but I'm not sure. During ltsp-manager installation I saw there was a part where a file related to dnsmasq or dhcp was configured, but errors occured. (not sure exactly which file, I may see it again as I progress here now). Nonetheless, the file, which specified dhcp address ranges / proxy among other things, was created & looked ok to a la
22:38
yman (me).
22:39taterme has left IRC (taterme!~ident@2602:30a:c067:8a30:214:d1ff:fe3a:f0ac, Remote host closed the connection)
22:44
<alazyworkaholic>
vagrantc: I have (and would rather not mess with too much) a consumer-grade router that is the LAN's DHCP server. How can I confirm whether dnsmasq is running correctly?
22:51
Earlier I tried to set it up following a mismatched bundle of tutorials, forum posts, etc. I'm starting over now. I've added the ts.sch.gr ppa, which gives me ltsp-manager. I'll just install that now.
22:51
If you have any other advice for a fresh setup, please tell.
23:30
help?
23:44
So far I have installed ltsp-manager with all its dependencies & ran its initial setup via the GUI. I also just ran #~ ltsp-config dnsmasq, which created /etc/dnsmasq.d/ltsp-server-dnsmasq.conf. I commented out this line of the file, under # IP ranges to hand out. dhcp-range=192.168.67.20,192.168.67.250,8h. I then ran #~ /etc/init.d/dnsmasq stop (then start).
23:46
My iPXE boot client now gets as far as seeing that the Next server = 192.168.1.100, which is the server (so it's correct).
23:46
The next line is Filename: /ltsp/amd64/pxelinux.0, but that file doesn't exist.
23:48
I've also just Disabled the DNS server functionality of dnsmasq by uncommenting the line port=0 in the /etc/dnsmasq.d/ltsp-server-dnsmasq.conf file.
23:48
<vagrantc>
alazyworkaholic: sorry, was away a bit
23:48
and need to leave soon
23:49
<alazyworkaholic>
vagrantc: No problem. It's not terribly urgent. Could you can come back within the next days and look at the IRC log? I'll keep posting my attempts.
23:49
<vagrantc>
alazyworkaholic: ltsp-manager should have run ltsp-config for you ... and the dhcp-range stuff shouldn't need to be commented out, unless you're actually running something in the 192.168.67.* range
23:50
alazyworkaholic: the whole point of ltsp-manager is so you don't have to run anything manually :)
23:50
alazyworkaholic: so if you need to do manual steps, please report bugs :)
23:51
alazyworkaholic: alkisg is more familiar with ltsp-manager ... but i need to bring myself up to speed on it
23:51
<alazyworkaholic>
vagrantc: Ok, I'll try to document my steps and report anything that doesn't seem to be my fault.
23:51
<vagrantc>
alkisg: reminds me, do you have anything you'd like to include in a new upload of ltsp-manager yet?
23:51
alkisg: it's still sitting in NEW for review ... would be good to get another version in soonish
23:52* vagrantc waves
23:52vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)