Setup /etc/machine-id in our Trusty containers

[cotsog]

We've received a report saying that /etc/machine-id wasn't available anymore in our Trusty containers (at least for language: node_js). This is preventing dbus from working properly which, from my understanding, is needed to run headless browser tests.

Thank you for having a look!

[meatballhat]

@cotsog I'm finding that installing dbus and dbus-x11 results in the presence of /var/lib/dbus/machine-id but not /etc/machine-id, FYI.

[emdantrim]

after looking into this a little bit further: it looks like usually /var/lib/dbus/machine-id matches whatever is in /etc/machine-id, and usually this works just fine, but some applications (possibly Qt-based applications?) still expect /etc/machine-id to be there.

looks to me like we should just symlink /var/lib/dbus/machine-id/ to /etc/machine-id.

there's also the option of using dbus-uuidgen to generate a new dbus uuid, however, that will then cause us to have two sources of truth for this.

other things around the internet seem to imply that /var/lib/dbus/machine-id is already the proper place for this file to live so symlinking it would be purely for compatibility, and if we were to do so it might just cause different problems to arise. (that's a gut instinct, though)

[DanTup]

FWIW, I think this might affect starting Chrome on Travis Linux too. I see:

[5796:5796:0206/084907.084788:ERROR:browser_dm_token_storage_linux.cc(101)] Error: /etc/machine-id contains 0 characters (32 were expected).

and it seems like Chrome isn't started properly. I'll see if I can symlink it manually, but it'd be nice if it was there out of the box :-)