<div dir="ltr"><div>Hi Patrick, Jeremy, and Micheal,</div><div><br></div><div>Thanks for your response on this.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">There is a deconflict system is there for a purpose, and avahi handles it<br>well, and being able to find all the *ssh* services is actually useful.</blockquote><div>Agree.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Likely this is due to the hostname being</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">different on all of them.</blockquote>Even in my case, the hostname will be unique.<div><br></div><div>I hope, the commit that Jeremy pushed would resolve this service name conflict issue.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 4, 2020 at 10:07 PM Patrick Williams <<a href="mailto:patrick@stwcx.xyz">patrick@stwcx.xyz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Sep 03, 2020 at 06:15:50PM +0800, Jeremy Kerr wrote:<br>
> Hi Asmitha,<br>
> <br>
> > To resolve this, the idea is to append the hostname of the client<br>
> > with the service name (whenever the service is being published),<br>
> > given that the hostname will always be unique in my case.<br>
> > <br>
> > So, the service file would look like: (example.service)<br>
> > > > <service-group><br>
> > > >        <name>example-hostname</name><br>
> > > >        <service><br>
> > > >                <type>...</type><br>
> > > >                <port>...</port><br>
> > > >        </service><br>
> > > > </service-group><br>
> <br>
> The typical way to do this is just with the hostname only - the service<br>
> type distinguishes different services. So, yes: for better usability,<br>
> you'll want to include the hostname in the <name> tag, rather than a<br>
> fixed string.<br>
> <br>
> The .service definitions support wildcards, which makes this super<br>
> easy. Something like this, from our current ssh config:<br>
> <br>
>    <service-group><br>
>      <name replace-wildcards="yes">%h</name><br>
>      <service><br>
>        <type>_ssh._tcp</type><br>
>        <port>22</port><br>
>      </service><br>
>    </service-group><br>
> <br>
> Otherwise, as you've noticed, the tooling will just show multiple<br>
> (indistinguishable) entries for each BMC.<br>
<br>
Yep, I agree with this direction.  I have many systems on my home<br>
network that advertise "_ssh._tcp" and I don't have problems with Avahi<br>
adding the "#N" mentioned.  Likely this is due to the hostname being<br>
different on all of them.<br>
<br>
> Given that the meta-phosphor configuration is to use the service name<br>
> (resulting in those duplicates), I've proposed a change to use the<br>
> hostname as the default instead:<br>
> <br>
>  <a href="https://gerrit.openbmc-project.xyz/c/openbmc/meta-phosphor/+/36199" rel="noreferrer" target="_blank">https://gerrit.openbmc-project.xyz/c/openbmc/meta-phosphor/+/36199</a><br>
> <br>
> Cheers,<br>
> <br>
> <br>
> Jeremy<br>
> <br>
<br>
-- <br>
Patrick Williams<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Thanks & Regards,<div>Asmitha Karunanithi</div></div></div></div></div>