RE: transfer interrupted, and Not privileged errors,

2000-11-09 Thread Todd Robinson

Yep, thanks, and thanks to the others who pointed it out off list too.  I
remember learning this some time ago, but excuses I wasn't really even
thinking about that problem, dog burned down, house ran away, I've got a
cold, going to be 40 in another month and my medium term memory is obviously
shot /excuses.

Oh well, on to the fun stuff that I still remember how to fix...


Todd

 -Original Message-
 From: Martin Pool [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, November 08, 2000 8:28 PM
 To: Todd Robinson
 Cc: [EMAIL PROTECTED]
 Subject: Re: transfer interrupted, and Not privileged errors,


 On  8 Nov 2000, Todd Robinson [EMAIL PROTECTED] wrote:
   That's pretty strange, for two reasons: as far as I knew, everything
   ought to go to stderr, stdout, or the log file.  When you say
   "console", do you mean it comes out in your current window, or it goes
   to the actual VGA adapter/serial console of the server?
 
  In the current window the rsync was executed from, even if you redirect
  stderr someplace else.  For instance, I run something just like this:
 
rsync -avvvz /tmp/rsync-2.4.6/lib fdops3::marktg 21 
 /rsync.txt

 Ah, OK.  This is because stderr is not actually redirected!

 The construct 21 means ``send fd2 (stderr) to wherever fd1 (stdout)
 is pointing *at the moment*''.  Since redirections are evaluated in
 order left-to-right, this sends stderr to the terminal (probably where
 it was already going), and then sends stdout to the file.  From the
 bash man page:

Note that the order of redirections is  significant.   For
example, the command

   ls  dirlist 21

directs  both  standard  output  and standard error to the
file dirlist, while the command

   ls 21  dirlist

directs only the standard output to file dirlist,  because
the  standard  error  was  duplicated  as  standard output
before the standard output was redirected to dirlist.

 I still remember the `ah-ha!' moment when this sunk in a few years
 ago.

 Regards,
 --
 Martin Pool, Linuxcare, Inc.
 +61 2 6262 8990
 [EMAIL PROTECTED], http://www.linuxcare.com/
 Linuxcare. Support for the revolution.






RE: transfer interrupted, and Not privileged errors,

2000-11-08 Thread Grace M. Garcia


how do i unsubscribe from the list?

thanks!

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Martin Pool
Sent: Wednesday, November 08, 2000 4:35 PM
To: Todd Robinson
Cc: [EMAIL PROTECTED]
Subject: Re: transfer interrupted, and Not privileged errors,


On 11 Oct 2000, Martin Pool [EMAIL PROTECTED] wrote:
 On Tue, Oct 10, 2000 at 09:39:20AM -0400, Todd Robinson wrote:

   rsync to marktg from fdops2
   wrote 32 bytes  read 2439031 bytes  total size 13862565
   transfer interrupted (code 102) at main.c(432)
 
 At least on Linux, 102 is 
 
   #define ENETRESET   102 /* Network dropped connection
 because of reset */

On SCO SystemV 5.0.5, 102 seems to be 

#define _TCPERR 90  /* Same as TCPERR above */
#define EADDRINUSE  (_TCPERR+12)/* Address already in use */

which is a kind of weird reason to get transfer interrupted...

-- 
Martin Pool, Linuxcare, Inc.
+61 2 6262 8990
[EMAIL PROTECTED], http://www.linuxcare.com/
Linuxcare. Support for the revolution.





Re: transfer interrupted, and Not privileged errors,

2000-11-08 Thread Martin Pool

On  8 Nov 2000, Martin Pool [EMAIL PROTECTED] wrote:

  The unlink message went to the console not the file, it was:
  
   unlink rsync-2.4.6/lib : Not privileged
 
 That's pretty strange, for two reasons: as far as I knew, everything
 ought to go to stderr, stdout, or the log file.  When you say
 "console", do you mean it comes out in your current window, or it goes
 to the actual VGA adapter/serial console of the server?

Oh... and the second reason it's strange is that rsync is deleting
anything at all.  Todd, would you mind please

1. running with just the -r (recursive) flag, not -a (archive)

2. confirming that when copying the rsync source, the error occurs
even if the source directory is empty

3. Applying the attached patch (or equivalently building from CVS);
this will produce better explanations of where the error occurs.  If
you're concerned about disrupting the machines then it's OK to just
build and not install the daemon; you can then run it with a command
like

  # ./rsync-patched/rsync --daemon --port 8129 

Thanks, 
-- 
Martin Pool, Linuxcare, Inc.
+61 2 6262 8990
[EMAIL PROTECTED], http://www.linuxcare.com/
Linuxcare. Support for the revolution.




Index: .cvsignore
===
RCS file: /data/cvs//rsync/.cvsignore,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- .cvsignore  1997/12/16 09:14:18 1.13
+++ .cvsignore  2000/10/13 03:28:12 1.14
@@ -1,5 +1,7 @@
-.ignore
+
 .cvsignore
+.ignore
+ID
 Makefile
 a
 b
@@ -18,4 +20,3 @@
 tech_report.log
 tech_report.ps
 test
-
Index: README
===
RCS file: /data/cvs//rsync/README,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- README  2000/09/06 02:39:45 1.24
+++ README  2000/11/02 11:38:13 1.25
@@ -90,11 +90,14 @@
 SETUP
 -
 
-Rsync uses rsh or ssh for communication. It does not need to be setuid
-and requires no special privileges for installation. It does not
-require a inetd entry or a daemon. You must, however, have a working
-rsh or ssh system. Using ssh is recommended for its security
-features. 
+Rsync normally uses rsh or ssh for communication.  It does not need to
+be setuid and requires no special privileges for installation.  You
+must, however, have a working rsh or ssh system. Using ssh is
+recommended for its security features.
+
+Alternatively, rsync can run in `daemon' mode, listening on a socket.
+This is generally used for public file distribution, although
+authentication and access control are available.
 
 To install rsync, first run the "configure" script. This will create a
 Makefile and config.h appropriate for your system. Then type
@@ -152,19 +155,20 @@
 source code repository then you can use anonymous cvs. You will need a
 recent version of cvs then use the following commands:
 
-   cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot login
+   cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot login
Password: cvs
 
-   cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot co rsync
+   cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot co rsync
 
-Look at the cvs documentation for more details.
+Look at the cvs documentation, or http://samba.org/cvs.html, for more
+details.
 
 
 COPYRIGHT
 -
 
 Rsync was written by Andrew Tridgell and Paul Mackerras, and is
-available under the Gnu Public License.
+available under the GNU General Public License.
 
 [EMAIL PROTECTED]
 [EMAIL PROTECTED]
Index: authenticate.c
===
RCS file: /data/cvs//rsync/authenticate.c,v
retrieving revision 1.14
retrieving revision 1.16
diff -u -r1.14 -r1.16
--- authenticate.c  2000/08/19 15:25:05 1.14
+++ authenticate.c  2000/10/26 07:31:29 1.16
@@ -1,6 +1,7 @@
-/* 
-   Copyright (C) Andrew Tridgell 1998
+/* -*- c-file-style: "linux"; -*-

+   Copyright (C) 1998-2000 by Andrew Tridgell 
+   
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
@@ -85,7 +86,7 @@
if (fd == -1) return 0;
 
if (do_stat(fname, st) == -1) {
-   rprintf(FERROR,"stat(%s) : %s\n", fname, strerror(errno));
+   rsyserr(FERROR, errno, "stat(%s)", fname);
ok = 0;
} else if (lp_strict_modes(module)) {
if ((st.st_mode  06) != 0) {
@@ -144,13 +145,13 @@
if (!filename) return NULL;
 
if ( (fd=open(filename,O_RDONLY)) == -1) {
-   rprintf(FERROR,"could not open password file \"%s\"\n",filename);
+   rsyserr(FERROR, errno, "could not open password file \"%s\"",filename);
if (envpw) rprintf(FERROR,"falling back to RSYNC_PASSWORD environment 
variable.\n");
return NULL;
}


RE: transfer interrupted, and Not privileged errors,

2000-11-08 Thread Todd Robinson

 That's pretty strange, for two reasons: as far as I knew, everything
 ought to go to stderr, stdout, or the log file.  When you say
 "console", do you mean it comes out in your current window, or it goes
 to the actual VGA adapter/serial console of the server?

In the current window the rsync was executed from, even if you redirect
stderr someplace else.  For instance, I run something just like this:

  rsync -avvvz /tmp/rsync-2.4.6/lib fdops3::marktg 21  /rsync.txt

(indicating a different source directory to affect a backup) in a cron job
wrapped in an exec.  I get the usual stuff in the log, but the 'unlink'
messages come to me in an e-mail from cron saying this is the output of my
job.

 Oh... and the second reason it's strange is that rsync is deleting
 anything at all.  Todd, would you mind please

 1. running with just the -r (recursive) flag, not -a (archive)

Ok, did:

 rsync -r /tmp/rsync-2.4.6/lib fdops3::marktg 21  /rsync.txt

got:
 unlink lib : Not privileged
 unlink lib : Not privileged
in the same window following the above command, /rsync.txt was empty (len
0), the server log file shows it received all the files in the lib
directory,

 2. confirming that when copying the rsync source, the error occurs
 even if the source directory is empty

 cd /tmp/rsync-2.4.6/lib
 rm *
 cd /
 rsync -r /tmp/rsync-2.4.6/lib fdops3::marktg 21  /rsync.txt

got:
 unlink lib : Not privileged
 unlink lib : Not privileged
in the same window following the above command, /rsync.txt was empty (len
0),
the server log shows no files transferred

 3. Applying the attached patch (or equivalently building from CVS);
 this will produce better explanations of where the error occurs.  If
 you're concerned about disrupting the machines then it's OK to just
 build and not install the daemon; you can then run it with a command
 like

  # ./rsync-patched/rsync --daemon --port 8129

Applied the patch and re-built, part way through the make I got these
errors:

 UX:acomp: WARNING: "socket.c", line 221: argument is incompatible with
prototype: arg #5
 UX:acomp: WARNING: "socket.c", line 264: argument is incompatible with
prototype: arg #3
 UX:acomp: WARNING: "socket.c", line 441: argument is incompatible with
prototype: arg #3
 UX:acomp: WARNING: "socket.c", line 470: argument is incompatible with
prototype: arg #3

installed Ok. kill and restart daemon. (note: all this is done on the server
side, not the client)

from the client side: (reload the rsync tar so there is stuff in lib now)

 rsync -r /tmp/rsync-2.4.6/lib fdops3::marktg 21  /rsync.txt

I get the following immediately after the command:

 recv_generator: unlink lib: Not privileged
 recv_generator: unlink lib: Not privileged

nothing in /rsync.txt, server log lists all files transferred, then 'wrote
32 read 72750 size 72169' and 'transfer interrupted (code 102) at
main.c(433)'


Thanks,

Todd





Re: transfer interrupted, and Not privileged errors,

2000-11-08 Thread Martin Pool

On  8 Nov 2000, Todd Robinson [EMAIL PROTECTED] wrote:
  That's pretty strange, for two reasons: as far as I knew, everything
  ought to go to stderr, stdout, or the log file.  When you say
  "console", do you mean it comes out in your current window, or it goes
  to the actual VGA adapter/serial console of the server?
 
 In the current window the rsync was executed from, even if you redirect
 stderr someplace else.  For instance, I run something just like this:
 
   rsync -avvvz /tmp/rsync-2.4.6/lib fdops3::marktg 21 
/rsync.txt

Ah, OK.  This is because stderr is not actually redirected!

The construct 21 means ``send fd2 (stderr) to wherever fd1 (stdout)
is pointing *at the moment*''.  Since redirections are evaluated in
order left-to-right, this sends stderr to the terminal (probably where
it was already going), and then sends stdout to the file.  From the
bash man page:

   Note that the order of redirections is  significant.   For
   example, the command

  ls  dirlist 21

   directs  both  standard  output  and standard error to the
   file dirlist, while the command

  ls 21  dirlist

   directs only the standard output to file dirlist,  because
   the  standard  error  was  duplicated  as  standard output
   before the standard output was redirected to dirlist.

I still remember the `ah-ha!' moment when this sunk in a few years
ago.

Regards,
-- 
Martin Pool, Linuxcare, Inc.
+61 2 6262 8990
[EMAIL PROTECTED], http://www.linuxcare.com/
Linuxcare. Support for the revolution.

 PGP signature