Resolving service name conflicts

Resolving service name conflicts

[Asmitha Karunanithi]

[-- Attachment #1: Type: text/plain, Size: 923 bytes --]

Hi All,

Hope all are doing good.

When I was trying to do 'avahi-browse', I was able to see service name
conflicts (since the service with the same name would be published by
various clients in the network and I could see <servicename>#100, after
trying for 99 times).

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>


I just wanted to clarify if the above idea would be the right solution to
resolve the service name conflict or is there any other way that is
currently available to resolve this issue?

-- 
Thanks & Regards,
Asmitha Karunanithi

[-- Attachment #2: Type: text/html, Size: 2690 bytes --]

Re: Resolving service name conflicts

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

On Wed, Sep 02, 2020 at 10:38:55AM +0530, Asmitha Karunanithi wrote:
> Hi All,
> 
> Hope all are doing good.
> 
> When I was trying to do 'avahi-browse', I was able to see service name
> conflicts (since the service with the same name would be published by
> various clients in the network and I could see <servicename>#100, after
> trying for 99 times).
> 
> 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>

Can you give an example of what a service name would be in this context?
Is it like 'ssh'?  I don't think you should be advertising services as
'ssh-hostname' in that case.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Resolving service name conflicts

[Asmitha Karunanithi]

[-- Attachment #1: Type: text/plain, Size: 1941 bytes --]

Hi Patrick,

Yup, it would be like "ssh-hostname" because there would be service name
conflicts, say if there are 100 systems in the network publishing the
service with the same name, there would be name conflicts for 100 times and
finally, the service would be published as "ssh#101" to the network.

To avoid this, if we append the service name with the hostname which will
be unique, we make sure that the service name would also be unique thus
resolving the service name conflicts.

Example would be:

    <name>ssh-(hostname)</name>
    <service>
        ....
    </service>

Else, one other solution would be to push a patch for avahi, to stop
looking for service name conflicts (unique service name).
Your thoughts on the same, Patrick?

On Wed, Sep 2, 2020 at 9:28 PM Patrick Williams <patrick@stwcx.xyz> wrote:

> On Wed, Sep 02, 2020 at 10:38:55AM +0530, Asmitha Karunanithi wrote:
> > Hi All,
> >
> > Hope all are doing good.
> >
> > When I was trying to do 'avahi-browse', I was able to see service name
> > conflicts (since the service with the same name would be published by
> > various clients in the network and I could see <servicename>#100, after
> > trying for 99 times).
> >
> > 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>
>
> Can you give an example of what a service name would be in this context?
> Is it like 'ssh'?  I don't think you should be advertising services as
> 'ssh-hostname' in that case.
>
> --
> Patrick Williams
>


-- 
Thanks & Regards,
Asmitha Karunanithi

[-- Attachment #2: Type: text/html, Size: 3178 bytes --]

Re: Resolving service name conflicts

[Michael Richardson]

Asmitha Karunanithi <asmithakarun@gmail.com> wrote:
    > Yup, it would be like "ssh-hostname" because there would be service name
    > conflicts, say if there are 100 systems in the network publishing the
    > service with the same name, there would be name conflicts for 100 times and
    > finally, the service would be published as "ssh#101" to the network.

If I understood correctly.

That goes against what RFC6762/6763 say.
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.
There can be other information in the PTR/SRV record.
One can ssh to hostname.local if you know the hostname.


--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

Re: Resolving service name conflicts

[Jeremy Kerr]

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.

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

Re: Resolving service name conflicts

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1826 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Resolving service name conflicts

[Asmitha Karunanithi]

[-- Attachment #1: Type: text/plain, Size: 2421 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4066 bytes --]