vfs_fruit: Time Machine/FULLSYNC: add mDNS/DNS-SD advertisement

[Omri Mor]

>> Alright, so here’s the latest version, incorporating the previous suggestions.
>> It includes some modernizations to the existing code:
>> 	DEBUG(10, …)	=>	DBG_DEBUG(…)
>> 	if (… < 0)			=>	ret = …; if (ret < 0)
>> That can be easily split into a different patch.
> 
> yes, please. Can you also please send your patches as git format patches as an
> attachment? Thanks!

Will do—I’ll open up a different thread for it, as it’s *technically* a separate issue.

> 
>> If we want to include the UUID (adVU), we’ll need to figure out where to store
>> it.  gencache isn’t appropriate, from what I can tell—storing there requires a
>> timeout (as it’s a *cache*),
> 
> It's essentially a store for data that can be *reconstructed*. You can set a
> timeout of get_time_t_max() like sitename_store() does, but that doesn't really
> help with the problem that we can't reconstruct the UUID if a user runs net
> cache flush for some reason (and there are valid reasons to do that). I assume
> that if the UUID of an existing TM destination changes, the client will likely
> refuse to backup to it (iirc been there, done that), but can you verify this to
> be sure?

Changing the adVU value, removing it, etc. all *seem* to have had no effect on the backup.
I just generated a completely new UUID; backup proceeded as normal.
Perhaps adVU helps in finding the disk if the share name changes?
We just don’t have documentation on *what* it does—the only reason Netatalk advertises it is because macOS Server does!
If it works fine without it, should we even bother?

>> which doesn’t make sense for a persistent UUID.
>> Perhaps secrets.tdb?
> 
> Na. :)

I didn’t think so, but I thought I’d make sure.

>> The documentation says it stores “internal settings”, which the UUID would
>> qualify for.  However, it’s not as if it’s ‘secret’ information, so I’m not
>> sure if it’s a good fit.  Is there a database for generic, persistent data?
> 
> No, we'll have to roll our own for this purpose. Take a look at db_open() in
> idmap_tdb_open_db() for an example of the API.
> 
> Not quite sure where to hook this into, it's generic enough to live in it's own
> source file, probably in source3/lib/*.c|h, linking into samba3core. You can
> then call it from the Avahi code.

Are there other uses besides this for a generic, persistent database?
Obviously there hasn’t (yet) been a pressing need for one, but I could see it being useful.
It shouldn’t be too difficult to do, I think. Model it on the gencache API, but without it being a cache (so no timeout).

If we *do* decide to generate and store a UUID, what would the key be?
Service number doesn’t make sense, as that can change between runs (I think?).
I’m not certain that service name makes sense either, if my suspicions as to what adVU is actually useful for are correct.

Omri