Re: Testers required: PXE boot Slackware installers from slackware.org.uk

On 07/26/2014 08:00 PM Darren Austin wrote:
> On Sat, 26 Jul 2014, Bengt Richter wrote:
>> Why not supply a tarball and some instructions for testing between a tester's
>> boxes on his internal network? And discuss the security aspects, so people
>> don't set themselves up for having their boxes reflashed by men in the middle
>> who then chain to the intended boot file without your noticing?
>
> That would utterly defeat the purpose of having an external server host the
> boot files.
>
> The point is that people *don't* need anything locally in order to install
> Slackware - not that they download a tar, extract it somewhere and install
> from that.  There are already options in Slackware for that - check out the
> usb-and-pxe-installers/ directory on a mirror :)
>
Sorry, I guess I was reacting to the subject line "Testers required" thinking,
"Ok, so I'd be booting needs-testing software directly from the internet --
  what could possibly go wrong?" ;-)

Presumably you've tested locally yourself, to where you feel it's pretty solid.
If by "testing" you mean try it once, that's one thing, but IME *testing* involves
doing it over and over to trap a bug, and I'd sure rather do it over the reliable
gigabit ethernet via router between my local boxes, having one of them serve
the boot images, than try it via the same router to the internet (through the slow
mobile broadband usb stick my router gets me out on in my situation here).
And it's not cheap. If I had unlimited fiber or a univerity dorm unlimited ethernet,
or such, maybe repeat tests would be thinkable.

But you want mainly user experience feedback, not debugging help, I take it?

> If they can or want to download stuff locally, there is obviously better
> options available.
>
So what are the really viable use-cases?

I guess at a LUG install fest configuring a gigabit router and a laptop with
SSD disk as a server would be faster than installers on USB2, or DVD, except
that the latter can be cloned and operate in parallel by handing them out.
And USB3 is pretty fast if your box has it.

What about installing into a remote virtual machine? Will that work?
Seems like that could be handy.

>> Well, at least you'll separate the trusting from the paranoids ;-)
>
> While TFTP doesn't allow you to obtain directory listings (so you can't
> browse the server like you would with FTP), you can download the pxelinux
> default config (the file required is /pxelinux.cfg/default), find out
> exactly what kernels and initrds are downloaded from the server, download
> those and check their md5sums against a mirror you trust.
>
> There is complete transparancy in terms of being able to verify that what
> you are downloading is actually unmodified Slackware kernels and initrds.
>
> As I mentioned in my first message, this is about making access to Slackware
> easier for people.. not trying to worry them about exceptionally unlikely
> (and probably quite impossible without LAN access) man in the middle
> attacks.
>
> If anyone wants to verify the kernels/initrds, I am happy to post
> instructions on how to do it - but really, anyone competent enough to use
> TFTP can figure it out :)
>

Can you put the md5sums in your loader's config file and make it check
before it starts the kernel? I don't like a lot of that kind of manual work ;-)

Also, is it possible to continue a glitched download? It's sure to happen over
the internet, on purpose or not. Is there a way to pass
a manual overriding boot command to the loader perhaps? Will it look for esc or
other key taps while booting, like BIOS or lilo pausing before default proceeding?
Where to store state? a good-up-to load address with a hash might let you reliably
continue? Storing that in UEFI NVS would make me nervous though. ;-) Your loader immediately
closes that access, right? Or doesn't even see it?

Regards,
Bengt Richter