The UI is optional and need to be explicitly activated, since I
don't want existing users to suddenly have an information-spewing
thing show up on their network.
iPXE appears to have *really* poor performance (orders of magnitude worse) if
it doesn't know the length of the kernel/initrds that it's downloading. Without
this change, booting CoreOS takes longer than I've had patience to wait. With
this change, the bottleneck becomes the network transfer speed.
Fixes#10.
pixiecore: Plumb NewSnooperConn into Server as an advanced option.
pixiecore/cli: Plumb DHCPNoBind to the CLI.
Now, by default, Pixiecore will bind() to the DHCP server port in a way
that shows up in `netstat` by default. If you want to enable the "coexist
with my existing DHCP server" mode, you need to explicitly pass
--dhcp-no-bind.
I started hacking on this, but I need to take care of other bits
of the port before I embark on such a large feature. The code is
currently dead and not used by pixiecore, but I didn't want to
lose the small bits of address fiddling I've done so far.
The v1compat CLI is now complete, with support for --debug. The v2 CLI
additionally supports optional timestamping, so that when you're using
a modern init system that captures logs for you (e.g. systemd), you
don't have stuttering timestamps.
This allows API servers to return URL(x) in the cmdline template,
which pixiecore translates to an appropriate ID(x) template call
to get the file proxied via Pixiecore.
The main difficulty in passing a commandline as a plain string is
that you sometimes want to encode IDs into it, to tell your kernel
to fetch something via Pixiecore. Solving that problem with maps is
a bit clunky. Instead, now we use a text/template {{ ID "foo" }} to
mean "make a URL that, when fetched, reads the file "foo" from the
Booter.
iPXE has an annoying race condition where it sometimes doesn't notice
the ProxyDHCP response when booting, and fails. So we embed a boot
script in the builtin iPXE binaries that implements the retry loop
recommended in the documentation. Empirically, this has resolved
flaky boots on my test machine, usually no more than a single
retry is needed.
This hack tries to interpret the commandline based on what Pixiecore v1
did, before handing off to the fancier v2 CLI logic.
Doesn't support API mode yet, since that's not yet implemented in
the library.
These flags are both for providing binaries when running the apache2
version of pixiecore (which doesn't have builtin ipxe), and for
overriding the builtin version if desired.
The cli package is meant for single-shot execution anyway, so
instead of plumbing everything through reentrantly, let's just
have a global you can seed before calling CLI().
