Please accept my most fervent apologies if this came off as
"attitudinal", everyone who read my message. It was never my intent to
offend anyone.
I am not a C programmer, but I've programmed in just about every other
language over the last 30 years, from toggling machine code instructions into a
front panel, to so-called 4GLs. I may use this to learn C, who knows. But my
observation is based on my years of experience not only as a developer, but also
as a system administrator. Every program "worth its salt" that
manipulates files allows some form of logging, without regard to the specific
setting of stdout and/or stderr. There is always a way to redirect the output or
pipe it to another command. That is sort of an unwritten law in the Unix world,
as far as I know, for command line utilities.
I realize that OpenSSH was and is written primarily for OpenBSD, and the
herculean efforts of the portability team make it available to the rest of the
world for free, as in beer. I am most and humbly grateful for all this.
Nevertheless, I see requests going back to 2000 for this feature, but apparently
there simply has not been the demand that I would have anticipated.
Yes, I can use rsync, but it means installing rsync on all of my servers, and we
have a relatively large AIX and Linux server farm, and I was hoping for a way to
simply log the activity of this command.
My suggestion (since nothing else has been suggested) is that the progress meter
be (optionally) not quite so flashy and smart and cool and all that, and simply
have a mode where the file name and bytes transferred come out after the copy
completes, rather than writing a line with the file name at the left margin, and
a constantly-updated progress meter at the right margin. It's very cool and
all, but perhaps simply checking the TERM variable and if it's set to
something like tty, or the logic that detects that stdout is not going to a CRT
could just not do that fancy stuff. You could still supress it with the -q
option, but that simple change would nicely handle the simplest of logging at
the client side.
Logging at the server side should also be configurable, so that such things go
to the syslog file. This is also in keeping with the spirit of most utilities
that provide a remote service.
As OpenSSH is used more and more in this age of SOX compliance, it would be nice
if these kinds of logging and auditing were available. I may try and pitch in,
who knows. But it's clear that I'm not the only that needs this, so
I'm tossing my $0,000,000.02 into the game, and dropping this into the
"Suggestion" box.
Jerel Crosland
Technical Specialist
21st Century Insurance
Knott's Berry Farm & National Organization of Women: Knott NOW!
-----Original Message-----
From: Roy L Butler [mailto:roy.butler at jpl.nasa.gov]
Sent: Tuesday, May 09, 2006 3:49 PM
To: Crosland, Jerel
Cc: openssh-unix-dev at mindrot.org
Subject: Re: scp logging
Jerel,
Crosland, Jerel wrote:> The ability to log even just the names of the files being transferred, and
possibly their sizes, has been a requested feature since early 2000 (over six
years!!) and I've yet to see any of the developers on this list respond
directly. I've found a patch from V?clav Tomec here: http://sweb.cz/v_t_m/
but it includes lots of other stuff (SecureID implementation and a tweak for
being able to select allow/deny users for each kind of authentication) which I
don't need and don't want to "support".
>
> Every file manipulation utility available for the Unix/Linux world provides
the ability to log what it is doing, except for scp and sftp. This is crazy!! It
displays the "progress meter" as long as the output is directed to a
screen, but if you redirect stdout to a file, it disables all output, except
errors! Is there really only about 10 of us in the entire world that want to use
scp in a script, and want a log of what it did? I find that hard to believe!!!
Is this planned as a feature in some future release, or is it just being
ignored? It's insane that there's no way to log the output! You
can't use -o LOGLEVEL=something and if you use -v or the debug logging
level, tons of stuff spews out, but not one single line that contains the file
name, it's size, and an indication of the status of the transfer.
>
> Am I just nuts for expecting this?
At first, I thought you meant logging on the server, and thought "Yeah,
that would be cool". It follows along the lines of web and FTP servers
usually logging uploads, but I can see how it doesn't necessarily fall
within sshd's needed facilities (who knows, maybe it is there and I just
don't know it).
But from reading further, it sounds like what you're complaining about,
is the lack of logging on the client side. If that's the case, I have
two comments for you, one about open source, and one that is a technical
solution to your wish, if you'll allow it to be so:
- If you want something from an open source project, you usually need to
step up to the plate with code. If it's accepted, great. If not, fork.
People who aren't getting paid to do something for you aren't going to
deal with a bad attitude.
- Use rsync over ssh. It will provide you all of the logging you like,
as well as the ability to perform incremental pushes depending on
source/destination contents.
Hope this helps. If not, you could also probably pay a commercial
vendor to implement your requests...
Roy
***********************************************************************
This e-mail and any files transmitted with it are intended
solely for the use of the addressee. This e-mail may
contain confidential and/or legally privileged information.
Any review, transmission, disclosure, copying, or any action
taken or not taken, by other than the intended recipient, in
reliance on the information, is prohibited. If you received
this e-mail in error, notify the sender and delete this e-mail
(and any accompanying material) from your computer and
network. In addition, please be advised that 21st Century
Insurance Group reserves the right to monitor, access and
review all messages, data and images transmitted through
our electronic mail system. By using our e-mail system, you
consent to this monitoring.
***********************************************************************