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


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

00:09quinox has left IRC (quinox!~quinox@ghost.qtea.nl, Quit: :wq)
00:09quinox has joined IRC (quinox!~quinox@ghost.qtea.nl)
03:14GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Ping timeout: 256 seconds)
04:15vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
04:50
<vagrantc>
sbalneav: just built packages with your latest and greatest, ready to test
04:56
<sbalneav>
vagrantc: I'm sometimes finding tht the sshfs mount doesn't happen.
04:56
I'm thinking it's some kind of race condition
04:57
<vagrantc>
yeah, seems rather plausible
04:57
<sbalneav>
i.e. maybe the ssh socket isn't *quite* ready yet
04:57
I'm beginning to nod off here, but tomorrow morning, I'll add a loop that will retry the mount up to 3 times
04:58
So if you notice the sshfs mount doesn't happen sometimes; that's prolly why
04:58
<vagrantc>
sbalneav: i seem to recall the user homedir wasn't cleaned up on logout
04:58
<sbalneav>
it can't be now.
04:58
<vagrantc>
are you UTC-6
04:58
?
04:58
<sbalneav>
yes
04:58
it's 11:00 or so here
04:58
<highvoltage>
" * Remove debian/watch file, as Ubuntu is no longer making new releases."
04:58
<sbalneav>
om
04:58
pm
04:58
<highvoltage>
vagrantc: huh? :)
04:59
<sbalneav>
in pam, by the time you get to the "close_session" part, you've dropped root privs
04:59
<vagrantc>
highvoltage: ubuntu hasn't released a new version of ltsp/ldm/ltspfs in quite some years, so it doesn't make sense to poll for newer versions
05:00
<sbalneav>
It is, I think, a deficiency of pam.
05:00
<vagrantc>
highvoltage: but i guess that could be interpreted strangely
05:00
so we need a pam_removehomedir :)
05:00
<highvoltage>
vagrantc: aah
05:00
<sbalneav>
well, it would have to be setuid :(
05:00
that's the problem.
05:01
unless the user completely owns their homedir, then we could do it.
05:01
<vagrantc>
highvoltage: they also moved from main to universe, so rather than just track that, and usually have it be an outdated version, i just figured best to remove it
05:01
<sbalneav>
but sometimes, remember, the DIR could be owned by root, and it *assumes* user ownership on the mount.
05:01
<vagrantc>
don't users typically own their homedir?
05:02
<sbalneav>
On a real filesystem, yes.
05:02
But we're automounting.
05:02
I'm not sure if the *mountpoint* is owned by the user.
05:02
<vagrantc>
removing a directory that you own within a directory that you don't also might be an issue
05:02
<sbalneav>
If it is, then it will be ok.
05:03
We can try; what's the worst that can happen? :D
05:03
os.removedir() in the close_session()
05:03
wrap it in a try block
05:03
<vagrantc>
i think it's highly unconventional for a user to now own their homedir, and if mounting with sshfs, the user "owns" the mountpoint too
05:04
sbalneav: yeah, i mean the worst that happens is the homedir is still mounted over sshfs, and you delete the user's files
05:04
most users don't bother to manage their files, so they're never notice
05:04
<sbalneav>
well, that would be bad :D
05:04
We'd have to check that the dir was empty before trying to remove it.
05:05
They never have anything in their directories except pirated MP3's and porn anyway.
05:05
<vagrantc>
ok, first test failed to mount sshfs
05:05
sbalneav: well, libpam_mkhomedir populates the dir with /etc/skel
05:06
sbalneav: unless we can tell it not to
05:06
<sbalneav>
I think so.
05:06
one sec....
05:06
Hmm, I wonder if "skel=/dev/null" would work...
05:06
<vagrantc>
we can pass skell-
05:06
er,
05:06
that
05:07
sbalneav: worst case we can pass an empty directory
05:07
skel=$(mktemp -d)
05:07
heh
05:07
<sbalneav>
Or give them their own chroot environment
05:07
skell=/
05:07
:)
05:08
startup might be a bit slow
05:08
<vagrantc>
heh
05:08
complete with setuid root binaries!
05:08
<sbalneav>
ok, play around with what's there now, I'll fix the sshfs mount tomorrow.
05:08
<vagrantc>
well, i guess those would get chowned
05:08
<sbalneav>
I'm just about ready to pass out. I'll get up early
05:08
have fun
05:08
<vagrantc>
i could probably patch out the detection
05:09
sbalneav: thanks!
05:09
sbalneav: sleep well!
05:09
<sbalneav>
np, glad to hear it's working at least partially
05:09
Success!
05:09
cya
05:14
<vagrantc>
oh, i don't have user_allow_other in fuse.conf
05:18markus_e92 has left IRC (markus_e92!~markus_e9@178-189-219-97.adsl.highway.telekom.at, Ping timeout: 244 seconds)
05:21markus_e92 has joined IRC (markus_e92!~markus_e9@178-189-219-97.adsl.highway.telekom.at)
05:55
<alkisg>
meh, I never get online at the same time as sbalneav :-/
05:59
<vagrantc>
heh
06:00
hrm.
06:00* vagrantc wishes the switch to subprocess could have been tested independent of the mount detection
06:01
<vagrantc>
alkisg: so, i guess you're awake :P
06:05
<alkisg>
:D
06:05* alkisg has already pulled up his sleeves and started working...
06:18Statler has joined IRC (Statler!~Georg@p4FC878B3.dip0.t-ipconnect.de)
06:22* vagrantc too
06:23* gehidore is thinking about going to bed
06:24
<vagrantc>
alkisg: so, will need to do some reverts on ltsp-pam support and test where it started having issues
06:24
alkisg: you working on anything in particular?
06:24
alkisg: would be really good to get ltsp uploaded to debian today, to have two upload windows before the freeze
06:28* vagrantc has some hunches about the changes to ssh.py
06:28
<vagrantc>
it also appears to leave the ssh socket behind
06:28
after login, but useable to connect to the server as the user ... but i'm hoping that's *new*
06:31sutula has left IRC (sutula!~sutula@207-118-156-240.dyn.centurytel.net, Ping timeout: 245 seconds)
06:32sutula has joined IRC (sutula!~sutula@207-118-156-240.dyn.centurytel.net)
06:40
<alkisg>
vagrantc: I think we should finish with ltsp uploads soonish, and start working on ltsp6
06:41
<vagrantc>
alkisg: we need some way to track all the stuff we keep thinking of adding to it
06:41
alkisg: to the ltsp upload
06:41
alkisg: the oerlay dir support seems like a good one
06:41
<alkisg>
I'm not sure how much of this is needed now though
06:41
And how much can be postponed for after ltsp6
06:42
<vagrantc>
right, that's why we should make a list and decide on it item by item :)
06:42
<alkisg>
The overlay dir is good, but its use currently is .../root/.ssh/authorized_keys, minor
06:42
<vagrantc>
then we can stop re-thinking it all :)
06:42
i can think of lots of uses for the overlay dir
06:42
<alkisg>
I'm not sure if we'll have any time left to work on ltsp6 though
06:42
We only have 2 days left...
06:42
<vagrantc>
me counts 3.5 days :)
06:42
<alkisg>
We can't work when we're at a school
06:43
<vagrantc>
ah
06:44
alkisg: well, we had some ideas about what *might* be worth implementing ... i think it might be easier to quickly go over the list and rule things out or postpone them
06:44
rather than vaguely decide we don't have time
06:44
<alkisg>
Sure, OK, want to use some kind of pad, or here it's fine?
06:45
E.g. we used http://sync.in/ltsp in the past...
06:47
<vagrantc>
works for me
06:47
looks like we already have lots of ideas there we've probably forgotten about :)
06:52* alkisg goes through the https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=0;dist=unstable;ordering=normal;repeatmerged=0;src=ltsp list...
06:54
<alkisg>
vagrantc: why are bugs like this one not closed? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819160
06:58
<vagrantc>
alkisg: that's probably closeable ... you can email NNN-done@bugs.debian.org to close it
06:58
alkisg: probably just left it open for a while in case there was a response, and didn't get around to housecleaning
06:58
<alkisg>
Gotcha
06:59
I think I'll leave the debian bug cleaning up to you, and participate more in upstream and ubuntu bug reports (which have a "done" button instead of a mail which requires me to google for the appropriate syntax and headers :P)
06:59
<vagrantc>
it would be nice to have a "close-if-no-activity-by" sort of feature in the debian BTS
07:00
<alkisg>
Like the "incomplete" state of launchpad, which closes the bugs after 60 days of inactivity...
07:00
<vagrantc>
alkisg: it's just NNN-done@bugs.debian.org, no special magic headers needed (although Version: is good to add if relevent)
07:01
<alkisg>
Sure, you can substitute google when needed, but I still won't remember it next time :)
07:01* vagrantc generally has to spend several minutes just to find the appropriate launchpad buttons
07:02* alkisg won't be easily convinced that command line handling of bug reports is better than a web ui... maybe it'll be best to bypass that subject :)
07:03* vagrantc doesn't understand how email is commandline
07:04
<vagrantc>
but yes, clearly we have different ideas about what's workable/useable
07:04
<alkisg>
With command line I mean "sending text, verbal commands to a service" instead of "clicking buttons"
07:04
I think that the command line in general works best when someone spends a lot of time with that, frequently
07:04
So, I prefer the console to e.g. nautilus in a lot of cases
07:05
But for things like bug management, which happens once per week or per month, I find it hard to remember all the necessary info, so I prefer GUIs
07:05
With the same rationale, I tell the teachers here to avoid console, because they won't be using it frequently
07:05
And try to develop UIs for the tasks that they'll need
07:06
<vagrantc>
i understand the logic, but i find it takes just as long to remember the GUI commands for many interfaces
07:06
anyways
07:06
<alkisg>
A gui that you have to remember is not well designed
07:07
<vagrantc>
i think we have a decent list of things to say yea or nay to
07:07
<alkisg>
A gui is supposed to be a selection of options that you can look at, and select the correct one in a couple of seconds
07:07
<vagrantc>
i can even find most of the options in launchpad
07:07
can't
07:07
or weather there's a drop-down or freeform tag to do what it is i'm trying to do
07:08
<alkisg>
Maybe our minds work differently; let's both stick with what we're good at
07:08
Me at launchpad, you at the debian bug tracker :)
07:08
<vagrantc>
hear hear
07:09
<alkisg>
!nbd-client
07:09
<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
07:11
<alkisg>
vagrantc: in the shutdown test that you did yesterday, and everything was working fine, were you using NBD swap at the client side?
07:11
<vagrantc>
yes
07:11
and persist
07:12
or wait ... i was using the -swap and -persist arguments to nbd-client
07:12
not using NBD_SWAP
07:12rac_ has joined IRC (rac_!7281176e@gateway/web/freenode/ip.114.129.23.110)
07:12
<rac_>
Good Afternoon,
07:12* vagrantc waves
07:12
<vagrantc>
alkisg: that's an interesting point ... i think swap is configured on my server, but it's not working or something
07:13
<alkisg>
I tried with a vbox ltsp server vm. At first it shut down fine.
07:13
<rac_>
how lts.conf configuration for setting Desktop Background ltsp client on ubuntu 16.04,
07:13
<vagrantc>
alkisg: nevermind, swap is enabled.
07:13
<alkisg>
Then I tried: modprobe nbd; nbd-client server -N swap /dev/nbd1; mkswap /dev/nbd1; swapon /dev/nbd1; poweroff
07:14
The result was that not only it hanged for a couple of minutes, but vbox crashed at the end of that time
07:14
trying again...
07:14
!lts.conf | echo rac_:
07:14
<ltsp>
rac_: lts.conf: (#1) http://manpages.ubuntu.com/lts.conf, or (#2) lts.conf manpage is available in the ltsp-docs package
07:14
<vagrantc>
alkisg: good thing you test in vbox, you find different bugs :)
07:14
<alkisg>
rac_: see LDM_THEME in the lts.conf manpage
07:14
vagrantc: I think the main problem is nbd-client on ubuntu
07:15
It's a very unstable version
07:15
<vagrantc>
alkisg: a reasonably safe assumption :)
07:15
<alkisg>
post-systemd, but without the nbd systemd fixes
07:15
<vagrantc>
alkisg: oh, i wonder if i was experiencing that issue with jessie, which is in a similar situation
07:15
when i tested jessie-backports
07:16
<alkisg>
Yeah you might want to enable the nbd backports too on that
07:18
Hrm, the first two commands were enough to cause the issue.... modprobe nbd; nbd-client server -N swap /dev/nbd1; mkswap /dev/nbd1
07:20
<vagrantc>
hmmm... backports for nbd would require me or someone else to maintain it... hrm.
07:20
<rac_>
Ok Thanks, i will try <alkisg>
07:20
<vagrantc>
my enthusiasm for backports does wane this close to a debian freeze
07:21
sbalneav: well, reverting the mount detection and subprocess patches seems to get it back to a better state for me
07:21
sbalneav: although i think it would be good to switch to subprocess ...
07:23
sbalneav: i haven't figured it out yet, but i *think* the issue has something to do with the switch from "if ltsp and SOCKET in pamh.env:" to "if not ltsp or not SOCKET in pamh.env:"
07:23
not or not syntax gets a little crazy sometimes
07:24
er "not FOO or not BAR" can be really brone to thought errors
07:24Hyperbyt1 has left IRC (Hyperbyt1!jan@middelkoop.cc, Ping timeout: 260 seconds)
07:25Hyperbyte has joined IRC (Hyperbyte!jan@middelkoop.cc)
07:25
<vagrantc>
which apparently were introduced in the subprocess patches ...
07:25* vagrantc tries again only reverting the subprocess patches
07:26
<vagrantc>
alkisg: so, we've got a list, lets make some decisions!
07:26
<alkisg>
vagrantc: I'm working on the shutdown item now...
07:26
<vagrantc>
alkisg: maybe each of us places 1-2 * by each item
07:26
alkisg: or just work on stuff :)
07:27
<alkisg>
but I think that we should skip it and consider it a bug fix for later and work on ltsp6 :D
07:27
<vagrantc>
i guess 0-2 stars
07:27zama has left IRC (zama!~zama@unaffiliated/stryx/x-3871776, Ping timeout: 244 seconds)
07:28
<alkisg>
I can push the ldap related commit... although there's only 1 user that can check if it works or not
07:28mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk)
07:28
<alkisg>
I've never used ldap myself...
07:28vervelak has left IRC (vervelak!~vervelak@139.91.200.185, Ping timeout: 248 seconds)
07:29
<vagrantc>
alkisg: the ldap commit seems useful since it's a fairly generic implementation
07:29
the patch looked big, but mostly due to whitespace?
07:29
<alkisg>
Yes
07:29vervelak has joined IRC (vervelak!~vervelak@139.91.200.185)
07:29* vagrantc should apply it locally and then diff ignoring whitespace
07:29zama has joined IRC (zama!~zama@unaffiliated/stryx/x-3871776)
07:29
<alkisg>
But there might be downsides, like, some people reported using some ldap users and some local groups
07:29
<vagrantc>
hrm.
07:29
<alkisg>
And because of that patch, the local groups were not fetched
07:29
<vagrantc>
ah
07:30
hrm.
07:30
well, if we're unsure about it and don't have a good test plan, i think we should leave it out for now then
07:30
as much as i'd like to improve support for that
07:31
<alkisg>
I think that it's reasonable to tell them "we don't support mixed user/group databases, half in ldap and half locally", but I don't know ldap well enough to say that
07:33
<vagrantc>
wish we had more time to explore splitting the init script into components that could be used by systemd or sysvinit
07:34
<alkisg>
Ah yeah I just remembered the printers-not-starting issue with ubuntu there, putting it on the list...
07:34
<vagrantc>
alkisg: any more thoughts on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810934
07:34
alkisg: network-manager seeing the ethernet
07:36
<alkisg>
vagrantc: no additional thoughts; right now we can only prevent nm from managing the interface; ideally it should be able to show the IP and create VPNs over it, but prohibit the user from changing the IP
07:36
<vagrantc>
oh, this one seems straightforward: https://bugs.launchpad.net/ltsp/+bug/1597358
07:37
<alkisg>
"manual" currently does that fine; if we also want to tell it via an nm configuration file, no harm done, but it doesn't add anything either
07:38
<vagrantc>
basically, ltsp-genmenu should call ltsp-localapps rather than re-implementing ltsp-localapps
07:38
<rac_>
<alkisg> after changing my image to be run comment, ltsp-update-image
07:39
<alkisg>
rac_: I didn't understand what you said
07:44
<vagrantc>
sbalneav: appears to be the subprocess patches, either one or both
07:45
alkisg: apparently i'm working on ltsp6 stuff concurrently ... which is maybe silly
07:45schlady has joined IRC (schlady!~schlady@141-53-219-214.ip.uni-greifswald.de)
07:45
<alkisg>
vagrantc: I cannot work on ltsp6 until you help me set it up :)
07:46
<vagrantc>
alkisg: it's pretty easy, you install the package :)
07:46
<alkisg>
So, do I need a chroot, or can I do it with ltsp-pnp?
07:46ricotz has joined IRC (ricotz!~ricotz@p5B2A894F.dip0.t-ipconnect.de)
07:46ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
07:47
<vagrantc>
alkisg: i've been testing it with LTSP-PNP
07:47
alkisg: http://wiki.ltsp.org/wiki/Dev:LTSPPamNotes#Current_Progress and ignore the bits referencing libpam-sshauth
07:47
<alkisg>
It won't affect my logins to my work PC, will it? :D
07:48
<vagrantc>
alkisg: it *shouldn't*
07:48
<alkisg>
" the lightdm file should go in /etc/pam.d. Backup the original somewhere. This replaces it. Modify the host= option appropriately. host=server should work, make sure server is set in /etc/hosts "
07:48
<vagrantc>
alkisg: all the features are enabled via init-ltsp.d stuff
07:49
<alkisg>
==> shouldn't that be done from init-ltsp.d?
07:49
<vagrantc>
alkisg: basically, just install the ltsp-pam package, which does all that manual stuff from init-ltsp.d hooks
07:49
alkisg: exactly!
07:50
alkisg: just skip to the current progress section and install ltsp-pam, and set the lts.conf variables as described
07:51
alkisg: the repository is signed by my key, one more reason to exchange signatures :)
07:51
<alkisg>
ltsp-pam.install:
07:51
ltsp-pam/ltsp.desktop /usr/share/xsessions/
07:51
ltsp-pam/xsession /etc/ltsp-pam/
07:52
Shouldn't those too, be done by init-ltsp.d?
07:52
<vagrantc>
if you must :P
07:53
although i put xsession in /etc/ltsp-pam specifically so it can be tweaked manually easily
07:53
the ltsp.desktop should ideally be autogenerated from the .desktop files present on the server's xsessions
07:53
if that's possible
07:53
e.g. something like ldminfod
07:54
alkisg: i'd be really surprised if anything used /etc/ltsp-pam/xsession other than our ltsp-pam stuff though
08:00Freejack has joined IRC (Freejack!~Freejack@unaffiliated/freejack)
08:02
<vagrantc>
ugh. really got to troubleshoot this nbd bug better
08:05
ok, it really just seems to be the last subprocess patch that is causing issues
08:34Statler has left IRC (Statler!~Georg@p4FC878B3.dip0.t-ipconnect.de, Remote host closed the connection)
08:36markus_e92 has left IRC (markus_e92!~markus_e9@178-189-219-97.adsl.highway.telekom.at, Ping timeout: 250 seconds)
08:39markus_e92 has joined IRC (markus_e92!~markus_e9@194-166-239-135.adsl.highway.telekom.at)
09:19vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
09:31rac_ has left IRC (rac_!7281176e@gateway/web/freenode/ip.114.129.23.110, Quit: Page closed)
09:35Statler has joined IRC (Statler!~Georg@mail.lohn24.de)
09:56markus_e92 has left IRC (markus_e92!~markus_e9@194-166-239-135.adsl.highway.telekom.at, Ping timeout: 244 seconds)
09:58markus_e92 has joined IRC (markus_e92!~markus_e9@91-115-73-58.adsl.highway.telekom.at)
10:06vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
10:29
<vagrantc>
alkisg: OVERLAY_DIR=/etc/ltsp/overlay-dir
10:30
<alkisg>
Or OVERLAY_DIR="/path/to/$IP"
10:31
<vagrantc>
OVERLAY_DIR=${OVERLAY_DIR:-"/etc/ltsp/overlay-dir"}
10:31
if you want to get particular
10:31
<alkisg>
I meant in lts.conf
10:31
<vagrantc>
if [ -d "${OVERLAY_DIR}" ]; then ...
10:31
yeah, sure
10:32
OVERLAY_DIR=/path/to/fatclient/overlay OVERLAY_DIR=/path/to/model
10:38gvy has joined IRC (gvy!~mike@altlinux/developer/mike)
10:39GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com)
10:41GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Remote host closed the connection)
10:46GodFather has joined IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com)
10:51
<alkisg>
sbalneav, vagrantc, congrats guys, I just tried it and apart from a few glitches it works fine!
10:52
I'm having an issue where "ssh -S ${S} -Y -p ${P} ${H} "${DISPLAYVAR} x-session-manager >> .xsession-error..." asks for the password to access the ssh control socket
10:52
If I provide it manually, then it works fine
10:53
Control sockeet connect(/var/tmp/administrator_server_22): Connection refused
10:53
administrator@server's password:
11:04markus_e92 has left IRC (markus_e92!~markus_e9@91-115-73-58.adsl.highway.telekom.at, Ping timeout: 260 seconds)
11:06
<alkisg>
So, it works fine on the first time, but then it leaves this process running:
11:06
0:00 /usr/bin/ssh -YMNnq -S /var/tmp/administrator_server_22 -p 22 -l administrator server
11:06markus_e92 has joined IRC (markus_e92!~markus_e9@194-166-99-141.adsl.highway.telekom.at)
11:07
<alkisg>
manually killing it makes everything work again
11:23
vagrantc: can you paste the lts.conf you're using to test the pam stuff?
11:25
ii tzdata 2016h-0ubuntu0.16.04 all time zone and daylight-saving time data
11:27
<vagrantc>
alkisg: https://paste.debian.net/900857/
11:27
alkisg: lts.conf
11:27
<alkisg>
vagrantc: hmm, SCREEN_02=shell makes mine default to vt2
11:28
chvt 7 there then properly brings up lightdm
11:28
<vagrantc>
hm
11:28
well, that's annoying
11:29* vagrantc wonders if forcing SCREEN_DEFAULT=07 would work around the issue
11:29
<vagrantc>
you could put SCREEN_07=null maybe?
11:29
but then maybe lightdm will move on to another tty
11:29
<alkisg>
SCREEN_07=null does work, yeah
11:38vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
12:26shahin has joined IRC (shahin!50a9ae12@gateway/web/freenode/ip.80.169.174.18)
12:36robb_nl has joined IRC (robb_nl!~robb_nl@ip-62-235-225-134.dsl.scarlet.be)
13:19GodFather has left IRC (GodFather!~rcc@96-35-101-212.dhcp.bycy.mi.charter.com, Ping timeout: 250 seconds)
13:26user3948572 has joined IRC (user3948572!~user39485@mail.lbathivel.com)
14:08shahin has left IRC (shahin!50a9ae12@gateway/web/freenode/ip.80.169.174.18, Quit: Page closed)
14:13
<sbalneav>
On station
14:53ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu)
14:58vsuojanen has left IRC (vsuojanen!~valtteri@83-136-248-31.uk-lon1.host.upcloud.com, Remote host closed the connection)
14:59dtcrshr has joined IRC (dtcrshr!~datacrush@unaffiliated/datacrusher)
15:05mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving)
15:28
<sbalneav>
alkisg: I've updated the ltsp-pam tree to (hopefully) fix the homedir mounting issue. WORKSFORME
15:46user3948572 has left IRC (user3948572!~user39485@mail.lbathivel.com, Quit: Quitte)
16:24robb_nl has left IRC (robb_nl!~robb_nl@ip-62-235-225-134.dsl.scarlet.be, Ping timeout: 258 seconds)
16:49vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
16:57
<sbalneav>
vagrantc: WB
16:57
Update your tree
16:57
1) Mount issue's been (I think) fixed
16:58
2) Updated the 50-whatever file to modify common-auth and -session
16:58
3) Homedir removed on logout
16:58
pam_mkhomedir.so umask=0022 skel=
16:58
is the magic to create an empty homedir
17:13gvy has left IRC (gvy!~mike@altlinux/developer/mike, Quit: Leaving)
17:14
<vagrantc>
yay empty skel
17:14* vagrantc fetchs
17:15Statler has left IRC (Statler!~Georg@mail.lohn24.de, Remote host closed the connection)
17:18
<vagrantc>
sbalneav: might tweak the common-session and common-auth to use cat > /etc/pam.d/$foo < EOF
17:19
or whatever the right syntax with that is...
17:20* vagrantc always has to look it up
17:20
<sbalneav>
Yeah, I was thinking the same myself
17:20
probably be sliiiiightly more readable :D
17:22* vagrantc has to wrap up the dying breed of ltsp5 uploads
17:22
<vagrantc>
alkisg was having troubles getting it to work on Ubuntu ... but that *might* have been some local configuration issues... or something
17:23
<sbalneav>
I should set up a test server/workstation here for an LTSP6 config.
17:24schlady has left IRC (schlady!~schlady@141-53-219-214.ip.uni-greifswald.de, Remote host closed the connection)
17:24
<sbalneav>
ltsp-pam would be available in stretch from backports, yes?
17:24
<vagrantc>
i'll aim for it
17:24schlady has joined IRC (schlady!~schlady@141-53-219-214.ip.uni-greifswald.de)
17:24
<vagrantc>
sbalneav: right now it's basically co-installable with ltsp5
17:25
which is kind of cool
17:25schlady has joined IRC (schlady!~schlady@141-53-219-214.ip.uni-greifswald.de)
17:25
<sbalneav>
I'm kinda pumped.
17:26
What do you figure the chances of getting lightdm-webkit2-greeter as a baseline package in stretch are?
17:26
<alkisg>
sbalneav: my main issue is that if I select the ltsp session, ssh.py prompts me for a password in order to access the ssh socket
17:26
<vagrantc>
sbalneav: almost not at all
17:26
<alkisg>
and since it lacks a terminal, it just hangs there forever, while lightdm/xorg get restarted
17:26
If I wrap it in an xterm, then I see the password prompt, and I'm able to provide it and use the ltsp session properly
17:26
<sbalneav>
alkisg: Try it now. See if it's any better.
17:27
<alkisg>
Ah, sure, doing so...
17:27
<sbalneav>
Hmm, it shouldn't prompt for a password; that's supposed to be supplied by the pam module....
17:27
<alkisg>
sbalneav: it's like the ssh master socket is not valid anymore
17:27
<sbalneav>
wierd.
17:27
vagrantc: Could it come in via backports?
17:27
Here's the problem:
17:28
lightdm-gtk-greeter doesn't handle pam messages.
17:28
If you need password expiry, it won't work.
17:29
All the work I did with lightdm-webkit2-greeter was specificially to get it to the point where it could actually properly pass through the pam convo to you, showing you all prompts/informational messages.
17:29
<alkisg>
vagrantc: I got the systemd-logind service issue; I only removed it for thin clients, but in this case, lightdm needs it to display the poweroff options
17:29
In your case maybe the VM has more ram and defaults to a fat client
17:29schlady has left IRC (schlady!~schlady@141-53-219-214.ip.uni-greifswald.de, Ping timeout: 250 seconds)
17:31
<alkisg>
So yup by forcing LTSP_FATCLIENT=False, lightdm properly displays suspend/reboot/shutdown for me too
17:31
And the user selection drop down box is a lot better now
17:34
vagrantc, sbalneav, I see this in changelog, but the source isn't there, where is it? Source: https://code.launchpad.net/~ltsp-upstream/ltsp/ltsp6-pam
17:35
<sbalneav>
?
17:35* alkisg used the package from vagrantc and is now looking to download the latest source...
17:36
<alkisg>
sbalneav: i.e. where's your code? :)
17:38* vagrantc forgot about irc for a bit
17:39
<alkisg>
vagrantc: where can I download Scotty's latest code?
17:39
I can't find a link in http://wiki.ltsp.org/wiki/Dev:LTSPPamNotes...
17:39
(or, I can find a few wrong links there...)
17:40
<sbalneav>
The stuff we're working on is:
17:40
<vagrantc>
alkisg: https://code.launchpad.net/~ltsp-upstream/+git/
17:40
alkisg: ltsp-pam
17:40
<alkisg>
Ah, git... yeah :D
17:40
<sbalneav>
http://git.launchpad.net/~ltsp-upstream/+git/ltsp-pam
17:40
<alkisg>
That's why it didn't show up anywhere!
17:41
<sbalneav>
doh
17:41
<vagrantc>
alkisg: anywhere that you noticed
17:41
alkisg: one more reason to drop bzr.
17:41
<alkisg>
Well, in the ltsp-upstream "code" tab...
17:41* vagrantc sees a "view git repositories" link
17:41* alkisg fires up his bzr-to-git command translator...
17:42
<alkisg>
vagrantc: so, you can find stuff in launchpad that I cannot find? :D
17:42
GUIs!!!
17:42
<vagrantc>
my travels, bzr to git and back again
17:42
alkisg: i *know* so inconsistant
17:42* alkisg still doesn't see "view git branches" in https://code.launchpad.net/ltsp though...
17:43
<alkisg>
Oh well we'll configure git as the default in the future
17:44
<vagrantc>
sbalneav: i was curious rather than commenting out the logging code if we could pass it a debug flag through the /etc/pam.d/ entry
17:45
sbalneav: debug and/or logging and/or etc.
17:45
<sbalneav>
Yeah, adding in a debug flag's next on my list
17:45
Prolly do that today.
17:46
1) make it work
17:46
2) make it pretty
17:46
3) make it bulletproof
17:46
We're still in 1) :D
17:47
brb sammich
17:49* alkisg thinks 50-display-manager-pam and 50-update-nss should be merged into a single 50-ltsp-pam, which also has some conditional logic there, to not activate itself if ldm is being used...
17:50
<alkisg>
and xsessions/ltsp.desktop should be generated/symlinked from that 50-ltsp-pam script too
17:52
<vagrantc>
sounds reasonable to me
17:53robb_nl has joined IRC (robb_nl!~robb_nl@ip-62-235-225-134.dsl.scarlet.be)
17:54
<alkisg>
sbalneav: instant success with the new version :)
17:55* alkisg retries without the LTSP_FATCLIENT=True bit, to see if that was to blame...
17:56
<alkisg>
Btw, the user that has logged in, isn't removed from extrausers upon logout
17:56
<sbalneav>
Can't be.
17:56
<alkisg>
...and the login works only once
17:56
<sbalneav>
oh, that's bad.
17:57
Wonder why that would be.
17:57
<alkisg>
the ssh master process lingers there without getting killed
17:57
<sbalneav>
Did the tunnel and sshfs shut down?
17:57
Hmmm
17:57
wonder why the ssh -O exit didn't work
17:58
that should happen on the close_session
17:58
<alkisg>
sbalneav: should I be testing the ltsp (=thin) session currently, the mate (=fat) session, or both of them?
17:59
<sbalneav>
Which were you testing there?
18:00
<alkisg>
The ltsp session
18:00
<sbalneav>
Well that's good. I've never tested that. :D
18:00
<alkisg>
Ah, ok :D
18:00
<sbalneav>
Try the fat, see how that behaves.
18:00
That it works as well as it seems to, is good.
18:00
<alkisg>
I didn't have any issues with that one either
18:01
<sbalneav>
Well.... damn. It's *almost* like I kinda know how to do stuff :DF
18:01
:D
18:01
I'm happy
18:01
<alkisg>
It even worked on my thin client with 256 mb ram...
18:01
(as a fat session of course)
18:01
<sbalneav>
hmmm, so all we have to do is figure out why that tunnels not being shut down
18:02
<alkisg>
I was reporting things about the thin session
18:02
Let me do tests & report for the fat session
18:02
<sbalneav>
While you're doing that, I'll take a stab at adding in a "debug" option, so maybe we can figure out what's going on.
18:03
This is... encouraging
18:06
<alkisg>
sbalneav: after logging out from a fat session, I still have the ssh process running:
18:06
adminis+ 2265 0.0 0.5 7756 1356 pts/2 Ss+ 20:04 0:00 /usr/bin/ssh -YMNnq -S /var/tmp/administrator_server_22 -p 22 -l administrator server
18:07
and: # id administrator
18:07
uid=1000(administrator) gid=1000(administrator) ομάδες=1000(administrator)
18:08
The second login does work though
18:11* vagrantc heads out for a bit
18:11
<vagrantc>
looking forward to seeing improvements when i get back :)
18:11vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
18:19
<alkisg>
Ah, the second login actually happened locally... with the local user, the local /home/administrator dir etc
18:19
i.e. because they were not deleted
18:58zama has left IRC (zama!~zama@unaffiliated/stryx/x-3871776, Ping timeout: 244 seconds)
19:11zama has joined IRC (zama!~zama@unaffiliated/stryx/x-3871776)
19:18gp has left IRC (gp!~gp@104-14-168-137.lightspeed.rcsntx.sbcglobal.net, Quit: Leaving)
19:35markus_e92 has left IRC (markus_e92!~markus_e9@194-166-99-141.adsl.highway.telekom.at, Ping timeout: 248 seconds)
19:36markus_e92 has joined IRC (markus_e92!~markus_e9@194-166-99-141.adsl.highway.telekom.at)
19:39
<alkisg>
Erm... I never get an sshfs mounted directory, even after a clean reboot...
19:42* alkisg checks if any ltsp script sets user_allow_other in fuse.conf...
19:44
<alkisg>
Hmm I set it manually, but it still didn't mount /home/username with sshfs
19:52
<sbalneav>
Try now
19:52
I *just* updated the tree
19:52
Found a bug.
19:53
The ssh tunnel was hanging because we were starting it with no homedir.
19:53
It WANTS a $HOME variable
19:53
so I create a tmp home in /var/tmp, and allow the ssh tunnel to use it.
20:12GodFather has joined IRC (GodFather!~rcc@104.137.225.193)
20:18robb_nl has left IRC (robb_nl!~robb_nl@ip-62-235-225-134.dsl.scarlet.be, Quit: robb_nl)
20:52vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
21:05
<sbalneav>
vagrantc: Update your tree
21:06
debug added, another bug fixed
21:08
<vagrantc>
sbalneav: yeah, saw
21:08
sbalneav: will look at it more tomorrow, wrapping up that ltsp upload i hoped to do early this morning. heh. :)
21:09
<sbalneav>
np, just letting you know.
21:09
<vagrantc>
sbalneav: really excited to see this though
21:09
sbalneav: it seems to have the potential to be a lot more maintainable than what we've got now
21:09
<sbalneav>
I'm happy things are working this well.
21:10
<vagrantc>
we've got a lot of pet features throughout the LTSP codebase that are basically unmaintained
21:10
<sbalneav>
Yes, correct me if I'm wrong, but if ltsp-pam becomes LTSP6, then we're (almost) free of compiled code.
21:10
<vagrantc>
will be nice to start fresh with something that ccuts out a lot of code
21:11
yeah, i don't think we'll have compiled code left.
21:11
<sbalneav>
I think Jim's parser for the lts.conf file would be the last bit?
21:12
<vagrantc>
i suspect LTSP6 will be the end of lts.conf ... replace it with ltspd or something like that
21:12
long list of ltsp5/ltsp6 features: http://sync.in/ltsp
21:14
sbalneav: http://wiki.ltsp.org/wiki/Dev:Ltspd
21:16
<sbalneav>
Ah, so just use configparser
21:16
oh, wait
21:16
<vagrantc>
and the parsing can be handled server-side ... or not, i suspect.
21:16
<sbalneav>
no, you're extending configparser
21:17
<vagrantc>
i suspect alkis has thought about it a lot since the time that was written
21:18
<sbalneav>
Well, I see nothing bad about an ltsp6 that's done up with anything complicated being done in python.
21:18
That can only be good for us.
21:20
Infinitely more hackable.
21:20
And fixable on the fly
21:20
<vagrantc>
also plan to completely get rid of ltsp-build-client
21:21
<sbalneav>
Oh, really? What do we to, just export / as read-only via nfs?
21:21
What do we do when thin clients are i386 but servers are AMD64?
21:21
<vagrantc>
for the most part, i think the ltsp-pnp chrootless model works pretty well
21:21
<sbalneav>
'cuz that's my current use case.
21:22
<vagrantc>
i'll probably include some chroot-building code, but nothing as complicated as what ltsp-build-client has become
21:22
many of the hacks ltsp-build-client implemented can be implemented at boot
21:22
<sbalneav>
sure.
21:22
I still like haveing the chroot, personally.
21:22
<vagrantc>
basically, instantiate a chroot, install some packages (ltsp-pam or whatever).
21:23
i might give a go at a simple little ansible example
21:23
or one of the other bajillion chroot creators
21:23
<sbalneav>
prolly best to pick something already written and well maintained.
21:23
<vagrantc>
chroots are good for cross-architecture
21:24
<sbalneav>
lessen our load as much as possible.
21:24
<vagrantc>
sure
21:24
i suspect i could write an ansible thing that's basically 3-5 stanzas
21:24
<sbalneav>
I mean, we're down to basically 2 and a half people working on this: you, alkis, and me (.5)
21:24
<vagrantc>
and even that's optimistic :/
21:25
<sbalneav>
I'll keep plugging away at it, for as long as I've got breath in me. I got a good 20 some odd years in me, I figure.
21:26ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
21:26
<sbalneav>
I'm not as active as I used to be, but I've never abandonded it either :D
21:26
<vagrantc>
the reality is that alkis and i aren't as active as we once were either
21:26
i haven't had a real-world install in quite some time
21:27
<sbalneav>
Well, and that's due to the unmaintainability of it.
21:27
<vagrantc>
had a brief fling last year
21:27
i'm *hoping* we won't have as much maintenance to do with some of these new ideas, yeah
21:27
<sbalneav>
If we hack out all the "edge case" usages, and make something that works for 80% of the population...
21:27
<vagrantc>
but a huge part of LTSP... is fixing bugs in random upstream software we depend on
21:28
<sbalneav>
right, but now, with the way we're going... there's a lot more eyes already on those pieces.
21:28
getting a bug fixed in lightdm will be easier than fixing ldm :D
21:29
bbiab, duty calls.
21:29* vagrantc waves
21:29
<sbalneav>
Or if you're heading to bed, night
21:32
<vagrantc>
first, upload ltsp-5.5.9 :)
21:32
i'm at the edit debian/changelog to a readable, reasonable log
21:58GodFather has left IRC (GodFather!~rcc@104.137.225.193, Quit: Ex-Chat)
21:58GodFather_ has joined IRC (GodFather_!~rcc@104.137.225.193)
22:25GodFather_ has left IRC (GodFather_!~rcc@104.137.225.193, Quit: Ex-Chat)
22:25GodFather__ has joined IRC (GodFather__!~rcc@104.137.225.193)
22:50GodFather__ has left IRC (GodFather__!~rcc@104.137.225.193, Ping timeout: 248 seconds)
22:56
<vagrantc>
ok... ltsp-5.5.9 tagged, and ltsp 5.5.9-1 uploaded to Debian.
22:56* vagrantc sleep 28800
22:56* vagrantc wishes
22:57vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)