IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 1 February 2015 (all times are UTC)
| 00:03 | syrius has joined IRC (syrius!~syrius@thunder.stormtek.net) | |
| 00:20 | doctari 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:11 | vagrantc 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:18 | F-GTSC has joined IRC (F-GTSC!~phantom@ppp121-44-150-162.lns20.syd7.internode.on.net) | |
| 01:20 | FGXR6 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:43 | roue has left IRC (roue!~roue@66-188-172-213.dhcp.stcd.mn.charter.com, Ping timeout: 256 seconds) | |
| 01:43 | yanu has left IRC (yanu!~yanu@178-117-230-250.access.telenet.be, Ping timeout: 256 seconds) | |
| 01:43 | roue_ has joined IRC (roue_!~roue@66-188-172-213.dhcp.stcd.mn.charter.com) | |
| 01:43 | yanu_ has joined IRC (yanu_!~yanu@178-117-230-250.access.telenet.be) | |
| 02:23 | vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving) | |
| 03:04 | andygraybeal has joined IRC (andygraybeal!~andy@h127.209.22.98.dynamic.ip.windstream.net) | |
| 03:31 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 272 seconds) | |
| 03:33 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
| 03:38 | doctari has left IRC (doctari!~doctari@2602:30a:2ccf:9f00:753d:150f:d6ec:f416, Quit: Leaving) | |
| 04:03 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 04:04 | telex 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:02 | andygraybeal has left IRC (andygraybeal!~andy@h127.209.22.98.dynamic.ip.windstream.net, Quit: Ex-Chat) | |
| 05:40 | gdi2k_ has left IRC (gdi2k_!~gdi2k@49.151.85.123, Ping timeout: 245 seconds) | |
| 05:53 | gdi2k_ has joined IRC (gdi2k_!~gdi2k@180.191.104.8) | |
| 06:36 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 07:08 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection) | |
| 07:54 | F-GTSC has left IRC (F-GTSC!~phantom@ppp121-44-150-162.lns20.syd7.internode.on.net, Ping timeout: 272 seconds) | |
| 08:01 | doctari has joined IRC (doctari!~doctari@2602:30a:2ccf:9f00:a448:44c5:53a8:e0c2) | |
| 08:05 | doctari has left IRC (doctari!~doctari@2602:30a:2ccf:9f00:a448:44c5:53a8:e0c2, Client Quit) | |
| 08:07 | doctari has joined IRC (doctari!~doctari@2602:30a:2ccf:9f00:a448:44c5:53a8:e0c2) | |
| 08:07 | F-GTSC has joined IRC (F-GTSC!~phantom@ppp121-44-39-208.lns20.syd4.internode.on.net) | |
| 08:38 | vmlintu_ has joined IRC (vmlintu_!~vmlintu@a91-152-200-70.elisa-laajakaista.fi) | |
| 08:45 | vmlintu has left IRC (vmlintu!~vmlintu@a91-152-200-70.elisa-laajakaista.fi, *.net *.split) | |
| 08:58 | ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 246 seconds) | |
| 08:58 | ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de) | |
| 09:04 | staffencasa_ has joined IRC (staffencasa_!~staffenca@8-220.ptpg.oregonstate.edu) | |
| 09:04 | staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 276 seconds) | |
| 09:05 | stgraber has left IRC (stgraber!~stgraber@ubuntu/member/stgraber, Ping timeout: 276 seconds) | |
| 09:06 | stgraber has joined IRC (stgraber!~stgraber@shell.stgraber.org) | |
| 09:59 | stgraber has left IRC (stgraber!~stgraber@shell.stgraber.org, Changing host) | |
| 09:59 | stgraber has joined IRC (stgraber!~stgraber@ubuntu/member/stgraber) | |
| 10:05 | <highvoltage> doctari: been weekending hard :)
| |
| 10:48 | khildin has joined IRC (khildin!~khildin@ip-80-236-242-109.dsl.scarlet.be) | |
| 11:07 | vmlintu_ is now known as vmlintu | |
| 11:10 | AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-uzvsqilnpwqhzedf) | |
| 11:11 | <vmlintu> highvoltage: what are you up-to these days?
| |
| 11:27 | adrianorg has left IRC (adrianorg!~adrianorg@177.156.59.219, Ping timeout: 264 seconds) | |
| 11:28 | adrianorg 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:21 | klausade has joined IRC (klausade!~klaus@cm-84.215.153.179.getinternet.no) | |
| 13:38 | hugo has joined IRC (hugo!~hugo@gateway/tor-sasl/hugo) | |
| 13:53 | <vmlintu> are you doing any development or is it more consulting/admin?
| |
| 14:23 | hugo 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:46 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 14:48 | telex has joined IRC (telex!teletype@freeshell.de) | |
| 15:12 | <doctari> can anyone help with a menu question?
| |
| 15:29 | khildin has left IRC (khildin!~khildin@ip-80-236-242-109.dsl.scarlet.be, Ping timeout: 245 seconds) | |
| 15:50 | vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc) | |
| 15:53 | elptuxman has joined IRC (elptuxman!46c448e4@gateway/web/freenode/ip.70.196.72.228) | |
| 15:56 | elptuxman has left IRC (elptuxman!46c448e4@gateway/web/freenode/ip.70.196.72.228) | |
| 16:17 | adrianorg has left IRC (adrianorg!~adrianorg@177.156.59.219, Ping timeout: 245 seconds) | |
| 16:19 | adrianorg has joined IRC (adrianorg!~adrianorg@179.179.75.82) | |
| 16:31 | vmlintu has left IRC (vmlintu!~vmlintu@a91-152-200-70.elisa-laajakaista.fi, Ping timeout: 265 seconds) | |
| 16:37 | vmlintu has joined IRC (vmlintu!~vmlintu@a91-152-200-70.elisa-laajakaista.fi) | |
| 16:56 | map7 has left IRC (map7!~map7@teksup41.lnk.telstra.net, Remote host closed the connection) | |
| 17:05 | freedomrun has left IRC (freedomrun!~quassel@unaffiliated/freedomrun, Read error: Connection reset by peer) | |
| 17:16 | ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz) | |
| 17:29 | ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat) | |
| 17:34 | AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-uzvsqilnpwqhzedf, Quit: Connection closed for inactivity) | |
| 17:35 | ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz) | |
| 17:48 | doctari_ has joined IRC (doctari_!~doctari@2602:30a:2ccf:9f00:8cf0:da81:43eb:81e2) | |
| 17:51 | doctari has left IRC (doctari!~doctari@2602:30a:2ccf:9f00:a448:44c5:53a8:e0c2, Ping timeout: 265 seconds) | |
| 18:05 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 18:11 | andygraybeal 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:48 | doctari_ has left IRC (doctari_!~doctari@2602:30a:2ccf:9f00:8cf0:da81:43eb:81e2, Quit: Leaving) | |
| 18:48 | doctari has joined IRC (doctari!~doctari@2602:30a:2ccf:9f00:8cf0:da81:43eb:81e2) | |
| 18:49 | * alkisg tells himself to RTFM... | |
| 18:53 | andygraybeal 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:06 | andygraybeal 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:08 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 20:09 | alkisg 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:21 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 20:21 | alkisg 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:56 | doctari 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:32 | austrian_ 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:41 | austrian_ 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:53 | alkisg 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:36 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 22:38 | telex has joined IRC (telex!teletype@freeshell.de) | |
| 23:12 | khildin has joined IRC (khildin!~khildin@ip-213-49-116-92.dsl.scarlet.be) | |
| 23:13 | khildin has left IRC (khildin!~khildin@ip-213-49-116-92.dsl.scarlet.be, Read error: Connection reset by peer) | |
| 23:19 | oh has joined IRC (oh!bc78c335@gateway/web/freenode/ip.188.120.195.53) | |
| 23:20 | oh 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:59 | ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat) | |