IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 13 June 2019 (all times are UTC)
| 00:03 | yanu_ has left IRC (yanu_!~yanu@178-116-60-189.access.telenet.be, Ping timeout: 252 seconds) | |
| 00:04 | yanu has joined IRC (yanu!~yanu@178-116-60-189.access.telenet.be) | |
| 00:48 | master has joined IRC (master!521d0db3@gateway/web/freenode/ip.82.29.13.179) | |
| 00:48 | master has left IRC (master!521d0db3@gateway/web/freenode/ip.82.29.13.179, Client Quit) | |
| 00:49 | masterchild has joined IRC (masterchild!521d0db3@gateway/web/freenode/ip.82.29.13.179) | |
| 00:49 | <masterchild> hi everybody
| |
| 00:49 | masterchild has left IRC (masterchild!521d0db3@gateway/web/freenode/ip.82.29.13.179, Client Quit) | |
| 02:13 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 04:26 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3105:3300:d0a7:2240:510:3d60) | |
| 04:50 | quinox has left IRC (quinox!~quinox@ghost.qtea.nl, Quit: WeeChat 2.4) | |
| 04:52 | quinox has joined IRC (quinox!~quinox@ghost.qtea.nl) | |
| 05:04 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 245 seconds) | |
| 06:06 | <fiesh> after gentoo's lib-location refactor, /usr/lib contains the 32 bit libraries, and /usr/lib64 the 64 bit ones. But ldm on our clients still searches for plugins in /usr/lib/ldm instead of /usr/lib64/ldm
| |
| 06:07 | But I can't find where that's configured or which binary contains this path...
| |
| 06:10 | hmm I guess part of the problem is that our ldm binary is from 2015 and not even available any more in portage... I should fix that or it's bound to break like it does right now at some point
| |
| 06:13 | hmm there seems to be no more gentoo support at all?
| |
| 06:30 | kjackal has left IRC (kjackal!~quassel@2a02:587:3105:3300:d0a7:2240:510:3d60, Ping timeout: 258 seconds) | |
| 06:37 | woernie has joined IRC (woernie!~werner@p50867386.dip0.t-ipconnect.de) | |
| 06:42 | quentinb has joined IRC (quentinb!66a55e06@gateway/web/freenode/ip.102.165.94.6) | |
| 06:51 | <fiesh> compiling it by hand worked fine, but now I get "CRITICAL: no Xsession"
| |
| 06:53 | judging by the source, LDM_XSESSION is missing?
| |
| 06:56 | quentinb has left IRC (quentinb!66a55e06@gateway/web/freenode/ip.102.165.94.6, Ping timeout: 256 seconds) | |
| 06:57 | <fiesh> hmm and setting it in lts.conf "fixes" the problem, X starts, but it seems ~/.xsession isn't executed since I just get an xterm
| |
| 07:00 | ok I guess my ldminfod is somehow broken
| |
| 07:01 | quentinb has joined IRC (quentinb!66a55e06@gateway/web/freenode/ip.102.165.94.6) | |
| 07:01 | stellasolitaria has joined IRC (stellasolitaria!~jhonny5@159.213.93.166) | |
| 07:03 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 07:04 | <alkisg> Hi quentinb
| |
| 07:05 | <fiesh> so I guess I need to fix my ldminfod
| |
| 07:05 | <alkisg> fiesh: maybe just use a symlink to the new path?
| |
| 07:05 | <fiesh> alkisg: yeah I thought about that, but given that the ldm is so outdated, I want to see how to update it properly, eventually everything rots if you can't update it ;)
| |
| 07:06 | <alkisg> fiesh: I did manage to completely avoid ldm in ltsp19, so hopefully you won't have to bother anymore
| |
| 07:06 | <fiesh> oh!
| |
| 07:06 | that would be nice
| |
| 07:06 | <alkisg> You'll be able to use the DM of your choice
| |
| 07:06 | <fiesh> then I'll have to choose -- I probably will go for xdm :-)
| |
| 07:06 | but I guess ldminfod should still work properly
| |
| 07:06 | <alkisg> No ldminfod at all
| |
| 07:07 | The new ltsp doesn't have any code from the old one
| |
| 07:07 | <fiesh> oh that's nice
| |
| 07:07 | <alkisg> no ldm, ltspfs, remote/localapps, thin clients...
| |
| 07:07 | <fiesh> fiesh@wsbox /tmp % git clone https://git.launchpad.net/\~natureshadow/ltsp
| |
| 07:07 | ...
| |
| 07:07 | warning: remote HEAD refers to nonexistent ref, unable to checkout.
| |
| 07:07 | <quentinb> did you see my email plans for today
| |
| 07:08 | <alkisg> fiesh: That's some unrelated user's repository; why are you looking at that
| |
| 07:08 | quentinb: let's talk in the private tab
| |
| 07:08 | <fiesh> alkisg: oh, lol
| |
| 07:08 | because I've never used launchpad before and am too dumb for it's UI :)
| |
| 07:08 | <alkisg> ltsp19 = github
| |
| 07:09 | ltsp5 = launchpad
| |
| 07:09 | So we won't even be using launchpad anymore
| |
| 07:09 | <fiesh> that's great
| |
| 07:09 | is ltsp19 already production ready?
| |
| 07:09 | <alkisg> fiesh: the only things that I saw so far that will need distro-specific love, are the initrd (I didn't do dracut yet) and pam
| |
| 07:09 | <fiesh> because then I might switch now just as well
| |
| 07:09 | <alkisg> No no it's in the early implementation phase, but all the design issues have been addressed and no blockers remain
| |
| 07:10 | <fiesh> ah ok
| |
| 07:10 | then I need to fix ldminfod for now ;)
| |
| 07:10 | <alkisg> E.g. currently I've booted "kubuntu.iso" and logged in via lightdm/pam/sshfs using the new code
| |
| 07:10 | <fiesh> heh ok
| |
| 07:10 | <alkisg> Yes, fix ldminfod or use the old one and a symlink
| |
| 07:10 | I.e. no need to "fix ldm" if the old one will work for 2 months more
| |
| 07:11 | <fiesh> % telnet localhost 9571
| |
| 07:11 | Trying ::1...
| |
| 07:11 | Connected to localhost.
| |
| 07:11 | Escape character is '^]'.
| |
| 07:11 | File "/usr/sbin/ldminfod", line 186
| |
| 07:11 | print "ERROR: failed to run locale"
| |
| 07:11 | ^
| |
| 07:11 | SyntaxError: Missing parentheses in call to 'print'. Did you mean print("ERROR: failed to run locale")?
| |
| 07:11 | I'm surprised the old image still works without ldminfod working correctly
| |
| 07:11 | didn't notice it break
| |
| 07:12 | <alkisg> Sounds like it's using python2 and you have python3?
| |
| 07:12 | <fiesh> ah hmm both are installed, but it defaults to python3
| |
| 07:12 | does it need python2?
| |
| 07:12 | <alkisg> Let me check, that's ancient code, probably
| |
| 07:12 | <fiesh> I can just change its she-bang then
| |
| 07:13 | hurray :)
| |
| 07:13 | that helped
| |
| 07:13 | <alkisg> fiesh: my version is python3 and doesn't have that print
| |
| 07:13 | <fiesh> thanks!
| |
| 07:13 | strange
| |
| 07:13 | <alkisg> So you can get the newer version instead
| |
| 07:13 | <fiesh> hmm I can try updating as well, yeah
| |
| 07:13 | % find . -name ldminfod
| |
| 07:13 | ./server/k12linux/scripts/chkconfig.d/ldminfod
| |
| 07:13 | ./server/Redhat/scripts/chkconfig.d/ldminfod
| |
| 07:13 | one of these?
| |
| 07:14 | <alkisg> !ltsp-source
| |
| 07:14 | <ltsp> ltsp-source: at https://code.launchpad.net/ltsp
| |
| 07:14 | <alkisg> wait
| |
| 07:14 | !ldm-source
| |
| 07:14 | <ltsp> ldm-source: at https://code.launchpad.net/~ltsp-upstream/ltsp/+git/ldm
| |
| 07:14 | <fiesh> that's the repo I cloned
| |
| 07:14 | oh it's with ldm
| |
| 07:15 | hmm the link seems to not work
| |
| 07:15 | well I'll just go with the python2 hack then
| |
| 07:20 | ok it seems there's some other issue, because ldm doesn't seem to care if ldminfod works or not -- so I'll "fix" it in lts.conf for now
| |
| 07:21 | alkisg: also, if you're starting from scratch with ltsp19 and require a build tool; we've had our fair share of experiences with all sort of build tools, from GNU and bsd make (omg) to scons (omg omg) to cmake (ok), and now arrived at meson. It's the first build system that actually doesn't suck
| |
| 07:21 | <alkisg> fiesh: no compiled code now at all
| |
| 07:21 | So, no build tool
| |
| 07:21 | <fiesh> oh that's even better
| |
| 07:21 | <alkisg> You'll be able just download a folder
| |
| 07:21 | <fiesh> if I can pull from a git repo instead, then I'm super happy :-)
| |
| 07:22 | <alkisg> You will
| |
| 07:22 | I want to make sure that it runs from git; you'll only need to symlink /usr/bin/ltsp to /your-git-dir/ltsp.sh
| |
| 07:27 | <fiesh> that's great
| |
| 07:27 | ok setting LDM_XSESSION doesn't work either...
| |
| 07:27 | I guess I'll revert and set the (wrong) symlink as a workaround for now
| |
| 07:28 | <alkisg> Yeah it's not worth investing time in ldm
| |
| 07:37 | kjackal has joined IRC (kjackal!~quassel@195.97.13.252) | |
| 07:44 | <fiesh> fml it still won't work, the 'no Xsession' remains, must be something else...
| |
| 07:46 | !ldm-source should point to "git.", not "code." btw
| |
| 07:46 | <ltsp> Error: "ldm-source" is not a valid command.
| |
| 07:49 | woernie has left IRC (woernie!~werner@p50867386.dip0.t-ipconnect.de, Ping timeout: 272 seconds) | |
| 07:49 | quentinb has left IRC (quentinb!66a55e06@gateway/web/freenode/ip.102.165.94.6, Quit: Page closed) | |
| 07:50 | <fiesh> could this line be related?
| |
| 07:50 | su - ${LDM_USERNAME} -c "$CLIENT_ENV $MY_LANG DISPLAY=$DISPLAY ICEAUTHORITY=$ICEAUTHORITY XAUTHORITY=$XAUTHORITY $LDM_XSESSION $LDM_SESSION"
| |
| 07:50 | it changed in X95-run-x-session
| |
| 07:50 | or rather was removed
| |
| 07:51 | <alkisg> fiesh: removed? you don't have a "su" line now?
| |
| 07:52 | <fiesh> ah sorry, it starts with XDG_SEAT now
| |
| 07:52 | no, I still have it, my bad ;)
| |
| 07:53 | <alkisg> Do you have a VM for testing? Do you want help over VNC?
| |
| 07:53 | <fiesh> ok that was bs, that's not the reason
| |
| 07:53 | I have an nbd image, no VM though
| |
| 07:53 | <alkisg> Hmm hard to remotely check the client side then...
| |
| 07:53 | <fiesh> the latter would be great, not sure how to do it though seeing that I can't really log in from the client
| |
| 07:53 | <alkisg> I'm guessing no epoptes too, right?
| |
| 07:53 | <fiesh> no alas not
| |
| 07:54 | it seems to me that the client doesn't poll ldminfod
| |
| 07:54 | <alkisg> Can you try changing your xsession to plain xterm, and see if you can at least get a post-login shell?
| |
| 07:54 | <fiesh> and it seems that might have been the case before as well, actually
| |
| 07:54 | <alkisg> Fat clients are supposed to run ldminfod locally
| |
| 07:54 | <fiesh> oh!
| |
| 07:54 | ok let me try re-installing it then
| |
| 07:54 | wait, and the server doesn't need to run it then?
| |
| 07:56 | ldminfod isn't even running on our working image
| |
| 07:57 | <alkisg> fiesh: thin clients query the server's ldminfod over tcp
| |
| 07:57 | fat clients run ./ldminfod locally
| |
| 07:57 | And that way, both get the session information
| |
| 07:57 | So you need the ldminfod binary, but you don't need xinetd or anything
| |
| 07:57 | And, only on the image, not on the server
| |
| 07:58 | <fiesh> ah ok
| |
| 07:58 | then I can remove xinetd again ;)
| |
| 07:58 | <alkisg> :D
| |
| 07:58 | <fiesh> ok /usr/share/ldm/ldminfod works
| |
| 07:59 | <alkisg> Hopefully ltsp19 will be much more gentoo-friendly, once it supports dracut and the pam config
| |
| 08:00 | <fiesh> hmm guess I'll take you up on the remote help offer -- I'll rebuild the image once more and boot into it and get an xterm going
| |
| 08:00 | <alkisg> Put x11vnc to it too
| |
| 08:00 | <fiesh> yeah I'd be super happy if that was the case ;)
| |
| 08:00 | already installed
| |
| 08:00 | <alkisg> and maybe screen/socat for terminal sharing
| |
| 08:01 | <fiesh> got tmux
| |
| 08:01 | <alkisg> My script doesn't support tmux :P
| |
| 08:01 | <fiesh> omg haha
| |
| 08:01 | ok how badly do you need it?
| |
| 08:01 | <alkisg> Oh only if you want to share a terminal with me
| |
| 08:01 | If you can share graphics, it's enough
| |
| 08:02 | Will you be able to export DISPLAY and run xterm on top of ldm and share X over vnc? then that's enough
| |
| 08:02 | <fiesh> we'll give it a shot, then try tmux, if that doesn't work, I'll install archaic software like screen ;)
| |
| 08:02 | I should be
| |
| 08:02 | <alkisg> OK that's fine then, no need for more
| |
| 08:03 | (socat/screen is what I used in epoptes when I coded that part years ago; so I have the server-side ready for incoming connections...)
| |
| 08:10 | <fiesh> man sometimes ionice drives me up the wall...
| |
| 08:10 | I've been stuck at 99% building the image for ages because the box is slightly busy due to someone else
| |
| 08:10 | hurray now
| |
| 08:19 | ok, back from within a tiny failsafe xterm
| |
| 08:19 | symlinking /usr/lib64/X11 to /usr/lib/X11 also doesn't appear to help
| |
| 08:21 | alkisg: please let me know when you're ready
| |
| 08:21 | <alkisg> fiesh: ok we can do it now
| |
| 08:21 | x11vnc -connect srv1-dide.ioa.sch.gr
| |
| 08:21 | We'll need another one :P
| |
| 08:23 | fiesh: how did you get the xterm?
| |
| 08:23 | <fiesh> heh ok, now I can see the chat ;)
| |
| 08:23 | hmm but tmux in tmux sucks
| |
| 08:23 | <alkisg> Do you have ssh access to the client?
| |
| 08:23 | Maybe it would be better to share the server screen, and share an ssh term from there?
| |
| 08:37 | <fiesh> hmm ok, so here are some observations:
| |
| 08:37 | selecting spectrwm as the session and starting work -- but somehow the xresources seem to be ignored because my font choice and colors are all wonky in xterm
| |
| 08:38 | selecting the default session leads to the comic sans style session choice dialog that I can't quite figure out what it's good for
| |
| 08:38 | and selecting Xsession as session leads to the same behavior
| |
| 08:38 | <alkisg> Do you set LDM_SESSION or something in lts.conf?
| |
| 08:38 | And if so, to what?
| |
| 08:39 | <fiesh> no, all unset
| |
| 08:39 | <alkisg> How are you setting xresources, from the environment or from files?
| |
| 08:39 | <fiesh> just by having them in .Xresources, they're picked up by something, not quite sure what tbh
| |
| 08:40 | (but that's always been the case as long as I can remember, not just with ltsp but any x session)
| |
| 08:40 | <alkisg> Do all your users use zsh?
| |
| 08:40 | <fiesh> some use bash
| |
| 08:40 | <alkisg> In zsh, does "exec .xsession" work?
| |
| 08:40 | <fiesh> I can restart the vnc session
| |
| 08:40 | <alkisg> I tried ". .xsession" and it didn't; while "source .xsession" did
| |
| 08:41 | Sure
| |
| 08:43 | Funny that "exec .xsession" works from zsh, without shebang, without the file being executable :D
| |
| 08:45 | bcg has left IRC (bcg!~b@dfx4btyyyyyyyyyyyyyyt-3.rev.dnainternet.fi, Quit: bcg) | |
| 08:46 | <alkisg> fiesh: ah btw can you temporarily try if it works fine with bash?
| |
| 08:48 | <fiesh> alkisg: no observable difference
| |
| 08:50 | bcg has joined IRC (bcg!~b@82-128-241-5.bb.dnainternet.fi) | |
| 08:54 | <fiesh> alkisg: sorry, back at desk
| |
| 08:56 | stellasolitaria has left IRC (stellasolitaria!~jhonny5@159.213.93.166, Ping timeout: 245 seconds) | |
| 09:04 | <alkisg> fiesh: so now /tmp/out will tell us what the default session tries to run
| |
| 09:05 | Did the spectrwm session work fine in the past, or you never tried it before?
| |
| 09:07 | <fiesh> alkisg: had to fix the script, somethign wasn't right -- I have no idea if it used to work, we've never used anything but the default session... I actually never even noticed you could change sessions there until now ;)
| |
| 09:15 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 09:17 | <fiesh> alkisg: chooser, chooser, session
| |
| 09:17 | <alkisg> Meh, two choosers
| |
| 09:27 | fiesh: I'm thinking it's all because your .xsession isn't +x ?
| |
| 09:28 | <fiesh> it could be -- I'll change it really quickly and see
| |
| 09:28 | that's so weird, I've never had my .xsession executable in my whole life ;)
| |
| 09:29 | oh boy it works
| |
| 09:29 | <alkisg> The Xsession script tests for -x
| |
| 09:29 | <fiesh> but how could that have been introduced recently!?
| |
| 09:29 | so strange
| |
| 09:29 | do I even need a shebang?
| |
| 09:29 | <alkisg> So you either need to change the Xsession script, or your .xsession
| |
| 09:29 | Normally yes, but zsh works without it
| |
| 09:29 | So it's best to make it +x AND put a shebang
| |
| 09:29 | More compatible with anything
| |
| 09:29 | <fiesh> yeah, I'll change that for all users
| |
| 09:30 | so strange
| |
| 09:30 | man
| |
| 09:30 | <alkisg> Btw also test after client reboot
| |
| 09:30 | Because we did a lot of temporary changes there
| |
| 09:30 | <fiesh> yeah, I'll reboot really quickly and see
| |
| 09:32 | <alkisg> Btw that funny dialog was xsm... I don't know all that ancient stuff, it was before my time :D
| |
| 09:32 | <fiesh> hah yeah, it's funny, and it does look like comic sans
| |
| 09:32 | ok doesn't work after reboot :-(
| |
| 09:33 | <alkisg> VNC again and let's see
| |
| 09:33 | <fiesh> symlinking /usr/lib64/X11 to /usr/lib/X11 doesn't change that
| |
| 09:37 | <alkisg> Oh
| |
| 09:37 | <fiesh> now it worked
| |
| 09:37 | <alkisg> fiesh: I forgot the 'set -x' part
| |
| 09:37 | haha
| |
| 09:37 | ok vnc to see
| |
| 09:40 | kjackal has left IRC (kjackal!~quassel@195.97.13.252, Read error: Connection reset by peer) | |
| 09:40 | kjackal has joined IRC (kjackal!~quassel@195.97.13.252) | |
| 09:41 | <fiesh> and again it works, hehe
| |
| 09:42 | <alkisg> fiesh: so, to sum up, it doesn't work the first time but it works all the rest ones?
| |
| 09:42 | Without us touching anything?
| |
| 09:42 | Reboot and test...
| |
| 09:42 | <fiesh> ok
| |
| 09:42 | I'll give it a shot
| |
| 09:43 | <alkisg> Try: default, default (if it works we're done, if it doesn't continue), spectrwm, default
| |
| 09:44 | Btw I love it that I say one thing and you understand three; it saves a lot of time! :)
| |
| 09:45 | <fiesh> haha that's good :-)
| |
| 09:45 | ok so here's what's happens:
| |
| 09:45 | *without* the symlink from /usr/lib64/X11 to /usr/lib: nothing works, neither default session nor spectrwm
| |
| 09:45 | <alkisg> That seems hardcoded in some script
| |
| 09:45 | <fiesh> *with* the symlink: default session doesn't work on the first try, but works on second try
| |
| 09:45 | <alkisg> OK so we need debug info from the first login
| |
| 09:46 | Sooo... you'd need to....
| |
| 09:46 | Reboot and verify that: symlink, spectrwm, then default => fails
| |
| 09:46 | <fiesh> and then evaluate the xsession-errors?
| |
| 09:46 | <alkisg> And if that the case, reboot again, and vnc at the spectrwm step, so that I put debug info right before it fails
| |
| 09:47 | Unfortunately your xsession removes the last .xsession-errors
| |
| 09:47 | That's why I need to put those set -x etc there
| |
| 09:47 | <fiesh> heh ok, one thing I am uncertain about now though: *maybe* the spectrwm session only ever worked because I always tried it second?
| |
| 09:47 | <alkisg> Maybe
| |
| 09:47 | <fiesh> but I'll reboot now and save the .xession-errors after the first try
| |
| 09:48 | <alkisg> OK
| |
| 09:54 | So maybe your startup scripts have a race condition there, and spectre exits on error
| |
| 09:55 | It would also be interesting to see if the spectre SESSION works on the first try
| |
| 09:59 | <fiesh> ok so to rule out spectrwm is the problem, I changed the .xsession
| |
| 09:59 | <alkisg> OK; and does it start with the first try?
| |
| 10:04 | <fiesh> oh man, exact same behavior with xterm, nothing is logged to xsession-errors :(
| |
| 10:04 | will you be here in like 30 minutes?
| |
| 10:04 | <alkisg> Barely
| |
| 10:04 | I can come back in around 4 hours though
| |
| 10:04 | <fiesh> hmm shit, then I'll stay for now ;)
| |
| 10:04 | <alkisg> So what does it show on the first try?
| |
| 10:15 | The problem with XAUTHORITY is that ltsp sets it to a random path, so you need ps to see what it is
| |
| 10:19 | <fiesh> ok, I got the xterm, but only one ;) so I'll tmux and spawn vnc?
| |
| 10:19 | <alkisg> Right
| |
| 10:19 | or put vnc in the background with -quiet &
| |
| 10:24 | I hope you did the symlnk there :P
| |
| 10:28 | kjackal has left IRC (kjackal!~quassel@195.97.13.252, Ping timeout: 258 seconds) | |
| 10:37 | <alkisg> fiesh: leaving for a bit; will be back in a while; do write what happened with the modified xsession
| |
| 10:38 | <fiesh> hurray, it works :)
| |
| 10:38 | <alkisg> Finally :D
| |
| 10:38 | <fiesh> hahaha thank you so much
| |
| 10:38 | I owe you one big time
| |
| 10:38 | Let me know how I can recompensate you
| |
| 10:38 | <alkisg> OK no need to pinpoint what was actually wrong, as ldm will go away anyway
| |
| 10:38 | <fiesh> hehe yeah
| |
| 10:38 | and I didn't even set a symlink!
| |
| 10:39 | ... I thought I had tried that before though, that's so strange, why's it work now
| |
| 10:39 | <alkisg> Because you +x your .xsession
| |
| 10:40 | There were 2 parts failing
| |
| 10:40 | Bye for now :)
| |
| 10:43 | <fiesh> heh yes, I just pieced that together as well :-)
| |
| 10:43 | thank you !
| |
| 10:51 | stellasolitaria has joined IRC (stellasolitaria!~jhonny5@159.213.93.166) | |
| 11:02 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3105:3300:d0a7:2240:510:3d60) | |
| 12:02 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
| 12:07 | stellasolitaria has left IRC (stellasolitaria!~jhonny5@159.213.93.166, Ping timeout: 248 seconds) | |
| 13:04 | ogra has joined IRC (ogra!~ogra@216.113.24.68) | |
| 13:04 | ogra has joined IRC (ogra!~ogra@ubuntu/member/ogra) | |
| 13:44 | spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut) | |
| 14:05 | stellasolitaria has joined IRC (stellasolitaria!~jhonny5@159.213.93.166) | |
| 14:17 | woernie has joined IRC (woernie!~werner@p5B29636A.dip0.t-ipconnect.de) | |
| 15:54 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 16:04 | kjackal has left IRC (kjackal!~quassel@2a02:587:3105:3300:d0a7:2240:510:3d60, Ping timeout: 258 seconds) | |
| 16:16 | <alkisg> I tested pam_exec and sshfs home in all debian/ubuntu VMs/CDs that I have, it worked fine everywhere
| |
| 16:16 | Last step is to script ssh; I'll start with https://pexpect.readthedocs.io/en/stable/api/pxssh.html
| |
| 16:16 | This is available in Ubuntu Live CDs but not in Debian Live; we'll see later if we need something lower-level so that it covers debian isos too
| |
| 16:18 | One issue with pam_exec is that I *think* that it removes the password from the pam stack after we read it from stdin, which means keyring unlocking again won't work
| |
| 16:19 | The good news is that screensaver unlocking worked fine
| |
| 16:20 | I'll mark the "ssh" accounts by replacing "user:x:" in passwd, with "user:ssh:"; that's not a valid crypted password, and it seems like a nice place to keep track of the accounts that need to be authenticated via ssh
| |
| 16:21 | Ah, and I think I can make the pam script work without seteuid, running as the user, as long as the home dirs are already created. So even if the user does something weird, he'll do it in his own account
| |
| 16:22 | <vagrantc> alkisg: what are you scripting with ssh?
| |
| 16:23 | alkisg: also, if there's a reasonable case to make to add something to the debian live CDs, i think we know who to ask
| |
| 16:23 | * vagrantc winks at highvoltage | |
| 16:24 | <alkisg> Hehe
| |
| 16:25 | vagrantc: I just need to pass the pam password to ssh
| |
| 16:25 | So that I see if it authenticates or not
| |
| 16:25 | (or, to sshfs, if we're using sshfs homes too, that part is optional)
| |
| 16:26 | For debian live isos, if we could have pxssh.py and sshfs, it would be awesome
| |
| 16:26 | <vagrantc> you know, you can probably call pam_exec multiple times ... once as root and once as the user
| |
| 16:27 | <alkisg> There's no point in that
| |
| 16:27 | We can run as the user, or if we need to create the home dirs, as root, and su to the user
| |
| 16:27 | No need to involve pam-exec twice
| |
| 16:28 | <vagrantc> oh, i though there was an issue with creating an ssh socket as the user vs. as root
| |
| 16:28 | <alkisg> Btw, I tried wget'ing the sshfs binary from ubuntu 18.04 and it worked everywhere, even in jessie :D
| |
| 16:28 | <vagrantc> hah
| |
| 16:28 | <alkisg> No no, just ssh needs a tty, it can't read passwords from stdin
| |
| 16:28 | <highvoltage> vagrantc: if you're thinking what I'm thinking you're thinking, them we may have had similar thoughts
| |
| 16:28 | <alkisg> Hahah
| |
| 16:29 | wget is missing too, from debian live, but that's ok as it has busybox wget
| |
| 16:31 | <vagrantc> alkisg: so what are these ssh accounts with user:ssh in /etc/passwd?
| |
| 16:32 | <alkisg> If I "su - alkisg" on a client, should it authenticate via ssh, or locally?
| |
| 16:32 | We need to keep track of which accounts are "remote"
| |
| 16:32 | And I though that second column in passwd is just fine for that purpose
| |
| 16:32 | <vagrantc> hmmm.
| |
| 16:33 | risk of abusing it for purposes other than intended ... granted it seems fairly stable.
| |
| 16:34 | <alkisg> "x" means "look in shadow"
| |
| 16:34 | "ssh" means "look via ssh"
| |
| 16:34 | Sounds somewhat sane "abuse"
| |
| 16:37 | <vagrantc> why do you need to diffeerentiate? i mean, can't you just try one pam module and fall back to the next?
| |
| 16:59 | stellasolitaria has left IRC (stellasolitaria!~jhonny5@159.213.93.166, Ping timeout: 245 seconds) | |
| 17:09 | <alkisg> Sure, but isn't that inefficient?
| |
| 17:10 | "ssh" there even tells pam_unix not to look in shadow, which is again the correct thing to do
| |
| 17:11 | <vagrantc> it just seems to be more fiddling than necessary?
| |
| 17:11 | which could have unintended consequences
| |
| 17:11 | <alkisg> remote authentication via ssh may delay a lot, and cause more unintended consequences
| |
| 17:11 | <vagrantc> true
| |
| 17:12 | <alkisg> E.g. suppose one uses that module in large installations with many local accounts; any time they put the wrong local password there, it would try to ssh to the server
| |
| 17:12 | While if we use the "ssh" trick, it won't try to contact the server for local accounts
| |
| 17:13 | And maybe someone has more pam modules under the stack; delaying a few seconds for ssh might be annoying
| |
| 17:13 | Finally, we might handle things differently for offline cases
| |
| 17:14 | E.g. roaming laptop, with and without ltsp
| |
| 17:14 | So if he passes "no-ssh-now-i-am-offline" in the cmdline, we can just OK him from pam_exec, without trying to contact a server
| |
| 17:15 | <vagrantc> all those are reasonable things, sure ... but relying on an invalid value for a crypt password ... is adventurous :)
| |
| 17:16 | <alkisg> man crypt => The returned value points to the encrypted password, a series of 13 printable ASCII characters (the first two characters represent the salt itself)
| |
| 17:16 | ssh is less than 13 :)
| |
| 17:17 | <vagrantc> i do not dispute your math :P
| |
| 17:17 | <alkisg> highvoltage: pxssh will make the code much smaller/readable, is there a chance to see that preinstalled in future debian live isos?
| |
| 17:18 | (it's there in ubuntu ones)
| |
| 17:18 | <vagrantc> alkisg: i don't see a pxssh package in debian
| |
| 17:18 | alkisg: where does it come from?
| |
| 17:19 | <alkisg> Idpkg -S /usr/lib/python3/dist-packages/pexpect/pxssh.py
| |
| 17:19 | python3-pexpect: /usr/lib/python3/dist-packages/pexpect/pxssh.py
| |
| 17:19 | It should be something like 200k
| |
| 17:20 | <vagrantc> planned release date for debian announce for 2019-07-06, btw
| |
| 17:23 | <alkisg> And 45k for sshfs
| |
| 17:24 | Yeah I saw it, it will make a great test case for ltsp19! :)
| |
| 17:25 | Sleaker has left IRC (Sleaker!quasselcor@2604:880:a:7::e1b, Ping timeout: 258 seconds) | |
| 17:25 | Sleaker has joined IRC (Sleaker!quasselcor@2604:880:a:7::e1b) | |
| 17:32 | <highvoltage> alkisg: yep certainly possible
| |
| 17:32 | <alkisg> Great!
| |
| 17:32 | <highvoltage> alkisg: buster release is earmared for 7 July, after that we can run amock again
| |
| 17:32 | <vagrantc> would the proper process be to file a bug/bugs on debian-live ?
| |
| 17:33 | <highvoltage> vagrantc: works for me
| |
| 17:33 | <alkisg> OK, so I'll start writing the code with pxssh; once it's taken form and I'm sure of the prerequisites, I'll do so
| |
| 17:33 | * vagrantc sees a number of fairly obvious similar requests in at https://bugs.debian.org/debian-live | |
| 17:34 | <alkisg> Any plans to migrate bugs.debian.org to salsa? :D /me hates the bug-via-mail interface :D
| |
| 17:34 | <highvoltage> not any time soon
| |
| 17:34 | <vagrantc> alkisg: inertia is not on your side with that issue
| |
| 17:35 | <alkisg> Eh, I'll have to make a thunderbird template for submit@bugs.debian.org then...!
| |
| 17:36 | <vagrantc> no idea how hard templates are, but all your need is Package: PACKAGENAME and ideally Version: VERSION
| |
| 17:37 | <alkisg> vagrantc: do you think we should default to keeping an ssh socket open, for remote apps? Or now with fat clients only and wayland etc it's not worth it and people can run ssh -X when they need to?
| |
| 17:38 | Not having to handle a socket will make the code somewhat smaller
| |
| 17:39 | <vagrantc> alkisg: they'd actually have to know where the socket is to use it
| |
| 17:39 | <alkisg> They'd run ssh -X app and enter the password
| |
| 17:39 | <vagrantc> right
| |
| 17:39 | <alkisg> I.e. completely unrelated to what we do
| |
| 17:39 | <vagrantc> which is what they'd do if they didn't know where the socket is
| |
| 17:39 | <alkisg> While with "ltsp remoteapps app" they'd automatically use our socket
| |
| 17:39 | <vagrantc> ah
| |
| 17:40 | <alkisg> Which would imply that we'd run ssh -X on connection, instead of e.g. sshfs
| |
| 17:40 | (or sshfs with the appropriate options for X forwarding, etc etc)
| |
| 17:40 | <vagrantc> right...
| |
| 17:40 | <alkisg> Hmm, or they could set up key-based authentication from their account to their account, and not need a password
| |
| 17:41 | <vagrantc> it's not a *huge* difference code-wise, is it?
| |
| 17:41 | <alkisg> That sounds sane too...
| |
| 17:41 | Well, we'd need a temp dir, a socket, and cleanup
| |
| 17:41 | and a few more sshfs etc options
| |
| 17:41 | And I don't know if these will break when ssh'ing -X to wayland
| |
| 17:41 | So a bit more testing too
| |
| 17:42 | * vagrantc would be surprised if anything like that works with wayland | |
| 17:42 | <vagrantc> i guess there's xwayland or whatever ...
| |
| 17:42 | <alkisg> I just hope `ssh -X user@server` won't return false, and will return "true but I wouldn't set up x forwarding"
| |
| 17:42 | <vagrantc> i guess go with less-is-more ... can always be added if desired
| |
| 17:43 | <alkisg> Because if it returns false, the user won't log in
| |
| 17:43 | Btw... if a user runs ssh-keygen and ssh-copy-id server, he should then be able to ssh -X server app from any client, right?
| |
| 17:44 | <vagrantc> presuming ssh -X works at all
| |
| 17:44 | <alkisg> Sure
| |
| 17:45 | But I mean, it's a workaround for not supporting remoteapps
| |
| 17:45 | It requires ssh-keygen, but other than that, it performs the same
| |
| 17:45 | Ah that reminds me
| |
| 17:46 | Nowadays ssh -X app doesn't really work for most apps; it needs ssh -X dbus-launch app
| |
| 17:46 | <vagrantc> slightly more expensive in the initial ssh negotiation than having a running tunnel
| |
| 17:46 | <alkisg> ...which is another reason to avoid messing with all that :D
| |
| 17:46 | <vagrantc> the stuff you need to stuff in front of a command seems to grow and change every other year
| |
| 17:47 | <alkisg> True :(
| |
| 17:47 | OK I think I'll follow the "less is more" for starters
| |
| 17:48 | From what I can see so far, we won't need to keep around ltsp5 after ltsp19 is released; it won't support thin clients, but it'll support so much more that it won't make sense to keep maintaining the old one at all
| |
| 17:48 | <vagrantc> hope so!
| |
| 17:49 | * vagrantc makes an interesting note that ltsp5 was from 2005 | |
| 17:49 | <alkisg> Ah and yet another reason to avoid the tunnel, is that it'll make it a bit harder for pam_exec to daemonize ssh without keeping a python process still running and wasting ram
| |
| 17:49 | haha
| |
| 17:49 | <vagrantc> though it wasn't yet called ltsp5...
| |
| 17:49 | <alkisg> see, you were using date-based version numbering back then too :P
| |
| 17:51 | <vagrantc> the first i see use of ltsp5 was 2007, although muekow was the experimental project to become ltsp5
| |
| 17:52 | <alkisg> How would you call the authentication package, taking into account it will be generated from the ltsp sources, but it might be usable outside ltsp?
| |
| 17:52 | e.g. apt install pamssh? ltsp-pamssh? or maybe it should even package it separately, or even in a different git tree?
| |
| 17:53 | *we
| |
| 17:53 | <vagrantc> hard call...
| |
| 17:54 | do you think it will be useful to make releases of it independent of LTSP ?
| |
| 17:54 | would require stricter version tracking, then
| |
| 17:55 | oh, gotta head out!
| |
| 17:55 | * vagrantc waves | |
| 17:55 | <alkisg> It would be easier to have it as part of ltsp, I think
| |
| 17:55 | OK
| |
| 17:55 | Bye
| |
| 17:55 | ty
| |
| 17:55 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 18:45 | GodFather has left IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com, Ping timeout: 245 seconds) | |
| 20:53 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving) | |
| 21:05 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 22:41 | woernie has left IRC (woernie!~werner@p5B29636A.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 22:54 | ogra has left IRC (ogra!~ogra@ubuntu/member/ogra, Ping timeout: 248 seconds) | |