IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 21 September 2017 (all times are UTC)
| 00:23 | ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection) | |
| 00:33 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 01:02 | mmarconm has left IRC (mmarconm!~mmarconm@191.217.39.241, Ping timeout: 248 seconds) | |
| 01:50 | adrianor1 has joined IRC (adrianor1!~adrianorg@177.156.63.127) | |
| 01:53 | adrianorg has left IRC (adrianorg!~adrianorg@189.58.238.64.dynamic.adsl.gvt.net.br, Ping timeout: 248 seconds) | |
| 02:27 | dgroos 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:52 | dgroos_ has joined IRC (dgroos_!~dagro001@63.225.132.145) | |
| 02:54 | dgroos has left IRC (dgroos!~dagro001@vpn.mpls.k12.mn.us, Ping timeout: 240 seconds) | |
| 02:54 | dgroos_ is now known as dgroos | |
| 03:00 | dgroos has left IRC (dgroos!~dagro001@63.225.132.145, Quit: dgroos) | |
| 04:52 | Statler has joined IRC (Statler!~Georg@p579FE005.dip0.t-ipconnect.de) | |
| 05:55 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 06:05 | fnurl has left IRC (fnurl!~fnurl@36-231-218-223.dynamic-ip.hinet.net, Read error: Connection reset by peer) | |
| 06:05 | fnurl has joined IRC (fnurl!~fnurl@1-160-58-134.dynamic-ip.hinet.net) | |
| 06:36 | mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk) | |
| 07:17 | Statler has left IRC (Statler!~Georg@p579FE005.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 07:37 | markit has joined IRC (markit!~marco@host179-38-static.243-95-b.business.telecomitalia.it) | |
| 07:42 | Statler has joined IRC (Statler!~Georg@p579FF4E1.dip0.t-ipconnect.de) | |
| 09:54 | ricotz_ has joined IRC (ricotz_!~ricotz@p5B2A9A59.dip0.t-ipconnect.de) | |
| 09:54 | ricotz_ has joined IRC (ricotz_!~ricotz@ubuntu/member/ricotz) | |
| 09:54 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Ping timeout: 248 seconds) | |
| 13:34 | eu^851015366dyna has joined IRC (eu^851015366dyna!55653542@gateway/web/freenode/ip.85.101.53.66) | |
| 13:34 | <eu^851015366dyna> hi
| |
| 13:35 | hii
| |
| 13:35 | eu^851015366dyna has left IRC (eu^851015366dyna!55653542@gateway/web/freenode/ip.85.101.53.66, Client Quit) | |
| 13:41 | lucascastro has joined IRC (lucascastro!~lucas@189.90.38.210.jupiter.com.br) | |
| 14:21 | mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving) | |
| 15:17 | ricotz_ 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:41 | lucascastro has left IRC (lucascastro!~lucas@189.90.38.210.jupiter.com.br, Remote host closed the connection) | |
| 15:51 | markit 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:31 | vagrantc 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:01 | asd__ 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:08 | asd__ 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:23 | lucascastro 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:44 | taterme 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:52 | lucascastro has left IRC (lucascastro!~lucas@170.78.53.20, Remote host closed the connection) | |
| 19:52 | Statler has left IRC (Statler!~Georg@p579FF4E1.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 20:39 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 20:48 | bella^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:53 | lucascastro has joined IRC (lucascastro!~lucas@138.68.106.79) | |
| 22:14 | Freejack has left IRC (Freejack!~quassel@unaffiliated/freejack, Ping timeout: 264 seconds) | |
| 22:18 | Freejack has joined IRC (Freejack!~quassel@unaffiliated/freejack) | |
| 22:20 | alazyworkaholic has joined IRC (alazyworkaholic!~alan@191.54.9.85) | |
| 22:21 | <vagrantc> bella^Gestor: it fails to boot at all?
| |
| 22:25 | ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 246 seconds) | |
| 22:26 | ogra_ 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:39 | taterme 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:52 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |