Resolving service name conflicts

[Asmitha Karunanithi]

Hi Patrick, Jeremy, and Micheal,

Thanks for your response on this.


> There is a deconflict system is there for a purpose, and avahi handles it
> well, and being able to find all the *ssh* services is actually useful.

Agree.

Likely this is due to the hostname being

different on all of them.

Even in my case, the hostname will be unique.

I hope, the commit that Jeremy pushed would resolve this service name
conflict issue.


On Fri, Sep 4, 2020 at 10:07 PM Patrick Williams <patrick at stwcx.xyz> wrote:

> 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
>


-- 
Thanks & Regards,
Asmitha Karunanithi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200905/06810247/attachment.htm>