|00:24||vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)|
|02:48||adrianorg has joined IRC (email@example.com)|
|02:51||adrianor1 has left IRC (firstname.lastname@example.org, Ping timeout: 258 seconds)|
|05:23||kjackal has joined IRC (kjackal!~quassel@2a02:587:3106:1000:a895:839f:87b0:61d8)|
|06:04||kjackal has left IRC (kjackal!~quassel@2a02:587:3106:1000:a895:839f:87b0:61d8, Ping timeout: 258 seconds)|
|06:25||kjackal has joined IRC (email@example.com)|
|08:17||woernie has joined IRC (woernie!~werner@p57A0E866.dip0.t-ipconnect.de)|
|10:14||profe01 has joined IRC (profe01!d500570e@gateway/web/freenode/ip.18.104.22.168)|
|10:32||kjackal has left IRC (firstname.lastname@example.org, Ping timeout: 244 seconds)|
|10:47||kjackal has joined IRC (kjackal!~quassel@2a02:587:3106:1000:a895:839f:87b0:61d8)|
|12:57||bengoa has left IRC (email@example.com, Quit: Leaving)|
|12:58||bengoa has joined IRC (firstname.lastname@example.org)|
|12:58||bengoa has left IRC (email@example.com)|
|12:58||bengoa has joined IRC (firstname.lastname@example.org)|
|13:07||Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)|
|13:29||mgariepy has left IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy, Quit: Leaving)|
|14:12||adrianor1 has joined IRC (email@example.com)|
|14:14||adrianorg has left IRC (firstname.lastname@example.org, Ping timeout: 248 seconds)|
|14:39||GodFather has joined IRC (GodFatheremail@example.com)|
|15:47||vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)|
|16:24||mgariepy has joined IRC (mgariepy!~mgariepy@ubuntu/member/mgariepy)|
|17:11||kjackal has left IRC (kjackal!~quassel@2a02:587:3106:1000:a895:839f:87b0:61d8, Ping timeout: 252 seconds)|
|17:15||woernie has left IRC (woernie!~werner@p57A0E866.dip0.t-ipconnect.de, Ping timeout: 248 seconds)|
|17:15||woernie has joined IRC (woernie!~werner@p57A0E866.dip0.t-ipconnect.de)|
|17:57||kjackal has joined IRC (firstname.lastname@example.org)|
Heh, I installed debian in a laptop, went to a trip, whoops, firmware missing for the wifi card. Meh, thankfully I also had windows to download the .deb :D
Which of those sound better? ltsp-kernel, ltsp-image, ltsp-initrd, ltsp-config... or ltsp kernel, ltsp image, ltsp initrd, ltsp config?
And, /etc/ltsp/client.conf (previously lts.conf) or /etc/ltsp/ltsp-client.conf? I can't say I like that extra ltsp- there, even though the man page should be man 5 ltsp-client, I guess...
*man 5 ltsp-client.conf
so there'd be an 'ltsp' executable that you pass commands to?
I already support both of those methods; it's just a question for packaging at this point, what users would prefer
not sure I care from an end user standpoint for the first part... for the second one, the extra ltsp- seems pointless
(for the conf)
/etc/ltsp/client.conf seems fine
Great, i like that answer, ty :)
alkisg: if we manage to ship commandline completions that handle the subcommands, then "ltsp" seems better.
and even without, then it can be on a TODO list to ship the commandline completions ...
vagrantc: would the users know to `man ltsp-kernel` for ltsp kernel?
alkisg: git manages to make "man git commit" work as expected
commandline completions again
or rather, not as expected, but as useful :)
|18:28||* vagrantc was quite surprised|
Great then, less packaging work, we won't have to ship the /usr/sbin/ltsp-kernel => /usr/share/ltsp/ltsp.sh symlinks :)
I even made ltsp-initrd-bottom work that way, as an "ltsp applet"...
ltsp.sh sources all generic functions, then the applet, along with vendor/user overrides etc, so the final applet code is minimal
E.g. this is ltsp-initrd, which creates ltsp.img: https://github.com/eellak/gsoc2019-ltsp/blob/master/ltsp/applets/initrd/55-initrd.sh
Btw, ltsp config dnsmasq --options will need 3 words, but I guess that's ok too
alkisg: this is just creating the stuff appended to the initrd, not the whole initrd?
Right, we don't touch the original initrd
so it's really not creating an initrd... not a big deal, but a bit of a mental disconnect for me
vagrantc: ehm, how so? It's a .cpio.gz file, an additional initrd, that is added to the file system that the client sees
alkisg: in my mind, an initrd is a complete initrd ... this is more of an initrd add-on.
alkisg: like i said, not a big deal
but someone might get the idea they only have to pass that part of the initrd or something...
The client init ram disk is comprised from 2 cpios; one the stock one, one the ltsp and the user code
right, i get that
Oh, he'd have to run ltsp config ipxe or something, it wouldn't be adviceable to try a simple pxelinux etc
it's not a technical disconnect, it's more of a mental image about what "ltsp initrd" generates.
So as to make it work with uefi and all
Any better name for it? ltsp client?
not really, hence not a big deal and documentation can solve it
As it zips the client code into that additional initrd?
Btw, ltsp-update-kernels (and update-kernels) created pxelinux and all,
now we need ipxe.efi, ipxe.lkrn, boot.ipxe, grub.efi etc, things that usually are created once, then the user may manually edit boot.ipxe,
...does that sound like an "ltsp config ipxe" command, or a separate "ltsp ipxe" or "ltsp tftp --ipxe" command?
It might be possible to use just syslinux or just grub in the future, but the initial version will use ipxe (+grub only for booting 32bit clients under uefi)
from what you mentioned, grub.efi is the only thing that makes "ltsp config ipxe" not quite make sense
and memtest, and whatever else we might want to put there as the default;
while the user then can manually add entries for netbooting cds or whatever, by reading the wiki
that grub is just a helper for ipxe, it doesn't get a real menu
alkisg: i'm leaning towards "ltsp config ipxe" given that it's primarily setting up ipxe related files
Thanks; I was thinking that all the other ltsp-config commands create configuration files for the server, while this messes with TFTP, like ltsp-initrd, ltsp-kernel etc, so ltsp tftp or something sounded a bit better to me... but just a bit
it's kind of a coin toss, really
except when you start thinking about https boot
then ltsp tftp ... well ... :)
Well, ipxe will always be downloaded via tftp
The kernel/initrd is another thing
yeah, those are all the things that spring to mind on the matter :)
man ltsp kernel ==> works, yey
nice to get it "right" on the first go, but also sometimes just have to pick something and run with it :)
I think I switched from 'ltsp kernel' to 'ltsp-kernel' to sourcing, to executing... about 6 times so far :D
I think I got the best version now; I'm _almost_ sure :P
vagrantc: ubuntu lts releases sync from testing, afaik; IF ltsp19 is ready, when can it be uploaded to testing, wrt buster release schedule etc?
btw, another idea would be to drop `ltsp config service`, in favor of ltsp service... ltsp dnsmasq, ltsp isc-dhcp-server, ltsp nfs-server...
|18:58||mads2 has joined IRC (email@example.com)|
Then it's surely ltsp ipxe :D
And I think to simplify things, an `ltsp pnp` command may help, that autodetects what's missing and gets everything ready
Ah and we'll need an ltsp migrate command too, to help in cleaning up configuration files etc
|19:14||spaced0ut has left IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut, Remote host closed the connection)|
alkisg: it depends on how long we want to keep ltsp5 around - do we want co-installable packages in the archive, etc.
|20:45||adrianorg has joined IRC (firstname.lastname@example.org)|
|20:46||adrianor1 has left IRC (email@example.com, Ping timeout: 258 seconds)|
|20:49||Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)|
|20:57||woernie has left IRC (woernie!~werner@p57A0E866.dip0.t-ipconnect.de, Remote host closed the connection)|
|22:33||pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 258 seconds)|
|23:42||pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme)|