IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 10 September 2017 (all times are UTC)
| 00:00 | GodFather has left IRC (GodFather!~rcc@47.33.250.142, Ping timeout: 248 seconds) | |
| 00:01 | ben-nabiy has left IRC (ben-nabiy!~bennabiy@unaffiliated/bennabiy, Remote host closed the connection) | |
| 00:59 | GodFather has joined IRC (GodFather!~rcc@47.33.250.142) | |
| 01:23 | GodFather has left IRC (GodFather!~rcc@47.33.250.142, Ping timeout: 248 seconds) | |
| 03:38 | fnurl_c has left IRC (fnurl_c!~fnurl@111-241-57-174.dynamic-ip.hinet.net, Read error: Connection reset by peer) | |
| 04:18 | <sutula> Apologize for using the channel as a man page...somewhere in the past three weeks I ran across a file or documentation stating how to avoid running specific daemons on a fat client, while using manager and current tools. Can anyone point me?
| |
| 04:25 | I think I found it: lts.conf, RM_SYSTEM_SERVICES
| |
| 04:26 | * sutula hopes that's correct, and welcomes any guidance | |
| 05:04 | ben_nabiy has joined IRC (ben_nabiy!~bennabiy@unaffiliated/bennabiy) | |
| 05:27 | ben_nabiy has left IRC (ben_nabiy!~bennabiy@unaffiliated/bennabiy, Quit: http://www.yellowdeli.com) | |
| 05:53 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 06:24 | <alkisg> sutula: yup, that's correct
| |
| 07:48 | markit has joined IRC (markit!~marco@88-149-177-66.v4.ngi.it) | |
| 08:40 | Statler has joined IRC (Statler!~Georg@p579FEA0E.dip0.t-ipconnect.de) | |
| 11:54 | Statler has left IRC (Statler!~Georg@p579FEA0E.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 15:17 | markit has left IRC (markit!~marco@88-149-177-66.v4.ngi.it, ) | |
| 16:36 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 17:28 | lucascastro has joined IRC (lucascastro!~lucas@177.14.240.143) | |
| 17:28 | muvlon has joined IRC (muvlon!~muvlon@2001-4dd7-3c1-0-4685-ff-fe12-32e8.ipv6dyn.netcologne.de) | |
| 17:29 | <muvlon> hi, everyone! \o/
| |
| 17:31 | I'm planning a medium-size (~50 clients) ltsp setup and could use some suggestions
| |
| 17:31 | first of all: I read about thin vs. fat clients in the docs
| |
| 17:31 | fat clients apparently cause a lot less load on the server
| |
| 17:31 | so is there any benefit to using thin clients?
| |
| 17:32 | I suppose thin clients can be made out of less powerful hardware
| |
| 17:33 | but the cheapest "dedicated" thin client hardware I could find on the web still costs in excess of 100$
| |
| 17:33 | <alkisg> muvlon: for any new installations that don't have really weird needs, go with fat clients
| |
| 17:33 | !cheap-client
| |
| 17:33 | <ltsp> cheap-client: (#1) http://www.gearbest.com/tv-box-mini-pc/pp_343636.html, or (#2) https://www.aliexpress.com/store/product/New-arrival-Beelink-Pocket-Z83-Windows-10-Mini-PC-Z8300-64bit-1-84GHz-2GB-RAM-32GB/1871240_32640039781.html
| |
| 17:34 | <alkisg> Even cheap ones like these ^ are better off working as fat clients
| |
| 17:34 | Then, use either one of these methods:
| |
| 17:34 | !ltsp-manager
| |
| 17:34 | <ltsp> ltsp-manager: LTSP Manager is a GUI tool that makes LTSP maintenance easy. It's the recommended way to install LTSP in common setups. More info: http://wiki.ltsp.org/wiki/Ltsp-manager
| |
| 17:34 | <alkisg> !ltsp-pnp
| |
| 17:34 | <ltsp> ltsp-pnp: ltsp-pnp is the recommented method to install and maintain LTSP for "usual" setups. Since it doesn't involve chroots, it requires little to no command line to maintain it. It automatically supports both thin and fat ltsp clients. https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp
| |
| 17:34 | <muvlon> right, a "fat" client with 2GB ram is really cheap today
| |
| 17:34 | <alkisg> Even with 1 GB RAM it's better as fat
| |
| 17:34 | <muvlon> that's what I thought too, just wanted to confirm
| |
| 17:34 | <alkisg> And with 50 clients, thins will have bandwidth issues
| |
| 17:34 | !thin-clients-bandwidth
| |
| 17:34 | <ltsp> thin-clients-bandwidth: A small explanation why thin clients can't perform well with video, lots of screen updates etc: https://sourceforge.net/p/ltsp/mailman/message/35694699/
| |
| 17:35 | <alkisg> While with fat clients, you can support all of them with a single server, without load balancing etc
| |
| 17:35 | <muvlon> the first aliexpress link looks good, but the second is a 404 :/
| |
| 17:36 | <alkisg> Google the name, beelink z83 etc
| |
| 17:36 | They probably updated it with something newer
| |
| 17:36 | <muvlon> I had one of those TV boxes at one time
| |
| 17:36 | it ran a crappy vendor android and basically nothing else
| |
| 17:37 | <alkisg> https://www.amazon.com/DIAOTEC-Z83-Mini-Windows-Box/dp/B01DK2DSQC
| |
| 17:37 | <muvlon> how can I turn it into an ltsp client?
| |
| 17:37 | <alkisg> Check that they're intel based
| |
| 17:37 | <muvlon> oh, that one is x86
| |
| 17:37 | <alkisg> Not armhf
| |
| 17:37 | Both of them are x86
| |
| 17:37 | <muvlon> I've seen that raspis work too, but that's probably because somebody made a dedicated firmware image, right?
| |
| 17:39 | * vagrantc worked a bit on raspberry pi support in ltsp, but largely gave up as the hardware wasn't very capable | |
| 17:39 | <vagrantc> maybe with the rpi2 or rpi3, it might be better, but i wouldn't hold my breath
| |
| 17:41 | <muvlon> what about other arm dev boards?
| |
| 17:42 | <vagrantc> at best, i'd say it's a hobby project at the moment
| |
| 17:43 | * vagrantc has something like 30 arm boards running, and has mostly given up on reasonable video suppor | |
| 17:43 | <muvlon> the server will be x86 anyway
| |
| 17:43 | <vagrantc> i originally got interested in arm years ago as potential thin clients, and look what happened :)
| |
| 17:43 | <muvlon> so it'd have to serve non-native binaries to the clients, right?
| |
| 17:44 | <vagrantc> yes, that part isn't hard, though
| |
| 17:44 | or, well, non-native to the server, native to the clients
| |
| 17:44 | <muvlon> true, distros handle that pretty well
| |
| 17:44 | hmm, video support is an issue, yes
| |
| 17:46 | vivante GPUs have mainline drivers, and some adrenos
| |
| 17:46 | but those are rare, most boards use mali or powervr
| |
| 17:46 | <vagrantc> and the mainline support is generally just framebuffer ... or very limited acceleration
| |
| 17:46 | <muvlon> ah right, fat clients need to render everything themselves...
| |
| 17:47 | <vagrantc> thin clients too
| |
| 17:47 | <muvlon> oh
| |
| 17:48 | <vagrantc> the video hardware is on the client, so it needs to render something client-side
| |
| 17:48 | in theory, the server could preprocess some of it, but in practice that's just not really a thing
| |
| 17:49 | <muvlon> so what does the server send?
| |
| 17:49 | <vagrantc> if you want an interesting project to work on, you can try arm, but if you want something that just works, you'd go with x86
| |
| 17:49 | <muvlon> compressed video? or something like GL instructions?
| |
| 17:49 | <vagrantc> just X11
| |
| 17:50 | <muvlon> ah right, X11 has networking support and such
| |
| 17:50 | <vagrantc> a lot of applications don't really support the network transparency of X11 well anymore, which leads to annoying bugs
| |
| 17:50 | which is why i'd strongly recommend fat clients
| |
| 17:51 | <muvlon> fat clients basically use the server as a network file system and that's it, right?
| |
| 17:51 | <vagrantc> basically
| |
| 17:51 | <alkisg> (08:37:56 PM) muvlon: I've seen that raspis work too, but that's probably because somebody made a dedicated firmware image, right? ==> they're 10+ times slower than the other links above, don't use raspberries for desktops, only for special uses like e.g. weather stations
| |
| 17:52 | <muvlon> do they need some sort of stub OS or can they boot directly over network?
| |
| 17:52 | <alkisg> !raspberrypi
| |
| 17:52 | <ltsp> raspberrypi: (#1) Ubuntu/LTSP on Pi 2: https://help.ubuntu.com/community/UbuntuLTSP/RaspberryPi, or (#2) Debian/LTSP (with raspbian chroot) on Pi: http://cascadia.debian.net/trenza/Documentation/raspberrypi-ltsp-howto/, or (#3) unofficial Ubuntu/LTSP (with raspbian chroot) on Pi: http://pinet.org.uk/
| |
| 17:52 | <alkisg> Read the first page there for instructions
| |
| 17:52 | After reading it, avoid them at all costs :)
| |
| 17:54 | <vagrantc> in theory, there's a way to configure rpi3 to do real network boot; haven't tried it
| |
| 17:54 | <muvlon> what about the x86 boxes, can they network boot?
| |
| 17:55 | having stateless clients would be a huge benefit to installation and maintenance
| |
| 17:55 | <alkisg> Sure
| |
| 17:55 | !local-boot
| |
| 17:55 | <ltsp> local-boot: If you want LTSP fat clients on a low-speed network, you can put i386.img on e.g. C:\Boot\LTSP\i386.img and use this command line in pxelinux.cfg: APPEND ro initrd=ltsp/i386/initrd.img init=/sbin/init-ltsp root=/dev/sda1 rootflags=ro loop=/Boot/LTSP/i386.img; IPAPPEND 3
| |
| 17:55 | <alkisg> !kernel
| |
| 17:55 | <ltsp> I do not know about 'kernel', but I do know about these similar topics: 'ltsp-update-kernels'
| |
| 17:55 | <alkisg> Hmm no factoid for that
| |
| 17:55 | <vagrantc> muvlon: most x86 systems can do PXE
| |
| 17:56 | <alkisg> Anyway, if for some reason some device doesn't netboot, (e.g. uefi only), then you can put the kernel/initrd locally in some sd card, and ltsp automatically updates them when needed
| |
| 17:56 | I implemented that for raspberry 2's, but it's valid for x86 as well
| |
| 17:56 | <muvlon> nice
| |
| 17:57 | <vagrantc> really would be good to figure out what we need to get UEFI network booting in working order
| |
| 17:57 | since those are getting more common
| |
| 18:00 | <muvlon> and for the server the primary thing to look out for would be Gb Ethernet and a fast disk?
| |
| 18:00 | <alkisg> Better support from upstream packages like dnsmasq proxydhcp mode in uefi
| |
| 18:01 | For 50 clients I would go for 2 gigabit ethernets, and an NFS /home for lower CPU usage on the server
| |
| 18:01 | Disk doesn't matter much, but you can put /home in an SSD if you want.
| |
| 18:01 | <muvlon> NFS as opposed to NBD?
| |
| 18:01 | <alkisg> As opposed to the default sshfs which needs a lot of cpu
| |
| 18:01 | <muvlon> ah
| |
| 18:01 | <alkisg> NBD serves /, and SSHFS serves /home
| |
| 18:02 | But NBD is read-only and cached a lot, so the disk speed isn't important for that one
| |
| 18:02 | (2 gigabit ethernets in bonded mode, with a single IP)
| |
| 18:02 | !bonding
| |
| 18:02 | <ltsp> bonding: https://help.ubuntu.com/community/UbuntuLTSP/Trunking
| |
| 18:03 | <muvlon> so I'll need a network card if I want to use the computer I was planning to use
| |
| 18:04 | since it has only 1 NIC
| |
| 18:04 | <alkisg> You can put it later, it's just for better net speed
| |
| 18:04 | You'll see e.g. a 20% better perfomance overall, but it's not critical
| |
| 18:05 | <muvlon> alright
| |
| 18:05 | <alkisg> A nic costs only 10€, certainly worth it for +20% performance
| |
| 18:06 | <muvlon> I have some fibre channel cards gathering dust, maybe I can find a cheap switch that supports it
| |
| 18:08 | anyway, thank you so much for your support so far :)
| |
| 18:10 | <alkisg> np
| |
| 18:17 | muvlon has left IRC (muvlon!~muvlon@2001-4dd7-3c1-0-4685-ff-fe12-32e8.ipv6dyn.netcologne.de, Quit: Leaving) | |
| 18:29 | lucascastro has left IRC (lucascastro!~lucas@177.14.240.143, Remote host closed the connection) | |
| 19:18 | gehidore has left IRC (gehidore!~username@unaffiliated/man, Quit: WeeChat 1.9) | |
| 19:19 | gehidore has joined IRC (gehidore!~username@unaffiliated/man) | |
| 19:40 | <bennabiy> alkisg: if one is using the ltsp-manager approach, and has two nics, will it be wise enough to detect that and appropriately use them?
| |
| 19:55 | <alkisg> bennabiy: yes, if you put internal nic ip = 192.168.67.1
| |
| 19:55 | Then it will set up dnsmasq appropriately, it will disable flow control, and it will enable NAT for fat clients
| |
| 20:03 | <bennabiy> ah
| |
| 20:38 | muvlon has joined IRC (muvlon!~muvlon@xdsl-87-78-108-204.netcologne.de) | |
| 21:04 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 21:59 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |