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


Channel log from 13 June 2019   (all times are UTC)

00:03yanu_ has left IRC (yanu_!~yanu@178-116-60-189.access.telenet.be, Ping timeout: 252 seconds)
00:04yanu has joined IRC (yanu!~yanu@178-116-60-189.access.telenet.be)
00:48master has joined IRC (master!521d0db3@gateway/web/freenode/ip.82.29.13.179)
00:48master has left IRC (master!521d0db3@gateway/web/freenode/ip.82.29.13.179, Client Quit)
00:49masterchild has joined IRC (masterchild!521d0db3@gateway/web/freenode/ip.82.29.13.179)
00:49
<masterchild>
hi everybody
00:49masterchild has left IRC (masterchild!521d0db3@gateway/web/freenode/ip.82.29.13.179, Client Quit)
02:13vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
04:26kjackal has joined IRC (kjackal!~quassel@2a02:587:3105:3300:d0a7:2240:510:3d60)
04:50quinox has left IRC (quinox!~quinox@ghost.qtea.nl, Quit: WeeChat 2.4)
04:52quinox has joined IRC (quinox!~quinox@ghost.qtea.nl)
05:04alkisg 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:30kjackal has left IRC (kjackal!~quassel@2a02:587:3105:3300:d0a7:2240:510:3d60, Ping timeout: 258 seconds)
06:37woernie has joined IRC (woernie!~werner@p50867386.dip0.t-ipconnect.de)
06:42quentinb 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:56quentinb 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:01quentinb has joined IRC (quentinb!66a55e06@gateway/web/freenode/ip.102.165.94.6)
07:01stellasolitaria has joined IRC (stellasolitaria!~jhonny5@159.213.93.166)
07:03alkisg 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:37kjackal 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:49woernie has left IRC (woernie!~werner@p50867386.dip0.t-ipconnect.de, Ping timeout: 272 seconds)
07:49quentinb 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:45bcg 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:50bcg has joined IRC (bcg!~b@82-128-241-5.bb.dnainternet.fi)
08:54
<fiesh>
alkisg: sorry, back at desk
08:56stellasolitaria 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:15ricotz 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:40kjackal has left IRC (kjackal!~quassel@195.97.13.252, Read error: Connection reset by peer)
09:40kjackal 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:28kjackal 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:51stellasolitaria has joined IRC (stellasolitaria!~jhonny5@159.213.93.166)
11:02kjackal has joined IRC (kjackal!~quassel@2a02:587:3105:3300:d0a7:2240:510:3d60)
12:02Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
12:07stellasolitaria has left IRC (stellasolitaria!~jhonny5@159.213.93.166, Ping timeout: 248 seconds)
13:04ogra has joined IRC (ogra!~ogra@216.113.24.68)
13:04ogra has joined IRC (ogra!~ogra@ubuntu/member/ogra)
13:44spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut)
14:05stellasolitaria has joined IRC (stellasolitaria!~jhonny5@159.213.93.166)
14:17woernie has joined IRC (woernie!~werner@p5B29636A.dip0.t-ipconnect.de)
15:54vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
16:04kjackal 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:59stellasolitaria 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:25Sleaker has left IRC (Sleaker!quasselcor@2604:880:a:7::e1b, Ping timeout: 258 seconds)
17:25Sleaker 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:55vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
18:45GodFather has left IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com, Ping timeout: 245 seconds)
20:53Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
21:05ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
22:41woernie has left IRC (woernie!~werner@p5B29636A.dip0.t-ipconnect.de, Remote host closed the connection)
22:54ogra has left IRC (ogra!~ogra@ubuntu/member/ogra, Ping timeout: 248 seconds)