IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 14 April 2019 (all times are UTC)
| 02:40 | BuddyButterfly has left IRC (BuddyButterfly!~BuddyButt@h2216388.stratoserver.net, Ping timeout: 268 seconds) | |
| 02:57 | BuddyButterfly1 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:03 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 09:38 | woernie has joined IRC (woernie!~werner@pD9E8BADB.dip0.t-ipconnect.de) | |
| 09:58 | adrianor1 has joined IRC (adrianor1!~adrianorg@186.213.156.190) | |
| 10:01 | adrianorg has left IRC (adrianorg!~adrianorg@177.134.56.99, Ping timeout: 252 seconds) | |
| 10:12 | ogra_ has left IRC (ogra_!~ogra_@80.152.237.3, Ping timeout: 255 seconds) | |
| 10:13 | ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de) | |
| 12:20 | woernie has left IRC (woernie!~werner@pD9E8BADB.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 15:40 | ZAJDAN has joined IRC (ZAJDAN!~zdenek@77.48.149.75) | |
| 15:41 | ZAJDAN has left IRC (ZAJDAN!~zdenek@77.48.149.75) | |
| 15:41 | ZAJDAN has joined IRC (ZAJDAN!~zdenek@77.48.149.75) | |
| 15:42 | ZAJDAN 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:10 | woernie 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:26 | vagrantc 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:37 | woernie has left IRC (woernie!~werner@pD9E8BADB.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 19:50 | ricotz 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:45 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 21:49 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 21:59 | vagrantc_ has joined IRC (vagrantc_!~vagrant@unaffiliated/vagrantc) | |