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

Request log from specific day:

Channel log from 19 October 2019 (all times are UTC)

05:04	<alkisg> Leolo_2: is centos 6 using systemd?
05:11	Google says it's using sysvinit; so nah; let's keep ltsp19 only for systemd distributions
05:12	But I thought that bcg already had working packages for ltsp5 on centos...
05:17	quinox has left IRC (quinox!~quinox@ghost.qtea.nl, Quit: WeeChat 2.4)
05:19	quinox has joined IRC (quinox!~quinox@ghost.qtea.nl)
06:38	woernie has joined IRC (woernie!~werner@p5B296156.dip0.t-ipconnect.de)
07:04	<alkisg> woernie: did you manage to solve all the issues?
07:14	ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
07:23	adrianor1 has joined IRC (adrianor1!~adrianorg@179.179.75.131)
07:25	adrianorg has left IRC (adrianorg!~adrianorg@177.18.173.66, Ping timeout: 240 seconds)
07:46	Leolo_2 has left IRC (Leolo_2!~fil@184-75-132-167.dr.cgocable.ca, Ping timeout: 240 seconds)
07:52	<bcg> my work is for centos 7, not 6
07:54	<alkisg> Ah they're not compatible? E.g. ltsp5 runs from ubuntu 12.04 to 18.04 without changes...
07:55	<bcg> centos 6 is initd and very old, 7 is systemd.
07:55	<alkisg> OK, ty
07:56	Btw I'm trying to move ltsp.org and epoptes.org to *.github.io sites, if anyone knows jekyll, I'd welcome some initial pointers...
08:58	statler has joined IRC (statler!~Georg@p5B30EE2F.dip0.t-ipconnect.de)
09:38	shored has left IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi, Read error: Connection reset by peer)
09:38	shored has joined IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi)
11:12	shored has left IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi, Read error: Connection reset by peer)
11:13	shored has joined IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi)
11:14	shored has left IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi, Max SendQ exceeded)
11:16	shored has joined IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi)
11:17	shored has left IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi, Client Quit)
11:18	shored has joined IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi)
11:27	ltsp_user35 has joined IRC (ltsp_user35!4fd398fa@p4FD398FA.dip0.t-ipconnect.de)
11:30	ltsp_user35 has left IRC (ltsp_user35!4fd398fa@p4FD398FA.dip0.t-ipconnect.de, Remote host closed the connection)
13:08	ltsp_user57 has joined IRC (ltsp_user57!53371506@6.red-83-55-21.dynamicip.rima-tde.net)
13:09	<ltsp_user57> hi
13:13	ltsp_user57 has left IRC (ltsp_user57!53371506@6.red-83-55-21.dynamicip.rima-tde.net, Remote host closed the connection)
14:25	<alkisg> OK https://epoptes.github.io is starting to be readable; https://ltsp.github.io will follow within the week...
17:05	vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
17:21	<alkisg> vagrantc: the new epoptes site, based on jekyll: https://epoptes.github.io - I will do ltsp.github.io with the same software/theme in a couple of days...
17:29	<vagrantc> alkisg: still looks about the same, but with very wide margins
17:29	:)
17:31	alkisg: so, would it be worth having ltsp19 ship "ltsp-server" instead of "ltsp" which is marked with Provides: "ltsp" ?
17:31	long-term, i think it'd be nicer to just ship ltsp.
17:34	and i'm torn on shipping an ltsp-server metapackage regardless
17:35	but if we'll ship "ltsp-server" as part of ltsp 19.x ... it'd be good to do that on the initial upload so it doesn't get stuck in NEW
17:43	<alkisg> vagrantc: ltsp would be the client package
17:44	So having ltsp-server provide ltsp, sounds a bit strange
17:44	(08:29:46 PM) vagrantc: alkisg: still looks about the same, but with very wide margins ==> the web gurus say it's better that way, people focus on reading narrow columns. Go figure.
17:45	But comparing to the existing ltsp.github.io. it's surely better
17:45	We may ship an ltsp-server metapackage though, unrelated to provides etc
17:49	<vagrantc> alkisg: the provides trick was just to workaround the NEW queue ... but long-term i don't think it's the right way
17:50	e.g. i could upload to experimental today, but would have to rename a bunch of the files in debian/ltsp.* -> debian/ltsp-server.* and update debian/control ... but could probably upload it today instead of waiting
17:50	<alkisg> vagrantc: I mean, if one wants to install ltsp in a chroot, he'd do "apt install ltsp", and he'd see ltsp-server getting installed, and get confused
17:50	(while he'd only want ltsp-client)
17:50	<vagrantc> alkisg: yes, it's not ideal, like i say, it's immediacy vs. correctness :)
17:50	<alkisg> I could prepare a metapackage tomorrow
17:51	<vagrantc> alkisg: but what i'm hearing is you'd rather wait :)
17:52	alkisg: so, ltsp-server metapackage ... then we might have to handle upgrades or something... i guess it coudl just be in README.Debian ...
17:53	existing installs wouldn't be able to have them side-by-side ...
17:53	or NEWS.Debian
17:56	<alkisg> If we ship what you said, they can be installed side-by-side?
17:56	<vagrantc> no
17:57	side-by-side installs would mean ltsp 19.x would have to only ship "ltsp" and not an ltsp-server metapackage ... (sort of)
17:58	the sort of being that any existing installs would probably continue to work, but you'd loose the infrastructure to update old installs ...
17:59	alkisg: if we shipped "ltsp" and ... "ltsp-default-install" with depends and/or recommends set appropriately, it could co-exist with ltsp5
17:59	<alkisg> I think we don't want to bother with automatically upgrading old installs
17:59	<vagrantc> agreed
18:00	basically, what i would prefer moving forward is "ltsp" and a metapackage that is not named "ltsp-server" to avoid conflicting with the existing ltsp-server packages
18:00	not sure what a name for the metapackage should be
18:01	would it be so bad for "ltsp" to recommends all the stuff currently in suggests?
18:01	<alkisg> We'd need an ltsp-client package otherwise
18:02	Currently, the ltsp package contains all the code, but corresponds to the ltsp-client package
18:04	Maybe we could grow an ltsp-server-dnsmasq package, but that would just avoid the installation line, nothing major
18:07	Maybe the best is to just leave it in the new queue... we gain the ability for them to coexist
18:11	In the future, we might actually desire a long installation line... "select one of the following lines, depending on what you want... dnsmasq? isc-dhcp? ipxe? syslinux? grub? etc"
18:12	<vagrantc> i guess it could make default assumptions based on what's installed?
18:12	a little counter to how debian packages generally work
18:13	<alkisg> I don't think packages can do that. Unless if you mean an `ltsp install` line, in which case we don't need an ltsp-server package
18:13	<vagrantc> well, last i looked, it was worth landing in experimental (which is good to do since it's going through NEW anyways)
18:13	so ... tag 19.10 ?
18:13	<alkisg> Sure!
18:13	I'll work on the site for the next days, soI won't be touching the code
18:14	After that, I'll check if it runs on xenial etc, and modify whatever's needed
18:14	<vagrantc> 19.11 is right around the corner anyways :)
18:14	* alkisg likes that versioning scheme
18:14	<alkisg> Also mesa and drm are going to following, and maybe even xorg
18:14	I'll switch epoptes to that too
18:15	<vagrantc> it's one thing ubuntu did that i wish debian would adopt
18:17	<alkisg> Meh multitasking creates the stupidest typos... "following" instead of "follow it"...
18:17	<vagrantc> heh
18:18	alkisg: so you're fine with me tagging? i think there were a few more minor typos i'd like to clean up, but otherwise it seemed ready enough for the NEW queue waiting game
18:19	alkisg: also, is it plausible for you to start doing signed tags?
18:21	<alkisg> vagrantc: sure, go ahead and tag please,
18:22	re: signed tags, no objection at all, I'll just need to read up on how to do that
18:28	<vagrantc> git tag --sign TAG vs. git tag TAG
18:28	and have access to a signing key
18:28	of course :)
18:34	alkisg: i was a bit configused with ltsp image -m in the ltsp-image manpage ... passing mksquashfs arguments requires using spaces ... and it worked fine for me to add spaces ... but the man page warns against using spaces?
18:38	<alkisg> vagrantc: I mean, "dont do this:" ltsp image -m param1 param2, but -m "param1 param2"
18:38	If the explanation is lacking, let's fix it
18:39	shored has left IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi, Read error: Connection reset by peer)
18:39	shored has joined IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi)
18:40	<vagrantc> alkisg: i'll try to update the wording now that it's clear what you mean :)
18:57	alkisg: we should record hashes of the downloaded binaries and check them, at least...
18:57	alkisg: which means keeping copies of all the versions you might ever ship
19:00	alkisg: e.g. https://example.org/downloads/binaries/sha256/asdfasdf1214436.../memtest.0
19:00	<alkisg> vagrantc: that would require us shipping a new ltsp version for each ipxe update
19:00	<vagrantc> alkisg: no, you keep the old ones there
19:01	<alkisg> I mean, if we upload a new ipxe.efi, then the old ltsp doesn't know its hash
19:01	<vagrantc> true
19:01	<alkisg> So a new ltsp is needed before the new ipxe.efi can be used
19:01	<vagrantc> but it also means that someone else can't put arbitrary stuff on that URL
19:01	<alkisg> At which point, it would be better to just include them in the binary
19:01	In the .deb
19:01	<vagrantc> alternately, signed binaries
19:01	can't ship binaries in debian packages that aren't built from source
19:02	but not having any trust path beyond https is ... dubious
19:02	<alkisg> What's microcode?
19:03	<vagrantc> in debian, microcode not build from sources is not in main
19:03	e.g. technically outside of debian
19:03	<alkisg> Btw, we'll be able to avoid all those once debian packages them
19:03	How can we sign/verify binaries?
19:03	Also, npm * is in debian
19:04	And it's downloading things from online, without hashes
19:04	wget too
19:04	<vagrantc> i'm not saying nothing does that, but it's very much frowned upon to download an execute arbitrary code
19:04	with no trust path...
19:05	<alkisg> Why isn't https enough?
19:05	<vagrantc> because certificate authorities that have demonstrated little to no competence are still able to certify all web sites?
19:07	the best way forward is to package what we need ... failing that, ship signed sha256sum files and include the public key ltsp trusts in ltsp and verify the signature on the signing file (or each individual file)
19:08	e.g. checksums.signed includes checksums for the current files, and are signed by a trusted key.
19:08	<alkisg> The initial though was to download them directly from boot.ipxe.org,
19:08	but then I thought I would avoid putting strain on their servers...
19:08	<vagrantc> i balked at it earlier too :)
19:09	<alkisg> OK I guess we can include a public signature
19:09	<vagrantc> so, i'd still be willing to push to experimental without that, but i wouldn't want it to move to unstable/testing/stable in Debian
19:10	alkisg: what exactly is needed to package it?
19:10	alkisg: some custom ipxe? memtest86*?
19:10	<alkisg> And the ltsp developers would keep the private key a secret? Or would I be the only one that would have it?
19:11	<vagrantc> alkisg: alternately, you have a keyring for validity ... e.g. my key, your key, etc.
19:11	<alkisg> vagrantc: afaik, we'd just need to uncomment a few lines in the debian ipxe package
19:11	<vagrantc> alkisg: the memtest stuff seems like optional features, but ipxe seems kind of fundamental :)
19:11	<alkisg> And include the targets in the deb, of course
19:12	We could also use /boot/memtest86+.bin, but it's less compatible, and it doesn't allow getting back to the menu with Esc
19:12	And I guess all distributions would need to do those changes too; not sure if ipxe is there in centos or fedora
19:13	And, we wouldn't be able to ship newer ipxe's outside of the distribution channels; that's not too bad I guess, we can tell users to manually download newer versions if they need them
19:14	Also, I'm not sure that ipxe for x86 would be there in non-x86 architectures
19:14	Or grub.signed, if we implement that
19:15	<vagrantc> yeah, not sure what architectures ipxe supports
19:15	<alkisg> So I'd have a hard time making a raspberry an ltsp server for x86 clients
19:15	<vagrantc> with debian and family, you can use multi-arch to get cross-architecture dependencies
19:16	well, not dependencies exactly...
19:16	requires more sysadmin work, but you're talking about cross-architecture servers, so ...
19:16	<alkisg> Additionally, if I wanted to boot ubuntu from debian, with secure boot on... I'd have a hard time getting grub.signed from ubuntu, installed on debian
19:17	I would be much easier if we just used signatures
19:17	<vagrantc> fair enough
19:18	since it's a number of fairly small binaries, might be best to just sign them directly, too
19:18	skips the complication of a signed checksum file (and potential security mistakes)
19:19	still not immune to downgrade attacks ... but we can only do so much :)
19:19	<alkisg> Not sure how to "sign binaries"...
19:19	They're not elf
19:19	<vagrantc> you can just sign arbitrary data with gpg
19:20	<alkisg> And is it still bootable?
19:20	<vagrantc> no, you'll need to extract the binary from the signed result, or used detached signatures
19:20	<alkisg> ...or a checksum file? :)
19:21	<vagrantc> same problem, with an added layer of indirection
19:21	<alkisg> I think the code would be simpler... but I don't mind with whatever we can do in shell
19:23	<vagrantc> gpg --sign FILE # produces FILE.gpg
19:23	gpg -d FILE.gpg > FILENEW
19:23	sha256sum FILE FILENEW
19:23	the latter just to verify proof that they match
19:24	<alkisg> OK but people can't just wget them if they want
19:24	They'll need to know that dance
19:25	With a separate file, it might be easier for the users to select arbitrary files from history versions
19:26	<vagrantc> you mean a checksum file?
19:27	the dance should be implemented in the ltsp tool, no?
19:27	<alkisg> Well someone might want to get ipxe.efi to put it in his boot partition
19:27	Or, get ipxe.efi from upstream
19:27	It would be confusing to have to un-gpg them
19:28	I do like to keep things as simple as possible for the users... if possible...
19:28	As not all of them are sysadmins; some are teachers and have never heard of gpg
19:28	<vagrantc> which is why the "ltsp" tool should handle it for them?
19:29	<alkisg> There's no ltsp tool in a standalone pc where the user would want to download ipxe.efi
19:29	<vagrantc> and then they just copy ipxe.efi from where the tool downloaded it to?
19:29	<alkisg> Hmm
19:29	<vagrantc> isn't that outside the scope of "ltsp" then?
19:29	<alkisg> I don't know it sounds complicated
19:29	Is it insecure to use a separate file?
19:29	<vagrantc> e.g. they either have "ltsp" and they use the tool, or they do things manually
19:30	<alkisg> "what is ipxe.efi.signed?" - I'm trying to avoid hearing that question from users
19:30	<vagrantc> alkisg: there have been some historic mistakes around signing data, and i think my simple example even implemented some of those mistakes :)
19:30	<alkisg> Like ubuntu-live.iso.signed; they avoided that
19:31	<vagrantc> alkisg: you can have both copies of the file present ... signed and unsigned ... and maybe even in a separate directory ... but the tool should handle it securely.
19:31	well... "securely" :)
19:32	alkisg: anyways, happy to postpone this till after ltsp gets through NEW
19:32	<alkisg> OK, great. I don't mind the separate signatures/checksums file, but I don't like the ipxe.efi.signed idea...
19:33	<vagrantc> is there a developer TODO file somewhere? or i guess i file an issue
19:34	<alkisg> I think I had a TODO in the wiki, and then I deleted it in favor of issues
19:34	<vagrantc> makes sense
19:36	so then it comes down to: sha256sum * > checksums.sha256 && gpg --detach-sign checksums.sha256
19:37	(or sha512, or some other reasonably secure checksum tool)
19:37	<alkisg> Nice
19:37	And we'd ship our keyrings in the ltsp package
19:38	<vagrantc> and then wget https://..../checksums.sha256 https://..../checksums.sha256.gpg && gpgv --keyring path/to/keyring.gpg checksums.sha256.gpg && sha256sum -c checksums.sha256 .... i think
19:38	could also do clearsigned checksums files, but that has had some security problems in the past, but it would also mean a single file.
19:40	see https://deb.debian.org/debian/dists/buster/InRelease vs. https://deb.debian.org/debian/dists/buster/Release.gpg + Release
19:41	those are more complicated examples than just using sha256sum ...
19:41	shored has left IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi, Read error: Connection reset by peer)
19:41	shored has joined IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi)
19:42	<vagrantc> but they illustrate the differences ... tricky part is if someone man-in-the-middles InRelease and appends stuff to it
19:42	the output of gpg hasn't exactly been always correct in that case
19:42	<alkisg> Ouch; that sounds.... like a bug in gpg?!
19:43	Shouldn't it just say "this messaged has been tampered with?"
19:43	<vagrantc> sort of
19:43	<alkisg> *message/content/whatever
19:43	<vagrantc> it's complicated :)
19:43	<alkisg> Also, maybe we could just check our https certificate?
19:44	(ourselves, instead of leaving it just up to wget)
19:44	<vagrantc> like against a specific certificate authority?
19:44	<alkisg> Against our own certificate file in ltsp.deb
19:44	<vagrantc> i treat https as either the belt or suspenders, but if you really need to hold pants up, use both :)
19:45	shored has left IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi, Read error: Connection reset by peer)
19:45	shored has joined IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi)
19:46	<vagrantc> i think https actually helped against the InRelease attack actually, even with self-signed certs ... but that's a whole different story
19:47	alkisg: so, there are a variety of options
19:47	i'll file an issue
19:47	<alkisg> E.g. I see `wget --ca-certificate=file`, not sure if it's safe enough if we just provide that file
19:51	<vagrantc> github might change which ca they use, and break ltsp until we figure out what they changed to
19:51	and figure out weather the change was legitimate
19:52	this is why i would prefer to just blindly trust the certificate authorities and also provide another independent signed checksum mechanism for the files
19:52	where we have more control over the signing keys
19:54	well, blindly trust, as pretty much all web browsers blindly trust
19:55	i guess there's some support for pinning... but that's probably a lot harder than just shipping signed checksum files
19:59	hrm. can't find the typo i found earlier ... found a new one though... time to tag and upload, i guess
20:06	woernie has left IRC (woernie!~werner@p5B296156.dip0.t-ipconnect.de, Remote host closed the connection)
20:33	<vagrantc> alkisg: uploaded to experimental/NEW ... now to wait...
20:33	unless i messed something up
20:36	<alkisg> Yey!
20:37	vagrantc: so now we're waiting for the ftp masters to review?
20:38	And if it migrates to testing, will ltsp5 be removed from testing?
20:39	(if so, I should do a last upload to the ltsp5 ppa)
20:40	<vagrantc> alkisg: the way it's currently packaged, they coexist without issues
20:40	at least, i think they can coexist
20:40	oh, but...
20:40	<alkisg> vagrantc: isn't it a problem if they both have source:ltsp?
20:40	<vagrantc> oh, but will need to upload an ltsp5 source package at some point.
20:40	yeah, exactly
20:41	<alkisg> Do we want that? To maintain ltsp5 for another... 10 years or so?
20:41	<vagrantc> no, i don't
20:41	<alkisg> Maybe we can just omit the ltsp5 package then, and just point users that need it to a ppa
20:42	<vagrantc> so it can't exist in the archive, but they could, for example, install the ltsp 5.x packages from buster on a bullseye system, or install the new ltsp 19.x packages from buster-backports when they land
20:42	<alkisg> Sounds fine to me
20:42	Also, I like the ability to boot the same chroot/vm either in ltsp5 or in ltsp19 mode
20:43	<vagrantc> this rewrite seems much easier to maintain and develop :)
20:43	<alkisg> I think that if someone spends a week and ports it to fedora/opensuse etc, it'll be very easy to maintain it for many distributions too
20:44	<vagrantc> i couldn't come up with a better name, but ltsp-next was kind of a silly name for the initramfs-tools hook :)
20:44	<alkisg> E.g. I don't need to have a fedora server to test; just a fedora vm or iso, to test the client side
20:44	<vagrantc> yes, that part is amazing :)
20:44	very excited about the future
20:44	<alkisg> I think some new users arrived too; let's see
20:45	<vagrantc> maybe i should actually set up some LTSP stuff on the local network :)
20:45	so i actually use it :)
20:45	then again ... it probably wouldn't change much
20:47	<alkisg> I need to remember to pull, then push so that it goes to the launchpad mirror, THEN build the recipe...
20:47	Building, let's see if it succeeds in xenial... https://code.launchpad.net/~ltsp/+recipe/ltsp-proposed
20:48	<vagrantc> can't launchpad just mirror github?
20:48	<alkisg> It can, with a 4 hours delay or so
20:48	And with occasional hiccups
20:49	So I prefer to just have two push targets
20:51	<vagrantc> ah
20:52	and the launchpad mirrors aren't pushable, i presume
20:54	<alkisg> If they're automatic mirrors, then no; so I always do it manually
20:58	<vagrantc> there are probably some github features that could be used instead...
20:58	but that probably requires more work for the moment :)
20:59	https://github.com/features/actions
21:45	<alkisg> vagrantc: is it possible to upload epoptes to buster with just a url change?
21:46	epoptes.org is expiring in a couple of days, so we move to epoptes.github.io
21:46	ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
21:50	* alkisg reads https://www.debian.org/doc/manuals/developers-reference/ch05.html#upload-stable ...
22:04	<vagrantc> alkisg: not likely...