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


Channel log from 19 December 2013   (all times are UTC)

00:10staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 240 seconds)
00:52Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
01:16Selveste1 has left IRC (Selveste1!~Selveste1@static-5-103-136-165.seas-nve.net, Ping timeout: 250 seconds)
01:21Selveste1 has joined IRC (Selveste1!~Selveste1@static-5-103-136-165.seas-nve.net)
01:32Selveste1 has left IRC (Selveste1!~Selveste1@static-5-103-136-165.seas-nve.net, Read error: Operation timed out)
01:32Selveste1 has joined IRC (Selveste1!~Selveste1@static-5-103-136-165.seas-nve.net)
02:10Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Quit: Leaving.)
02:30mattcen has joined IRC (mattcen!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au)
02:54Fenuks has joined IRC (Fenuks!~Fenuks@80.89.133.25)
03:02alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
03:11
<alkisg>
Good morning
03:12
vagrantc: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1262287
03:13
Do you think we should start mounting /tmp as a tmpfs on the clients, as most distros do nowadays? (btw what do wheezy/jessy do with /tmp?)
03:14
I don't know if the problem is only with ssh or if it affects all sockets in /tmp.... if it does, gnome-keyring, pulseaudio etc are also affected
03:41
Hmmm wheezy doesn't, ok
03:44
<vagrantc>
it's an optional feature in wheezy
03:46
dunno if there are new plans for jessie
03:46
i often configure my setups too use tmpfs on /tmp
03:47
<alkisg>
Anyways, for libpam-sshauth we should change the socket to /var
03:48
err, /var/run or /run
03:48
<vagrantc>
yeah, /var/run or /run would be fine
03:49* alkisg assumes that aufs doesn't have the same problem as overlayfs, since vagrantc and sbalneav didn't experience it...
03:50
<vagrantc>
although we'd need to create a subdir in /run that was owned by the user to create the user-owned socket, yes?
03:51
<alkisg>
There's a trend for user-owned dirs in /run/user, e.g.: $ echo $XDG_RUNTIME_DIR
03:51
/run/user/1002
03:51
Too bad that mktemp doesn't use it yet
03:51
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html, Lennart Poettering etc
04:00
<vagrantc>
mktemp -d /run/user/BLAH
04:00
mktemp -d /run/user/BLAH/tmpfile-XXXX ?
04:01
<alkisg>
Sure, or setting TMPDIR
04:02
<vagrantc>
many programs ignore tempdir intentionally
04:02
<alkisg>
I think the spec says that a program should prefer XDG_RUNTIME_DIR first, then honour TMPDIR etc
04:04
vagrantc: maybe for ltsp we could create /run/tmp and dynamically symlink /tmp to it?
04:04
Or are there any issues if /tmp is a symlink?
04:04
http://lists.freedesktop.org/archives/xdg/2010-November/011707.html
04:05
and then http://lists.freedesktop.org/archives/xdg/2010-November/011709.html
04:05* vagrantc wonders how many applications will follow those specs, though
04:10
<alkisg>
Hmmm so if /tmp is a tmpfs, maybe we shouldn't be putting nbd-swap there, but to /var/tmp instead?
04:33alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 264 seconds)
05:27gdi2k has joined IRC (gdi2k!~gdi2k@120.28.248.83)
05:30
<gdi2k>
alkisg, Thanks for your assistance the other day with the strange audio issues I was having (frequencies being cut, causing voice quality issues on VOIP). Turns out the headsets are "optimized" and cut off at less than 10 khz. This, combined with linphone cutting the higher again for ulaw resulted in bad clarity. We've switched to wideband speex16 on the clients and let Asterisk do the conversion to ulaw, and now things are fine
05:30
(sound on ltsp itself is fine)
05:31
<alkisg>
gdi2k: good to hear :)
05:32
<gdi2k>
I have 10 thin clients on my server now, and load is around 6 - 7 when all are doing work. This is on a quad core with no HT. Time to upgrade?
05:37
<alkisg>
!fatclient
05:37
<ltsp>
I do not know about 'fatclient', but I do know about these similar topics: 'fatclients', 'fatclient-printers'
05:37
<alkisg>
!fatclients
05:37
<ltsp>
fatclients: You may find some info about the Ubuntu/LTSP implementation of fat clients at https://help.ubuntu.com/community/UbuntuLTSP/FatClients
05:37
<alkisg>
:)
05:37
...or localapps
05:38
<gdi2k>
I'm familiar with fat clients but our machines are crusty old antiques, running something like firefox locally would drive people nutty. We do run skype and linphone local though
05:38
<vagrantc>
run a lighter desktop?
05:39
<gdi2k>
we use XFCE, which isn't bad - much lighter and I worry about usability
05:40
<vagrantc>
dunno how LXDE compares, but i think it's even lighter and comprable useability, depending on what you're using
05:40* alkisg was suggesting that instead of spending money on a better server you could spend them on new clients instead
05:40
<gdi2k>
is fat clients the way to go these days if adding new clientds?
05:40
<vagrantc>
arguably ... many applications behave badly on thin clients
05:41
<gdi2k>
seems like I can put together a current-gen celeron for $200, which will probably be faster than the server (Phenom X4 955)
05:41
<vagrantc>
gdi2k: you're running with LDM_DIRECTX=true ?
05:41
<alkisg>
vagrantc: so, about the user-owned ssh socket, remoteapps etc, can we just depend on socat which can bind a user-owned socket with the ssh socket, and also supports multiple connections with it (forking), and call it a day? :)
05:41
That way keys would also still work
05:41
<gdi2k>
vagrantc, yes
05:41
<vagrantc>
alkisg: i'm ok with that :)
05:42
<alkisg>
Nice, thanks :)
05:42
<vagrantc>
alkisg: it doesn't have many dependencies we don't already have installed, doesn't increase the image size significantly, and is code we don't have to maintain :)
05:43
<alkisg>
And we can reuse it in many places
05:43* vagrantc assumes socat is commonly available in multiple distros
05:44
<alkisg>
I think it's even available in windows... :D
05:44
<vagrantc>
wtsp?
05:45
<alkisg>
maybe atsp too
05:45
(android :P)
05:45* vagrantc hasn't worked on dgkfbsdtsp for a couple years
05:46* vagrantc threatened to work on dghtsp at one point
05:47* alkisg is reading a _presentation_ of vagrantc about dgkfbsdtsp and wonders why it isn't written in plain text... :D
05:48
<alkisg>
bbiab
05:48alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection)
05:49
<gdi2k>
on a fat client set up, the server doesn't do much aside from serving up boot images and file systems for the clients right? As long as it has good disks and network, it doesn't have to be a monster right?
06:27work_alkisg is now known as alkisg
06:27
<alkisg>
gdi2k: right
06:29
<gdi2k>
alkisg, nice, so at this point, as I have no more thin clients and the server is at its limit, my best approach to adding would be to just add fat clients and perhaps a new fast-disk'd "server" just for those fat clients. reasonable?
06:36
<alkisg>
gdi2k: sure, and you probably don't even need the faster disk
06:37
<gdi2k>
alkisg, sounds good, thanks for your help
06:37
<alkisg>
vagrantc: proof of concept: pam) ssh -NMS /tmp/s guest@localhost
06:37
ltsp-remoteappsd) socat UNIX-LISTEN:/tmp/soc,fork EXEC:"ssh -S /tmp/s guest@localhost"
06:37
ltsp-remoteapps) socat - UNIX-CONNECT:/tmp/soc
06:38
...and now ltsp-remoteapps can get output from the server AND are able to run in parallel :)
06:38freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
06:39
<alkisg>
(or EXEC:"ssh -XCS /tmp/s guest@localhost" to get a display too)
06:45
...-XC is needed on both the EXEC line and on the ssh line
06:46
vagrantc: currently, remoteapps always use the ssh socket, regardless of the LDM_DIRECT value, right?
06:46
I mean, they don't do the xhost magic, but run ssh -Y...
07:05
<vagrantc>
alkisg: don't remember
07:11
looking at the reverse dependencies for socat, all sorts of cool projects use it.
07:11
maybe ltsp will be cooler when we switch to using it.
07:12
<alkisg>
If I run `ssh -MS` as user, I can then just go ahead and reuse it with `ssh -S` as root
07:13
If I run `ssh -MS` as root and then chown the socket, I can't reuse it with `ssh -S` as user...
07:13* alkisg asks in #openssh if that should be possible somehow, which would save us from all the trouble...
07:16
<alkisg>
Meh... the filesystem again, tmpfs behaves differently than ext4
07:18
Ah, seteuid might do it
07:19
<vagrantc>
ouch
07:21
well, have fun with that! :)
07:21
<alkisg>
bb!
07:21vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
07:35freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Ping timeout: 260 seconds)
07:51freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
08:00staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu)
08:07staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 260 seconds)
08:13vmlintu has joined IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi)
08:15alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
09:03bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Read error: Operation timed out)
09:04freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish)
09:04bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com)
09:08
<alkisg>
Yey, libpam-sshauth works for me too! :D
09:19Gremble has joined IRC (Gremble!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net)
09:19Gremble is now known as Guest33252
10:16workingcats has joined IRC (workingcats!~workingca@212.122.48.77)
11:01staffencasa has joined IRC (staffencasa!~staffenca@128.193.8.220)
11:07staffencasa has left IRC (staffencasa!~staffenca@128.193.8.220, Ping timeout: 240 seconds)
11:11Fenuks has left IRC (Fenuks!~Fenuks@80.89.133.25, Read error: Operation timed out)
11:45willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116)
11:47alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 245 seconds)
11:57alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
12:38alkisg has left IRC (alkisg!~alkisg@plinet.ioa.sch.gr, Quit: Leaving.)
12:42work_alkisg has joined IRC (work_alkisg!~alkisg@plinet.ioa.sch.gr)
12:45work_alkisg has left IRC (work_alkisg!~alkisg@plinet.ioa.sch.gr, Client Quit)
12:45work_alkisg has joined IRC (work_alkisg!~alkisg@plinet.ioa.sch.gr)
12:48work_alkisg has joined IRC (work_alkisg!~alkisg@plinet.ioa.sch.gr)
12:49work_alkisg is now known as alkisg
12:49brunolambert has joined IRC (brunolambert!brunolambe@nat/revolutionlinux/x-klutklhhjxctmdjq)
13:01cliebow has left IRC (cliebow!~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us, Ping timeout: 272 seconds)
13:09vmlintu has left IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi, Read error: Connection reset by peer)
13:14cliebow has joined IRC (cliebow!~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us)
13:41freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
13:49Guest33252 has left IRC (Guest33252!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net, Quit: I Leave)
13:52knipwim has left IRC (knipwim!~wim@ip4da83870.direct-adsl.nl, Quit: leaving)
15:18mgariepy has left IRC (mgariepy!mgariepy@ubuntu/member/mgariepy, Quit: Leaving)
15:20mgariepy has joined IRC (mgariepy!mgariepy@ubuntu/member/mgariepy)
15:40staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu)
15:47staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 240 seconds)
15:49staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu)
16:14Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
16:18staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 240 seconds)
16:22vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
16:32alkisg1 has joined IRC (alkisg1!~alkisg@ubuntu/member/alkisg)
16:42Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Quit: Leaving.)
16:45alkisg has left IRC (alkisg!~alkisg@plinet.ioa.sch.gr, Ping timeout: 248 seconds)
16:46work_alkisg has joined IRC (work_alkisg!~alkisg@plinet.ioa.sch.gr)
16:51alkisg1 is now known as alkisg
16:52gdi2k has left IRC (gdi2k!~gdi2k@120.28.248.83, *.net *.split)
16:52alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 264 seconds)
16:55gdi2k has joined IRC (gdi2k!~gdi2k@120.28.248.83)
16:58gdi2k has left IRC (gdi2k!~gdi2k@120.28.248.83, *.net *.split)
17:04gdi2k has joined IRC (gdi2k!~gdi2k@120.28.248.83)
17:09gdi2k has left IRC (gdi2k!~gdi2k@120.28.248.83, *.net *.split)
17:12
<alkisg>
vagrantc: I managed to get libpam-sshauth/lightdm and libpam-sshauth/logind working!
17:12
So, just to make sure, the plan now is to write an ldm in shell that uses libpam-sshauth, and drop ldm.c/ssh.c etc, right?
17:12
...but keep using our greeter...
17:15gdi2k has joined IRC (gdi2k!~gdi2k@120.28.248.83)
17:19
<alkisg>
vagrantc: and the next step after that, would be to merge ltspdm/ldminfod/gtkgreeter to ltsp-trunk, and drop ldm-trunk?
17:22
<vagrantc>
hm.
17:22
alkisg: i think it should still be a separate project
17:22
<alkisg>
vagrantc: the greeter?
17:23
or ltsp-pam?
17:23
<vagrantc>
alkisg: at least
17:23
alkisg: not killing off ldm-trunk, but maybe changing what's there.
17:23
still not clear on the need to rewrite in shell...
17:23
<alkisg>
OK, I don't mind at all, as long as ldm-trunk is just the greeter, it doesn't even receive a lot of updates...
17:24
It's just much easier, I think it's overengineered now, with plugins etc
17:25
It's much harder to test/debug, to add features in it, it needs more ram... i don't see any benefits at all in having it in .c
17:25
The greeter, sure. libpam-sshauth, sure. But ldm.c is just a wrapper to run shell scripts...
17:26
For example, it'll take me longer to write ldm/pam.c than to rewrite ldm from scratch in shell...
17:27
There's a regression potential, ok, but it's there anyway since we're switching to pam
17:28
<vagrantc>
and the reason to do this rewrite rather than switch to lightdm is we don't think we'll be able to run enough of the ldm hooks from lightdm?
17:29
or *dm?
17:30
<alkisg>
The rewrite should take e.g. a week, then we can progressively start modifying the code so that any dm is supported
17:30
But lightdm has a lot of bugs, e.g. it messes up the keyboard layout so people using it can't type greek after login if they don't go to gnome control center and manually add the keyboard layout,
17:31
there are problems with accountsservice etc etc... it's quite buggy
17:31
Many bug reports were filed years ago but noone seems to care
17:31
<vagrantc>
hrm,
17:31
well, that's a shame.
17:32
<alkisg>
Also, moving to lightdm will require a lot of changes, I don't think we can do them in a single run
17:33
and we'll lose a lot of functionality, e.g. we won't be able to select a server or a backend easily
17:33
<vagrantc>
alkisg: are these lightdm issues things that haven't gotten fixed at all, or are we talking about backportability?
17:33
<alkisg>
They're not fixed at all
17:33
<vagrantc>
regarding the server/backend selection ... those could be implemented as session types...
17:34
but that gets pretty ugly.
17:34
<alkisg>
Yeah, imagine 10 servers and 3 backends... :D
17:35
<vagrantc>
most of my setups have been 2-4 servers with 1 backend...
17:35
and 2-5 session types
17:36
<alkisg>
I think the most significant part is that with ldm (in shell or c, that doesn't matter) we'll be able to move forward progressively, we'll have something that still works in any commit in ltsp-trunk
17:36
Then we'll have enough time to think on how to properly implement the session types, where to put the hooks etc...
17:36
<vagrantc>
with getting ldm using libpam-sshauth, we're talking about something that could work in parallel with lightdm support
17:36
<alkisg>
Sure
17:37
<vagrantc>
so those who didn't need features could still use *dm, but default would still be the next-gen ldm
17:37
<alkisg>
Yup I think we agree on everything _but_ the need to rewrite ldm in shell
17:38
Your main objections are regressions and security, right?
17:38
<vagrantc>
yeah. regressions are likely to happen no matter which route we go though.
17:39
maybe even more likely with lightdm/libpam-sshauth
17:40
<alkisg>
s/maybe/surely/ :)
17:41
With ldm in shell we're supposed to keep all the existing functionality without changing anything in ltsp, while with lightdm we'll have to rewrite all the hooks, rename all the LDM* lts.conf variables etc etc
17:43
vagrantc: why did you use pam-mkhomedir instead of mounting it with sshfs ia the ssh socket?
17:43
*via
17:43
libpam-sshauth does give us a hook that runs as root, right?
17:49freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish)
17:49staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu)
17:52
<vagrantc>
alkisg: i just followed sbalneav's instructions and turned it into a package
17:52
maybe tweaked a few things
17:53
alkisg: i think you need the homedir to actually mount, and may as well use pam_mkhomedir?
17:54
<alkisg>
vagrantc: the idea there is to run sshfs as the user/
17:54
?
17:54
EXTRAMOUNTS won't work that way...
17:54
...meh, not even /home/username can be mounted that way, the user has no rights there
17:55
<vagrantc>
alkisg: root or user, you need the directory to mount on top of
17:55
<alkisg>
But why use pam when we can do it with mkdir?
17:55
<vagrantc>
dunno.
17:56
alkisg: why *not* use the pam_mkhomedir?
17:56
<alkisg>
We already have scripts that do all that.. I think the first steps forward should involve as little changes to our existing scripts as possible, to avoid regressions
17:56
<vagrantc>
sure
17:56
<alkisg>
Well, to prevent installing a whole package and putting it to the pam stack just to avoid an existing mkdir...
17:59* alkisg tries to organize his thoughts:
18:00
<alkisg>
The move to lightdm will need a lot of time, I don't think it can be done for e.g. 14.04, and I doubt it can be ready for jessie,
18:00
<vagrantc>
it doesn't require an additional package
18:01
<alkisg>
so that means ldm/pam.c or ldm.sh need to be implemented in order to have something releaseable for them...
18:02
And, I think I'd want to invest in those three options in this order: 1) ldm.sh, 2) lightdm, 3) ldm/pam.c
18:02bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 265 seconds)
18:03
<alkisg>
I don't mind going with (2), but I fear that ltsp-trunk won't be in a releaseable state for 14.04/jessie
18:03* alkisg can work-around most of the lightdm bugs with sch-scripts, e.g. automatically fix the keyboard layout after lightdm breaks it on login etc
18:04
<vagrantc>
is gdm any better?
18:04
<alkisg>
I don't remember if lightdm works in 16 bit color mode or not
18:04
<vagrantc>
it does on debian
18:04
<alkisg>
gdm 2 was fine, gdm 3 was broken for as long as ubuntu had it, I don't know if they fixed it recently
18:05bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com)
18:05
<alkisg>
I suppose all the LDM* variables should go away from lts.conf before releasing ltsp 6, if we decide that we want to completely drop ldm, right?
18:06
<vagrantc>
makes sense
18:07
<alkisg>
So yup I don't think we can drop ldm in time for 14.04/jessie with our currently limited time/manpower etc
18:08
...so maybe it's time to hit a pause button, focus on bug fixing etc, and continue with the big plans for the next big releases... :)
18:09* vagrantc 's next big release is in 2015, freeze end of 2014
18:09
<vagrantc>
but i guess there's always backports...
18:09
hopefully.
18:12Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
18:13
<alkisg>
What we _could_ do at this time, is to introduce the replacement of the LDM* variables, and support both of them until ltsp 6...
18:15
E.g. LDM_PRINTER_LIST could become LTSP_PRINTER_LIST, and be implemented for both ldm and *dm...
18:17* vagrantc notes there are still some LTSP 4.x compatibility variables in code
18:20
<alkisg>
I wonder if we can have code that renames all the LDM_* environment variables to LTSP_* variables, so that then the new code only checks for LTSP_*...
18:20
LTSP_AUTOLOGIN, LTSP_DIRECTX, LTSP_SSHOPTIONS, LTSP_SESSION... do those names make sense?
18:22
<vagrantc>
would need to make sure the compatibility layer was available...
18:23
i.e. versioned depends/breaks and such
18:23
but that doesn't sound too hard.
18:23
<alkisg>
We can duplicate the variables instead of renaming them
18:24
Nah it doesn't make sense, if we're going to move scripts from ldm to ltsp then we don't want the ldm scripts to do the same tasks twice
18:24
<vagrantc>
ah, only new code will use the new vars... got it
18:25
yeah, don't move that code into LTSP.
18:25
<alkisg>
We will move it in the future, right?
18:25
You just don't want to move it yet?
18:25
<vagrantc>
only when you completely are rid of LDM...
18:26
<alkisg>
I failed to express it correctly, but the idea above ^ was to move the scripts first, so that the "getting rid of ldm" was much easier later on
18:26
...while ltsp-trunk/ldm-trunk were still in a releaseable state at any time
18:26
<vagrantc>
moving scripts from ldm-trunk to ltsp-trunk will create really crazy interdependencies
18:27
<alkisg>
I feel that the "start with getting rid of ldm" equals to "have ltsp broken for 6 work-months",
18:27
<vagrantc>
i don't think that's possible as an incremental step
18:28
<alkisg>
...that's why I was trying to find ways to do it progressively, either with ldm/pam.c or with that ^ idea...
18:28
<vagrantc>
right
18:28
but i don't think it's good to move the ldm hooks out of ldm.
18:29
<alkisg>
OK, yeah that's reasonable too, even though ldm doesn't really work without ltsp...
18:29
<vagrantc>
i had ldm workinng without LTSP at one point...
18:29
just as a proof of concept
18:30
<alkisg>
Wait, maybe I missed something... are you saying that we can rename the variables to LTSP_* currently, and just leave the scripts in the ldm package?
18:30
Or are you also saying "don't rename the variables yet"?
18:30
<vagrantc>
i'm saying don't move scripts.
18:30
<alkisg>
(it's not just about renaming, it's also about finding dm-agnostic ways to do things)
18:30
<vagrantc>
i *think* variable renaming could still happen even with scripts in LDM
18:31workingcats has left IRC (workingcats!~workingca@212.122.48.77, Quit: Leaving)
18:31
<alkisg>
...so there's work to do before dropping ldm, nice :)
18:33
<vagrantc>
basically, can either update LDM to use LTSP_* vars, and have a compatibility layer that sets LTSP_* from LDM_* (if LTSP_* is unset)
18:34
or leave LDM as is, and set up the compatibility layer to set LDM_* from LTSP_* (if LDM_* is unset).
18:35
for the dm-agnostic stuff ... we could have hook dirs that copy some of the functionality in LDM into LTSP directly, but LDM wouldn't use them. but that's kind of ugly to maintain forked code.
18:35
or LDM could be rewritten to check both vars every time...
18:41
<alkisg>
Let's see an example
18:41
Currently: LDM_SSHOPTIONS, SSH_OVERRIDE_PORT
18:41
Future: PAM_SSHAUTH_HOST, PAM_SSHAUTH_PORT
18:41staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 245 seconds)
18:41
<alkisg>
...no SSHOPTIONS there
18:42
So, we could implement those from init-ltsp.d by modifying /etc/ssh/*config,
18:42
or we could ask Scotty to implement them in libpam_sshauth, if we need them
18:42
And then ok the compatibility scripts would do the appropriate renames...
18:48alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
18:51
<alkisg>
OK, I'm convinced. When we do decide to move forward, the way to do is to duplicate ltsp-trunk to ltsp-old, start breaking :P things in ltsp-trunk, and just backport relevent stuff to ltsp-old until ltsp-trunk is releaseable... :D
18:53
<vagrantc>
ltsp-5.x
19:26staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu)
19:37willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Ping timeout: 250 seconds)
19:44staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 272 seconds)
19:47Phantomas1 has joined IRC (Phantomas1!~Phantomas@ubuntu/member/phantomas)
19:48Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 250 seconds)
19:53staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu)
20:11vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
20:20Phantomas1 has left IRC (Phantomas1!~Phantomas@ubuntu/member/phantomas, Ping timeout: 264 seconds)
20:32alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection)
20:38Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
21:02freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
21:48brunolambert has left IRC (brunolambert!brunolambe@nat/revolutionlinux/x-klutklhhjxctmdjq, Quit: Leaving.)
21:53willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116)
23:12alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 245 seconds)
23:21Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Remote host closed the connection)
23:24telex has left IRC (telex!~telex@freeshell.de, Read error: Connection reset by peer)
23:28telex has joined IRC (telex!~telex@freeshell.de)