All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Williams <patrick@stwcx.xyz>
To: Jeremy Kerr <jk@ozlabs.org>
Cc: Asmitha Karunanithi <asmithakarun@gmail.com>, openbmc@lists.ozlabs.org
Subject: Re: Resolving service name conflicts
Date: Fri, 4 Sep 2020 11:37:42 -0500	[thread overview]
Message-ID: <20200904163742.GB3532@heinlein> (raw)
In-Reply-To: <e2ff765d96571e247a812bbd8b039b5396eb5a98.camel@ozlabs.org>

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

  reply	other threads:[~2020-09-04 16:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-02  5:08 Resolving service name conflicts Asmitha Karunanithi
2020-09-02 15:58 ` Patrick Williams
2020-09-03  7:49   ` Asmitha Karunanithi
2020-09-03 12:37     ` Michael Richardson
2020-09-03 10:15 ` Jeremy Kerr
2020-09-04 16:37   ` Patrick Williams [this message]
2020-09-05  7:35     ` Asmitha Karunanithi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200904163742.GB3532@heinlein \
    --to=patrick@stwcx.xyz \
    --cc=asmithakarun@gmail.com \
    --cc=jk@ozlabs.org \
    --cc=openbmc@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.