IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 6 November 2019 (all times are UTC)
| 00:00 | <vagrantc> crossgrading is definitely possible with debian (and presumably debian derivatives), but it involves a lot of manual effort and is not likely a way to save time, certainly not with something as simple as an LTSP environment
| |
| 00:15 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 00:48 | <robert45> is there any way to clone a client image? Because Im getting different results when a new amd64 image. i386 image is working fine
| |
| 00:48 | Sorry, I meant to say: "when a new amd64 image is used"
| |
| 00:51 | nevermind, its good no!
| |
| 00:51 | now*
| |
| 02:00 | jgee has left IRC (jgee!~jgee@190.159.118.121, Quit: The Lounge - https://thelounge.chat) | |
| 02:10 | jgee has joined IRC (jgee!~jgee@190.159.118.121) | |
| 04:03 | robert45 has left IRC (robert45!~robert45@r167-57-51-13.dialup.adsl.anteldata.net.uy, ) | |
| 04:41 | Ark74 has left IRC (Ark74!~Luis@177.238.145.140, Quit: Leaving) | |
| 05:39 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3107:2e00:18f7:8bb3:207c:e001) | |
| 05:40 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 05:45 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3107:2e00:2889:a70e:6ea0:d288) | |
| 06:47 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 07:30 | <enoch85> good morning!
| |
| 07:32 | so I have two issues left: dual screens, and to be able to boot iPXE over NAT
| |
| 07:35 | <alkisg> enoch85: ipxe over nat requires local media, e.g. floppy, cd etc
| |
| 07:36 | dual screen should already be working out of the box, vnc to me to see why it's not
| |
| 07:36 | finally, there's lightdm-autologin-greeter if "2 seconds timeout for login" isn't good enough; I haven't tested it though
| |
| 07:37 | (09:35:56 AM) alkisg: enoch85: ipxe over nat requires local media, e.g. floppy, cd etc ==> or a local dhcp server
| |
| 07:48 | <enoch85> I just tested the dual screen thing and added 2 monitors in the VM by specifying 2 screens in the settings of the VM
| |
| 07:48 | it didn't help
| |
| 07:48 | also when booting a client with only DP connected, it boots up correctly then the screen dies after the kernels have been loaded
| |
| 07:49 | I'll send VNC soon
| |
| 07:49 | !vnc
| |
| 07:49 | <ltsp> I do not know about 'vnc', but I do know about these similar topics: 'x11vnc', 'kvm-vnc', 'vnc-plinet', 'vnc-dide', 'vnc-edide', 'vnc-alkisg', 'uvnc-dide'
| |
| 07:53 | <enoch85> alkisg could you please send me the terminal command for vnc?
| |
| 07:53 | forgot :/
| |
| 07:54 | <alkisg> enoch85: x11vnc -connect srv1-dide.ioa.sch.gr
| |
| 07:56 | <enoch85> it's booting now
| |
| 07:56 | <alkisg> enoch85: eh, vnc stopped; and boot the client too
| |
| 07:57 | Rerun the vnc command
| |
| 07:57 | x11vnc has a bug in 18.04; I solved it in the greek schools ppa, maybe I should upload it to the ltsp ppa too
| |
| 07:58 | <enoch85> this is on a single screen btw
| |
| 07:58 | <alkisg> enoch85: are both screens connected?
| |
| 07:59 | <enoch85> no, will boot a client with duial screens
| |
| 07:59 | sec
| |
| 07:59 | <alkisg> Right, we want to see the problem, not a working one :)
| |
| 08:00 | <enoch85> haha sure, sory
| |
| 08:00 | sorry*
| |
| 08:00 | booting one now
| |
| 08:00 | should come online soon
| |
| 08:01 | <alkisg> And which outputs are connected, vga and dp?
| |
| 08:02 | <enoch85> correct
| |
| 08:02 | <alkisg> Are you using an adaptor or something?
| |
| 08:02 | <enoch85> no
| |
| 08:02 | <alkisg> It doesn't detect it as connected
| |
| 08:03 | <enoch85> it first boot one the DP screen then "reverts" to the VGA screen
| |
| 08:03 | I can show you in a video
| |
| 08:03 | sec
| |
| 08:03 | <alkisg> No need
| |
| 08:03 | <enoch85> ok
| |
| 08:03 | <alkisg> It's a kernel/xorg issue, not an ltsp issue,
| |
| 08:03 | let's see...
| |
| 08:05 | kjackal has left IRC (kjackal!~quassel@2a02:587:3107:2e00:2889:a70e:6ea0:d288, Ping timeout: 246 seconds) | |
| 08:07 | <meo> same adapter or separate? you may want to force xrandr initialization
| |
| 08:09 | <enoch85> adapter? it's seperate adapters if you mean the connetion
| |
| 08:09 | sec
| |
| 08:10 | <meo> no I mean is this the same GPU or separate? i.e. 1 display connected to the motherboard another to a PCI card? xrandr does get confused on configurations like this with older chips, and you sometimes need to manually map the outputs
| |
| 08:10 | <enoch85> https://cloud.danielhansson.nu/s/tMnrgp5zAZbGSga
| |
| 08:10 | aah, it's on the same card
| |
| 08:11 | afaik
| |
| 08:11 | <meo> yeah looks that way
| |
| 08:11 | what does xrandr output show
| |
| 08:13 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 08:15 | <enoch85> I'll go and check sec
| |
| 08:17 | it's working!
| |
| 08:18 | <alkisg> Great
| |
| 08:18 | The kernel doesn't autodetect that the display is on
| |
| 08:18 | So it needs to be forced
| |
| 08:18 | <enoch85> I didn't follow quite, but is this a change in the OS itself, or is it fixable with an LTSP command?
| |
| 08:19 | <alkisg> This command in ltsp.conf fixes it: POST_INIT_ENABLE_DP1="echo on > /sys/class/drm/card0-DP-1/status"
| |
| 08:19 | <enoch85> so you didn't change anything in the "backend"?
| |
| 08:19 | <alkisg> MAYBE this would fix it too, but no need to test: KERNEL_PARAMETERS="video=DP1:e"
| |
| 08:20 | <enoch85> yeah OK, I will fiddle with it later
| |
| 08:20 | <alkisg> No; this isn't an ltsp issue, it's a kernel issue, and that command was the workaround
| |
| 08:20 | Maybe with a newer or older kernel it wouldn't even be needed
| |
| 08:21 | <enoch85> ok, so that LTSP command is the only thing required to fix it? no changes in the actual code itself?
| |
| 08:21 | command/parameter
| |
| 08:22 | just so that I get it, sorry for my ignorance here :)
| |
| 08:23 | <alkisg> Exactly
| |
| 08:23 | <enoch85> ok perfect!
| |
| 08:24 | thanks again for your awesome help!
| |
| 08:24 | <alkisg> np
| |
| 08:25 | <enoch85> and with IPXE over NAT I would need to boot from USB containing the iPXE boot files?
| |
| 08:26 | I wouldn't work with firewall rules? e.g. allow all traffic to the iPXE server?
| |
| 08:26 | <alkisg> Which side is the client?
| |
| 08:26 | <enoch85> the scenario is this:
| |
| 08:27 | <alkisg> If the server is behind NAT, you'd also need port forwarding for all the involved ports
| |
| 08:27 | <enoch85> Server in one city ----> Site to Site tunnel ----> Client connecting to the server
| |
| 08:27 | <alkisg> ssh, nfs, tftp etc
| |
| 08:27 | <enoch85> yeah, that's nno problem
| |
| 08:27 | client in another city
| |
| 08:27 | <alkisg> If you're using VPN, then you shouldn't need NAT, right?
| |
| 08:27 | <enoch85> I'm not 100% sure
| |
| 08:28 | but yeah you may be right
| |
| 08:28 | <alkisg> How would the client join the VPN on boot?
| |
| 08:28 | <enoch85> it's very locked down though so we only allow certain ports on the other side
| |
| 08:28 | it's a site to site tunnel with a VPN FW on the other side
| |
| 08:29 | so everything behind the VPN FW is on our network
| |
| 08:29 | no need to manually connect
| |
| 08:29 | <alkisg> What is the other site dhcp server?
| |
| 08:29 | Is it configurable?
| |
| 08:29 | <enoch85> The other site uses it's own IP and have DHCP from the VPN FW
| |
| 08:29 | its*
| |
| 08:30 | <alkisg> Is that configurable?
| |
| 08:30 | <enoch85> yes
| |
| 08:30 | <alkisg> OK, then you'd just need to put the correct next-server there
| |
| 08:30 | <enoch85> I mean you can lock down IP adresses and such
| |
| 08:30 | <alkisg> and boot filename
| |
| 08:30 | <enoch85> as with any DHCP
| |
| 08:30 | hmm, let me check
| |
| 08:31 | <alkisg> Which software the DHCP server is? E.g. pfsense? plain isc-dhcp? windows dhcpd?
| |
| 08:31 | <enoch85> pfsense
| |
| 08:31 | and yes, everything is configurable
| |
| 08:31 | <alkisg> pfsense doesn't support conditional boot filenames
| |
| 08:31 | <enoch85> bummer
| |
| 08:32 | <alkisg> So you'd need a custom-compiled undionly.kpxe to bypass that
| |
| 08:32 | <enoch85> okok
| |
| 08:32 | out of my league :)
| |
| 08:32 | kjackal has joined IRC (kjackal!~quassel@ppp079166021071.access.hol.gr) | |
| 08:32 | <alkisg> Do your research, and if you end up needing what I just said, you can just hire me to do that
| |
| 08:33 | <enoch85> sure, will do!
| |
| 08:33 | thanks again
| |
| 08:33 | <alkisg> np
| |
| 08:34 | So to sum up, you won't need local media, just a custom undionly.kpxe on your ltsp server, not on pfsense; and a boot-filename=undionly.kpxe setting in pfsense.
| |
| 08:35 | Another way would be to deploy a small boot server there, that would also host the image, and save you all the nfs bandiwidth
| |
| 08:40 | <enoch85> yeah ok, good to know. I'll continue on my end here and let you know down the road.
| |
| 08:41 | enoch85 has left IRC (enoch85!25f71ea4@37-247-30-164.customers.ownit.se, Remote host closed the connection) | |
| 09:06 | georgeneophytou has joined IRC (georgeneophytou!~georgeneo@217.27.33.213) | |
| 09:15 | georgeneophytou1 has joined IRC (georgeneophytou1!~georgeneo@217.27.33.213) | |
| 09:16 | georgeneophytou1 has left IRC (georgeneophytou1!~georgeneo@217.27.33.213, Client Quit) | |
| 09:16 | georgeneophytou1 has joined IRC (georgeneophytou1!~georgeneo@217.27.33.213) | |
| 09:19 | georgeneophytou1 has left IRC (georgeneophytou1!~georgeneo@217.27.33.213, Client Quit) | |
| 09:20 | statler has joined IRC (statler!~Georg@gwrz3.lohn24.de) | |
| 09:21 | neo has joined IRC (neo!~georgeneo@217.27.33.213) | |
| 09:21 | neo is now known as Guest45350 | |
| 09:22 | Guest45350 has left IRC (Guest45350!~georgeneo@217.27.33.213) | |
| 09:25 | georgeneophytou has left IRC (georgeneophytou!~georgeneo@217.27.33.213, Quit: Textual IRC Client: www.textualapp.com) | |
| 09:27 | georgeneophytou has joined IRC (georgeneophytou!~georgeneo@217.27.33.213) | |
| 09:28 | <georgeneophytou> good morning, is it possible to set user quotas for storage? alkisg
| |
| 09:29 | <alkisg> georgeneophytou: good morning, this is unrelated to ltsp, google for "user quotas linux"
| |
| 09:29 | <georgeneophytou> okay thanks
| |
| 09:57 | <alkisg> georgeneophytou: are you using guest sessions or block device homes or something that is ltsp specific? i.e. other than plain sshfs/nfs home?
| |
| 09:59 | <georgeneophytou> I am just using the standard LTSP install but I was wondering about quotas
| |
| 10:00 | kjackal has left IRC (kjackal!~quassel@ppp079166021071.access.hol.gr, Ping timeout: 250 seconds) | |
| 10:00 | <alkisg> OK then yeah not ltsp specific
| |
| 10:02 | <meo> wonder if sshfs will behave funny under quotas
| |
| 10:05 | <alkisg> :q
| |
| 10:05 | <uumas> meo: I don't see why it would. I know we've had zfs quotas in the past with ltsp and there were no problems.
| |
| 10:07 | <meo> uumas: dunno, there's fuse in the middle, so how well it handles error conditions depends on both fuse and sshfs implementation
| |
| 10:08 | <alkisg> I imagine quotas would work, but the user might not get any warnings about remaining space before the quotas are exhausted
| |
| 10:14 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3107:2e00:2889:a70e:6ea0:d288) | |
| 10:18 | Da-Geek has joined IRC (Da-Geek!~Da-Geek@5.154.189.38) | |
| 10:37 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 240 seconds) | |
| 10:45 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 10:55 | pavars has joined IRC (pavars!~pavars@balticom-198-107.balticom.lv) | |
| 11:04 | <pavars> Hi, does anyone here know why ltsp5 would randomly disconnect users? So far only one user gets disconnected, bet sometimes other users get disconnected too. In .xsession-errors I see got Disconnected from D-Bus
| |
| 11:13 | <alkisg> pavars: graphics or networking issues
| |
| 11:13 | If you're using thin clients, it's a big worse, as opengl doesn't behave well over the network
| |
| 11:13 | If you're using ltsp fat clients, then it's the same as standalone workstations, some apps or drivers can crash xorg
| |
| 11:14 | *a bit worse
| |
| 11:18 | <pavars> we tried different cables and different thin client so it could be graphics
| |
| 11:18 | <alkisg> You would see a /var/crash entry then
| |
| 11:18 | Or messages in /var/log/Xorg.7.log.old
| |
| 11:18 | <pavars> can it be that it works normally and then at some random point it disconnects the user
| |
| 11:19 | enoch85 has joined IRC (enoch85!25f71ea4@37-247-30-164.customers.ownit.se) | |
| 11:19 | <alkisg> You mean like an ltsp internal reason? No
| |
| 11:19 | There's no code in ltsp to randomly disconnect users
| |
| 11:21 | <pavars> there are some files in /var/crash
| |
| 11:21 | I will investigate when the next crash happens
| |
| 11:21 | <alkisg> Yup, that's the correct path
| |
| 11:37 | pavars has left IRC (pavars!~pavars@balticom-198-107.balticom.lv, Remote host closed the connection) | |
| 11:38 | pavars has joined IRC (pavars!~pavars@balticom-198-107.balticom.lv) | |
| 11:53 | Faith has joined IRC (Faith!~Paty_@2001:12d0:2080::231:49) | |
| 11:53 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
| 12:07 | section1 has joined IRC (section1!~section1@178.33.109.106) | |
| 12:10 | vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi) | |
| 12:40 | <enoch85> alkisg 3 clients testing now :) ended up with using rdesktop as I din't get xfreerdp to work with desktop shortcuts
| |
| 12:40 | they are experiancing lag when moving windows, do you happen to know if I can make it quicker in LTSP?
| |
| 12:42 | <alkisg> enoch85: nah, the speed of rdp isn't related to ltsp, it's only configurable by its options
| |
| 12:43 | rdp is like thin clients, remote desktop = slow
| |
| 12:43 | That's why when we need windows here, we're using VMs instead
| |
| 12:44 | Windows VMs are like fat clients, remote disk, not remote screen
| |
| 12:45 | <enoch85> So what you're saying is that we shold setup small VMs instead and then connect directly to the VMs from the clients? I'm not following here...
| |
| 12:48 | also my boss was asking (and I just want to make sure) are the guest sesssions run from the server, or on the client hardware as if everything was loaded onto the client RAM and DISK?
| |
| 12:49 | i.e are the RDP sessions run from the server, or from the clients?
| |
| 12:49 | I noticed that if I reboot the server, the connections to the clients die, so that means to me that everything is run from the server
| |
| 12:50 | watching "nload" I can see that there are about 30 kbp/s on three clients
| |
| 12:50 | not any load though, and only 600 MB RAM consumed on the server
| |
| 12:54 | <alkisg> they run on the clients
| |
| 12:55 | <enoch85> ok
| |
| 12:55 | <alkisg> the clients root is nfs, so if you stop the server, they hang
| |
| 12:56 | it's remote disk, not remote screen
| |
| 12:58 | You may also test rdp performance by booting clients from a usb disk, it'll be the same
| |
| 13:01 | <enoch85> what would it cost for us if you fixed iPXE over WAN?
| |
| 13:01 | alkisg
| |
| 13:02 | <alkisg> You mean to compile undionly? I charge 30 euros per hour, I guess that would take 1 or 2 hours
| |
| 13:04 | <enoch85> ok, thanks I wil talk to my boss
| |
| 13:04 | <alkisg> np
| |
| 13:04 | <enoch85> could we deploy that file on every single location, or does it need to be specific on each location?
| |
| 13:05 | <alkisg> I think it can be the same in all locations
| |
| 13:05 | pavars has left IRC (pavars!~pavars@balticom-198-107.balticom.lv, Remote host closed the connection) | |
| 13:05 | <enoch85> ok, and everytime iPXE updates we would need to compile a new file?
| |
| 13:05 | <alkisg> As long as clients boot, there's no reason to update ipxe
| |
| 13:05 | <enoch85> ok
| |
| 13:05 | I mean new versions
| |
| 13:05 | <alkisg> Its code is replaced by the kernel, so there are no "left over" security holes etc
| |
| 13:06 | <enoch85> so iPXE 1.1, 1.2 and so on
| |
| 13:06 | <alkisg> We have schools here with 10 years old gpxe
| |
| 13:06 | And no reason to change it
| |
| 13:06 | <enoch85> hehe ok
| |
| 13:06 | <alkisg> (gpxe was the old ipxe)
| |
| 13:06 | <enoch85> ok
| |
| 13:07 | btw, could we choose to skip the iPXE menu? I saw that you can set timeout, but is it possible to set that to 0?
| |
| 13:07 | <alkisg> yes
| |
| 13:07 | <enoch85> ok
| |
| 13:07 | perfect
| |
| 13:07 | <alkisg> see the man page
| |
| 13:07 | *the ltsp.ipxe notes
| |
| 13:09 | <enoch85> MENU_TIMEOUT=“0" ?
| |
| 13:18 | <alkisg> # To completely hide the menu, set menu-timeout to -1
| |
| 13:21 | <enoch85> thanks!
| |
| 13:27 | pavars has joined IRC (pavars!~pavars@balticom-198-107.balticom.lv) | |
| 14:25 | spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut) | |
| 14:33 | pavars has left IRC (pavars!~pavars@balticom-198-107.balticom.lv, Remote host closed the connection) | |
| 14:37 | pavars has joined IRC (pavars!~pavars@balticom-198-107.balticom.lv) | |
| 14:49 | pavars has left IRC (pavars!~pavars@balticom-198-107.balticom.lv, Remote host closed the connection) | |
| 15:11 | <alkisg> What sounds better, SESSION_SCRIPT, LTSP_SESSION or something else? It's a new ltsp.conf parameter, similar in functionality to .xsession.
| |
| 15:11 | https://github.com/ltsp/ltsp/issues/18#issuecomment-550353273
| |
| 15:21 | eddytv has joined IRC (eddytv!~eddy@2620:11e:1000:6:3c68:bc19:6453:337a) | |
| 15:29 | <eddytv> Greetings! I was looking at the new LTSP wiki and was curious if there was any support for using LXC container images as iPXE boot images. It would be great to be able to use something like distrobuilder (https://linuxcontainers.org/distrobuilder/introduction/) to create images for fat-clients.
| |
| 15:41 | <||cw> eddytv: isn't that what ltsp-build-client already does?
| |
| 15:41 | <eddytv> That is no longer a thing in the new LTSP.
| |
| 15:45 | I'd like to be able to build client images from a reproducible "recipe", whether it be a Dockerfile or a YAML definition for distrobuilder or whatever. I don't want to manually install a random VM where a bunch of commands have been run, making it a challenge to reproduce. And since I'm already using Docker and LXC, I'd prefer that over dealing with another virtualization solution, hence my question.
| |
| 15:46 | <||cw> ah, right. so distrobuilder says it can output a chroot, and ltsp image can point to a chroot, so give it a shot?
| |
| 15:46 | https://ltsp.github.io/man/ltsp-image/ basically just says "manage the chroot or vm image however you like using whatever tools"
| |
| 15:47 | <eddytv> Part of the reason I ask is because of https://github.com/ltsp/community/issues/27
| |
| 15:48 | The person gave up and switched to using "a full VM"
| |
| 15:48 | <||cw> that's for running the server in one, totally different
| |
| 15:49 | <alkisg> eddytv: why do you need help from ltsp to create a chroot?
| |
| 15:50 | There are lots of methods nowadays, ltsp-build-client isn't relevant anymore
| |
| 15:50 | !chroot
| |
| 15:50 | <ltsp> chroot: To manage chroots with the new LTSP, see https://github.com/ltsp/community/wiki/chroots
| |
| 15:50 | <eddytv> Well, that was going to be the next thing I wanted to ask about. I already have DHCP infrastructure, NFS infrastructure, etc. and don't want to run a VM just for LTSP and duplicate those services.
| |
| 15:50 | <||cw> that issues specifically is in getting a bind mount to work in a container, which running a client doesn't need
| |
| 15:51 | <alkisg> eddytv: there's no "ltsp server" package. So you just install the ltsp package, and run as many services as you want, or none at all
| |
| 15:51 | But you do need `ltsp image` or `ltsp ipxe` to configure things for you
| |
| 15:51 | <eddytv> But could I run those in a Docker container that is running `nbd`?
| |
| 15:51 | <||cw> you don't need a 2nd dhcp server, just dhcp proxy
| |
| 15:51 | <alkisg> The new ltsp doesn't use nbd
| |
| 15:52 | <eddytv> Ah, good to know.
| |
| 15:52 | <alkisg> What would the docker container do?
| |
| 15:53 | <eddytv> So let's say I can generate my own chroot which contains the new `ltsp` PPA. And I have DHCP and NFS services available already. Do I need "an LTSP server"?
| |
| 15:53 | pavars has joined IRC (pavars!~pavars@balticom-198-107.balticom.lv) | |
| 15:53 | <alkisg> Will you run mksquashfs yourself?
| |
| 15:53 | Will you configure ipxe yourself?
| |
| 15:53 | And dhcp and nfs and all?
| |
| 15:54 | If you do *all* server side things, then sure you don't need an ltsp "server"
| |
| 15:54 | But note that the ltsp server is primarily just a client template; so you can use a client to maintain the image even if the image is in an nfs server
| |
| 15:55 | Where are your users? Where's /home?
| |
| 15:56 | <eddytv> /home is NFS
| |
| 15:56 | <alkisg> And user accounts?
| |
| 15:57 | <eddytv> For my use case, they can be local, in the client image.
| |
| 15:57 | <alkisg> Which software runs dhcpd?
| |
| 15:57 | <eddytv> dnsmasq
| |
| 15:58 | <alkisg> all fine then
| |
| 15:58 | <eddytv> For reference, I'm trying to update an existing, but very old, LTSP deployment that is running on a 14.04 server
| |
| 15:59 | I'd like to migrate to the new LTSP, and am hoping to avoid dedicated VMs if possible
| |
| 15:59 | Since the preference is for Docker/LXC containers for everything
| |
| 16:01 | <alkisg> moment, phone
| |
| 16:03 | eddytv_ has joined IRC (eddytv_!~eddy@2620:11e:1000:220:d45:ebba:82c4:cb64) | |
| 16:04 | <eddytv_> (sorry, got disconnected). It sounds like the new LTSP may "just work", I will give it a shot. Thanks very much ||cw and alkisg.
| |
| 16:05 | eddytv has left IRC (eddytv!~eddy@2620:11e:1000:6:3c68:bc19:6453:337a, Ping timeout: 264 seconds) | |
| 16:06 | eddytv_ is now known as eddytv | |
| 16:07 | <alkisg> (06:01:13 PM) alkisg: moment, phone
| |
| 16:08 | pavars has left IRC (pavars!~pavars@balticom-198-107.balticom.lv, Remote host closed the connection) | |
| 16:08 | woernie has joined IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de) | |
| 16:15 | <alkisg> Back
| |
| 16:17 | Btw ltsp19 requires systemd, so it won't run on 14.04. It needs 16.04+
| |
| 16:19 | `ltsp image` does some mount/tmpfs/overlay magic, so I'm not sure if it'll run on containers out of the box or if it'll need a bit of fixing
| |
| 16:20 | If you replace it with just mksquashfs, then it'll surely work
| |
| 16:22 | Da-Geek has left IRC (Da-Geek!~Da-Geek@5.154.189.38, Quit: Leaving) | |
| 16:23 | <eddytv> We are retiring the 14.04 server, so no issues there! The mksquashfs solution seems like a useable alternative, although it would be *great* if I could use `ltsp image` in a container.
| |
| 16:26 | <alkisg> You may try it, I think it'll need a few apport exceptions or however they're called; I gave a link in the issue
| |
| 16:27 | It's `ltsp image container` :D so you'll looking to run a container in a container :D
| |
| 16:27 | The new ltsp isn't intrusive, you may even put it in the hypervisor if it's compatible
| |
| 16:28 | And just run `ltsp image container` outside of the container
| |
| 16:42 | statler has left IRC (statler!~Georg@gwrz3.lohn24.de, Remote host closed the connection) | |
| 16:42 | pavars has joined IRC (pavars!~pavars@balticom-198-107.balticom.lv) | |
| 16:55 | <eddytv> Thanks Alkis, especially for all your work on "LTSP19". I plan to play around with the new implementation and see how it goes for my use case.
| |
| 16:55 | pavars has left IRC (pavars!~pavars@balticom-198-107.balticom.lv, Ping timeout: 246 seconds) | |
| 17:20 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 17:56 | <alkisg> vagrantc: heya, which one sounds better? SESSION, LTSP_SESSION, SESSION_SCRIPT... https://github.com/ltsp/ltsp/issues/18#issuecomment-550353273
| |
| 17:57 | LTSP will prefix it to the Exec lines of xsession.desktop and wayland sessions
| |
| 17:57 | (when set)
| |
| 18:00 | SESSION_WRAPPER, PREFIX_SESSION...
| |
| 18:10 | enoch85 has left IRC (enoch85!25f71ea4@37-247-30-164.customers.ownit.se, Ping timeout: 260 seconds) | |
| 18:15 | <vagrantc> hmmmm...
| |
| 18:16 | i naturally am inclined towards LTSP_SESSION ... but then everything's prefixed with LTSP_ ... which seems silly.
| |
| 18:17 | <alkisg> Yeah I tried to avoid it except for the most common words where it wasn't nice to have them alone
| |
| 18:17 | <vagrantc> SESSION_WRAPPER seems pretty good
| |
| 18:17 | though i think i lean towards LTSP_SESSION, if you don't mind the LTSP_ prefix
| |
| 18:17 | although was that variable used in ltsp 5.x ?
| |
| 18:18 | don't see it... ok.
| |
| 18:37 | <alkisg> Ty; will use one of those 2
| |
| 19:23 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving) | |
| 19:28 | <eddytv> alkisg: at 10:51:56 you said "The new ltsp doesn't use nbd" and I just noticed that "NBD" is still prominently listed on the https://ltsp.github.io home page, which is probably why I thought it was still an option.
| |
| 19:33 | robert45 has joined IRC (robert45!~robert45@r190-135-251-229.dialup.adsl.anteldata.net.uy) | |
| 19:34 | <robert45> hey guys! I have removed my old 32bit image and built a new 64bit image, however, Im presenting with all this kind of errors. I have INIT_COMMAND_RM_NETPLAN already on my lts.conf. Any ideas? https://imgur.com/a/nhwaNzj
| |
| 19:40 | <alkisg> eddytv: if you set it up yourself...
| |
| 19:41 | robert45: ppa in the chroot?
| |
| 19:43 | robert45: or, wrong syntax/place of lts.conf
| |
| 19:43 | <eddytv> ah, so if I wanted to use `nbd` you're saying technically you could...
| |
| 19:43 | <alkisg> yeah; we might also write some support in the future
| |
| 19:43 | maybe for swap...
| |
| 19:44 | <eddytv> any idea if there's a performance benefit for serving the squashfs via nbd vs. nfs?
| |
| 19:44 | <alkisg> performance is about the same, nfs has better caching, and a LOT MORE stability
| |
| 19:44 | Like 1000% more
| |
| 19:45 | <eddytv> Good to know. Sounds like NFS is the way to go.
| |
| 19:45 | <alkisg> You can even reboot the server and have the clients continue afterwards
| |
| 19:45 | Yeah, we made those decisions for you when designing ltsp19 ;)
| |
| 19:46 | <eddytv> Fantastic. That's what I like to hear! Thanks again (to everyone) for all the work on the new version.
| |
| 19:46 | <alkisg> np
| |
| 19:47 | isc-dhcp, tftpd-hpa, ldap etc are also mentioned there, and also manual...
| |
| 19:53 | section1 has left IRC (section1!~section1@178.33.109.106, Quit: Leaving) | |
| 20:27 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
| 20:28 | dgroos has joined IRC (dgroos!~dgroos@205.215.175.117) | |
| 20:29 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Client Quit) | |
| 20:41 | woernie has left IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 20:45 | <dgroos> Using ltsp19 on ubuntu 18.04 (gdk). Having issues with screens timing out then trouble logging out a student through epoptes.
| |
| 20:46 | Sometimes logout will work but it can take a minute or longer.
| |
| 20:46 | <alkisg> what does "timing out" mean?
| |
| 20:46 | <dgroos> Sometimes a dialog box will be shown on the login screen at the client.
| |
| 20:47 | If a student is not interacting with a computer for a while, it will lock (what I was calling timeout)
| |
| 20:48 | And if they leave class, I can't log them out via epoptes or it may work or it might take a minute or more.
| |
| 20:50 | I've checked the syslogs of a few clients but didn't know what to look for.
| |
| 20:51 | <alkisg> suspend? screensaver?
| |
| 20:52 | <dgroos> for example, not sure if it's a problem: "rfkill: input handler disabled" and a while later it will give the message that it's enabled.
| |
| 20:52 | screensaver
| |
| 20:52 | <alkisg> dgroos: rfkill is about wifi, do your clients try to connect with wifi?
| |
| 20:52 | <dgroos> maybe?
| |
| 20:52 | <alkisg> Were you using the same clients in ltsp5 without issues?
| |
| 20:53 | <dgroos> I wasn't but other teachers were, I think. I can test as I've got both systems.
| |
| 20:54 | <alkisg> How often does that happen? Can you ping me right after it happens so that we check logs?
| |
| 20:54 | <dgroos> (oops, meant to say that other teachers were using these, not myself, and I don't know if there were problems)
| |
| 20:54 | <alkisg> nfs has very good recovery, so you may go offline for a while and it'll continue working when it comes back,
| |
| 20:55 | but the question is, if it's networking, where exactly is the issue...
| |
| 20:55 | <dgroos> OK, I've got a few that I left that have gone into lock mode so I can try shutting them down and see what happens.
| |
| 20:55 | <alkisg> Check also output of dmesg
| |
| 20:55 | Can you see them via epoptes when they're "locked"?
| |
| 20:56 | <dgroos> ok, I'll check that first, then try the logout and ping if I see problem.
| |
| 20:56 | yes
| |
| 20:56 | <alkisg> right click, open terminal, dmesg
| |
| 20:56 | The most important information
| |
| 20:56 | No need to logout it doesn't provide useful info
| |
| 20:56 | <dgroos> ok
| |
| 20:56 | <alkisg> Just logs stuff that we don't want to see and will confuse us
| |
| 20:57 | lchaos has joined IRC (lchaos!8a3300bf@138.51.0.191) | |
| 20:59 | <dgroos> the last message in the dmesg log at the client I'm looking at is rfkill: input handler disabled.
| |
| 20:59 | (colors, I like that!)
| |
| 20:59 | <alkisg> dmesg | tail -n 50 | nc termbin.com 9999
| |
| 20:59 | Give us more info, not just the last line
| |
| 21:00 | <dgroos> termbin, that's new to me!
| |
| 21:00 | <alkisg> It avoids the need to copy/paste :)
| |
| 21:00 | <dgroos> k
| |
| 21:01 | very cool :-)
| |
| 21:01 | 9999 is the id of this paste?
| |
| 21:01 | <alkisg> No, it's the port that termbin listens to
| |
| 21:01 | The output of the command is the url
| |
| 21:01 | That you're supposed to give us
| |
| 21:02 | <dgroos> oh :P
| |
| 21:02 | https://termbin.com/eyzo
| |
| 21:02 | <alkisg> The last message there is when the client boots
| |
| 21:02 | If this client is hanged, it's not related to the kernel... hmm...
| |
| 21:02 | (52 seconds after boot)
| |
| 21:03 | loop17... I guess those are snaps
| |
| 21:03 | <dgroos> (not saying it is hanged, I've not tried to log it out yet)
| |
| 21:03 | let me try...
| |
| 21:04 | <robert45> alkisg yeah that was it! thanks!
| |
| 21:04 | have a good one guys
| |
| 21:04 | robert45 has left IRC (robert45!~robert45@r190-135-251-229.dialup.adsl.anteldata.net.uy, ) | |
| 21:05 | <alkisg> dgroos: edit this file: /usr/share/ltsp/ltsp/server/image/image.excludes => remove the snap/* line, then run ltsp image /
| |
| 21:05 | <lchaos> Hello All, I'm hoping to get some direction to further troubleshoot an issue I've come across in my LTSP setup. The problem is that the ltsp clients fail to boot after receiving an ipaddress and the tftpboot image. The client then proceeds to boot as normal until it starts spitting out 3 errors and goes into squashfs and freezes. if I remember
| |
| 21:05 | correctly the errors related to system network, and I've noticed that the lan interface on the server goes down momentarily as well.
| |
| 21:05 | <alkisg> There was a bug with snaps, so they may lag, I don't use them and I don't know
| |
| 21:05 | netplan | echo lchaos:
| |
| 21:05 | !netplan | echo lchaos:
| |
| 21:05 | <ltsp> lchaos: netplan: To work around https://bugs.launchpad.net/netplan/+bug/1763608/comments/47, either update to a new LTSP version, or put this in lts.conf: INIT_COMMAND_RM_NETPLAN="rm -rf /lib/systemd/system-generators/netplan /run/netplan"
| |
| 21:06 | <dgroos> will do, thanks!
| |
| 21:06 | eddytv has left IRC (eddytv!~eddy@2620:11e:1000:220:d45:ebba:82c4:cb64, Quit: My computer has gone to sleep. ZZZzzz…) | |
| 21:08 | <dgroos> Also, should I be able to broadcast to a screen where no one has net logged into the client?
| |
| 21:08 | I know that this would work w/ltsp5
| |
| 21:08 | <alkisg> Yes
| |
| 21:08 | <dgroos> OH
| |
| 21:08 | <alkisg> There was a bug with epoptes but I thought it was only in 16.04
| |
| 21:08 | Can you vnc?
| |
| 21:08 | <dgroos> sure, thanks! just a sec
| |
| 21:08 | <alkisg> (debhelper compatibility made the epoptes service not start)
| |
| 21:10 | <lchaos> @ltsp; Thanks for a quick reply, and guidance. I'm excited to start follow up on your advice. Thanks again!1
| |
| 21:10 | <alkisg> lchaos: ltsp is a bot
| |
| 21:10 | We invoke it to mention our notes to other users here :)
| |
| 21:10 | I.e. it saves us typing :)
| |
| 21:11 | <lchaos> @alkisg; Thanks for clarifying. :) (slightly embarrassed). Thank you.
| |
| 21:13 | <alkisg> dgroos: you're on wayland again
| |
| 21:13 | lchaos: no worries man
| |
| 21:14 | dgroos: vnc doesn't work on wayland
| |
| 21:14 | Hrm... although... how am I watching your screen... hm...
| |
| 21:16 | lchaos has left IRC (lchaos!8a3300bf@138.51.0.191) | |
| 21:18 | dgroos_ has joined IRC (dgroos_!~dagro001@205.215.175.117) | |
| 21:23 | <dgroos_> alkisg: interesting, broadcasting worked on the client but not shown in epoptes
| |
| 21:24 | (don't know if you can see from the access you have)
| |
| 21:24 | <alkisg> dgroos_: I think broadcasting works fine, but it's not "on top", it goes under gdm because of gnome-shell
| |
| 21:26 | Yeah that's it
| |
| 21:26 | By killing gnome-shell, I can see e.g. the remote terminal
| |
| 21:26 | <dgroos_> on a vnc session into the client you are saying?
| |
| 21:26 | <alkisg> So I guess epoptes will need to find a workaround in order to be able to show stuff in front of gdm, not behind it
| |
| 21:27 | We start with client reboot,
| |
| 21:27 | then, right click from epoptes, open root terminal
| |
| 21:27 | This was supposed to show on TOP of gdm
| |
| 21:27 | But it's under it; it's not shown at all (like screen broadcasting)
| |
| 21:27 | <dgroos_> oh
| |
| 21:28 | <alkisg> Then,`killall gnome-shell` kills the compositor, and one can properly see the terminal
| |
| 21:28 | So the problem is gnome-shell, it's doing fancy things and hides "on-top" windows beneath
| |
| 21:28 | Just switch to MATE :P
| |
| 21:29 | File a bug in epoptes so that we don't forget about it, and I may have a look ...next year or so; this isn't very important
| |
| 21:29 | <dgroos_> MATE is cool but I had a lot of issues with it last year.
| |
| 21:30 | Will do, thanks for checking into it!
| |
| 21:30 | <alkisg> np
| |
| 21:31 | <dgroos_> Shall I do the work with the snap drive or is the logout issue related to this layer issue?
| |
| 21:31 | <alkisg> Try the snap, it might be related
| |
| 21:32 | <dgroos_> k thanks again, will try now.
| |
| 21:33 | dgroos has left IRC (dgroos!~dgroos@205.215.175.117, Quit: Leaving) | |
| 21:33 | dgroos_ is now known as dgroos | |
| 21:33 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 21:56 | eddytv has joined IRC (eddytv!~eddy@2601:402:4500:4670:c954:cfa4:b07f:bd36) | |
| 22:33 | kjackal has left IRC (kjackal!~quassel@2a02:587:3107:2e00:2889:a70e:6ea0:d288, Ping timeout: 246 seconds) | |
| 22:43 | spaced0ut has left IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut, Quit: Leaving) | |
| 23:11 | eddytv has left IRC (eddytv!~eddy@2601:402:4500:4670:c954:cfa4:b07f:bd36, Quit: My computer has gone to sleep. ZZZzzz…) | |
| 23:11 | dgroos has left IRC (dgroos!~dagro001@205.215.175.117, Quit: dgroos) | |
| 23:34 | dgroos has joined IRC (dgroos!~dagro001@205.215.175.117) | |
| 23:40 | dgroos has left IRC (dgroos!~dagro001@205.215.175.117, Quit: dgroos) | |