On Nov 6, 2007 8:17 PM, James Carlson <james.d.carlson at sun.com> wrote:
>
> The *one* important issue is the one we've actually trampled into the
> ground, and that's the issue about the location.  According to the
> GNU documentation, /usr/libexec/rmt isn't negotiable.  My guess would
> be (and I haven't looked at the sources) that they try
> /usr/libexec/rmt first and then historical /etc/rmt when invoking it.

My experience is that they try just the first compiled in path.

> On that theory (project team: please verify), both delivering as
> /usr/libexec/grmt and as /usr/lib/grmt are wrong, because nothing will
> look there for this helper binary.  It won't be compatible, because
> the path is effectively part of the wire protocol.

Not entirely. The client gtar will look for rmt on the remote machine
vaia a path that it thinks is sensible. For example, /usr/sfw/bin/gtar
expects to find /usr/sfw/libexec/rmt on the remote machine. So
provided that the path where rmt lives and the path compiled into
gtar match, everything is fine.

Which all breaks down in a heterogeneous environment. Two
different machines may have different ideas where rmt lives.

> If that's correct, then we should either deliver /usr/libexec/rmt as a
> symlink or (perhaps better yet) do nothing.

It depends which gtar we're trying to match the behaviour of. If
we want to interoperate with Solaris 10 clients, then we need to
deliver /usr/sfw/libexec/rmt. If we want to interoperate with gtar
from another OS, then we need to deliver rmt where that OS
expects to find it. If we want to interoperate with the gtar covered
by this case, then we need to be sure that we either configure it
to look for /etc/rmt or have a copy of rmt where we're going to
look for it.

It goes the other way. If we expect users to use gtar to talk to rmt on
remote systems, then we should choose an rmt location that's going
to exist on other systems. I don't have access to any other systems,
but it might be sensible to make a survey of where other platforms
place their rmt.

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/

Reply via email to