00:39 | markit has left IRC (markit!~marco@mail.ammdomus.it, ) | |
02:26 | gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Remote host closed the connection) | |
02:27 | gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com) | |
02:30 | gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Remote host closed the connection) | |
02:31 | gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com) | |
02:32 | gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Remote host closed the connection) | |
02:33 | gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com) | |
02:42 | gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Ping timeout: 265 seconds) | |
03:31 | gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com) | |
03:32 | gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Remote host closed the connection) | |
03:32 | gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com) | |
03:38 | gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Ping timeout: 268 seconds) | |
03:48 | eu^182253233245 has joined IRC (eu^182253233245!b6fde9f5@182.253.233.245) | |
03:49 | eu^182253233245 has left IRC (eu^182253233245!b6fde9f5@182.253.233.245, Remote host closed the connection) | |
04:07 | gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com) | |
04:08 | gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Remote host closed the connection) | |
04:09 | gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com) | |
04:14 | gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Ping timeout: 240 seconds) | |
04:31 | gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com) | |
04:32 | gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Remote host closed the connection) | |
04:32 | gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com) | |
04:37 | gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Ping timeout: 260 seconds) | |
05:07 | gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com) | |
05:18 | dsjii has left IRC (dsjii!~david@047-134-241-234.res.spectrum.com, Quit: Leaving) | |
05:20 | gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Ping timeout: 240 seconds) | |
07:12 | woernie has joined IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de) | |
07:18 | gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com) | |
07:30 | <alkisg> gbaman: what's broken on the desktop?
| |
07:50 | gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Ping timeout: 260 seconds) | |
07:51 | gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com) | |
07:55 | gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Ping timeout: 258 seconds) | |
08:58 | statler has left IRC (statler!~Georg@p5B30EE2F.dip0.t-ipconnect.de, Remote host closed the connection) | |
09:42 | markit has joined IRC (markit!~marco@mail.ammdomus.it) | |
09:44 | <markit> hi alkisg, did you read that last epoptes fixed the broadcast? Now works fine
| |
09:45 | btw, what do you mean with "If you need to customize /etc, you can do so with POST_INIT_x commands" ? Do I have to enter there a sort of "echo newparameter=something >> /etc/whatever.conf" there?
| |
09:45 | <alkisg> markit: I did read it, but there were no related changes, so it must have been something else
| |
09:46 | Yes, or you can put files in /etc/ltsp/*, and they will reach the client via ltsp.img, and you can then symlink or cp them
| |
09:48 | statler has joined IRC (statler!~Georg@80.151.99.211) | |
09:49 | <markit> like POST_INIT_SWAPPINES="cat /etc/ltsp/sysctl.conf >> /etc/sysctl.conf" ?
| |
09:49 | <alkisg> Sure
| |
09:50 | <markit> great!
| |
09:50 | <alkisg> If it's just a few lines, you can include them directly in ltsp.conf
| |
09:51 | POST_INIT_SWAPPINESS="echo 'line1
| |
09:51 | line2' >> /etc/sysctl.conf"
| |
09:51 | <markit> I set client swappiness to 10, should be much better than default 60
| |
09:52 | <alkisg> Swap is broken in linux, I don't expect playing with swappiness or zswap or zram to help much
| |
09:52 | There's an effort to fix it by the kernel devs
| |
09:53 | <markit> btw, yesterday I went crasy with modifications in /etc/sddm.conf.d/, behaviour was very bizarre... then I realized that ALL files there are processed, not only the *.conf ones, but also *.conf~ produced by emacs :(
| |
09:53 | <alkisg> Isn't SDDM_CONF in ltsp.conf enough?
| |
09:54 | The idea is that you touch /etc/sddm* only if you want to change things on the server
| |
09:54 | And then for the clients, you modify ltsp.conf
| |
09:54 | <markit> Yes, I want it changed on the server too
| |
09:54 | <alkisg> ok
| |
09:56 | <markit> I tried epoptes from a client, logging as administrator, but the epoptes server is not present in the image AFAIU
| |
09:56 | <alkisg> Do you mean the epoptes server key?
| |
09:56 | <markit> is there a way for a teacher to use a client instead of the server?
| |
09:56 | <alkisg> The epoptes binary is there, isn't it?
| |
09:56 | Sure, with passwordless ssh -X
| |
09:57 | <markit> from the client I run epoptes from K menu but nothing happened
| |
09:57 | <alkisg> The only reason to run epoptes directly on the client, without ssh -X, would be if an ltsp client is the epoptes server *instead* of the ltsp server being the epoptes server
| |
09:57 | Which one is the epoptes server?
| |
09:57 | The ltsp server or the ltsp client?
| |
09:58 | <markit> well, the ltsp server, then I would love to be able to have the teacher connect and use it not only from the ltsp server but also from a ltsp client
| |
09:58 | <alkisg> That's what I said about passwordless ssh -X
| |
09:58 | Google about passwordless ssh, it needs ssh-copy-id
| |
09:59 | <markit> (so I could move the ltsp server to the Proxmox school's server into a VM)
| |
09:59 | <alkisg> Then you can run whatever program you want remotely, not just epoptes
| |
09:59 | <markit> Oh, I see.
| |
10:00 | Btw, do you think that wayland is something interesting for the 20.04? Better stay in X-Windows for a couple of decades more? :)
| |
10:00 | <alkisg> wayland doesn't support screen sharing etc
| |
10:00 | So forget about epoptes and all related programs there
| |
10:00 | ssh -X won't work, remote desktop, lock screen, screen broadcasting etc
| |
10:01 | I guess they'll need a few more years to get that part ready. THEN I'll be able to move to wayland; your needs may vary :)
| |
10:01 | <markit> so it's broken by desigh
| |
10:01 | <alkisg> They're slowly implementing a pipewire and a gnome-remote-desktop thing
| |
10:01 | But it'll need years for real programs to work with those
| |
10:02 | <markit> ok
| |
10:04 | With ltsp5 chroot I had the possibility to install some programs on the server and not in chroot for the clients, is there some way to do the same? What about the "default application"? I mean, if programs X,Y,Z can open i.e. .pdf, and I remove X from the client image, will .pdf be open by Y or an error will occur?
| |
10:04 | <alkisg> markit: it might be possible to forward just the socket, instead of the whole epoptes gui... I'll check, ask me again later
| |
10:04 | You can still have chroots and images in the new ltsp
| |
10:04 | Even virtualbox VMs, which are a lot easier to maintain than chroots
| |
10:04 | Think if your use case needs different apps, or just hidden apps
| |
10:05 | If you need different apps on the server vs the clients, then just use a virtualbox or proxmox vm
| |
10:06 | <markit> that way I would have "nested virtualization" if I move ltsp server to a Proxmox VM
| |
10:07 | <alkisg> The vm doesn't need to be maintained ON the server
| |
10:07 | You can maintain it on proxmox, and just share it to the server with whatever means
| |
10:07 | You can either mount it as a disk, or via nfs, or however you like
| |
10:07 | Then you run `ltsp image`, and you an unmount it
| |
10:07 | *can
| |
10:08 | <markit> mmm interesting, I will ask you about "how" and try myself another time, don't want to abuse your precious time. Thanks a lot
| |
10:08 | <alkisg> np
| |
10:08 | (you can still use chroots if you like them; but imho they are too many programs that just don't work well in chroots)
| |
10:10 | <markit> well, just I could have programs that are important in the server (like emacs, wireshark, etc) that I don't want to appear in children's clients, or take control of some files (like double click on a .py file and having emacs open it instead of Kate ;P)
| |
10:11 | would love to have a fast way to prevent them to be in the client image
| |
10:11 | <alkisg> chmod -x wireshare is enough to make it not runnable
| |
10:11 | POST_INIT_CHMOD_PROGRAMS="chmod -x ..."
| |
10:11 | <markit> yep! good idea
| |
10:11 | <alkisg> About what opens what, what you describe is per user, not per system
| |
10:12 | kvaps has joined IRC (kvaps!2e1c6842@wedos.wedos.net) | |
10:12 | <alkisg> You want *markit* to open them with emacs, not "server"
| |
10:12 | So if markit logs in on a client, he'd still open them via emacs
| |
10:12 | <markit> isn't a global default association when I install a program? I often have new installed programs take control of a filetype
| |
10:13 | <alkisg> There are both
| |
10:13 | There's the global one, the default for all the users
| |
10:13 | And then each user can select his own, by right click > open with > set as default
| |
10:13 | <markit> I've the feeling that if I install emacs (just an example), all .txt files will be open by it by default for all users
| |
10:14 | I know, but young children can't do it
| |
10:14 | <alkisg> YOU would do that
| |
10:14 | The default would be kate
| |
10:14 | <markit> teachers here are.... ehm... not very good with computers?
| |
10:14 | <alkisg> Your own override would be emacs
| |
10:14 | Don't force emacs to the users. Leave the default, kate. Only use emacs for yourself.
| |
10:15 | Try it, you need some reading, if you have questions when you try it, ping again
| |
10:15 | <markit> I just thought emacs installation whould have taken precedence for ALL users by default, and I had to change back to Kate user by user, but I will try, thanks
| |
10:16 | <alkisg> There's a priority
| |
10:16 | Each package defines its priority
| |
10:16 | I believe emacs would have lower priority than kate
| |
10:16 | So you need to change markit settings only. Not system settings at all.
| |
10:16 | <markit> was just an example of a program with higher priority, I don't know for sure either
| |
10:17 | <alkisg> Google for `update-alternatives`, `xdg-open`, `xdg-mime`, and check right click > open as
| |
10:17 | *open with
| |
10:17 | <markit> but the question was "if I need a program of higher priority only for teacher on the server, how can I have all clients stay with older priority?"
| |
10:17 | <alkisg> It shouldn't take you more than 5 minutes to learn those
| |
10:17 | I answered it 5 times already :(
| |
10:17 | I don't know how else to answr it
| |
10:18 | teacher uses USER settings, clients use SYSTEM settings
| |
10:18 | It's very easy to do that
| |
10:18 | <markit> I thought there was a misunderstanding, I will re-read carefully your answers and, better, try them :)
| |
10:19 | (I'm also doing 3 things at the same time, just using the time I can spend on IRC when you are available to ask questions I will try later when I can)
| |
10:26 | <alkisg> Yey!
| |
10:27 | markit: with ssh socket forwarding, it's possible to run the epoptes gui from wherever, and additionally fast, without having to forward Xorg
| |
10:27 | gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com) | |
10:27 | <alkisg> I'll write a how-to in the epoptes site later on
| |
10:28 | You basically run this from the client: mkdir /run/epoptes; chgrp epoptes /run/epoptes; rm /run/epoptes/epoptes.socket; ssh -L /run/epoptes/epoptes.socket:/run/epoptes/epoptes.socket user@server
| |
10:29 | And while this is still running and forwarding the socket, you run epoptes from the menu, and it works fine
| |
10:38 | <markit> thanks, I copy and paste in my ltsp notes and try later :)
| |
10:41 | * alkisg also notes another way that won't require ssh at all: http://www.dest-unreach.org/socat/doc/socat-openssltunnel.html | |
10:41 | <alkisg> I'll need to automate that one
| |
11:00 | gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Ping timeout: 240 seconds) | |
11:17 | <kvaps> Hey, I just I found and forked cool tftp server: https://github.com/kvaps/trivialt/
| |
11:17 | <alkisg> Heya kvaps
| |
11:18 | <kvaps> It supports single port mode, and can be used over Nat
| |
11:18 | <alkisg> Does it have any benefits over dnsmasq or tftpd-hpa?
| |
11:19 | When we needed proxydhcp, we asked the dnsmasq developer, simon, and he implemented it
| |
11:19 | If you need that, and dnsmasq doesn't support it, why not just ask about it?
| |
11:19 | <kvaps> Is dnsmasq support single port mode for tftp?
| |
11:19 | <alkisg> He supported proxydhcp in a few days, it didn't even take a long time...
| |
11:20 | No idea, but if it doesn't, you should ask simon to support it
| |
11:21 | <kvaps> The problem is that this sungle port mode is not described in RFC or some other document, it's like extra feature, just for avoid firewalls
| |
11:22 | <alkisg> Oh, all the projects have code and workarounds outside of RFCs
| |
11:22 | <kvaps> more details about the single port feature: https://github.com/kvaps/trivialt/#unique-features
| |
11:22 | <alkisg> If other people need it and it doesn't need a lot of code changes, it should be doable
| |
11:23 | <kvaps> That's true, we can try create issue for dnsmasq
| |
11:25 | <alkisg> What are the changes of the fork, compared to https://github.com/vcabbage/go-tftp ?
| |
11:26 | <kvaps> It is just command line client, it uses vcabbage/go-tftp in dependencies
| |
11:27 | alkisg: Is dnsmasq have some bugtracker or just mailing list?
| |
11:27 | <alkisg> Mailing list
| |
11:27 | <kvaps> ok\
| |
11:52 | Feature request sent: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2019q4/013650.html
| |
12:10 | gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com) | |
12:11 | <gbaman> alksig got it sorted, involved a bug with the version of qemu shipped with 18.04 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923289
| |
12:11 | And then need to it seems run update-mime-database /usr/share/mime each time the client boots
| |
12:11 | Running it in the chroot doesn't seem to do a whole lot
| |
12:13 | But now I am using a newer build of qemu and have the mime database being updated each startup on the Pi itself, got a working version of Raspbian on LTSP, directly from a Raspbian SD card image
| |
12:29 | Been doing some thinking though alksig, this change to using ltsp.img with the passwd file, am I not right saying then that any new user or a password change would require a reboot of the client?
| |
13:06 | GodFather has left IRC (GodFather!~rcc@wsip-66-210-242-210.ph.ph.cox.net, Ping timeout: 240 seconds) | |
13:19 | <alkisg> gbaman: use tab to correctly autocomplete the name, alkisg
| |
13:19 | Yes, a client reboot is required, or at least some method to send the updated passwd/group
| |
13:20 | I had a few issues with qemu as well, so I'm maintaining my raspbian images using nfsrw boot method
| |
13:20 | I.e. I'm booting a client in nfs read-write mode and I'm maintaining the image from there
| |
14:20 | <gbaman> In general alkisg, I haven't found any major issues in the past with qemu chroot method, certainly a lot simpler for teachers than having to make changes on a Pi
| |
14:24 | As for the users stuff, I could see that being an issue. If a user changes their password for example, then the client would need a reboot
| |
14:25 | What's stopping the merge taking place dynamically, each time the greeter is launched, pulling in over sshfs?
| |
14:26 | Or it being live on a share?
| |
15:04 | <alkisg> gbaman: in ltsp so far, users couldn't change their password on fat clients
| |
15:05 | Also, booting an rpi client and selecting "teacher nfsrw mode" is a lot simpler than having to maintain chroots,
| |
15:05 | pulling passwd over sshfs in insecure, as the user has control over sshfs at that point, and he can just return a passwd where he is root
| |
15:08 | <gbaman> Hmm
| |
15:09 | It was definitely at least possible to add accounts while clients were already booted, then log in immediately?
| |
15:14 | <alkisg> Indeed. But that had the security issue I'm mentioning
| |
15:14 | I.e. in ltsp5, any user could easily become root
| |
15:15 | Sometime in the future, the ltsp server needs to run a service; it then can send ltsp.conf or passwd etc over that
| |
15:15 | But without an openssl/https etc service, it's not safely doable
| |
15:22 | <gbaman> Fair enough
| |
15:51 | gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Remote host closed the connection) | |
15:52 | gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com) | |
16:01 | <alkisg> gbaman: if one runs `rpi-update` and gets a newer kernel, how can he get the kernel-headers for that new kernel?
| |
16:09 | gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Ping timeout: 268 seconds) | |
16:38 | gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com) | |
16:38 | gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Remote host closed the connection) | |
16:39 | gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com) | |
17:00 | markit has left IRC (markit!~marco@mail.ammdomus.it, ) | |
17:37 | kvaps has left IRC (kvaps!2e1c6842@wedos.wedos.net, Remote host closed the connection) | |
17:53 | statler has left IRC (statler!~Georg@80.151.99.211, Remote host closed the connection) | |
18:44 | adrianor1 has joined IRC (adrianor1!~adrianorg@179.187.30.233.dynamic.adsl.gvt.net.br) | |
18:47 | adrianorg has left IRC (adrianorg!~adrianorg@191.32.96.65, Ping timeout: 265 seconds) | |
20:27 | yanu has left IRC (yanu!~yanu@178-116-54-5.access.telenet.be, Ping timeout: 265 seconds) | |
21:24 | woernie has left IRC (woernie!~werner@p57A0E783.dip0.t-ipconnect.de, Remote host closed the connection) | |
21:58 | yanu has joined IRC (yanu!~yanu@178-116-54-5.access.telenet.be) | |
22:09 | yanu has left IRC (yanu!~yanu@178-116-54-5.access.telenet.be, Ping timeout: 265 seconds) | |
22:31 | GodFather has joined IRC (GodFather!~rcc@wsip-66-210-242-210.ph.ph.cox.net) | |
23:57 | yanu has joined IRC (yanu!~yanu@178-116-50-13.access.telenet.be) | |