[ANNOUNCE] D-Bus 1.0 RC 2 (0.94) released

[Havoc Pennington]

David Zeuthen wrote:
> On Sat, 2006-10-14 at 18:22 -0400, Havoc Pennington wrote:
>> David Zeuthen wrote:
>>> This is broken. It breaks at least livecd, stateless, OLPC and other use
>>> cases where you never run things such as %post on the machine that boots
>>> the OS. The fix is easy though: the bus needs to run this on start-up
>>> and cache it in a file somewhere for future use.
>> It's OK to do this at boot time instead of in %post, but I think it's 
>> more complicated so I recommended %post instead for the normal case.
> 
> Problems with %post: stateless, livecd, OLPC etc.

None of which use RPM for individual machine installs, so the %post 
suggestion is a no-op on them. It should be obvious that a suggestion 
for what to do in a package managed setup does not apply to a 
non-package-managed setup. Especially since I documented it in the man page.

> Well, it's a bad suggestion I think. And I'd tend to say it's a bug that
> libdbus requires the uuid, is it interesting at all for non-bus cases
> anyway? 

IMO the uuid should potentially be at an even lower level, it's almost a 
kernel or init feature except we need it cross-platform. It's something 
we've wanted lots of times over the years.

Making sure this uuid exists will take a little work now but will fix 
lots of busted uses of the hostname as a machine identifier. (Hostnames 
are not unique - especially when they are localhost.localdomain - and it 
would also be nice to be able to change the hostname without confusing 
the hell out of everything.)

> If it's only interesting for buses then it's worth considering just make
> the system bus generate it on system bus start up. Of course that breaks
> if you're only using a session bus but those cases are rare and people
> doing such weird things can generate it as they see fit.

It is not hard to add the 1 line command to the system bus init script.

> The whole situation right now smells like that you'd rather want to
> provide a plethora of options at the cost of complexity. And that's fine
> but only if those options make sense, maybe they do, I'm just not
> convinced.

There aren't a plethora of options. It's very simple. There's a 1-line 
simple command to ensure the file exists. You have to be sure it runs 
between bootup and the first usage of dbus. The two obvious choices are 
init scripts and %post, or both.

The reason it isn't handled 100% upstream is the same reason we have 
different init scripts and spec files for every distribution; the right 
way to handle this is going to vary a bit by distribution and how the 
files on the system are deployed and managed.

> Another, and IMO better, option is of course to not have the uuid from a
> file (insert old rant how software requiring magic configuration files
> are bad) but use some tricks to generate an uuid on the fly. If that's
> possible at all. You could probably look at the MAC addresses (normally
> that doesn't even require root) and create some digest or something
> else.

The file is simply a way to share the uuid among multiple processes.

It *is* generated on the fly, either in %post or on boot or whenever you 
want to run the command.

The reasons for using a file instead of having every process ask the 
system bus for it:
  - many processes don't need to connect to the system bus right now,
    and it's a pretty high-overhead thing just to get 16 bytes of uuid
  - there are reasonable no-system-bus cases where people are using
    dbus, e.g. to run gtk apps on OS X

The uuid is a random number and not based on the MAC address - I don't 
know why a MAC would be better. It is not more stable; network cards can 
come and go, there can be more than one of them, etc. And it's a pain to 
obtain.

> Can we at least, for now, change the Red Hat init script (which we
> distribute in the tarball) generate the uuid instead of doing it in
> %post and recommend distros to do the same instead of the broken %post
> suggestion? That would at least make it work for normal OS'es including
> them doing things such as stateless, OLPC and livecd.

I would recommend doing it in both %post and the init script, to avoid 
requiring a reboot after installing dbus, and to avoid potential 
problems with using dbus prior to the next reboot.

If you want to fix stateless/OLPC/livecd removing the %post has nothing 
to do with it; they aren't going to run the %post anyway. The important 
fix for stateless/OLPC/livecd is that you need to move the file to /var 
so it isn't shared among machines due to a shared /etc.

Having it in /var by default may well be right, and avoid the /etc 
symlink or ever looking in /etc - we should quite possibly make this 
change. I'm not sure which subdir of /var though, my guess would be 
/var/lib. Putting it in /var would also keep packagers from accidentally 
sticking it in the package's file list.

Anyway, all the patches for this were on the list weeks ago, along with 
the %post suggestion, and nobody said anything then. I'm not "against" 
changing how it works, so there's no need to say things like "can we at 
least" - we can do whatever makes sense.

Some changes that seem appropriate are:
  - change to /var by default (and adjust docs/manpage to reflect this)
  - tweak the api docs and man page a bit to suggest that the uuid will
    typically instead of only sometimes change on every reboot
  - have every distribution maintaining their init scripts upstream
    adjust them to include the uuid generation on system bus startup

I would appreciate it if someone could make a quick patch along these lines.

Havoc