Resolving service name conflicts

[Patrick Williams]

On Thu, Sep 03, 2020 at 06:15:50PM +0800, Jeremy Kerr wrote:
> Hi Asmitha,
> 
> > To resolve this, the idea is to append the hostname of the client
> > with the service name (whenever the service is being published),
> > given that the hostname will always be unique in my case.
> > 
> > So, the service file would look like: (example.service)
> > > > <service-group>
> > > >        <name>example-hostname</name>
> > > >        <service>
> > > >                <type>...</type>
> > > >                <port>...</port>
> > > >        </service>
> > > > </service-group>
> 
> The typical way to do this is just with the hostname only - the service
> type distinguishes different services. So, yes: for better usability,
> you'll want to include the hostname in the <name> tag, rather than a
> fixed string.
> 
> The .service definitions support wildcards, which makes this super
> easy. Something like this, from our current ssh config:
> 
>    <service-group>
>      <name replace-wildcards="yes">%h</name>
>      <service>
>        <type>_ssh._tcp</type>
>        <port>22</port>
>      </service>
>    </service-group>
> 
> Otherwise, as you've noticed, the tooling will just show multiple
> (indistinguishable) entries for each BMC.

Yep, I agree with this direction.  I have many systems on my home
network that advertise "_ssh._tcp" and I don't have problems with Avahi
adding the "#N" mentioned.  Likely this is due to the hostname being
different on all of them.

> Given that the meta-phosphor configuration is to use the service name
> (resulting in those duplicates), I've proposed a change to use the
> hostname as the default instead:
> 
>  https://gerrit.openbmc-project.xyz/c/openbmc/meta-phosphor/+/36199
> 
> Cheers,
> 
> 
> Jeremy
> 

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200904/79857138/attachment.sig>