IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 9 February 2018 (all times are UTC)
| 00:26 | ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection) | |
| 01:15 | lucascastro has left IRC (lucascastro!~lucas@201.182.221.14, Remote host closed the connection) | |
| 02:31 | nehemiah has left IRC (nehemiah!~nehemiah@saphar.net) | |
| 06:34 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 06:50 | Statler has joined IRC (Statler!~Georg@p5489711A.dip0.t-ipconnect.de) | |
| 08:06 | kjackal has joined IRC (kjackal!~quassel@ppp-2-84-213-175.home.otenet.gr) | |
| 08:07 | Natureshadow has left IRC (Natureshadow!~Naturesha@commu.teckids.org, Read error: Connection reset by peer) | |
| 08:16 | lotuspsychje has joined IRC (lotuspsychje!~lotuspsyc@ip-83-134-158-104.dsl.scarlet.be) | |
| 09:13 | Statler has left IRC (Statler!~Georg@p5489711A.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 09:27 | lotuspsychje has left IRC (lotuspsychje!~lotuspsyc@ip-83-134-158-104.dsl.scarlet.be, Quit: Leaving) | |
| 09:28 | Natureshadow has joined IRC (Natureshadow!~Naturesha@commu.teckids.org) | |
| 09:38 | ciro^desktop has joined IRC (ciro^desktop!5512dc24@gateway/web/freenode/ip.85.18.220.36) | |
| 09:38 | ciro^desktop has left IRC (ciro^desktop!5512dc24@gateway/web/freenode/ip.85.18.220.36, Client Quit) | |
| 09:49 | Statler has joined IRC (Statler!~Georg@gwrz3.lohn24.de) | |
| 10:23 | kjackal has left IRC (kjackal!~quassel@ppp-2-84-213-175.home.otenet.gr, Read error: No route to host) | |
| 10:24 | kjackal has joined IRC (kjackal!~quassel@ppp-2-84-213-175.home.otenet.gr) | |
| 10:47 | kjackal has left IRC (kjackal!~quassel@ppp-2-84-213-175.home.otenet.gr, Ping timeout: 248 seconds) | |
| 10:53 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
| 11:46 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3102:f800:2474:665f:df33:9b26) | |
| 13:02 | ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 256 seconds) | |
| 13:03 | ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de) | |
| 14:21 | nehemiah has joined IRC (nehemiah!~nehemiah@saphar.net) | |
| 16:02 | <nehemiah> We're trying to use LTSP within a Linux container. We got quite far but now, trying to create the client image, we get this error: 'No overlay or aufs support detected'. What am I missing?
| |
| 16:06 | nehemiah has left IRC (nehemiah!~nehemiah@saphar.net, Quit: Leaving.) | |
| 16:07 | nehemiah has joined IRC (nehemiah!~nehemiah@saphar.net) | |
| 16:25 | AndreaC has joined IRC (AndreaC!4f3ef031@gateway/web/freenode/ip.79.62.240.49) | |
| 16:31 | <nehemiah> Found out that I have to load the overlay module on the host.
| |
| 16:43 | <alkisg> LTSP needs a whole lot of bandwidth, why would you run it in a container?
| |
| 16:43 | You have a server that has e.g. 10 network cards and you want to host multiple ltsp servers there?!
| |
| 17:21 | <||cw> should be fine for fat clients on an otherwise underused server
| |
| 17:22 | boot storm would swamp the NICs, but that should last too long
| |
| 17:22 | <alkisg> Isn't the point of containers to host multiple servers?
| |
| 17:23 | LTSP needs a full server on its own... and you can run VMs inside LTSP if you have spare CPU/RAM...
| |
| 17:23 | So I wonder what's the actual use case there
| |
| 17:24 | <||cw> yes, but not all the containers have to be the same workload
| |
| 17:24 | you could run a ltsp container and a web server container
| |
| 17:25 | I have a remote office that I have 1 server, it runs a samba file server, firewall/router, windows TS, and ltsp is used only to run rdp to that windows TS server. it's several years old now and still heavily overspec'd for the task
| |
| 17:26 | <nehemiah> The idea is that the server does a whole lot more then just LTSP. We have a powerful server and like to use it for more then just LTSP. Besides that we are trying to make a solution that easily to replicate since we are an growing organization with about 75 locations all over the world. It's very easy to replicate an LX container.
| |
| 17:43 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 17:49 | lucascastro has joined IRC (lucascastro!~lucas@201.182.221.154) | |
| 17:59 | AndreaC has left IRC (AndreaC!4f3ef031@gateway/web/freenode/ip.79.62.240.49) | |
| 18:04 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 256 seconds) | |
| 18:04 | <alkisg> I believe it's a lot more easy to replicate an OS installation, than a container, because the container ALSO needs an installation
| |
| 18:04 | I can understand the need for containers when there's a lot of manual configuration needed, and a lot of containers exists on the same server etc...
| |
| 18:05 | But ltsp is so automated and it needs so many resources ... dunno I don't think I have a use case for ltsp in a container anywhere... ah maybe except inside windows installations
| |
| 18:06 | lucascastro has left IRC (lucascastro!~lucas@201.182.221.154, Ping timeout: 248 seconds) | |
| 18:18 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 18:26 | robot_ has joined IRC (robot_!891a8196@gateway/web/freenode/ip.137.26.129.150) | |
| 18:27 | robot_ is now known as Guest28387 | |
| 18:34 | forum has joined IRC (forum!~Thunderbi@212-197-179-250.adsl.highway.telekom.at) | |
| 18:40 | Guest28387 has left IRC (Guest28387!891a8196@gateway/web/freenode/ip.137.26.129.150, Ping timeout: 260 seconds) | |
| 18:44 | kjackal has left IRC (kjackal!~quassel@2a02:587:3102:f800:2474:665f:df33:9b26, Ping timeout: 256 seconds) | |
| 18:48 | lucascastro has joined IRC (lucascastro!~lucas@201.182.221.154) | |
| 19:10 | Statler has left IRC (Statler!~Georg@gwrz3.lohn24.de, Remote host closed the connection) | |
| 19:38 | <nehemiah> Where can I add a kernel parameter in a way that it would stick after I update my client image?
| |
| 19:38 | <vagrantc> update-kernels.conf
| |
| 19:39 | and then you have to regnerate all the files and so on
| |
| 19:39 | e.g. run update-kernels and ltsp-update-kernels and/or ltsp-update-image
| |
| 19:39 | forum has left IRC (forum!~Thunderbi@212-197-179-250.adsl.highway.telekom.at, Ping timeout: 240 seconds) | |
| 19:39 | forum has joined IRC (forum!~Thunderbi@212-197-179-250.adsl.highway.telekom.at) | |
| 19:40 | <vagrantc> it's kind of cumbersome
| |
| 19:40 | mostly for historical reasons
| |
| 19:40 | * vagrantc takes a bit of blame | |
| 19:47 | <nehemiah> Does that only work if you use ltsp-manager? I was trying now with just a custom chroot. But every time after rebuilding the image, the ipappend gets set back to 2 making the nbd boot fail on the clients. Setting that manually back to three fixes it but it would be nice if I got it to stick. The update-kernels command is not available, is that part of ltsp-manager?
| |
| 19:48 | Statler has joined IRC (Statler!~Georg@p5489711A.dip0.t-ipconnect.de) | |
| 19:51 | <vagrantc> you have to edit the update-kernels.conf in the chroot, and run update-kernels from within the chroot
| |
| 19:51 | why doing a chroot now, anyways?
| |
| 20:03 | <nehemiah> I'm open to all suggestions so I tell you what I'm facing and the decisions I have to make because I feel a little bit stuck between a rock and a hard place. We have a server that we'd like to use, we already have some containerized services and KVM's which are 64bit. We like to put all those thing on one server. The server will in a place specially prepared for it where a user usually doesn't have access to it. I thought that it would be
| |
| 20:03 | great to containerize LTSP too but there is a lot of opposition their. Based on what alksig suggested we could run a LTSP server and still have our containers and KVM running there. But we need to support 32bit clients. So, we tried to install Ubuntu 64bit and have a 32bit chroot. Hope that makes sense. If you have any suggestions, I'm more than happy to here them.
| |
| 20:03 | <vagrantc> sure, that makes sense
| |
| 20:05 | that pretty much sounds one of the main use-cases where LTSP chroots still make sense...
| |
| 20:11 | <nehemiah> Don't get me wrong. I like ltsp-manager and the seven steps that work great (if you follow that :p). But I'm just trying to figure out what's best in our situation.
| |
| 20:13 | <vagrantc> yeah, needing to use a 64-bit server and 32-bit clients pretty much defines the need
| |
| 20:14 | only other option would really be to run a 32-bit LTSP server in a virtual machine or something instead of on the server directly
| |
| 20:15 | forum has left IRC (forum!~Thunderbi@212-197-179-250.adsl.highway.telekom.at, Remote host closed the connection) | |
| 20:21 | nehemiah has left IRC (nehemiah!~nehemiah@saphar.net, Quit: Leaving.) | |
| 20:21 | nehemiah has joined IRC (nehemiah!~nehemiah@saphar.net) | |
| 20:37 | <alkisg> nehemiah: you can also do the opposite, have an 64bit "generic" server, with a 32 bit "ltsp-server" VM on it
| |
| 20:37 | That way you can manage the 32bit ltsp server VM with ltsp-manager, and boot all your clients from there
| |
| 20:37 | Usually 64bit clients don't need an 64bit OS, but the server does, because it may have more than e.g. 8 GB RAM.
| |
| 20:51 | <||cw> 32bit linux can still use 8GB ram, it's just a tiny bit slower on heavy ram usage
| |
| 20:51 | it just can't use more than 2GB per process
| |
| 20:53 | <vagrantc> well, there are bugs that make ram above 8GB exponentially problematic
| |
| 20:54 | <||cw> I think it'd still rather run ltsp in a VM than a container, especially if you're running VMs anyway
| |
| 20:55 | <vagrantc> containers typically block access to device nodes, which make some aspects of building an LTSP image difficult, so yeah, a full VM is generally better
| |
| 20:58 | <||cw> or tries to emulate the nodes, which is probably OK if you're offloading DHCP elsewhere entirely
| |
| 21:01 | adrianor1 has joined IRC (adrianor1!~adrianorg@186.213.159.33) | |
| 21:04 | <alkisg> ||cw: there's a bug that makes hard disks unusable with more than 8gb ram and 32bit. It emerged last year.
| |
| 21:05 | adrianorg has left IRC (adrianorg!~adrianorg@179.177.212.54.dynamic.adsl.gvt.net.br, Ping timeout: 256 seconds) | |
| 21:05 | <alkisg> I.e. disk access gets thousands of times slower
| |
| 21:06 | nehemiah has left IRC (nehemiah!~nehemiah@saphar.net, Remote host closed the connection) | |
| 21:34 | lucascastro has left IRC (lucascastro!~lucas@201.182.221.154, Remote host closed the connection) | |
| 21:39 | <||cw> interesting
| |
| 21:52 | Statler has left IRC (Statler!~Georg@p5489711A.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 22:04 | lucascastro has joined IRC (lucascastro!~lucas@201.182.221.14) | |
| 23:02 | dragon788 has left IRC (dragon788!sid158229@gateway/web/irccloud.com/x-lwbtvedaaphsfjrj, ) | |
| 23:02 | dragon788 has joined IRC (dragon788!sid158229@gateway/web/irccloud.com/x-rowydmluvjxwdtfh) | |
| 23:17 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |