IRC chat logs for #ltsp on irc.libera.chat (webchat)


Channel log from 14 April 2019   (all times are UTC)

02:40BuddyButterfly has left IRC (BuddyButterfly!~BuddyButt@h2216388.stratoserver.net, Ping timeout: 268 seconds)
02:57BuddyButterfly1 has joined IRC (BuddyButterfly1!~BuddyButt@h2216388.stratoserver.net)
07:39
<alkisg>
I'm thinking of allowing only one $TFTP/ltsp/lts.conf in ltsp6, does anyone need two or more lts.conf?
07:45
(I mean, $TFTP/ltsp/$ARCH/lts.conf, different ones per each ARCH)
08:03ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
09:38woernie has joined IRC (woernie!~werner@pD9E8BADB.dip0.t-ipconnect.de)
09:58adrianor1 has joined IRC (adrianor1!~adrianorg@186.213.156.190)
10:01adrianorg has left IRC (adrianorg!~adrianorg@177.134.56.99, Ping timeout: 252 seconds)
10:12ogra_ has left IRC (ogra_!~ogra_@80.152.237.3, Ping timeout: 255 seconds)
10:13ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
12:20woernie has left IRC (woernie!~werner@pD9E8BADB.dip0.t-ipconnect.de, Remote host closed the connection)
15:40ZAJDAN has joined IRC (ZAJDAN!~zdenek@77.48.149.75)
15:41ZAJDAN has left IRC (ZAJDAN!~zdenek@77.48.149.75)
15:41ZAJDAN has joined IRC (ZAJDAN!~zdenek@77.48.149.75)
15:42ZAJDAN has joined IRC (ZAJDAN!~zdenek@77.48.149.75)
15:44
<ZAJDAN>
Alkisg: last time very often Epoptes displays pop-ups (client disconnected, connected), but actually the clients still runs
16:15
<alkisg>
ZAJDAN: that can happen if the client spends all its cpu, and fails to send the thumbnail 3 times
17:06
<ZAJDAN>
aha
17:08
could help reboot the clients?
17:10woernie has joined IRC (woernie!~werner@pD9E8BADB.dip0.t-ipconnect.de)
17:15
<alkisg>
ZAJDAN: thin or fat? cpu/ram?
17:37
<ZAJDAN>
thin(Celeron-900Mhz-512MB Ram)
18:07
<alkisg>
It's also possible that the thumbshots fail due to network being overloaded, e.g. if many users watching videos etc
18:26vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
18:38
<alkisg>
vagrantc: heya, could you give me your thoughts on a couple of design choices I'm thinking to make?
18:38
1) Only one kernel will be copied from images, and it will be copied to $TFTP/ltsp/imagename/vmlinuz and initrd.img. This will make boot.ipxe (moving to ipxe instead of pxelinux) a whole lot more readable/easily editable. If someone wants more kernels he'd need to copy them manually.
18:38
2) lts.conf will live in /etc/ltsp/lts.conf, and get to $TFTP/ltsp/ltsp.img via `ltsp-update-tftp`. ltsp.img will be the additional initramfs image that will contain the initramfs code, lts.conf, sshkeys etc. We'll only have one lts.conf/ltsp.img for all chroots.
18:41
Also... what's a good english word to use instead of "chroot" now that we'll mostly be using VMs? Xen uses "domain", while virtualbox uses "image"... I think domain can also mean "directory", e.g. if someone creates a chroot with debootstrap, he can still use it with ltsp6, but "image" sounds a bit better to my ears...
18:41
<vagrantc>
alkisg: it becomes more opaque which vmlinuz/initrd it actually is
18:41
alkisg: often times people think they're booting one kernel when they're actually booting another...
18:41
<alkisg>
You can see the kernel version with `file path/to/vmlinuz`
18:41
<vagrantc>
alkisg: it's just a symlink?
18:42
<alkisg>
No, it gets copied from e.g. ubuntu.vmdk/boot/vmlinuz-4.15 to TFTP/ltsp/i386/vmlinuz
18:42
This keeps the TFTP veeery clean. Only one kernel/initrd per chroot, no other files at all
18:43
<vagrantc>
so it would be possible for ubuntu.vmdk/boot/vmlinuz-4.16 to exist, but TFTP/ltsp/i386/vmlinuz to be the stale -4.15
18:43
<alkisg>
Well, ltsp-update-image would copy the latest kernel, when it would mksquashfs the image to /opt/ltsp/images
18:43
<vagrantc>
sure
18:44
<alkisg>
And, we can show a warning if the user boots with a kernel that doesn't match /lib/modules/<dir>
18:45
<vagrantc>
i do like to be able to boot an older kernel version, but the code complexity might not be worth it
18:45
<alkisg>
Note that with uefi, the boot.ipxe is more complex, e.g. 40 lines. If we want to add multiple kernels there, it won't be manageable anymore
18:45
(my current boot.ipxe automatically supports 32/64bit, and bios/uefi)
18:45
<vagrantc>
so now we need to learn a whole new programming language? :)
18:46
<alkisg>
Hehe
18:46
I moved the complexity from dnsmasq.conf to ipxe, as it works with proxydhcp as well
18:46
<vagrantc>
and while i know it's also not the primary target, curious how it would affect, say, arm LTSP environments
18:46
<alkisg>
While dnsmasq can only do fancy things with real dhcp
18:46
ARM would go to a different dir under $TFTP
18:47
E.g. raspberries need their code under $TFTP root dir, they don't even support subfolders there
18:47
<vagrantc>
regarding point 2 ... i've occasionally had environments where different lts.conf per chroot was desireable, but probably nothing that couldn't be better handled by customizations in the lts.conf itself
18:47
<alkisg>
Great
18:47
<vagrantc>
alkisg: raspberry pi are the most unusual case for ARM
18:48
despite rpi popularity
18:48
<alkisg>
I would like some design input there if you can spare the time, once I have an initial release
18:49
<vagrantc>
yeah, the ARM code needs to be totally revamped
18:49
<alkisg>
(I don't have any arm boards)
18:49
I.e. I'd show you the current dnsmasq/boot.ipxe/ltsp-config etc, and you'd tell me "modify those things to support ARM better"
18:49
<vagrantc>
alkisg: though i was thinking we should switch to using pxelinux.cfg files for ARM ... but that obviously seems at odds with your current direction
18:49
<alkisg>
pxelinux doesn't support uefi well
18:49
So it's a no-go
18:50
<vagrantc>
ARM is basically just a mess ... there are EFI capable arm boards, and modern u-boot has EFI implementations, but not necessarily complete
18:50
<alkisg>
You may use a pxelinux folder for arm though; e.g. I'm also using grub.efi to boot 32bit kernels under 64bit uefi
18:51
<vagrantc>
i've found grub's network boot support to be verrry slowwwwww
18:51
<alkisg>
So `ltsp-config tftp` can generate the appropriate folders for arm too; they don't need to share the boot.ipxe configuration file
18:51
That's grub over ipxe
18:51
(or over pxe stack)
18:51
It's fine that way
18:51
<vagrantc>
maybe on x86
18:51
<alkisg>
And I *only* use it for that specific case, which noone else suports
18:51
E.g. ipxe or uefi can't boot 32bit kernels
18:52
(on 64bit uefi booted machines)
18:52
<vagrantc>
and as to changing terminology away from "chroot" ... "image" tends, in my mind, to mean an actual disk image or soemthing ... so generate the image from the image starts to get weird
18:52
<alkisg>
Generate the export?
18:52
Most ltsp6 users will be maintaining VMs
18:53
<vagrantc>
image does seem like the most generic term for soemthing ... it can be the image of an installed os, the image of a virtual machine, the image of LTSP ...
18:53
<alkisg>
So imaging a debian VM called i386.vmdk, and an ubuntu VM called amd64.vmdk
18:53
In that case, they'd run `ltsp-update-image /path/to/i386.vmdk`
18:53
And it would generate /opt/ltsp/images/i386.img
18:53
<vagrantc>
no "ltsp-update-image /" ?
18:54
<alkisg>
Sure, / and chroots will be supported too
18:54
<vagrantc>
ok, so nothing really changing there, per se
18:54
<alkisg>
But the main use case will be to use VMs, as they're so much easier to maintain than chroots
18:54
So the wording should be selected with that in mind
18:54
(my schools will still prefer ltsp-update-image -c /)
18:56
Finally, about the process, I'll start with a clean tree, and import any ltsp* code I need, and initially also have ldm installed
18:56
while dropping ltsp-build-client, ltspfs, remote/localapps etc
18:57
altlinux code, everything dropped initially
18:57
When it's ready, bcg can import the fedora code he'll need; but he'll need to review most of it as it'll be very changed architecture
18:58
E.g. init-ltsp.d will be part of the ltsp.img initramfs code now
18:58
So as to allow booting .isos or other images that don't even have ltsp-client installed
18:58
<vagrantc>
i do like shoving everything into the initramfs
18:58
<alkisg>
Great :)
18:58
<vagrantc>
which is kind of funny, as we used to do more in the initramfs
18:58
<alkisg>
Not exactly
18:59
We had our own code to replace the "upstream" nbd code
18:59
<vagrantc>
we moved some code out of the initramfs into init-ltsp.d
18:59
<alkisg>
And we dropped that part
18:59
While the init-ltsp.d was mostly in ltsp-build-client previously
18:59
<vagrantc>
it came from all over :)
18:59
<alkisg>
True
19:00
But I think it's clearer now; init-ltsp.d = dynamic changes that allow chrootless setups
19:00
Putting init-ltsp.d to initramfs now isn't really a big change
19:00
We can even copy it and chroot /rootmnt run it from the initramfs
19:00
<vagrantc>
what i really like about moving more into the initramfs ... is it makes it plausible to have nothing ltsp-specific in the image
19:00
<alkisg>
Right, that's what I have in mind
19:01
Ideally, when e.g. libpam-sshauth or something is preinstalled everywhere,
19:01
we can boot any distro/image/iso with no modifications, as init-ltsp.d is just interpreted code, not compiled
19:02
So `ltsp-update-image ubuntu.iso` will be a good way to start :D
19:03
OK nice so I think we don't have any major disagreements there, I'm in the right track!
19:06
Ah, about the man pages... is it acceptable for `ltsp-tool --help` to `exec man ltsp-tool`? If yes, we can use markdown as our documentation source; if not, we'll use the `usage` function of the scripts, plus help2man, as we do now
19:08
<vagrantc>
will there also be -h that generates a summary?
19:08
i find tools that *only* have documentation has manpages to be annoying ...
19:08
<alkisg>
We can't generate a summary, we'd need to write it
19:09
I mean, we can convert the markdown to a non-man page, but what's the point in that, it wouldn't be any shorter
19:10
OK, let's keep the usage in the source code then
19:10
as the source of the manpages
19:10
Also... I'd like it if /usr/sbin/ltsp-update-kernels was a symlink to /usr/share/ltsp/ltsp-update-kernels.sh. I.e. shell scripts under /usr/share/ltsp would have an extension, while "binaries"==symlinks wouldn't. Is that OK?
19:11
(it's also about organization, I would love to see debian packaging at some point rely on one dir + symlinks, it feels a bit better to me...)
19:12
<vagrantc>
that seems overly complicated
19:12
i mean, the symlink to another file in a directory
19:12
why not have it call the right things in the first place?
19:13
<alkisg>
Let's see the source:
19:13
<vagrantc>
ah, so you can just copy the whole directory tree in the packaging?
19:13
<alkisg>
In my case: everything in src/, copied to /usr/share/ltsp, then debian/rules symlinks
19:13
In your case: in the source tree, things can't be in a single dir, as they need to be moved around
19:13
So they need to be outside the dir that will get copied to /usr/share/ltsp
19:13* vagrantc suspects in other distros /usr/libexec might be more appropriate than /usr/share ...
19:14
<alkisg>
Sure, wherever the distro wants to copy the main dir, no problem there
19:14
They'd just do the symlinks from their installer/rules/setup/flatpak/whatever
19:14
<vagrantc>
i see what you're saying, though, sure
19:15
though i prefer not to use .EXTENSION at all... :)
19:15
<alkisg>
If there's no objection, I'd prefer it that way, it feels much better to me
19:15
You'd not using gedit :D
19:15
<vagrantc>
yes, i use editors that know what syntax highlighting to use based on what's actually in the file.
19:15
<alkisg>
I do like extensions. I don't like them in commands. So that method with symlinks gives the best of both worlds, I think
19:16
<vagrantc>
it's at least a workable compromise :)
19:16
<alkisg>
Yey, we agreed on 5 out of 5, is it my idea or are you getting softer? :P :D
19:18
Do we need irclogs? We could have a bot periodically push it to a github repository if needed, but if we'll be maintaining the wiki, I'm not sure we'll need them...
19:18
(I'm trying to avoid the need for a .php server)
19:19
(also, much of the support will move to the github issues instead of the mailing list)
19:19
(which are also linkable, hence irclogs more and more worthless)
19:23
<vagrantc>
alkisg: so you managed to make contact with the right people to move the web page?
19:23
if we're doing a good job of documentation, then yeah, irc logs shouldn't be necessary
19:24
<alkisg>
vagrantc: yes, I did manage to contact Jim, which contacted Ron
19:24
They both said OK,
19:24
<vagrantc>
great!
19:25
<alkisg>
the plan is for me to implement some initial ltsp6 first, then write a few pages on github, then move ltsp.org there, either as a CNAME or as an http redirect, if it's going to go away
19:25
I think that'll happen this September
19:26
<vagrantc>
so the changes you're working on now ... is it stuff you intend to just do a major update on existing code, or still trhowing away all the old code and merging back in selectively where needed?
19:27
<alkisg>
Throwing away all the old code and start from a clean tree with no history, but since it'll still be ltsp, I'll keep what code I can
19:27
<vagrantc>
it's about time for a fresh start :)
19:27
<alkisg>
No compiled code though in ltsp, only in ldm, as long as we still need ldm
19:28
I'm not sure if I'll have enough time to replace ldm with something pam based in this summer, or if it'll have to wait for ltsp7
19:28
But at least the code will receive a major reboot
19:29
About the migration path... the won't be. Only ltsp-config remove-ltsp5
19:29
...which will move $TFTP/dirs to some backup dir etc etc
19:30
I'll document all the new directives supported that the new lts.conf will support, but the users will need to basically rewrite it, manually importing the bits that are the same
19:31
About the versioning, you still prefer ltsp 6.year.month? Or just ltsp year.month now?
19:32
<vagrantc>
not sure
19:33
keeping 6/7/etc allows to at least conceptually keep the same ... generation/paradigms
19:33
but it might not really be ... honest? sometimes we've made pretty major changes
19:33
<alkisg>
I like the gnu style of major.minor.revision, i like the date style of year.month.revision.. but mixing them feels kind of weird
19:35
<vagrantc>
i'm partial to including date somehow ... so if you don't want to mix them, i guess i'd suggest just moving to date-based versions
19:35
<alkisg>
Also, since ltsp is a bit like distributions, in that it depends a lot on changes on other software (e.g. systemd changes? ltsp needs to change too)... having the date instead of major.minor may be a bit more fitting
19:36
Nice, let's move to dates then
19:36
<vagrantc>
i also like that we'll at least know what year we're talking about when they give us a partial version string
19:36
<alkisg>
Yeah I need to look up what ltsp 5.5.9 menas
19:36
means
19:36
<vagrantc>
not that i know exactly which features ... but is it ltsp from 2007, or 2018? that sort of thing becomes immediately obvious
19:37
easier to know how far back to dig
19:37woernie has left IRC (woernie!~werner@pD9E8BADB.dip0.t-ipconnect.de, Remote host closed the connection)
19:50ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Remote host closed the connection)
19:54
<quinox>
and don't start giving releases nicknames!
19:54* quinox looks angry at Ubuntu with their animal nicknames... how am I supposed to know what year the panda was from
20:01
<alkisg>
Haha... true, I wouldn't mind having 18.04 in my apt sources.list instead of bionic :)
20:02
And the best would come when dpkg --compare-versions would consider 01 BIGGER than 99, so that our 2101 users would safely update their ltsp :D
20:06* alkisg needs to update the gsoc proposal to "designing and implementing ltsp19" then :P
20:23
<alkisg>
(although to be honest, ltsp19 should to be named "quality quinox" or something, to reflect his contributions!)
20:27
<quinox>
lol
20:38
<vagrantc>
alkisg: well, you could simply add the millenia digits at that point :)
21:45vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
21:49vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
21:59vagrantc_ has joined IRC (vagrantc_!~vagrant@unaffiliated/vagrantc)