headers
Peter Stuge | 1 Mar 2006 02:08

Re: scp and SGI DMF

On Tue, Feb 28, 2006 at 03:58:27PM -0800, Iain Morgan wrote:
> This causes DMF (the HSM) to recall the file from tape and the scp
> hangs until it is successfully recalled.

Oh.

> So, I'm wondering if there would be any interest in either adding
> (yet another) command-line option to add O_TRUNC to the open()
> flags when writing a file

I doubt this will ever happen. scp is only maintained for backwards
compatibility with rcp.

> or perhaps to change the default behaviour. (I'm assuming the
> latter is unlikely.)

Can you test what rcp does? The general intention for scp is that it
should behave the same way rcp does, if rcp truncates then scp may
quite possibly change.

> I should note that sftp doesn't seem to have the same problem.
> However, the lack of a recursive copy makes it problematic for many
> of our users.

Teaching sftp how to do recursive copies is probably the best
solution in any case since sftp is actually developed rather than
just maintained.

//Peter
(Continue reading)

Permalink | Reply | 5 comments |
headers
Damien Miller | 1 Mar 2006 09:18
Favicon

Re: scp and SGI DMF

On Wed, 1 Mar 2006, Peter Stuge wrote:

> > I should note that sftp doesn't seem to have the same problem.
> > However, the lack of a recursive copy makes it problematic for many
> > of our users.
> 
> Teaching sftp how to do recursive copies is probably the best
> solution in any case since sftp is actually developed rather than
> just maintained.

Absolutely! I would love someone interested to pick this up.

There is a patch in bugzilla[1] to implement recursive uploads that I
have been meaning to review for ages. Implementing recursive downloads
is more tricky, and would probably require hacking sftp awareness into
the guts of fts(3) or similar.

-d

[1] http://bugzilla.mindrot.org/show_bug.cgi?id=520
Permalink | Reply | 0 comments |
headers
Tob_Sch | 1 Mar 2006 13:26
Picon
Picon

sshrc not working when using restricted shells on HP-UX

Hi,

we compiled OpenSSH 4.3p2 / OpenSSL 0.9.8a / zlib 1.2.3 on different
platforms.

When we connect to a user which has got a restricted login shell on a HP-UX
(e.g. 11.00) server, we get errors during passing the sshrc file, altough
there are enough rights to access this file e.g. via "dd if=<path to sshrc>"
in the restricted shell. This doesn't appear when using restricted shells on
all other platforms!!!

Here's the error message during starting the connection:

sh: /bin/sh: The operation is not allowed in a restricted shell.

The problem occurs on
HP-UX with rksh and rsh

The problem doesn't occure on
SunOS with rksh
AIX with rksh
Linux with rbash 

Thanks in advance for help.

--

-- 
Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer!
Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer
Permalink | Reply | 6 comments |
headers
Darren Tucker | 1 Mar 2006 13:44
Picon
Picon

Re: sshrc not working when using restricted shells on HP-UX

Tob_Sch <at> gmx.de wrote:
[about restricted shells]
> Here's the error message during starting the connection:
> 
> sh: /bin/sh: The operation is not allowed in a restricted shell.

I would interpret that as one of the commands in the sshrc failing,
rather than parsing of the file itself failing.   What's in sshrc?  Does
putting "set -x" at the top of sshrc provide any enlightenment?

--

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
Permalink | Reply | 3 comments |
headers
Darren Tucker | 1 Mar 2006 14:02
Picon
Picon

Re: sshrc not working when using restricted shells on HP-UX

Darren Tucker wrote:
> Tob_Sch <at> gmx.de wrote:
> [about restricted shells]
>> Here's the error message during starting the connection:
>>
>> sh: /bin/sh: The operation is not allowed in a restricted shell.
> 
> I would interpret that as one of the commands in the sshrc failing,
> rather than parsing of the file itself failing.   What's in sshrc?  Does
> putting "set -x" at the top of sshrc provide any enlightenment?

Looking at the code, it does:
	f = popen(_PATH_BSHELL " " _PATH_SSH_SYSTEM_RC, "w");

which is effectively running:

	/bin/sh /usr/local/etc/sshrc

I suspect the difference is that the platforms that work use /bin/sh for
popen() but HP-UX uses the login shell.

Hmm, SuSv3 implies that popen should use sh, but doesn't come right out
and say it:

"The environment of the executed command shall be as if a child process
were created within the popen() call using the fork() function, and the
child invoked the sh utility using the call:

execl(shell path, "sh", "-c", command, (char *)0);"
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tob_Sch | 1 Mar 2006 14:05
Picon
Picon

Re: sshrc not working when using restricted shells on HP-UX

Hi Darren,

thanks for the fast answer.

I already tried this. It only shows verbose output when connecting to a user
with no restricted login shell. For users with rksh / rsh the error message
below is the same and only output.
It seems to me that the way sshd brings the sshrc-file to the ssh-client is
different on HP-UX (or HP-UX works different from SunOS, AIX, Linux).

The script only uses the id, awk, echo, ps -ef, uname, logger -commands.

Best regards, Tobias

> --- Ursprüngliche Nachricht ---
> Von: Darren Tucker <dtucker <at> zip.com.au>
> An: Tob_Sch <at> gmx.de
> Kopie: openssh-unix-dev <at> mindrot.org
> Betreff: Re: sshrc not working when using restricted shells on HP-UX
> Datum: Wed, 01 Mar 2006 23:44:23 +1100
> 
> Tob_Sch <at> gmx.de wrote:
> [about restricted shells]
> > Here's the error message during starting the connection:
> > 
> > sh: /bin/sh: The operation is not allowed in a restricted shell.
> 
> I would interpret that as one of the commands in the sshrc failing,
> rather than parsing of the file itself failing.   What's in sshrc?  Does
> putting "set -x" at the top of sshrc provide any enlightenment?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Rapier | 1 Mar 2006 16:40
Picon
Favicon

Re: scp and SGI DMF


Peter Stuge wrote:
> On Tue, Feb 28, 2006 at 03:58:27PM -0800, Iain Morgan wrote:
>> This causes DMF (the HSM) to recall the file from tape and the scp
>> hangs until it is successfully recalled.
> 
> Oh.

I think we saw problems like this with our tape silos as well. Its not 
something that most people have to deal with though which sort of makes 
it an orphan problem. So unless it can be argued that truncating a file 
before overwriting the file is correct behaviour I don't see it getting 
into the code base. One thing I'm wondering though - what would be the 
effect of not using a switch and just making truncate the default 
behaviour? It looks like its the default behaviour in sftp as it is. 
Anyway, something like this seems to be a pretty straightforward patch 
that only would need to be implemented on the NASA servers.

>> So, I'm wondering if there would be any interest in either adding
>> (yet another) command-line option to add O_TRUNC to the open()
>> flags when writing a file
> 
> I doubt this will ever happen. scp is only maintained for backwards
> compatibility with rcp.

See, I've never been convinced that this is the right way to handle SCP. 
   A lot of people use because its easy and straightforward. So I'm not 
sure its best to relegate it to enforced stagnation because it was 
originally envisioned as a drop in replacement for rcp. Thats just me 
though.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Rick Jones | 1 Mar 2006 18:13
Picon
Favicon

Re: scp and SGI DMF

Chris Rapier wrote:
>>I doubt this will ever happen. scp is only maintained for backwards
>>compatibility with rcp.
> 
> 
> See, I've never been convinced that this is the right way to handle SCP. 
>    A lot of people use because its easy and straightforward. So I'm not 
> sure its best to relegate it to enforced stagnation because it was 
> originally envisioned as a drop in replacement for rcp. Thats just me 
> though.

 From what I've seen of the questions asked in various support places, 
I'd have to say I've seen more questions about scp than sftp.  I would 
initially ass-u-me that implies more folks are using scp than sftp, but 
have to admit that is not the only possible conclusion.

rick jones
Permalink | Reply | 1 comment |
headers
Chris Rapier | 1 Mar 2006 18:31
Picon
Favicon

Re: scp and SGI DMF


Rick Jones wrote:
> Chris Rapier wrote:
>>> I doubt this will ever happen. scp is only maintained for backwards
>>> compatibility with rcp.
>>
>> See, I've never been convinced that this is the right way to handle SCP. 
>>    A lot of people use because its easy and straightforward. So I'm not 
>> sure its best to relegate it to enforced stagnation because it was 
>> originally envisioned as a drop in replacement for rcp. Thats just me 
>> though.
> 
>  From what I've seen of the questions asked in various support places, 
> I'd have to say I've seen more questions about scp than sftp.  I would 
> initially ass-u-me that implies more folks are using scp than sftp, but 
> have to admit that is not the only possible conclusion.

Well, obviously it could also mean that SFTP is just easier to use for 
most people. I personally prefer SCP most of the time. Just more 
straight forward for transferring files in my world.

I'd love to see some improvements in it. We considered doing some of 
that at one point. Parallel streams, transferring multiple files as a 
single data stream, ganged transfers using multiple servers (like 
gridftp), etc. Admittedly those applications are for more high 
performance environments but its really only a matter of time until 
today's high performance becomes tomorrow's consumer grade. Well, never 
got the time to get to it though. :\
Permalink | Reply | 0 comments |
headers
Rick Jones | 1 Mar 2006 19:18
Picon
Favicon

Re: scp and SGI DMF

Peter Stuge wrote:
> Can you test what rcp does? The general intention for scp is that it
> should behave the same way rcp does, if rcp truncates then scp may
> quite possibly change.

FWIW, this is a system call trace of an rcp under HP-UX 11.11 (11iv1) 
wen rcp was asked to copy a remote file to /tmp/foobie.  I'm just 
showing those things accessing the /tmp/foobie file:

stat64("/tmp/foobie", 0x7a0018b8) ........................ = 0
                             st_dev: 64 0x000003
                             st_ino: 121698
                            st_mode: S_IFREG|0755
                           st_nlink: 1
                            st_rdev: 0
                            st_size: 19016840
                         st_blksize: 8192
                          st_blocks: 18576
                             st_uid: 8394
                             st_gid: 20
                           st_atime: Wed Mar  1 10:05:45 2006
                           st_mtime: Wed Mar  1 10:05:47 2006
                           st_ctime: Wed Mar  1 10:05:47 2006
open("/tmp/foobie", O_WRONLY|O_CREAT|O_LARGEFILE, 0) ..... = 5

It then drops into a read/write loop writing the file.

I can make no assertions as to whether HP-UX's rcp is unique in its 
behaviour.  However, from the looks of things, it would be "OK" to add 
O_TRUNC because at the very end of the copy, rcp does this:
(Continue reading)

Permalink | Reply | 0 comments |

Gmane