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


Channel log from 1 February 2015   (all times are UTC)

00:03syrius has joined IRC (syrius!~syrius@thunder.stormtek.net)
00:20doctari has joined IRC (doctari!~doctari@2602:30a:2ccf:9f00:753d:150f:d6ec:f416)
00:20
<doctari>
can anyone help me with menueditor?
00:27
<Hyperbyte>
!ask
00:27
<ltsp`>
ask: Don't ask to ask a question, simply ask it, and if someone knows the answer, they'll respond. Please hang around for at least a full hour after asking a question, as not everybody constantly monitors the channel.
01:01
<doctari>
sorry
01:02
how do I setup custom application menus for a group of students?
01:02
the menueditor app under edubuntu just comes up blank
01:08
<Hyperbyte>
I've never used the menu editor
01:08
I always just edit the .desktop files in /usr/share/applications/
01:09
This question isn't really about LTSP either, by the way. You'd better seek out resources from your specific Linux distribution.
01:11vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
01:13
<doctari>
well ltsp is used for class room setups so I was hoping that someone might have some experience
01:13
besides no one is talking at #edubuntu
01:18F-GTSC has joined IRC (F-GTSC!~phantom@ppp121-44-150-162.lns20.syd7.internode.on.net)
01:20FGXR6 has left IRC (FGXR6!~phantom@ppp121-44-153-157.lns20.syd7.internode.on.net, Ping timeout: 244 seconds)
01:21
<doctari>
well Hyperbyte maybe you can answer. How can I assigned a specific .desktop to certain users?
01:21
and which file do I need to edit?
01:43roue has left IRC (roue!~roue@66-188-172-213.dhcp.stcd.mn.charter.com, Ping timeout: 256 seconds)
01:43yanu has left IRC (yanu!~yanu@178-117-230-250.access.telenet.be, Ping timeout: 256 seconds)
01:43roue_ has joined IRC (roue_!~roue@66-188-172-213.dhcp.stcd.mn.charter.com)
01:43yanu_ has joined IRC (yanu_!~yanu@178-117-230-250.access.telenet.be)
02:23vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
03:04andygraybeal has joined IRC (andygraybeal!~andy@h127.209.22.98.dynamic.ip.windstream.net)
03:31cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 272 seconds)
03:33cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
03:38doctari has left IRC (doctari!~doctari@2602:30a:2ccf:9f00:753d:150f:d6ec:f416, Quit: Leaving)
04:03telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
04:04telex has joined IRC (telex!teletype@freeshell.de)
04:41
<austrian_>
doctari: We edited the /usr/share/glib-2.0/schemas files so that new users would have our default desktop.
05:02andygraybeal has left IRC (andygraybeal!~andy@h127.209.22.98.dynamic.ip.windstream.net, Quit: Ex-Chat)
05:40gdi2k_ has left IRC (gdi2k_!~gdi2k@49.151.85.123, Ping timeout: 245 seconds)
05:53gdi2k_ has joined IRC (gdi2k_!~gdi2k@180.191.104.8)
06:36alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
07:08alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection)
07:54F-GTSC has left IRC (F-GTSC!~phantom@ppp121-44-150-162.lns20.syd7.internode.on.net, Ping timeout: 272 seconds)
08:01doctari has joined IRC (doctari!~doctari@2602:30a:2ccf:9f00:a448:44c5:53a8:e0c2)
08:05doctari has left IRC (doctari!~doctari@2602:30a:2ccf:9f00:a448:44c5:53a8:e0c2, Client Quit)
08:07doctari has joined IRC (doctari!~doctari@2602:30a:2ccf:9f00:a448:44c5:53a8:e0c2)
08:07F-GTSC has joined IRC (F-GTSC!~phantom@ppp121-44-39-208.lns20.syd4.internode.on.net)
08:38vmlintu_ has joined IRC (vmlintu_!~vmlintu@a91-152-200-70.elisa-laajakaista.fi)
08:45vmlintu has left IRC (vmlintu!~vmlintu@a91-152-200-70.elisa-laajakaista.fi, *.net *.split)
08:58ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 246 seconds)
08:58ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
09:04staffencasa_ has joined IRC (staffencasa_!~staffenca@8-220.ptpg.oregonstate.edu)
09:04staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 276 seconds)
09:05stgraber has left IRC (stgraber!~stgraber@ubuntu/member/stgraber, Ping timeout: 276 seconds)
09:06stgraber has joined IRC (stgraber!~stgraber@shell.stgraber.org)
09:59stgraber has left IRC (stgraber!~stgraber@shell.stgraber.org, Changing host)
09:59stgraber has joined IRC (stgraber!~stgraber@ubuntu/member/stgraber)
10:05
<highvoltage>
doctari: been weekending hard :)
10:48khildin has joined IRC (khildin!~khildin@ip-80-236-242-109.dsl.scarlet.be)
11:07vmlintu_ is now known as vmlintu
11:10AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-uzvsqilnpwqhzedf)
11:11
<vmlintu>
highvoltage: what are you up-to these days?
11:27adrianorg has left IRC (adrianorg!~adrianorg@177.156.59.219, Ping timeout: 264 seconds)
11:28adrianorg has joined IRC (adrianorg!~adrianorg@177.156.59.219)
12:07
<highvoltage>
vmlintu: still doing a variety of linux/opensourcy stuff. started my own company again recently (it's so new it doesn't even have a website yet). it's still early days :)
12:07
vmlintu: and you?
12:43
<vmlintu>
highvoltage: still working with schools or something else?
12:46
highvoltage: i'm doing mostly the same as before.. just more schools and more of everything
13:06
<highvoltage>
vmlintu: working with some small universities that specialises in math and science and also companies that provide linux support to other companies
13:06
but not so much schools.
13:21klausade has joined IRC (klausade!~klaus@cm-84.215.153.179.getinternet.no)
13:38hugo has joined IRC (hugo!~hugo@gateway/tor-sasl/hugo)
13:53
<vmlintu>
are you doing any development or is it more consulting/admin?
14:23hugo has left IRC (hugo!~hugo@gateway/tor-sasl/hugo, Quit: Leaving)
14:24
<highvoltage>
vmlintu: development in-house, consulting externally
14:25
vmlintu: I'll hopefully have some on-line products that are in a working state in a few months, it's a lot of work to get something off the ground :)
14:26
<vmlintu>
highvoltage: cloud / saas products? Sounds interesting
14:46telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
14:48telex has joined IRC (telex!teletype@freeshell.de)
15:12
<doctari>
can anyone help with a menu question?
15:29khildin has left IRC (khildin!~khildin@ip-80-236-242-109.dsl.scarlet.be, Ping timeout: 245 seconds)
15:50vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
15:53elptuxman has joined IRC (elptuxman!46c448e4@gateway/web/freenode/ip.70.196.72.228)
15:56elptuxman has left IRC (elptuxman!46c448e4@gateway/web/freenode/ip.70.196.72.228)
16:17adrianorg has left IRC (adrianorg!~adrianorg@177.156.59.219, Ping timeout: 245 seconds)
16:19adrianorg has joined IRC (adrianorg!~adrianorg@179.179.75.82)
16:31vmlintu has left IRC (vmlintu!~vmlintu@a91-152-200-70.elisa-laajakaista.fi, Ping timeout: 265 seconds)
16:37vmlintu has joined IRC (vmlintu!~vmlintu@a91-152-200-70.elisa-laajakaista.fi)
16:56map7 has left IRC (map7!~map7@teksup41.lnk.telstra.net, Remote host closed the connection)
17:05freedomrun has left IRC (freedomrun!~quassel@unaffiliated/freedomrun, Read error: Connection reset by peer)
17:16ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz)
17:29ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat)
17:34AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-uzvsqilnpwqhzedf, Quit: Connection closed for inactivity)
17:35ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz)
17:48doctari_ has joined IRC (doctari_!~doctari@2602:30a:2ccf:9f00:8cf0:da81:43eb:81e2)
17:51doctari has left IRC (doctari!~doctari@2602:30a:2ccf:9f00:a448:44c5:53a8:e0c2, Ping timeout: 265 seconds)
18:05alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
18:11andygraybeal has joined IRC (andygraybeal!~andy@h143.193.213.151.dynamic.ip.windstream.net)
18:13
<alkisg>
doctari_: apt-get install edubuntu-menueditor python-gmenu; menueditor
18:13
And file a bug for menueditor to put python-gmenu in its dependencies (or ping mgariepy, I think he's maintaining it...)
18:18
My turn to ask something unrelated... is it possible to use kvm (virt-manager, whatever) and have a virtual machine in bridged mode *and* keep using network manager, so that one can see the network speed, IP etc in the nm settings?
18:20
<doctari_>
we found a workaround for that part alkisg but the problem is that the archive that men-editor create has no conf files in it just a directory structure
18:20
<vmlintu>
alkisg: what network speed you'd want to see?
18:31
<alkisg>
doctari_: people worked with that previously, e.g. in 10.04, I have never used it myself, but do you mean that you haven't found a good tutorial, or that it is now broken?
18:32
vmlintu: in the network-manager applet, for the connection to show its status, for the user to be able to go to its properties and see 100mbps or ip, mask...
18:32
I.e. I don't want to use /etc/network/interfaces....
18:36
<vmlintu>
alkisg: ah, I first understood that you want to use network-manager on the kvm guest and see the network status from there
18:37
<alkisg>
No no I just think that all that bridging doesn't allow network-manager to manage the connection, and it's not able to show its status...
18:38
while e.g. vbox uses injection instead of bridging or something like that, and it's completely transparent for the user, no host network setup necessary...
18:39
<vmlintu>
I've seen people writing that network-manager is quite buggy when used with libvirt and bridging, but it's possible to get it working..
18:40
<alkisg>
Hrm... virt-manager also managed to break dnsmasq, it put a "bind-interfaces" directive which doesn't allow dnsmasq to function properly with its default "enable dns server" setting...
18:40
I had to edit that virt-manager file and change it to bind-dynamic
18:42* vagrantc waves to alkisg
18:42
<alkisg>
Hi Vagrant!
18:43
<vagrantc>
alkisg: i use network manager and have virtual machines in bridged mode ... but i usually use the bridges configured by libvirt
18:43
alkisg: it should be able to attach to any existing bridge though
18:43
i've done that before too
18:44
<alkisg>
vagrantc: so libvirt sets up bridges that you can use along with network-manager?
18:44
E.g. have a normal dynamic ip with network-manager, and have the VM in bridged mode there?
18:46
In `ip a`, I have: virbr0 192.168.122.1/24
18:46
In virt-manager, "bridged mode" is not enabled, it's gray...
18:48doctari_ has left IRC (doctari_!~doctari@2602:30a:2ccf:9f00:8cf0:da81:43eb:81e2, Quit: Leaving)
18:48doctari has joined IRC (doctari!~doctari@2602:30a:2ccf:9f00:8cf0:da81:43eb:81e2)
18:49* alkisg tells himself to RTFM...
18:53andygraybeal has left IRC (andygraybeal!~andy@h143.193.213.151.dynamic.ip.windstream.net, Ping timeout: 245 seconds)
18:59
<vagrantc>
alkisg: i simply use a bridge, not sure what bridged mode is :)
19:00
<alkisg>
I can't find what to do in the gui in order to use bridged mode
19:00
<vagrantc>
alkisg: you can use macvtap interfaces which i think is similar to what you're talking about virtualbox using
19:00
<alkisg>
But without using command line or configuration files, just GUIs
19:00
<vagrantc>
yes
19:02
alkisg: at least with virt-manager ... when viewing the virtual machine hardware, you can select the NIC, and select macvtap interface from the drop-down...
19:03
alkisg: view -> details, select NIC, network source drop-down
19:03
<alkisg>
Yup thanks I see it now, it wasn't there in the create vm wizard
19:03
<vagrantc>
alkisg: might not be
19:04
alkisg: i don't tend to use macvtap because the host network becomes inaccessible, and i frequently have squid-deb-proxy or some other caching proxy running on the host
19:04
<alkisg>
Ouch, the host net become inaccessible?!
19:05
<vagrantc>
the host networking continues to function, but the client can't reach the host
19:05
that isn't the case with virtualbox?
19:05
<alkisg>
In vbox, the host is e.g. 192.168.1.10 and the vm at 192.168.1.11 and they communicate like normal machines
19:06
with ethernet packets, ip packets, whatever
19:06andygraybeal has joined IRC (andygraybeal!~andy@h124.212.22.98.dynamic.ip.windstream.net)
19:06* vagrantc has been struggling with resolving https://bugs.debian.org/767764 and https://bugs.launchpad.net/ltsp/+bug/1072711 in a cleaner way
19:06
<alkisg>
And the user doesn't need to specify the IP anywhere, so it'll work in whatever host subnet...
19:07* vagrantc wonders if network-manager can configure a bridge that libvirt could then hook into
19:08
<vagrantc>
the default in libvirt has a NATted bridge
19:08
<alkisg>
vagrantc: so LIBGL_ALWAYS_INDIRECT is causing more issues?
19:08
<vagrantc>
macvtap also doesn't tend to work on wireless
19:08
alkisg: seems to be
19:09
<alkisg>
I don't know why we put that there... I think stgraber put it to enable some software gl, but why would we need to specify it, why isn't it autodetected?
19:09
<vagrantc>
alkisg: and the init-ltsp.d hook should've gone in LDM ... :(
19:09
alkisg: dunno. i'm tempted to disable all the LIBGL_ALWAYS_INDIRECT code
19:10
alkisg: and make a flag to enable it or something
19:10
<alkisg>
I never got it to do anything useful, I only had to disable it in a few cases myself too
19:10
Should we drop it until we find a use case where it actually helps?
19:11
I think there's a bug report in launchpad where stgraber says he managed to get unity working slowly with that, but I never did get unity working (not that I tried much...)
19:13
<vagrantc>
i'm inclined to drop it entirely, or make it an explicitly enabled feature
19:15
automake is a nightmare
19:15
to add one file you have to touch 4 different files or something
19:16
or i'm not grasping ldm's autofoo correctly.
19:16
<alkisg>
If you let me reimplement ldm in shell, we wouldn't need automake :P
19:17
<vagrantc>
heh
19:19
ok, figured out the automake bits enough to install that awful "rm .../nouveau" hack
19:24
<alkisg>
vagrantc: doesn't init-ltsp.d/50-opengl remove nouveau already? http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/revision/2447
19:25
<vagrantc>
alkisg: yes, but it belongs in the ldm package.
19:25
alkisg: and i'm wondering if it shouldn't just go in the screen script instead.
19:26
would be more self-contained, only applies when LDM_DIRECTX is there
19:27
alkisg: the launchpad bug with the noveau hack ... does that happen regardless of LIBGL_ALWAYS_INDIRECT=true/false ?
19:27
seems like rather than removing the driver, not setting LDM_DIRECTX would be cleaner
19:28
er, not setting LIBGL_ALWAYS_INDIRECT
19:28
<alkisg>
vagrantc: if we remove LIBGL_ALWAYS_INDIRECT, we have no issues
19:29
I don't understand what's the issue in the debian bug tracker though (haven't read all of it)
19:29
If nouveau is rm'ed, why do they experience the bug?
19:30
But I do vote for dropping the whole LIBGL_ALWAYS_INDIRECT code until we have an actual, recent use case where it helps
19:30
<vagrantc>
alkisg: basically, the idea of removing a driver from the filesystem seems like a very ugly hack ... so i'm wondering if we can get rid of both problems by addressing the LIBGL_ALWAYS_INDIRECT issue?
19:31
<alkisg>
Please do, remove both of those hacks
19:31
<vagrantc>
the less agressive option is to make them conditional
19:31
and default to off
19:31
<alkisg>
We have CLIENT_ENV for that
19:31
How much more conditional?
19:32
<vagrantc>
if someone wants it, they can easily add it to CLIENT_ENV ?
19:32
sounds good to me.
19:32
<alkisg>
There's a lot of mesa options to put them all as conditionals... http://www.mesa3d.org/envvars.html
19:32
Yes CLIENT_ENV works fine
19:34* vagrantc wonders if this is too invasive for jessie
19:34
<vagrantc>
it's really ugly overall
19:34* alkisg pats vagrantc in the shoulder and says "go for it"
19:42* vagrantc is also tempted to drop the 16-bit color by default feature
19:43
<vagrantc>
due to https://bugs.debian.org/705143 and the likes
19:46
<alkisg>
vagrantc: that's a cinnamon bug, not a 16-color bug
19:46
I think workarounds are good when we actually work around bugs from other packages
19:46
16bit means 2 times faster graphics, it's too significant to drop it when it works...
19:47
<vagrantc>
alkisg: but requiring workarounds for several of the most common desktop environments seems like a loosing battle.
19:47
<alkisg>
What "several"?
19:47
It always works when there's no compositing, right?
19:47
And, compositing managers no longer care about remote x, right?
19:48
<vagrantc>
cinnamon, gnome3, gnome-flashback ... if i remember correctly
19:48
<alkisg>
gnome-flashback doesn't have problems with 16 bit
19:48* vagrantc will try again
19:48
<alkisg>
cinnammon and gnome3 don't work over the network
19:49
I've never seen cinnammon-2d, is it still being developed?
19:49
<vagrantc>
not sure
19:49
<alkisg>
I did hear about problems with compiz and some 16bit cards though
19:50
(gnome-flashback with compiz enabled)
19:55
<vagrantc>
alkisg: so, just to be clear, the noveau driver removal hack is really just a workaround for when LIBGL_ALWAYS_INDIRECT=true ?
19:55
<alkisg>
Yes, I didn't know how much stgraber wanted that, and instead of completely removing it I decided to only disable it in the case that I saw it was causing problems
19:56
err, instead of removing it, I removed nouveau*
19:56
following some advice from #nouveau or something...
19:57
So, apparently, cinnamon does have a 2d variant in jessie... https://packages.debian.org/jessie/all/cinnamon-common/filelist
19:58* alkisg needs to try that, if it works as advertised it might be a good alternative to gnome-flashback
20:01* alkisg adds the cinnamon ppa for 14.04...
20:03
<alkisg>
Having a normal gnome3 desktop stack with a 2d mint-like menu is all we need... hopefully cinnamon-2d is exactly that :)
20:07
bb in 2'..
20:08alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
20:09alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
20:11
<alkisg>
Errr cinnamon-2d says "software rendering", and it's very slow *and* has severe drawing issues locally on my dual core 2.2 ghz pc...
20:11
So nope it's not ltsp's fault :)
20:21alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
20:21alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
20:51
<vagrantc>
alkisg: i was also thinking more about how to configure ipxe with a bootscript earlier, and just using http (and ideally, https boot)
20:53
figuring out some way to store https certificate information on the boot media would allow for a secured network boot, only needing to update the local media on certificate change
20:53
and then you could actually verify the rootfs hash
20:54
by storing some verification data in the initramfs
20:56doctari has left IRC (doctari!~doctari@2602:30a:2ccf:9f00:8cf0:da81:43eb:81e2, Ping timeout: 245 seconds)
20:59
<alkisg>
vagrantc: we can skip pxelinux completely with undionly.kpxe
20:59
I tried it, it works fine, it even supports detection for pae, 64bit etc
20:59
So we won't be needing ifcpu64 either
20:59
And it supports uefi too, albeit with a few issues, but a lot better than syslinux
21:00
for uefi, grub is the only one that has good support
21:00
So if you agree too, we can work on replacing pxelinux with ipxe/undionly...
21:00
<vagrantc>
alkisg: it's sounding good!
21:00
<alkisg>
We won't be needing tftp at all then, just ltspd=http(s)
21:01
<vagrantc>
would be a big break from prior ltsp versions
21:01
<alkisg>
(and if we could implement just the proxydhcp part in ltspd, which should be really small, we could skip dnsmasq too...)
21:02
<vagrantc>
for some reason that seems riskier to me
21:02
<alkisg>
It's not very significant, I don't mind about that, it would just be more pnp :)
21:03
(proxydhcp is just 1 packet)
21:03
<vagrantc>
not the whole dhcp server?
21:03
<alkisg>
No, of course not
21:03
<vagrantc>
ah, ok.
21:04
<alkisg>
If someone wants a real dhcp he'd have to use dnsmasq/isc-dhcp
21:04
<vagrantc>
i know there are basically out-of-the-box python http server implementations, but rewriting a dhcp server would seem like too much :)
21:04
<alkisg>
I don't even want to implement a tftp server :D
21:04
I think someone implemented proxydhcp in java in 20 lines or so
21:05* vagrantc wonders how hard it would be to boot old chroots with the new stuff, too
21:05
<alkisg>
back before we asked dnsmasq to implement it...
21:06
I don't think python has a simpletftpserver
21:06
So we'd have to use dnsmasq/tftpd and ltsp-update-kernels etc there
21:07
<vmlintu>
Would tftpless booting happen through grub that loads something locally?
21:07
<alkisg>
Client loads either pxe + (tft/undionly.kpxe), or ipxe
21:07
at that point we have http(s) support
21:08
So sorry I forgot the pxe part, we'd still need tftpd there
21:08
<vagrantc>
ah, right.
21:08
<alkisg>
Just to get the undionly.kpxe
21:08
<vmlintu>
ok.. so it'd be same as pxe + lpxelinux.0 + http
21:09
<alkisg>
yes, ipxe instead of pxelinux
21:09
Gives more scripting support, and uefi support
21:09
And https, sanboot, etc
21:10
<vagrantc>
alkisg: i'm thinking we need a systematic way to log some of these new feature ideas... might make it easier to actually move forward than just chatting on irc when ideas come to us :)
21:11* alkisg never had problems with which of the ideas to work on, only with finding the time to do that... :)
21:11
<alkisg>
We do have some todo page in the wiki, don't we?
21:11
E.g.: http://wiki.ltsp.org/wiki/Dev:Ltspd
21:12
<vmlintu>
if you are planning big changes, laptop support is something that requires a big rewrite
21:12
<alkisg>
vmlintu: I think you should start upstreaming your code :)
21:13
<vmlintu>
alkisg: I've done a few excercises on that, but basically it rips out 98% of ltsp code and replaces it with something new
21:13
<alkisg>
vmlintu: I have no problem with that :D
21:13
I've been thinking of starting something from scratch so many times that I lost count
21:13
As long as it's well designed...
21:14
<vagrantc>
meh. i've lost my wiki.ltsp.org credentials again
21:14
vmlintu: what do you mean by laptop support?
21:15
<vmlintu>
vagrantc: most of our new client devices are now laptops. They boot locally using grub + squashfs image copied to a local partition.
21:15
It's the same image as thin/fat clients and ltsp servers use
21:16
<vagrantc>
ltsp with a local install?
21:16
<vmlintu>
The image is updated by downloading an rdiff and patching old image to create a new one
21:16
<vagrantc>
basically could boot to ltsp over the network and then install it to the local media?
21:16
<vmlintu>
vagrantc: yes, that's how it works
21:17
<vagrantc>
yeah, that sounds worth upstreaming
21:17
<vmlintu>
vagrantc: I've been using a system like that on my main laptop for the past 1,5 years now..
21:17
<alkisg>
vmlintu: rdiff with squashfs?
21:18
<vmlintu>
alkisg: yep
21:18
<alkisg>
Isn't that ...like downloading the whole file again?
21:18
I mean, squashfs == compression, and compression ==> no sensible rdiff..
21:18
<vmlintu>
no.. it's quite manageable actually
21:18
<vagrantc>
alkisg: compression doesn't always break binary diffs
21:18
<alkisg>
To get a small diff, you'd need an uncompressed file system like ext4, right?
21:19
<vagrantc>
take "gzip --rsyncable" for example
21:19
<vmlintu>
the compressed image is now 9.5gb and weekly diffs are often 300mb
21:19
<vagrantc>
although, depending on the image size, it might just be simpler to rewrite the image...
21:19
wow.
21:20
<vmlintu>
I think I've seen 1gb diffs too, but for us that's not a problem
21:20
<vagrantc>
vmlintu: so what parts of LTSP are you using?
21:20
<alkisg>
vmlintu: are you using the "add files to squashfs" capability of squashfs, or are you just using binary diff between the old and the new 9 gb images?
21:20
<vmlintu>
alkisg: they are all new images
21:21
<alkisg>
Nice
21:22
<vmlintu>
vagrantc: I think ltspfs is only part that we haven't modified. There's no ldm and we don't use lts.conf anymore as it's replaced by ldap based configuration.
21:23
vagrantc: thin/fat client concepts are still ltsp
21:23
vagrantc: ltsp servers are netboot devices themselves
21:24
<alkisg>
We do plan on ditching ldm so that's not a problem
21:24
Are you using ltsp-build-client?
21:25
<vagrantc>
heh. with LDM_DIRECTX=true, LTSP_FATCLIENT=false and LIBGL_ALWAYS_INDIRECT=true, cinnamon2d just hangs for me, but cinnamon issues an error and falls back to software rendering, but works.
21:25
<alkisg>
Are you using init-ltsp.d and other stuff?
21:25
<vagrantc>
vmlintu: i've long dreamed of network booted network booting servers :)
21:25
recursive network boot
21:25
<alkisg>
There are people that do that with plain ltsp...
21:26
<vmlintu>
vagrantc: we have now bootservers that have basically just tftpd+dhcpd+nfsd+something else
21:26
<vagrantc>
oh, i'm probably being hit by the 16-bit color depth issues...
21:27* vagrantc notes that the 16-bit color depth also makes all LDM themes look grainy
21:27
<alkisg>
That's a problem with ldm
21:28
<vmlintu>
kerberos is currently the only supported authentication method
21:32austrian_ has left IRC (austrian_!~austrian@174.32.163.60, Ping timeout: 246 seconds)
21:34
<alkisg>
vmlintu: are you using some gui for user management?
21:36
<vmlintu>
alkisg: puavo
21:37
alkisg: if you want to see how it works, I can setup a demo puavo organisation for you.. maybe it'd explain it better..
21:38
<alkisg>
It feels silly that we both develop such tools...
21:38
vmlintu: sounds good, thanks, but not yet, I'm not yet in the phase of implementing new features in ltsp
21:39
<vmlintu>
alkisg: I mean the gui part, if you want to see it
21:39
<alkisg>
Yes, I understood, but I'll forget what I saw, when after a few months I'll want to work on these things
21:40
vmlintu: which DE are you using?
21:40
Mate?
21:40
(so, about the puavo demo organization, I'll ask you in a few months when I'll want to start working on such things, thank you...)
21:40
<vmlintu>
alkisg: gnome3 flashback
21:41austrian_ has joined IRC (austrian_!~austrian@174.32.160.95)
21:42
<alkisg>
We agree there! :)
21:42
I think stabilizing gnome-flashback is very significant... more so than ltsp advancements
21:44
<vmlintu>
alkisg: what ltsp means is the next big question, I think
21:45
when running an image locally on a laptop there's no terminal server anywhere anymore..
21:46
<alkisg>
I would go for "liveboot" but debian already had that :)
21:46
And, liveboot has more code that I'd like to reuse than ltsp...
21:53* alkisg ==> pumpkin
21:53alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection)
21:54
<vagrantc>
vmlintu: essentially just remote homedirs and authentication at that point?
22:00
<vmlintu>
vagrantc: for laptops we are mostly using local homedirs as they are true laptops that can be anywhere
22:00
vagrantc: homedir access to server is done separately
22:01
After we switched laptops from local installations managed by puppet to using the same image as thin/fat clients, reliability went through the roof
22:03
e.g. we updated laptops from quantal -> trusty just by updating the image on the laptops' harddrives. No need to run apt-get or anything
22:03
<vagrantc>
so there really isn't much of anything ltsp on it
22:04
<vmlintu>
and the biggest benefit for laptops and ltsp servers is that we can rollback the whole system to old version if some update fails because of a broken ubuntu update or something similar
22:05
vagrantc: if you think ltsp as a terminal server project, then no. If you think ltsp as a way to create running desktop images, then laptops are all about that
22:07
But when taking ldm and ltspfs out of the picture, ltsp really isn't much of code, but more of a concept and a mindset, I think
22:07
<vagrantc>
i've mostly thought of LTSP as a network booting infrastructure
22:08
but i've definitely thought about using LTSP codebase to do the sorts of things you've apparently implemented :)
22:08
<vmlintu>
but it has tons of code to configure X and audio
22:09
And the laptops do need that code as much as fatclients do
22:09* vagrantc thought we gutted most of the X configuration code
22:09
<vagrantc>
X mostly configures itself these days.
22:09
<vmlintu>
maybe tons was a bit too much ;)
22:10
there's xrandr code etc
22:10
<vagrantc>
ah, sure.
22:10
so you're using a screen script to start the display manager?
22:10
<vmlintu>
no
22:11
lightdm is started by upstart
22:11
<vagrantc>
then it doesn't use the LTSP Xrandr code
22:12
vmlintu: you've really piqued my curiosity! :)
22:12
<vmlintu>
vagrantc: it's easy to configure lightdm to run scripts to call xrandr when it starts
22:13
vagrantc: here's the lightdm.conf we are using: https://github.com/opinsys/puavo-ltsp/blob/master/client/templates/etc/lightdm/lightdm.conf
22:15
<vagrantc>
vmlintu: you hard-code 16-bit color for a local system?
22:15
oh, i see, you have a conditional in there
22:15
<vmlintu>
for thinclients
22:16* vagrantc didn't know lightdm supported conditionals
22:16
<vagrantc>
that bodes well for lightdm+libpam-sshauth
22:16
<vmlintu>
the xrandr code is now actually changed to support gnome's screen setting tool
22:16
that's a ruby template, not real lightdm.conf
22:16
<vagrantc>
ah!
22:17
it looks like you've got all the features in there we need, though
22:17
the display-setup-script is what runs xrandr and such?
22:18
<vmlintu>
yes
22:19
<vagrantc>
tweaking the sessions-directory would also be useful
22:22
<vmlintu>
but I need to get some sleep.. I can go over the features in more detail if you want
22:23
later I mean
22:25* vagrantc eyes up https://tracker.debian.org/pkg/fts and https://github.com/gonicus/fts
22:27
<vagrantc>
vmlintu: night! thanks for all the ideas!
22:36telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection)
22:38telex has joined IRC (telex!teletype@freeshell.de)
23:12khildin has joined IRC (khildin!~khildin@ip-213-49-116-92.dsl.scarlet.be)
23:13khildin has left IRC (khildin!~khildin@ip-213-49-116-92.dsl.scarlet.be, Read error: Connection reset by peer)
23:19oh has joined IRC (oh!bc78c335@gateway/web/freenode/ip.188.120.195.53)
23:20oh is now known as Guest49254
23:21
<Guest49254>
hello, can someone point me somewhere on how to use nodm on ltsp thin client?
23:21
<vagrantc>
why not just use LDM's autologin features?
23:21
Guest49254: what's your goal? what kind of setup?
23:23
<Guest49254>
I am trying to make a kiosk with persistant home directory, but currently I am far from it..
23:25
<vagrantc>
simplest thing would be to use LDM fatclient with autologin
23:26
unless you want the persistent homedir somewhere other than the server...
23:28
<Guest49254>
no, on server would be just fine. Alright, my first problem would be with autologin then, when I chroot into the environment on server and make a new user with password there, it's not recognized on client
23:28
i am always getting errors in auth.log that it's unknown user
23:57
<vagrantc>
you don't typically add users in the chroot
23:58
normally, you just add users on the server and they authenticate on the server.
23:59ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat)