Switching to randomly generated hostnames

[Daniel Drake]

On Wed, May 2, 2012 at 1:18 AM, Martin Langhoff
<martin.langhoff at gmail.com> wrote:
> On Tue, May 1, 2012 at 11:29 AM, Daniel Drake <dsd at laptop.org> wrote:
>> In Nicaragua we are seeing cases where XOs have no hostname set, both
>> on XO-1 and XO-1.5. On XO-1 this is presumably because libertas
>> usb8388 init was never 100% reliable, and on XO-1.5 its presumably
>> because the wireless card was DOA but was replaced after first boot.
>
> That is happening too on 12.1.0 on XO-1.75 right now for me. I've been
> looking at the exact problem, with comments at
> http://dev.laptop.org/ticket/11710#comment:14
>
> To summarize:
>
> 1 - the code to setup /etc/sysconfig/network is in the wrong place --
> it should trigger boot that /etc/sysconfig/network is missing

Yes, we can improve the code that handles this case.

> 2 - yes, libertas init is slow, I've implemented a draft patch that
> waits for it to complete with something smarter than "sleep" -- with
> this patch, it seems to succeed 100% of the time for me. Not of the
> wlan is DOA, but in that case fixing #1 addresses the problem.

As noted in the ticket, this is fixed in 3.3. It can also be fixed by
backporting a number of patches to 3.0 (but I figured waiting for 3.3
would be better than putting the time into the backport).

The udevsettle behaviour and timing will also change quite a bit with
3.3. So most of your observations on the ticket (w.r.t wireless
device) will be changed or invalidated.

For a preview of how things will look, you can test on XO-1 or XO-1.5.

> See draft patch addressing #2 and #3 at
> http://dev.laptop.org/attachment/ticket/11710/0001-draft-patch-load-drivers-early-settle-only-wlan-wait.patch
>
> OK - but we only need to wait for it for first boot. Maybe we can tidy
> up my code in the patch above, unless you think it is fundamentally
> flawed.

I think its just not worth the complexity when we could do something
trivial with random numbers, which would be robust against all kinds
of situation (no wifi, slow init, no mfg data, wifi card changed,
collision of selected MAC address bytes). This is code that we've had
trouble with several times before, and in the past it has caused us
headaches (i.e. last cycle it mysteriously broke collaboration and
took Simon a good few hours to narrow down the cause).

We can get rid of all this, plus the complexity in the patch
(collaborating with udev, putting things in another thread, waiting
for files to appear) and replace it with a 1-liner, and still achieve
the same important result.

>> I propose we move to generating hostnames in the same format as before
>
> I am not against this alternative plan but TBH I think the problem of
> waiting for certain devices is one we need to address in general in
> this wild systemd world. The USBVGA support put me on this track.
> Maybe we need to evolve that "waitforpath" function to a
> "waitfordevice".

Yes, we need a "general" solution to wait for the USBVGA corner cases
at least. Using the state of /sys after probe and and then waiting for
a file to appear seems like a good solution to me.


For the hostnames, I think the best thing to do is accept it as a
corner case and work to avoid the complexity so that we have something
that works now and that will (very very likely) keep working in the
future.

As for how to simplify it, the idea of using mfg data for MAC address
or serial number seems like a good option to me, as good as the random
number thing.

One thing I'd like to re-emphasize: these hostnames do not need to be
globally unique, they only need to be unique within a group of peers
with who you will collaborate with under Sugar.

With this in mind do people have strong preferences on how to generate
this? After reading the responses my new proposal would be to try and
use the last 3 bytes of the MAC address read from mfg data, and if
that doesnt exist, fall back on 3 random hex bytes.

Daniel