IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 19 December 2013 (all times are UTC)
| 00:10 | staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 240 seconds) | |
| 00:52 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 01:16 | Selveste1 has left IRC (Selveste1!~Selveste1@static-5-103-136-165.seas-nve.net, Ping timeout: 250 seconds) | |
| 01:21 | Selveste1 has joined IRC (Selveste1!~Selveste1@static-5-103-136-165.seas-nve.net) | |
| 01:32 | Selveste1 has left IRC (Selveste1!~Selveste1@static-5-103-136-165.seas-nve.net, Read error: Operation timed out) | |
| 01:32 | Selveste1 has joined IRC (Selveste1!~Selveste1@static-5-103-136-165.seas-nve.net) | |
| 02:10 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Quit: Leaving.) | |
| 02:30 | mattcen has joined IRC (mattcen!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au) | |
| 02:54 | Fenuks has joined IRC (Fenuks!~Fenuks@80.89.133.25) | |
| 03:02 | alkisg 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:33 | alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 264 seconds) | |
| 05:27 | gdi2k 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:48 | alkisg 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:27 | work_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:38 | freedomrun 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:21 | vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving) | |
| 07:35 | freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Ping timeout: 260 seconds) | |
| 07:51 | freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun) | |
| 08:00 | staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu) | |
| 08:07 | staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 260 seconds) | |
| 08:13 | vmlintu has joined IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi) | |
| 08:15 | alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47) | |
| 09:03 | bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Read error: Operation timed out) | |
| 09:04 | freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish) | |
| 09:04 | bennabiy 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:19 | Gremble has joined IRC (Gremble!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net) | |
| 09:19 | Gremble is now known as Guest33252 | |
| 10:16 | workingcats has joined IRC (workingcats!~workingca@212.122.48.77) | |
| 11:01 | staffencasa has joined IRC (staffencasa!~staffenca@128.193.8.220) | |
| 11:07 | staffencasa has left IRC (staffencasa!~staffenca@128.193.8.220, Ping timeout: 240 seconds) | |
| 11:11 | Fenuks has left IRC (Fenuks!~Fenuks@80.89.133.25, Read error: Operation timed out) | |
| 11:45 | willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116) | |
| 11:47 | alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 245 seconds) | |
| 11:57 | alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47) | |
| 12:38 | alkisg has left IRC (alkisg!~alkisg@plinet.ioa.sch.gr, Quit: Leaving.) | |
| 12:42 | work_alkisg has joined IRC (work_alkisg!~alkisg@plinet.ioa.sch.gr) | |
| 12:45 | work_alkisg has left IRC (work_alkisg!~alkisg@plinet.ioa.sch.gr, Client Quit) | |
| 12:45 | work_alkisg has joined IRC (work_alkisg!~alkisg@plinet.ioa.sch.gr) | |
| 12:48 | work_alkisg has joined IRC (work_alkisg!~alkisg@plinet.ioa.sch.gr) | |
| 12:49 | work_alkisg is now known as alkisg | |
| 12:49 | brunolambert has joined IRC (brunolambert!brunolambe@nat/revolutionlinux/x-klutklhhjxctmdjq) | |
| 13:01 | cliebow has left IRC (cliebow!~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us, Ping timeout: 272 seconds) | |
| 13:09 | vmlintu has left IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi, Read error: Connection reset by peer) | |
| 13:14 | cliebow has joined IRC (cliebow!~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us) | |
| 13:41 | freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun) | |
| 13:49 | Guest33252 has left IRC (Guest33252!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net, Quit: I Leave) | |
| 13:52 | knipwim has left IRC (knipwim!~wim@ip4da83870.direct-adsl.nl, Quit: leaving) | |
| 15:18 | mgariepy has left IRC (mgariepy!mgariepy@ubuntu/member/mgariepy, Quit: Leaving) | |
| 15:20 | mgariepy has joined IRC (mgariepy!mgariepy@ubuntu/member/mgariepy) | |
| 15:40 | staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu) | |
| 15:47 | staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 240 seconds) | |
| 15:49 | staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu) | |
| 16:14 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 16:18 | staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 240 seconds) | |
| 16:22 | vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc) | |
| 16:32 | alkisg1 has joined IRC (alkisg1!~alkisg@ubuntu/member/alkisg) | |
| 16:42 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Quit: Leaving.) | |
| 16:45 | alkisg has left IRC (alkisg!~alkisg@plinet.ioa.sch.gr, Ping timeout: 248 seconds) | |
| 16:46 | work_alkisg has joined IRC (work_alkisg!~alkisg@plinet.ioa.sch.gr) | |
| 16:51 | alkisg1 is now known as alkisg | |
| 16:52 | gdi2k has left IRC (gdi2k!~gdi2k@120.28.248.83, *.net *.split) | |
| 16:52 | alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 264 seconds) | |
| 16:55 | gdi2k has joined IRC (gdi2k!~gdi2k@120.28.248.83) | |
| 16:58 | gdi2k has left IRC (gdi2k!~gdi2k@120.28.248.83, *.net *.split) | |
| 17:04 | gdi2k has joined IRC (gdi2k!~gdi2k@120.28.248.83) | |
| 17:09 | gdi2k 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:15 | gdi2k 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:49 | freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish) | |
| 17:49 | staffencasa 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:02 | bennabiy 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:05 | bennabiy 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:12 | Phantomas 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:31 | workingcats 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:41 | staffencasa 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:48 | alexqwesa 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:26 | staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu) | |
| 19:37 | willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Ping timeout: 250 seconds) | |
| 19:44 | staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 272 seconds) | |
| 19:47 | Phantomas1 has joined IRC (Phantomas1!~Phantomas@ubuntu/member/phantomas) | |
| 19:48 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 250 seconds) | |
| 19:53 | staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu) | |
| 20:11 | vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving) | |
| 20:20 | Phantomas1 has left IRC (Phantomas1!~Phantomas@ubuntu/member/phantomas, Ping timeout: 264 seconds) | |
| 20:32 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection) | |
| 20:38 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 21:02 | freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun) | |
| 21:48 | brunolambert has left IRC (brunolambert!brunolambe@nat/revolutionlinux/x-klutklhhjxctmdjq, Quit: Leaving.) | |
| 21:53 | willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116) | |
| 23:12 | alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 245 seconds) | |
| 23:21 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Remote host closed the connection) | |
| 23:24 | telex has left IRC (telex!~telex@freeshell.de, Read error: Connection reset by peer) | |
| 23:28 | telex has joined IRC (telex!~telex@freeshell.de) | |