On Fri, Jul 15, 2005, David M. Fetter wrote:
>Actually, we are having the same problem now. I found out why. It is
>because of the following configure options:
>
> 220 --disable-etc-default-login \
> 221 --with-default-path=/bin:/usr/bin \
> 222 --with-superuser-path=/bin:/usr/bin:/sbin:/usr/sbin \
>
>I understand the thoughts behind adding such configure options, however
>for the generic use of openssh, these options shouldn't be default. In
>addition, these options break openssh for everybody who is using an
>openpkg environment because this means that prior to login the path is
>hardcoded to what you see above. This also means that things like
>`rsync -av -e ssh dir/ host:/tmp/dir/` will not work because openssh
>won't see the rsync binary that resides under %{l_prefix}/bin, etc.
>This breaks svn over ssh as well. So, either these options should
>include %{l_prefix}/bin and %{l_prefix}/sbin or they should just be
>removed altogether. Any thoughts?
I agree totally (and we modify openssh locally to make it work in what I
consider a sane manner). While there may be some systems that don't honor
the PATH settings of openssh, I don't think that tuning to their lowest
common denominator makes sense, and violates the principle of least
surprise.
>On Tue, 2005-03-29 at 21:48 +0200, Ralf S. Engelschall wrote:
>> On Tue, Mar 29, 2005, Bill Campbell wrote:
>>
>> > I ran into a problem at a customer's yesterday when I found that
>> > openssh no longer prepends the OpenPKG bin directory to the PATH
>> > on the server. Looking back through my archives, this appears to
>> > have happened between Release 2.1 and Release 2.2. This causes
>> > things like ``rsync -e ssh xxx'' to fail on the remote system or
>> > to find invalid configuration if there's a vendor supplied
>> > version of the program on the remote end that conflicts with the
>> > OpenPKG version of the program.
>> >
>> > The attached patch fixes this in what I think is a logical manner
>> > for OpenPKG Release 2.2, 2.3, and CURRENT.
>>
>> Unfortunately, no, it doesn't. Well, to be precise, it "fixes" it
>> on those platforms where OpenSSH supports the --with-default-path
>> functionality only!
>>
>> That's the reason why we explicitly removed any %{l_prefix} stuff there
>> (see http://cvs.openpkg.org/chngview?cn=19660) for cross-platform
>> consistency reasons. Because it is totally confusing if one some
>> platforms one magically has the %{l_prefix} in path by default set
>> by sshd(8) and on other platforms it isn't. Hence we decided to
>> intentionally not try to add %{l_prefix}/bin there at all and instead
>> have to life with the fact that there has to be either (1) a global
>> shell profile setting PATH correctly, or (2) a local shell profile
>> setting PATH correctly or (3) the user calls the command with an
>> absolute path.
>>
>> All this I personally don't like very much, but to be honest, I do not
>> see a solution. Even hacking sshd(8) is not possible because the reason
>> why --with-default-path isn't working on all platforms is partly because
>> on those login(1) is used by sshd(8) (and this way PATH is reset by the
>> system after sshd forked off its child), etc.
>>
>> Ralf S. Engelschall
>> [EMAIL PROTECTED]
>> www.engelschall.com
>>
>> ______________________________________________________________________
>> The OpenPKG Project www.openpkg.org
>> Developer Communication List openpkg-dev@openpkg.org
>>
>--
>David M. Fetter - UNIX Systems Administrator
>Portland State University - www.oit.pdx.edu
--
Bill
--
INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC
UUCP: camco!bill PO Box 820; 6641 E. Mercer Way
FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
URL: http://www.celestial.com/
``Never chastise a Windows user...just smile at them kindly as you would a
disadvantaged child.'' WBM
______________________________________________________________________
The OpenPKG Project www.openpkg.org
Developer Communication List openpkg-dev@openpkg.org
