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


Channel log from 7 December 2016   (all times are UTC)

00:13ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection)
02:05GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com)
02:38tyler_ has joined IRC (tyler_!4b668552@gateway/web/freenode/ip.75.102.133.82)
02:38
<tyler_>
help
02:39
wtf is this
02:39tyler_ has left IRC (tyler_!4b668552@gateway/web/freenode/ip.75.102.133.82, Client Quit)
02:40
<sbalneav>
lol
02:46GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Quit: Ex-Chat)
02:46GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com)
03:53GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Ping timeout: 265 seconds)
04:48vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
05:15PeperPots has left IRC (PeperPots!sid1218@gateway/web/irccloud.com/x-exoajbaykdxyhfeo, Ping timeout: 260 seconds)
05:15Parker955_Away has left IRC (Parker955_Away!~parker@2607:5300:60:8425::2d62:a8e6, Ping timeout: 260 seconds)
05:19PeperPots has joined IRC (PeperPots!sid1218@gateway/web/irccloud.com/x-scdgqkwvcpoxbpqf)
05:20Parker955_Away has joined IRC (Parker955_Away!~parker@2607:5300:60:8425::2d62:a8e6)
05:26
<vagrantc>
alkisg: i was wondering if we could update/rewrite for ltsp6 ltsp-update-image to support creating other filesystem types, such as compressed btrfs images
05:26
alkisg: this way you could build the initial image with an ltsp-pnp style method, but the do manual tweaks and updates directly to the image
05:27
mostly for testing purposes, but probably useful in other use-cases as well.
05:28* vagrantc wants to take a look at vmdebootstrap as a replacement for ltsp-build-client
05:31
<vagrantc>
hrm. vmdebootstrap has a lot of recommended packages.
05:32
on a fairly complete ltsp server: apt install vmdebootstrap ... After this operation, 411 MB of additional disk space will be used.
05:33
apt install vmdebootstrap --no-install-recommends ... After this operation, 6,772 kB of additional disk space will be used.
05:34
it's basically qemu that it's pulling in.
05:34* vagrantc wonders a bit
05:45
<alkisg>
vagrantc: about other filesystem types, the tricky part would be to calculate the image size in advance
05:46
Note though that: sudo qemu-nbd --read-only --partition=1 --connect=/dev/nbd3 ~/VirtualBox\ VMs/xenial-mate-sch/xenial-mate-sch.vdi
05:47
...qemu-nbd allows us access to any kind of virtual disk/partition
05:47
So people could just use whatever vm manager they'd want to manage a "chroot"...
05:51
sbalneav: I tried the new code, it didn't solve the issue that I have that my /home/administrator dir isn't mounted with sshfs, but generated locally
05:51
Ah, let me do that allow_others again...
05:52
nope it was already there, user_allow_other, and didn't work
05:52* vagrantc wonders about creating a sparse very large image, and then shrinking it
05:53
<alkisg>
Hmm yeah if it's sparse, I don't even think we have to shrink it afterwards
05:53
<vagrantc>
alkisg: yeah, i think the "install a vm and then build an image out of it" approach is really cool. but i don't think it's a comparable replacement for ltsp-build-client
05:54
presuming NBD/btrfs/ext* handle compressed images well
05:54
<alkisg>
In some cases the vm can even be exported directly, without building an image...
05:54
<vagrantc>
not sure i can get vmdebootstrap to generate an image without a partition table ...
05:54
<alkisg>
We can take care of that in our initramfs code
06:02
<vagrantc>
hm.
06:03
<alkisg>
sbalneav: I tried passing "debug" to ssh.py, but I don't see anything in syslog... where is it supposed to go?
06:03
<vagrantc>
vmdebootstrap may be making too many assumptions.
06:03
maybe a syslog daemon isn't running?
06:03
<alkisg>
Locally on the client?
06:03
<vagrantc>
right
06:04
<alkisg>
No, I see other things both in client's /var/log/syslog and in the server's /var/log/ltsp-clients.log as I've enabled rsyslogging
06:04
I just don't see anything pam-related
06:04
<vagrantc>
sbalneav: with all those "if debug: syslog(...)" bits, wouldn't it be simple to write a debug function that was a no-op if debug != True ?
06:05
hrm.
06:05* vagrantc wonders if debug=/var/log/libpam-python.log might be simpler
06:06* vagrantc is full f feature requests this morning
06:14Statler has joined IRC (Statler!~Georg@p4FC875EC.dip0.t-ipconnect.de)
06:17alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 250 seconds)
06:22alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
06:33adrianorg has left IRC (adrianorg!~adrianorg@187.115.109.125, Ping timeout: 260 seconds)
06:34adrianorg has joined IRC (adrianorg!~adrianorg@187.115.109.125)
06:34markus_e92 has left IRC (markus_e92!~markus_e9@194-166-99-141.adsl.highway.telekom.at, Ping timeout: 258 seconds)
06:39markus_e92 has joined IRC (markus_e92!~markus_e9@80-121-40-209.adsl.highway.telekom.at)
07:03forum has joined IRC (forum!~Icedove@81-5-197-8.hdsl.highway.telekom.at)
07:13forum has left IRC (forum!~Icedove@81-5-197-8.hdsl.highway.telekom.at, Ping timeout: 260 seconds)
07:30mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk)
07:31
<vagrantc>
sbalneav: hopefully you're asleep, but the latest ltsp-pam is working reasonably well on stretch, at least with fat clients
07:31
alkisg: i'd be curious to see your hooks for updating and applying git at boot
07:32
<alkisg>
vagrantc: actually that's a wishlist; now I have to copy those manually to the appropriate locations,
07:32
code changes would need to be made that would allow symlinking stuff around
07:33
Once I get it working, I'll start submitting patches
07:33
<vagrantc>
ah, you boot with a shell and apply manually?
07:33
<alkisg>
But I can't get the ssh tunnel to work
07:33
<vagrantc>
hrm.
07:33
<alkisg>
No no I run sudo cp git/something /usr/share/something on the server before booting the client
07:33
I only skip ltsp-update-image as I'm exporting /
07:33
<vagrantc>
ah right, that method.
07:34
i was realizing that the OVERLAY_DIR feature can't realistically modify init-ltsp.d scripts, as it runs from init-ltsp.d
07:34
or at least, no scripts earlier than it runs
07:35
alkisg: i could also extend OVERLAY_DIR to use URLs, probably
07:35
grab a tarball, extract it
07:36
could even use https :)
07:36
<alkisg>
Or nbd :)
07:36
<vagrantc>
more secure than the rootfs itself :)
07:36
a second nbd export?
07:36
<alkisg>
Yes, overlayed on top of the old one
07:36
(without even using cp)
07:36
<vagrantc>
oh yeah, that's nice.
07:37
actually, could just append a squashfs from a directory, too.
07:37
<alkisg>
And I also want to play with the additional initramfs idea
07:37
<vagrantc>
oh yeah, i've done that when testing debian-installer ...
07:37
<alkisg>
ltspd will make a lot of things possible with very simple means
07:38
<vagrantc>
you just have to append a cpio archive created with the right arguments
07:38
alkisg: was there some proof-of-concept ltspd code floating around somewhere?
07:39
<alkisg>
I have it here locally, but I don't think we've pushed it anywhere
07:39
<vagrantc>
ah
07:42
hrm. screen unlock worked
07:42
and logging in from console almost worked ... but then it immediately logs out
07:42
<alkisg>
vagrantc: the client home/username is mounted via sshfs for you, right?
07:42
<vagrantc>
alkisg: yes
07:43
<alkisg>
When you tried to login from the console, were you logged in from a DM as well?
07:43
<vagrantc>
got some weird issues on second login though ... mate-terminal didn't start the second time
07:44
alkisg: how to explain... it worked on console when logged in via DM also, it didn't work on console when not logged in via DM also
07:44
so there's something in the DM code that makes the whole stack work
07:45
and trying to log in with MATE just crashed on the first login attempt
07:45
eating lots of CPU cycles
07:47ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
07:48
<alkisg>
vagrantc: there are some steps that are not documented anywhere, such as adding user_allow_other to /etc/fuse.conf
07:48
Any others steps that might be to blame for my non-working setup?
07:49
<vagrantc>
MATE was definitely working the other day
07:49
<alkisg>
Did you add that to fuse.conf manually?
07:49
Also... do you know if sbalneav is testing with debian or with ubuntu? Am I the first person testing this in ubuntu?
07:50
<vagrantc>
not sure what sbalneav is running
07:50
alkisg: i just tweaked fuse.conf manually now
07:50
alkisg: maybe should put that in init-ltsp.d
07:50
<alkisg>
Yeah
07:53* vagrantc is kind of relieved to finally have ltsp 5.5.9 uploaded :)
08:00
<vagrantc>
alkisg: fwiw, it looks like recent versions of mkfs.ext4 could support replacing mksquashfs with mkfs.ext4 -d /opt/ltsp/i386 ...
08:00
<alkisg>
Hehe, that sounds good, but we could just use `cp -a` and implement it...
08:01
<vagrantc>
cp -a is data lossy in a variety of cases
08:01
<alkisg>
Like what?
08:02vervelak has left IRC (vervelak!~vervelak@139.91.200.185, Ping timeout: 250 seconds)
08:02vervelak has joined IRC (vervelak!~vervelak@139.91.200.185)
08:07
<vagrantc>
so, the issue i'm getting with MATE now is ... "Could not connect to the session bus: Failed to connect to socket /run/user/1001/bus: Connection refused"
08:07* vagrantc wonders if this has to do with the temporary homedir creatiokn sbalneav added
08:07
<vagrantc>
as it was working fine with MATE before...
08:11
<alkisg>
Ah I do see the debug logs of python
08:12
<vagrantc>
aha
08:12
ok, mate works fine on first login, but has that issue on second login
08:13
<alkisg>
When you logout, is everything cleaned up correctly?
08:13
No processes, no mounts, no sockets left?
08:13
If not, try to manually clean them up before logging in again
08:14* alkisg isn't sure why fusermount is expected to work from a user process...
08:15
<alkisg>
The mount wasn't done by the user, and it's not in a dir whose parent is owned by the user, right?
08:15
<vagrantc>
oh no
08:15
... /etc/resolv.conf -> /var/run/NetworkManager/resolv.conf
08:16
which doesn't exist on the fat client
08:16
<alkisg>
That's done by an init-ltsp.d script?
08:16
<vagrantc>
not sure what's causing that
08:17
possibly updates to stretch in the last 24 hours
08:22
<alkisg>
sbalneav: so, the ssh master socket is opened by root, and then chrowed to the user?
08:22forum has joined IRC (forum!~Icedove@81-5-197-8.hdsl.highway.telekom.at)
08:23* vagrantc suspects/hopes sbalneav is sleeping
08:23
<alkisg>
Wouldn't it be better to (1) do the initial ssh for fetching the user info as root, and (2) then create a master socket as the user, so that sshfs/fusermount etc etc all run as the user?
08:23
Yup but I hope he sees the logs like he did yesterday
08:23
Unfortunately we don't seem to have much common online time...
08:24* vagrantc nods
08:24
<alkisg>
So, that would require keeping the password until the open_session() phase, I don't know if that's easily doable
08:29
brb...
08:29alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
08:33alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
08:36
<vagrantc>
and now i understand what sbalneav wanted libnss-multifile
08:36
i tried the switch-user button from mate's lock screen ... and it worked
08:37
but as soon as the second user was logged in, the first user was deleted from /var/lib/extrausers
08:38
and X got confused
08:38
could also be the hard-coded DISPLAY=:0.0 in ssh.py
08:42Statler has left IRC (Statler!~Georg@p4FC875EC.dip0.t-ipconnect.de, Remote host closed the connection)
08:44
<alkisg>
Why does ssh.py touch the display variable?
08:44* alkisg thinks a chat with sbalneav is needed...
08:49
<vagrantc>
it includes some comments like "not sure if this is needed"
08:50
might be needed to set up the thin client sessions or something like that
09:10* vagrantc pushes untested updates tp 50-display-manager-pam merging 50-update-nss and updating fuse.conf
09:47vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
09:57markus_e92 has left IRC (markus_e92!~markus_e9@80-121-40-209.adsl.highway.telekom.at, Ping timeout: 250 seconds)
09:58markus_e92 has joined IRC (markus_e92!~markus_e9@192-164-100-234.adsl.highway.telekom.at)
10:19forum has left IRC (forum!~Icedove@81-5-197-8.hdsl.highway.telekom.at, Remote host closed the connection)
10:20
<alkisg>
!nbd-client
10:20
<ltsp>
nbd-client: To try mounting the NBD image from the client initramfs: nbd-client 192.168.67.1 -N /opt/ltsp/i386 /dev/nbd0
10:20forum has joined IRC (forum!~Icedove@81-5-197-8.hdsl.highway.telekom.at)
10:29dshah has joined IRC (dshah!5549015b@gateway/web/freenode/ip.85.73.1.91)
10:31Statler has joined IRC (Statler!~Georg@mail.lohn24.de)
10:31vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
10:38user3948572 has joined IRC (user3948572!~user39485@mail.lbathivel.com)
10:41schlady has joined IRC (schlady!~schlady@141-53-223-201.ip.uni-greifswald.de)
10:48forum has left IRC (forum!~Icedove@81-5-197-8.hdsl.highway.telekom.at, Remote host closed the connection)
10:48forum has joined IRC (forum!~Icedove@81-5-197-8.hdsl.highway.telekom.at)
10:57
<alkisg>
!qemu
10:57
<ltsp>
I do not know about 'qemu', but I do know about these similar topics: 'q'
10:57
<alkisg>
!virtual
10:57
<ltsp>
Error: "virtual" is not a valid command.
10:57
<alkisg>
!kvm
10:57
<ltsp>
kvm: Virtual thin client: kvm -vga-vmware -ctrl-grab -no-shutdown -net nic,model=virtio -net user,tftp=/var/lib/tftpboot,bootfile=/ltsp/i386/pxelinux.0
11:00
<vagrantc>
using "mkfs.ext4 -d directory" instead of mksquashfs isn't working out so well, as it lacks an exclude mechanism.
11:00
and probably other things as well
11:00
<alkisg>
I think rsync supports providing a list of excludes
11:03
<vagrantc>
was just hoping to have a drop-in replacement for mksquashfs
11:03* alkisg suspects that his vm doesn't boot because of some issue with the latest kernel and the vbox "old style" type of virtualization...
11:04
<vagrantc>
alkisg: if you called it "old school" you'd get more cred.
11:04* alkisg is calling it "time consumer" currently... :(
11:04* vagrantc pouts too
11:08
<alkisg>
Let's try the bill-gates way of fixing things... brb...
11:08alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
11:10alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
11:14
<vagrantc>
alkisg: did you mean steal other people's work and make millions and millions?
11:17
<alkisg>
Haha... nah, just "if it doesn't work, try rebooting"
11:26
<vagrantc>
well, grml-debootstrap seems promising as a replacement for ltsp-build-client, at least for debian systems.
11:26
though i don't know if it even handles Ubuntu
11:27
but there are so many chroot builder options, i think it's time we got out of that business :)
11:28
since all we need to do is install some packages
11:29
<alkisg>
+1
11:29forum has left IRC (forum!~Icedove@81-5-197-8.hdsl.highway.telekom.at, Ping timeout: 260 seconds)
11:39vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
11:46GodFather has joined IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net)
12:40vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
13:50
<vagrantc>
sbalneav: so, on stretch ltsp-pam is mostly working for fat clients ... but things that leave processes running after logout tend to cause issues
13:50
e.g. login with MATE, run mate-terminal and leave it open, log out of the session
13:50
on the subsequent logins, MATE can't access dbus
13:51
but, apparently, killing the running processes allows it to work again...
13:52
still haven't figured out why it's not working at all on ubuntu
13:53
though i've mostly just listened to alkisg fight with it
14:00forum has joined IRC (forum!~Icedove@81-5-197-8.hdsl.highway.telekom.at)
14:08
<sbalneav>
Wow lot to unpack here
14:08
Morning
14:08
So, it should do the logging in the auth log
14:08
/var/log/auth.log
14:11mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving)
14:13
<vagrantc>
yeah, i think we've been finding the logs now :)
14:14
sbalneav: we've been busy proding and poking at things and just queued up plenty of questions and ideas :)
14:14
i adjusted the init-ltsp.d hooks a bit
14:21
it appears to be unable to remove the homedir, because there are files leftover in there...
14:21sebd has left IRC (sebd!~seb@85.31.145.12, Ping timeout: 250 seconds)
14:28hermon has joined IRC (hermon!42bab003@gateway/web/freenode/ip.66.186.176.3)
14:28sebd has joined IRC (sebd!~seb@aditu.ldd.fr)
14:30hermon has left IRC (hermon!42bab003@gateway/web/freenode/ip.66.186.176.3, Client Quit)
14:35GodFather has left IRC (GodFather!~rcc@96-92-43-9-static.hfc.comcastbusiness.net, Ping timeout: 268 seconds)
14:39
<vagrantc>
sbalneav: was curious what your test environment is
14:42
<alkisg>
sbalneav: I'm having some VM issues currently, so I can't test much, but I'm thinking that the kill/unmount process is the opposite of what it should be,
14:42
i.e. if systemd has any processes running, those would prevent the `fusermount -u` from working....
14:42
So the old way we did it was, logout, killall, unmount, remove dir
14:45GodFather has joined IRC (GodFather!~rcc@75-145-237-204-Michigan.hfc.comcastbusiness.net)
14:46
<alkisg>
sbalneav: also, I was thinking that maybe my problem is that the socket which is owned by root, isn't accessible by the user. Are you testing on Ubuntu? If not, maybe it's Ubuntu that has some checks against that, or maybe it's apparmor...
14:47
<sbalneav>
The socket shouldn't be owned by root
14:48
The socket should be user owned.
14:48
I'm testing on debian.
14:48
<alkisg>
sbalneav: Here's what I'm manually trying:
14:48
root: ssh -MS /tmp/socket administrator@localhost
14:48
(ok, logged in, now to another tab)
14:48
root: chown administrator:administrator /tmp/socket
14:48
and finally:
14:48
<sbalneav>
No, that won't work
14:49
<alkisg>
administrator: ssh -S /tmp/socket administrator@localhost ls
14:49
Control socket connect(/tmp/socket): Permission denied
14:49
I think that ssh has checks against that
14:49
<sbalneav>
SSH get's REALLY pissy if the user who OWNS the socket isn't the user logged in on the socket
14:49
<alkisg>
OK, so what is happenning in our case?
14:49
<sbalneav>
That's why, in the code, you'll see I drop privs and setgid(user) and setuid(user) BEFORE I spawn the ssh tunnel
14:50
<alkisg>
So the master socket is created initially with the correct uid/gid
14:50
<sbalneav>
Correct
14:50
<alkisg>
Hmm, I don't know why it wouldn't work for me then
14:51
<sbalneav>
So, when you use my ssh.py code, you're getting a tunnel launched, but the tunnel ISN'T owned by the user?
14:51
<vagrantc>
alkisg: the socket is ending up root owned for you?
14:51
<sbalneav>
Have you got the libnss-extrausers stuff installed?
14:52
<alkisg>
Sorry I haven't actually checked the file system, I was assuming that it ran as root at that point...
14:52
<vagrantc>
huh.
14:52
would you look at that
14:52
<alkisg>
Yes the authentication part is working
14:52
<sbalneav>
No, that tunnel *should* be owned by the user.
14:52
<vagrantc>
attempting to log in on tty1 resulted in the login succeeding (e.g. motd displayed), but then it's prompting for the root password???
14:52
<alkisg>
The correct user info gets to the extrausers passwd, group and shadow files
14:53
<sbalneav>
vagrantc: Yeah, it does that for me too. I don't know why. Something I'll have to fix.
14:53ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu)
14:53
<vagrantc>
and now i'm back to the login and automatically log out
14:54ltsp_school has joined IRC (ltsp_school!42bab003@gateway/web/freenode/ip.66.186.176.3)
14:54
<sbalneav>
hmmm
14:55
<vagrantc>
seems like something must be racy
14:55
<sbalneav>
entirely possible.
14:55
<vagrantc>
if it sometimes prompts for root@server's password
14:55
but usually just logs out right away
14:55
<ltsp_school>
We have a brand new install of LTSP on Ubuntu 16.04 64bit, using lightdm and lightdm-gtk-greeter. When an LTSP user arrives at a login prompt, and enters an incorrect password, there is a 35 second long delay before they can enter another password. For the first part of the delay the message below the login displays "checking", for the last 5 seconds or so it displays "permission denied".
14:56
<alkisg>
ltsp_school: are you sure you're using lightdm with ltsp? how? we don't normally support this...
14:56
<ltsp_school>
We would like to be able to reduce the timeout from 35 seconds to 10 seconds or so.
14:56
<alkisg>
That's what we're trying to implement... :D
14:57
<ltsp_school>
I'll double check, but I'm pretty sure. Do you normally support gdm?
14:57
<sbalneav>
vagrantc: For a tty login, I really shouldn't be spawning a tunnel, or the sshfs
14:57
<alkisg>
ltsp_school: we're normally using LDM. Is the background of the client login screen white with a splash?
14:58
<sbalneav>
What I suspect I should be doing is checking if we have a $DISPLAY set.
14:58
<ltsp_school>
Yes.
14:58
<alkisg>
ltsp_school: that's LDM then, not lightdm
14:58
It's the ltsp display manager
14:58
<ltsp_school>
Oops. Sorry for the confusion.
14:59
<vagrantc>
we're trying to get rid of it in order to meet people's assumptions about what they're running. :)
15:00
sbalneav: that said, with the code in pam.d/common-* (instead of lightdom only), it now works with screensavers out of the box ... at least as long as the processes aren't still running :)
15:00
<sbalneav>
I'm less concerned about the wierd text login, which we can fix later. I'm far more concerned as to why alkisg isn't seeing a tunnel owned by the user.
15:00
<alkisg>
ltsp_school: if you give the wrong password two times, does it still delay for 35 seconds the second time?
15:00
<ltsp_school>
Tried uncommenting GSSAPIAuthentication no in sshd_config on the server, but it didn't seem to change the behavior.
15:00
<sbalneav>
vagrantc: I can add some more cleanup code. That I'm not worried about.
15:01
<vagrantc>
sbalneav: yeah, alkisg's issues sound most confusing
15:01* vagrantc ponders firing up an Ubuntu VM
15:01
<ltsp_school>
Yes. It delays for about 35 seconds on second login attempt.
15:01
<vagrantc>
see if i can reproduce it with a default install or something
15:01
i wonder if ltsp_school's issue is name resolution related?
15:02
<alkisg>
sbalneav, vagrantc, now it worked correctly for me for the first time
15:02
<vagrantc>
ssh sometimes takes a long time to respond if the reverse DNS doesn't match
15:02
alkisg: yay!
15:02
<sbalneav>
hm
15:02
<alkisg>
My /home/username was mounted with sshfs
15:03
<sbalneav>
what changed?
15:03
<alkisg>
I've absolutely no idea
15:03
<sbalneav>
lol
15:03
ok
15:03
The code is kinda fragile at the moment; I'm not doing a lot of checks I should be.
15:04
I'm gonna spend an hour or two here, clean some stuff up, try to make things a bit more robust.
15:04
What's your time there, vagrantc, alkisg? 6:00 pm or so?
15:04
<alkisg>
17.00
15:04
<sbalneav>
ok
15:05
<ltsp_school>
Tried uncommenting #UseDNS no in sshd_config (and restarting ssh service), but that didn't change behavior either. We were also suspecting name resolution at one point.
15:05
<sbalneav>
Give me until 19:00
15:05
<alkisg>
np!
15:05
<sbalneav>
I'll refactor some stuff, do more logging and cleanup, and see if we can make this a bit less "twitchy"
15:05
<alkisg>
!screen_02
15:05
<ltsp>
screen_02: To get a root shell on an Ubuntu thin client: https://help.ubuntu.com/community/UbuntuLTSP/ClientTroubleshooting#Using_a_shell_SCREEN
15:05
<alkisg>
ltsp_school: try "ssh user@server" from screen_02
15:06* vagrantc usually disappears around 20:00 till 22:30
15:06
<alkisg>
Give the wrong password there and see the delay
15:06
But *do* use the "server" dns name, don't change it to your server's actual name
15:09
sbalneav, vagrantc, wow, even /home/administrator was properly removed on logout... the only thing erroneously left was the passwd entry in extrausers
15:10
<ltsp_school>
Tried ssh user@server. No delay when I entered an incorrect password.
15:10
<alkisg>
console login seemed to work, but logged out so fast that I couldn't see anything
15:10
<vagrantc>
alkisg: we're now on the same page!
15:11
<alkisg>
second time lightdm login worked fine too
15:11
<vagrantc>
what's really weird is the console login works fine when logged in via lightdm concurrently
15:12
<alkisg>
ah, true
15:12
<vagrantc>
alkisg: i was able to get MATE to hang consistantly on subsequent logins by running mate-terminal and logging out without closing it
15:12
<alkisg>
maybe something is trying to access xorg...
15:13
<vagrantc>
sounds like sbalneav will do some more tidying of the code and we can give another try
15:13
<ltsp_school>
When I try the same thing at console there's no delay at all.
15:13
<vagrantc>
alkisg: one feature "cp" lacks is supporting an exclude file
15:13
<alkisg>
vagrantc: when I logged out from console, /home/administrator was gone, so the mate session that is still running will indeed have a number of issues... :D
15:13
<vagrantc>
alkisg: figured that out when implementing btrfs support for ltsp-update-image
15:13
<alkisg>
ltsp_school: what was the exact command that you ran at the console?
15:14
<vagrantc>
alkisg: i presume your username is administrator
15:14
<alkisg>
yeah, the test user at least
15:15
<ltsp_school>
At console I simply tried logging in via the gui with the wrong password. No delay in telling me that it was incorrect and to try again.
15:16
<alkisg>
ltsp_school: what was the exact command that you tried in screen_02=shell?
15:17
bbl...
15:17
<ltsp_school>
I logged in as root at the shell and then ran the command "ssh onionj@server." It then prompted me for a password and I gave it the wrong password to test the timeout.
15:19user3948572 has left IRC (user3948572!~user39485@mail.lbathivel.com, Quit: Quitte)
15:50ltsp_school has left IRC (ltsp_school!42bab003@gateway/web/freenode/ip.66.186.176.3, Quit: Page closed)
15:52forum has left IRC (forum!~Icedove@81-5-197-8.hdsl.highway.telekom.at, Remote host closed the connection)
15:52forum has joined IRC (forum!~Icedove@81-5-197-8.hdsl.highway.telekom.at)
15:57
<sbalneav>
vagrantc, alkisg, update your trees
15:57
Try what's in there now
15:57
I realized what the race was.
15:57
Debugging should be more voluminous
16:19forum has left IRC (forum!~Icedove@81-5-197-8.hdsl.highway.telekom.at, Remote host closed the connection)
16:20forum has joined IRC (forum!~Icedove@81-5-197-8.hdsl.highway.telekom.at)
16:37forum has left IRC (forum!~Icedove@81-5-197-8.hdsl.highway.telekom.at, Read error: Connection reset by peer)
16:37forum has joined IRC (forum!~Icedove@81-5-197-8.hdsl.highway.telekom.at)
16:40
<vagrantc>
sbalneav: ah, you went with my debug function idea :)
16:51mabu_ has joined IRC (mabu_!5093c94c@gateway/web/freenode/ip.80.147.201.76)
16:51
<mabu_>
hi at all
16:55mabu_ has left IRC (mabu_!5093c94c@gateway/web/freenode/ip.80.147.201.76, Client Quit)
17:00
<sbalneav>
vagrantc: yeah.
17:04
<vagrantc>
sbalneav: latest commit looks a little more stable
17:04
sbalneav: reliably removing the user's homedir and such
17:04
sbalneav: MATE still leaves processes hanging
17:06
sbalneav: that somehow prevent future dbus connections...
17:06
and so subsequent logins fail ... though if i *just* run MATE it's usually fine ... but mate-terminal, firefox ... those somehow trigger hangs
17:06
<sbalneav>
what I need to do is just right a generalized kill routine.
17:06
<vagrantc>
so much for running screen/tmux on the server :)
17:07
<sbalneav>
The issue is, we needed to wait for the socket to appear in the auth phase.
17:08
That also fixed the mount; I should probably remove the "try the mount twice" code.
17:08
I'm working on cleanup code now.
17:09
<vagrantc>
well, bit by bit, it's getting better :)
17:09* vagrantc grabs some food
17:12
<sbalneav>
I wonder if pkill -u is smart enough to kill itself last?
17:12
I should try
17:12
we could just do a "pkill -u $user" on the way out the door.
17:24forum has left IRC (forum!~Icedove@81-5-197-8.hdsl.highway.telekom.at, Ping timeout: 246 seconds)
17:31schlady has left IRC (schlady!~schlady@141-53-223-201.ip.uni-greifswald.de, Remote host closed the connection)
17:32schlady has joined IRC (schlady!~schlady@141-53-223-201.ip.uni-greifswald.de)
17:36schlady has left IRC (schlady!~schlady@141-53-223-201.ip.uni-greifswald.de, Ping timeout: 250 seconds)
17:44dshah has left IRC (dshah!5549015b@gateway/web/freenode/ip.85.73.1.91, Ping timeout: 260 seconds)
17:49Statler has left IRC (Statler!~Georg@mail.lohn24.de, Quit: Leaving)
18:00vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
18:07GodFather has left IRC (GodFather!~rcc@75-145-237-204-Michigan.hfc.comcastbusiness.net, Ping timeout: 268 seconds)
18:14forum has joined IRC (forum!~Icedove@81-5-197-8.hdsl.highway.telekom.at)
18:19silvia has joined IRC (silvia!4e0c634b@gateway/web/freenode/ip.78.12.99.75)
18:29forum has left IRC (forum!~Icedove@81-5-197-8.hdsl.highway.telekom.at, Ping timeout: 260 seconds)
18:29robb_nl has joined IRC (robb_nl!~robb_nl@ip-83-134-1-11.dsl.scarlet.be)
18:37robb_nl has left IRC (robb_nl!~robb_nl@ip-83-134-1-11.dsl.scarlet.be, Quit: robb_nl)
19:03
<sbalneav>
Well, I have to admit I'm flummoxed as to why a lightdm login works, but a shell login doesn't.
19:04
Update your repos, boys
19:04
I made some of the DISPLAY handling a bit more sane
19:40sbalneav has left IRC (sbalneav!~sbalneav@wnpgmb0311w-ds01-165-236.dynamic.mtsallstream.net, Ping timeout: 265 seconds)
19:40sbalneav has joined IRC (sbalneav!~sbalneav@wnpgmb0311w-ds01-165-236.dynamic.mtsallstream.net)
20:49vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
20:49* vagrantc git fetches
20:50
<sbalneav>
13:03:56 sbalneav Well, I have to admit I'm flummoxed as to why a lightdm login works, but a shell login doesn't.
20:50
13:04:28 sbalneav Update your repos, boys
20:50
13:04:44 sbalneav I made some of the DISPLAY handling a bit more sane
20:51* gehidore makes some more changes
21:00
<sbalneav>
vagrantc: Do we have a wiki page started with the issues we're uncovering/have left to solve for the LTSP6 stuff?
21:01
<vagrantc>
sbalneav: not to my knowledge
21:02
<sbalneav>
Should we? :D
21:02
<vagrantc>
sbalneav: could probably take a stab at updating http://wiki.ltsp.org/wiki/Dev:LTSPPamNotes
21:02
<sbalneav>
That'd be awesome.
21:02
<vagrantc>
sbalneav: although i should probably turn in a bit earlier than i have been, to attempt to get more sleep...
21:03
<sbalneav>
Well, I wasn't suggesting you do it NOW lol
21:03
NO
21:03
<vagrantc>
heh
21:03
<sbalneav>
NO SLEEP FOR YOU
21:03
WOOOOOOORK HAAAAAARDER
21:04
<vagrantc>
sbalneav: oh, believe me, i *want* to go test the latest changes and see how it behaves! i just am attempting to be wiser. :)
21:04
<sbalneav>
correct me if I'm off, but from *your* point of view, if we can get the cleanup stuff landed, that would handle most of your issues, true?
21:05
<vagrantc>
it seems that the main issues are lingering processes that somehow break dbus
21:05
so if cleanup solves that, i think so
21:06
<sbalneav>
ok, I'll work on it tonight.
21:06
<vagrantc>
at least for the bare-minimal functionality
21:06
sbalneav: it's been great testing and packaging with you again! :)
21:09
<sbalneav>
Good, same here. Glad we've finally ruminated on the pieces long enough to have something that's making progress.
21:09
<vagrantc>
sbalneav: so, should i offer up libpam-sshauth in debian for adoption? :)
21:10
this seems to be just as fast, easier to test, easier to debug ...
21:10
<sbalneav>
I think so. What I'd rather do is just... replace the entire libpam-sshauth piece with libpam-python and ssh.py
21:11
<vagrantc>
sbalneav: e.g. re-use the package name, but replace everything under the hood
21:11
<sbalneav>
All I need to do is just add in the public-key piece, which is entirely doable, and it's pretty much a one-for-one replacement.
21:11
hmmm, that's a thought
21:12
separate out the ssh.py piece
21:12
How does that work for you?
21:13
so when someone installs libpam-sshauth, they get a /usr/share/pam-sshauth/ssh.py, and libpam-python installs.
21:13
as a dep
21:13
that way, the (few) people who are using it can go on using it... without having to dig out a piece from ltsp
21:14
Go sleep
21:14
We can talk tomorrow
21:15
<vagrantc>
yeah, that's a plan
21:16ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
21:16
<vagrantc>
i think alkisg is more inclined to keep it just inside LTSP and tightly integrated... but if it's not too much extra work, i like the idea of generally useful code
21:16
<sbalneav>
wouldn't be that hard.
21:17
it's basically.... 80% there now.
21:17
it's just some packaging stuff.
21:19
<vagrantc>
the "if ltsp" stuff might need to be more generalize
21:20
was also curious if the homedir mounting could be modularized to support other things like samba and/or nfs
21:20
<sbalneav>
Oh, of course.
21:21
<vagrantc>
i mean, we make the sshfs module, and leave people up to their own foot-shooting for other implementations
21:21
<sbalneav>
Well, here's how I'd do it:
21:22
As far as I know, we should be able to call the pam_python module multiple times.
21:22
<vagrantc>
hopefully that won't make it too complicated though ... i can mostly follow it now, and with time and familiarity could probably maintain it a bit
21:23
this seems to be just as fast, easier to test, easier to debug ...
21:23
<sbalneav>
the "libpam_sshauth" bit ONLY does the authentication bit, and spawns the tunnel.
21:23
and we have an option "notunnel" for people who don't want the ssh tunnel spawned.
21:23
<vagrantc>
write a differnt pam_python script for the sshfs homedir mounting
21:23
<sbalneav>
bingo
21:23
that one falls under the ltsp project
21:24
all I have to do is test, for sure, we can do that.
21:24
<vagrantc>
i could see sshfs homedirs being a reasonable general feature though
21:25
plumbing X through it, though ... that's starting to seem more LTSP specific
21:25
<sbalneav>
Yeah
21:28
All of this is easy, once we've got the functioning python bits; it's just a question of packaging; which bit goes where
21:29GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com)
21:30
<vagrantc>
everything's easy once it's working! :)
21:30
<sbalneav>
as always
21:30
<vagrantc>
but it's really awesome to see progress on this
21:31
<sbalneav>
This is about as far as we've ever come, I think
21:31
far farther
21:31
<vagrantc>
it seems like libpam-sshauth was about this good, but i have greater confidence in the maintainability of this
21:32
<sbalneav>
yeah
21:33
<vagrantc>
i didn't get around to testing it, but i started working on something that tweaks the .desktop files to call the xsession script which handles thin clients, but also could be used to put hooks in for other features
21:34
for fat clients
21:34
e.g. if LTSP_FATCLIENT=true, then do local sessions, otherwise remote sessions
21:34
although that kind of relies on the assumption that the local and remote systems have the same .desktop files
21:35
a real implementation would be much more complicated
21:35
but i wanted to play with editing/generating .desktop files, rather than having a single "LTSP" session.
21:50* vagrantc yawns and waves
21:50vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
22:04adrianor1 has joined IRC (adrianor1!~adrianorg@187.58.140.220)
22:07adrianorg has left IRC (adrianorg!~adrianorg@187.115.109.125, Ping timeout: 250 seconds)
22:16adrianor1 is now known as adrianorg
22:16GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Quit: Ex-Chat)
22:16GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com)
22:22ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection)
22:28gdi2k has left IRC (gdi2k!~gdi2k@119.94.27.63, Ping timeout: 246 seconds)
23:01
<sbalneav>
alkisg: I've completely removed all the session stuff from the python ssh.py module. It now ONLY does the authentication, and the spawning of the tunnel.
23:03
instead, for the session, we'll use pamsession.sh
23:03
and pam_exec
23:04
this makes things even more hackable for you and vagrantc
23:07
headin' home for the day. On later
23:41dtcrshr has left IRC (dtcrshr!~datacrush@unaffiliated/datacrusher, Read error: Connection reset by peer)